Assertion-based verification basics in Verilog - Time & Space Complexity

Time Complexity: Assertion-based verification basics

O(n)

Understanding Time Complexity

When we use assertions in Verilog, we want to check if certain conditions hold during simulation.

We ask: how does the time to check these assertions grow as the design or input size grows?

Scenario Under Consideration

Analyze the time complexity of the following assertion code snippet.

    property p_check;
      @(posedge clk) disable iff (!reset) (data_in == expected);
    endproperty
    
    assert_p_check: assert property (p_check);
    

This code checks on every clock edge if the input data matches an expected value, ignoring checks when reset is low.

Identify Repeating Operations

Assertions run repeatedly during simulation cycles.

• Primary operation: Checking the condition (data_in == expected) every clock cycle.
• How many times: Once per clock cycle during active simulation.

How Execution Grows With Input

The number of checks grows directly with the number of clock cycles simulated.

Input Size (n)	Approx. Operations
10 cycles	10 checks
100 cycles	100 checks
1000 cycles	1000 checks

Pattern observation: The work grows linearly as simulation time increases.

Final Time Complexity

Time Complexity: O(n)

This means the time to check assertions grows in a straight line with the number of clock cycles.

Common Mistake

[X] Wrong: "Assertions only run once and do not add to simulation time."

[OK] Correct: Assertions are checked every relevant event, so their cost adds up over many cycles.

Interview Connect

Understanding how assertions impact simulation time helps you write efficient verification code and shows you think about design performance.

Self-Check

"What if we added multiple assertions checking different signals each cycle? How would the time complexity change?"

Practice

1. What is the main purpose of an assertion in Verilog verification?

easy

A. To declare variables for testbench

B. To generate synthesis code for hardware

C. To automatically check if a condition is true during simulation

D. To optimize the design for speed

Solution

1. Step 1: Understand what assertions do

   Assertions are used to check if certain conditions hold true automatically during simulation.

2. Step 2: Differentiate from other Verilog constructs

   Assertions do not generate hardware or declare variables; they only verify behavior during simulation.

3. Final Answer:

   To automatically check if a condition is true during simulation -> Option C

4. Quick Check:

   Assertions check conditions automatically [OK]

Hint: Assertions check conditions during simulation automatically [OK]

Common Mistakes:

• Confusing assertions with synthesis code
• Thinking assertions declare variables
• Assuming assertions optimize hardware

2. Which of the following is the correct syntax to write a simple immediate assertion in Verilog?

easy

A. assert property (signal == 1'b1);

B. assert(signal == 1'b1);

C. assert property signal == 1'b1;

D. assert(signal = 1'b1);

Solution

1. Step 1: Recall immediate assertion syntax

   The correct syntax for a simple immediate assertion is 'assert (condition);'.

2. Step 2: Check each option for syntax correctness

   assert(signal == 1'b1); matches the immediate assertion syntax. assert property (signal == 1'b1); uses 'assert property' which is for concurrent assertions. assert property signal == 1'b1; misses parentheses after 'property'. assert(signal = 1'b1); uses assignment '=' instead of comparison '=='.

3. Final Answer:

   assert(signal == 1'b1); -> Option B

4. Quick Check:

   Immediate assertion syntax: 'assert (condition);' [OK]

Hint: Immediate assertions use 'assert (condition);' with '==' for comparison [OK]

Common Mistakes:

• Using 'assert property' for immediate assertions
• Missing parentheses around condition
• Using '=' instead of '==' for comparison

3. Given the assertion: assert property (@(posedge clk) (data != 0)); What happens if data is zero at a clock edge during simulation?

medium

A. The assertion ignores the zero value

B. The assertion passes silently

C. The simulation stops immediately without message

D. The assertion fails and reports an error

Solution

1. Step 1: Understand the assertion condition

   The assertion checks at every positive clock edge that 'data' is not zero.

2. Step 2: Analyze what happens if 'data' equals zero

   If 'data' is zero at a clock edge, the condition 'data != 0' is false, so the assertion fails and reports an error.

3. Final Answer:

   The assertion fails and reports an error -> Option D

4. Quick Check:

   Assertion fails if condition is false at check time [OK]

Hint: Assertion fails if condition is false at check time [OK]

Common Mistakes:

• Thinking assertion passes when condition is false
• Assuming simulation stops silently
• Believing assertion ignores failures

4. Identify the error in this assertion code snippet:

assert property @(posedge clk) (reset == 1'b0);

medium

A. Incorrect use of 'assert property' without parentheses around condition

B. No error, the assertion is correct

C. Using '==' instead of '=' for comparison

D. Missing parentheses around the clock event

Solution

1. Step 1: Check assertion syntax for event and condition

   The correct syntax requires parentheses around the entire property expression, including the event and condition.

2. Step 2: Identify missing parentheses

   The code misses parentheses around '@(posedge clk) (reset == 1'b0)', which is required for 'assert property'.

3. Final Answer:

   Incorrect use of 'assert property' without parentheses around condition -> Option A

4. Quick Check:

   'assert property' needs parentheses around event and condition [OK]

Hint: Always wrap event and condition in parentheses after 'assert property' [OK]

Common Mistakes:

• Omitting parentheses around event and condition
• Confusing '=' with '=='
• Assuming no parentheses needed for event

5. You want to verify that a signal valid remains high for exactly 3 clock cycles after it goes high. Which assertion best captures this behavior?

hard

A. assert property (@(posedge clk) valid |-> valid ##1 valid ##1 !valid);

B. assert property (@(posedge clk) valid |-> ##3 valid);

C. assert property (@(posedge clk) valid |-> ##1 valid ##1 valid ##1 !valid);

D. assert property (@(posedge clk) valid ##3 valid);

Solution

1. Step 1: Understand the requirement

   The signal 'valid' must stay high for exactly 3 clock cycles after it goes high, then go low.

2. Step 2: Analyze each assertion

   assert property (@(posedge clk) valid |-> valid ##1 valid ##1 !valid); uses '|->' implication and timing control to check 'valid' at current cycle, then stays high for 2 more cycles, then low at the 4th cycle, matching exactly 3 cycles high.

3. Step 3: Eliminate incorrect options

   assert property (@(posedge clk) valid |-> ##1 valid ##1 valid ##1 !valid); checks 4 cycles high (3 ##1 delays plus !valid at 4th). assert property (@(posedge clk) valid |-> ##3 valid); checks only after 3 cycles, not duration. assert property (@(posedge clk) valid ##3 valid); lacks implication operator and timing control.

4. Final Answer:

   assert property (@(posedge clk) valid |-> valid ##1 valid ##1 !valid); -> Option A

5. Quick Check:

   Use '|->' with timing to check exact cycle count [OK]

Hint: Use '|->' and timing controls to check exact cycles [OK]

Common Mistakes:

• Confusing number of cycles with delays
• Missing implication operator '|->'
• Incorrect timing control syntax