Introduction

In Part 1, Alice learned:

• what assertions are
   

• immediate vs concurrent assertions
   

• why timing checks need assertions
   

Now interviewers push further.

They don’t ask what assertions are —
they ask how exactly time is checked.

This article exists to make temporal assertions feel logical, not magical.

 

What Is a Temporal Assertion?

​

A temporal assertion in SystemVerilog checks relationships between signal values across multiple clock cycles using implication operators and sequences.

In short:

• not “is it true now?”

• but “does this happen after that?”
   

 

Alice & Bob Mental Model (Very Important)

• Alice defines a timeline rule

• Bob watches signals across clock edges

• If the timeline rule is violated, Bob flags it
   

Think of Alice saying:

“Whenever I see X, I expect Y later.”

That expectation is the assertion.

 

The Two Most Important Operators: |-> and |=>

These two operators appear in almost every interview.

Understanding them removes 80% of confusion.

 

|-> — Overlapping Implication

Meaning in Plain Language

A |-> B Means:

If A is true in this cycle,
then B must be true in the same cycle or later, depending on B.

Most commonly:

• A and B are checked in the same clock tick
   

 

Example — Same-Cycle Check

property req_grant_overlap;

  @(posedge clk)

    req |-> grant;

endproperty

 

assert property (req_grant_overlap);

 

Meaning:

• whenever req is high

• grant must also be high that same cycle
   

 

Where This Is Used

• combinational handshakes

• valid–ready protocols

• same-cycle guarantees
   

 

|=> — Non-Overlapping Implication

Meaning in Plain Language

A |=> B Means:

If A is true in this cycle,
then B must be true in the next cycle

This is the most common form in protocols.

 

Example — Next-Cycle Response

property req_grant_next;

  @(posedge clk)

    req |=> grant;

endproperty

 

assert property (req_grant_next);

 

Meaning:

• if req is high now
   

• grant must be high on the next clock
   

 

​

 

Sequences — Describing Behavior Over Time

Alice now wants to describe patterns, not just single events.

Example:

• req stays high for 2 cycles

• then grant appears

That’s a sequence.

 

Simple Sequence Example

sequence req_two_cycles;

  req ##1 req;

endsequence

 

Meaning:

• req is high

• and stays high in the next cycle
   

 

Using the Sequence in an Assertion

property req_then_grant;

  @(posedge clk)

    req_two_cycles |=> grant;

endproperty

 

assert property (req_then_grant);

 

This reads naturally:

If req stays high for two cycles, grant must come next.

 

Why Sequences Matter (Interview Depth)

Sequences let Alice:

• describe protocols

• describe timing relationships

• avoid procedural state machines
   

Interviewers often ask:

“Why not just write logic?”

Correct reasoning:

Assertions separate checking from implementation.

 

disable iff — Ignoring False Failures

Alice now faces a real-world issue.

During reset:

• signals are meaningless

• assertions should not fail
   

She tells Bob:

“Ignore everything while reset is active.”

 

Example — Assertion with Reset

property req_grant_reset;

  @(posedge clk)

    disable iff (!rst_n)

    req |=> grant;

endproperty

 

assert property (req_grant_reset);

 

Meaning:

• assertion is inactive when reset is low
   

• no false errors
   

 

Interview Trap (Very Common)

Q: What happens if you forget disable iff?

Correct answer:

Assertions may fail during reset and create false negatives.

This shows practical experience.

 

Common Assertion Failure Flavors (Situations)

Alice commonly writes assertions to catch:

• request without response

• response without request

• signal changing when it shouldn’t

• protocol violations

• reset misuse

Assertions are not “extra” — they encode design intent.

 

Immediate vs Concurrent — Why Both Exist (Revisited)

• immediate assertions → value correctness
   

• concurrent assertions → temporal correctness
   

Interviewers sometimes ask:

“Why not only concurrent?”

Answer:

Immediate assertions are simpler and cheaper for local checks.

 

Common Interview Traps (You Can Now Avoid)

• confusing |-> and |=>

• forgetting the clock

• missing disable iff

• assuming assertions drive signals

• thinking assertions replace testbenches
   

Assertions observe, they don’t act.

 

Interview Questions Now Answerable

• Difference between |-> and |=>?

• Why are sequences needed?

• What does disable iff do?

• Why are assertions clocked?

• Can assertions replace checkers?
   

If you can explain these, you’re strong.

 

One Sentence to Remember (Interview Friendly)

Temporal assertions describe what must happen after an event, not just what is true now.


Next Article: Coverage