Assertion-based verification basics in Verilog - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the result of this assertion check?

Consider the following SystemVerilog assertion inside a testbench:

assert property (@(posedge clk) disable iff (reset) (data_in == 8'hFF));

What happens if data_in is 8'h00 when reset is low and a clock edge occurs?

Verilog

assert property (@(posedge clk) disable iff (reset) (data_in == 8'hFF));

A The assertion fails because data_in is not 8'hFF when reset is low.

B The assertion passes because reset disables the check.

C The assertion is ignored because data_in is 8'h00.

D The assertion triggers a runtime error due to invalid data_in value.

💡 Hint

Remember that 'disable iff (reset)' disables the assertion only when reset is high.

The assertion checks that data_in equals 8'hFF at every positive clock edge unless reset is active (high). Since reset is low and data_in is 8'h00, the assertion fails.

❓ assertion

intermediate

Which assertion correctly checks a signal toggles every clock cycle?

You want to verify that signal sig toggles its value on every positive edge of clk. Which assertion correctly expresses this?

A assert property (@(posedge clk) sig === $stable(sig));

B assert property (@(posedge clk) sig == $past(sig));

C assert property (@(posedge clk) sig != $past(sig));

D assert property (@(posedge clk) sig != sig);

💡 Hint

Use $past to compare the current and previous value of the signal.

The assertion checks that at every positive clock edge, the current value of sig is not equal to its previous value, meaning it toggles.

🔧 Debug

advanced

Why does this assertion never fail?

Given the assertion:

assert property (@(posedge clk) disable iff (reset) (req |-> ##1 ack));

where req and ack are signals, why might this assertion never fail even if ack is not asserted after req?

A Because the disable iff clause disables the assertion permanently.

B Because the implication operator '|->' only checks when req is true, and if req is never true, assertion never triggers.

C Because the clock is not defined, so the assertion is ignored.

D Because ack is checked at the wrong clock edge.

💡 Hint

Consider when the antecedent of the implication is true.

The '|->' operator means the assertion only checks the consequent if the antecedent (req) is true. If req never becomes true, the assertion never fails.

🧠 Conceptual

advanced

What is the main purpose of 'disable iff' in assertions?

In assertion-based verification, what does the 'disable iff' clause do?

A It forces the assertion to always check regardless of conditions.

B It enables the assertion only during reset.

C It resets the assertion counters when the condition is false.

D It disables the assertion check when the specified condition is true.

💡 Hint

Think about when you want to ignore assertion failures.

'disable iff (condition)' disables the assertion check whenever the condition is true, commonly used to ignore checks during reset.

❓ framework

expert

Which UVM component is responsible for checking assertions during simulation?

In the Universal Verification Methodology (UVM) framework, which component typically handles assertion checking and reporting?

A uvm_report_server

B uvm_monitor

C uvm_agent

D uvm_scoreboard

💡 Hint

Consider where assertion failures are collected and reported.

The uvm_report_server collects and manages all reports including assertion failures during simulation.

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