Blocking vs Nonblocking Assignments

Where the interviewer goes next. Open a node to practise that follow-up.

WhyWhat IfProve ItBreak ItCompareScale It

1. Blocking vs Nonblocking Assignments
2. WhyWhy Nonblocking Makes Process Order IrrelevantL1 Junior

   Two clocked always blocks read each other's outputs. Why does <= make the result independent of which block the simulator runs first?

   Reveal the Model Answer

   With <=, neither block changes a variable during the Active region; each only reads and schedules. Whichever block runs first, both read the same pre-edge values. The updates all land later, in the NBA region. With =, the first block to run changes its output before the second reads it. So the order decides the answer.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 With <=, neither block changes a variable during the Active region; each only reads and schedules. Key point 2 Whichever block runs first, both read the same pre-edge values. Key point 3 The updates all land later, in the NBA region. Key point 4 With =, the first block to run changes its output before the second reads it. Key point 5 So the order decides the answer.

   What Interviewers Listen For (Junior)

   A good junior answer walks through both orders of the two blocks. It shows they give the same values with <= and different values with =.

   Misconception

   "<= makes the simulator run all always blocks at the same instant."

   Processes still run one after another. The order stops mattering because no process sees another one's update until the NBA region.

   Source IEEE 1800-2017 §4.9.4, §4.7

   • Lesson 6.2Scheduling Regions and Nonblocking Updates
3. Break ItBreaking a Clocked Block with a Blocking TemporaryL1 JuniorL2 Mid-Level

   A clocked block computes tmp = a + b; and then sum <= tmp;. Another always block also reads tmp at the same edge. What can go wrong?

   always @(posedge clk) begin
     tmp = a + b;
     sum <= tmp;
   end
   always @(posedge clk) observed <= tmp;

   Reveal the Model Answer

   Inside the block the code is fine, because tmp is a local temporary. The bug is the second reader: it may run before or after the first block in the same Active region. So it sees either the old or the new tmp. Keep blocking temporaries local to their block, or declare them inside it. Share only flop outputs written with <=.

   1. The edge wakes botht=5 (illustrative)

      The rising edge at t=5 wakes the driver and the monitor. Both are now waiting to run in the Active region of the same time step.

      Follow the calls, values and waits

      1. call driver: Rising edge → Active region
      2. call monitor: Rising edge → Active region
   2. Order A: driver firstt=5 (illustrative)

      If the scheduler runs the driver first, rdata is already a1 when the monitor reads it. The monitor sees the new beat.

      Follow the calls, values and waits

      1. call run: Active region → Racy driver
      2. data rdata = a1: Racy driver → racy_bus pins
      3. call run: Active region → Raw monitor
      4. data reads a1: racy_bus pins → Raw monitor
   3. Order B: monitor firstt=5 (illustrative)

      If it runs the monitor first, the monitor reads 00, the value from before the edge. The standard allows both orders.

      Follow the calls, values and waits

      1. call run: Active region → Raw monitor
      2. data reads 00: racy_bus pins → Raw monitor
      3. call run: Active region → Racy driver
      4. data rdata = a1: Racy driver → racy_bus pins
   4. Move the write off the edget=5 to t=7 (illustrative)

      A drive through drv_cb with output skew 2 lands at t=7. At t=5 every reader sees 00, in any order, so the race is gone.

      More context

      The DUT reads the pins at the same edge, so it is exposed to the race in exactly the same way as the monitor.

      Follow the calls, values and waits

      1. data reads 00: racy_bus pins → Raw monitor
      2. data rdata = a1 at t=7: Racy driver → racy_bus pins

   Read the diagram as text

   • Rising edge: t=5: clk becomes 1
   • Active region: woken processes; order not specified
   • Racy driver: rdata = a1 after @(posedge clk)
   • Raw monitor: reads rdata after @(posedge clk)
   • racy_bus pins: rvalid, rdata

   • Rising edge → Active region: wakes both
   • Active region → Racy driver: runs
   • Active region → Raw monitor: runs
   • Racy driver → racy_bus pins: writes
   • racy_bus pins → Raw monitor: reads

   A result that depends on which process runs first is not a result. Remove the race; do not pick a winner.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Inside the block the code is fine, because tmp is a local temporary. Key point 2 The bug is the second reader: it may run before or after the first block in the same Active region. Key point 3 So it sees either the old or the new tmp. Key point 4 Keep blocking temporaries local to their block, or declare them inside it. Key point 5 Share only flop outputs written with <=.

   Half-Truth

   "Mixing = and <= in one clocked block is always illegal."

   The language allows it. A blocking temporary that only its own block reads is a common, safe pattern. The danger is a temporary that another process reads at the same edge.

   • Lesson 6.2Scheduling Regions and Nonblocking Updates
   • Lesson 6.7Debug Case: A Racing Monitor
4. Prove ItSolve 6.2.1: The Pipeline That Lost a StageSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 6.2.1

5. What IfA Testbench That Drives on the Sampling EdgeL1 JuniorL2 Mid-Level

   Asked once they say flops use <=

   The testbench does @(posedge clk) start = 1; and the DUT samples start in always_ff @(posedge clk). Sometimes the DUT reacts a cycle early. Why?

   // Testbench
   initial begin
     @(posedge clk) start = 1;
   end
   // DUT
   always_ff @(posedge clk) accepted <= start;

   Reveal the Model Answer

   The testbench process and the DUT flop wake on the same edge, in the same region, and their order is unspecified. If the testbench runs first, the DUT samples the new start on that same edge. That is a cycle earlier than real hardware would. Drive after the edge, through a clocking block or with <=, so the DUT always samples the pre-edge value.

   With a blocking write, q depends on which process runs first. With a nonblocking write, the DUT always sees the value from before the edge.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 The testbench process and the DUT flop wake on the same edge, in the same region, and their order is unspecified. Key point 2 If the testbench runs first, the DUT samples the new start on that same edge. Key point 3 That is a cycle earlier than real hardware would. Key point 4 Drive after the edge, through a clocking block or with <=, so the DUT always samples the pre-edge value.

   Half-Truth

   "Put #0 before the drive and the race is gone."

   #0 moves the process to the Inactive region. That works only until another process also uses #0. Then their order is unspecified again, and the result can differ between simulators.

   Source IEEE 1800-2017 §4.4.2.3; Spear & Tumbush, SystemVerilog for Verification (3rd ed.) ch. 4 p141

   Tool as Truth

   "It passes on our simulator, so the testbench is correct."

   Passing on one tool only shows one legal order. The standard allows either order, so the test can fail after a tool update.

   Source IEEE 1800-2017 §4.7

   • Lesson 6.3Clocking Blocks and Sampled Views
   • Lesson 6.7Debug Case: A Racing Monitor
   • Problem 6.7.1The Monitor That Saw the Future
6. Prove ItSolve 6.7.1: The Monitor That Saw the FutureSimulator-graded

   Show it, don't just say it: this Silicon Lab problem is graded by the simulator.

   Open Problem 6.7.1

7. CompareClocking Blocks vs Driving on the Falling EdgeL2 Mid-Level

   Compare a clocking block with driving stimulus on the falling edge as ways to avoid testbench races.

   Reveal the Model Answer

   Driving on the falling edge puts drives and samples in different time steps, so it is simple and race-free. But it only works for single-edge designs with a known duty cycle. A clocking block samples inputs just before the active edge (#1step, the Preponed region). It drives outputs after a set skew, so the testbench stays cycle-based on the real edge. Clocking blocks scale to agents and interfaces; falling-edge drives suit small directed benches.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Driving on the falling edge puts drives and samples in different time steps, so it is simple and race-free. Key point 2 But it only works for single-edge designs with a known duty cycle. Key point 3 A clocking block samples inputs just before the active edge (#1step, the Preponed region). Key point 4 It drives outputs after a set skew, so the testbench stays cycle-based on the real edge. Key point 5 Clocking blocks scale to agents and interfaces; falling-edge drives suit small directed benches.

   Spec Misquote

   "An input skew of #1step means one nanosecond before the edge."

   1step is one unit of the time precision, not one nanosecond. The sample is taken in the Preponed region, so it reads the values from just before the edge.

   Source IEEE 1800-2017 §14.4, §4.4.2.1

   • Lesson 6.3Clocking Blocks and Sampled Views
8. What IfReading a Clockvar After the Raw EdgeL2 Mid-Level

   Asked if they write a monitor with clocking blocks

   A monitor waits for @(posedge clk) and then reads cb.rdata. It sometimes reports the previous beat. What happened?

   clocking cb @(posedge clk);
     default input #1step;
     input rdata;
   endclocking
   initial forever begin
     @(posedge clk);
     $display("rdata=%h", cb.rdata);
   end

   Reveal the Model Answer

   Clockvars (the sampled signals of a clocking block) are updated when the clocking event is processed, in the Observed region. A process that resumes on the raw posedge clk can read cb.rdata before that update. It then gets the previous sample. Wait on @(cb) instead, so the read happens after the clockvars change.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Clockvars (the sampled signals of a clocking block) are updated when the clocking event is processed, in the Observed region. Key point 2 A process that resumes on the raw posedge clk can read cb.rdata before that update. Key point 3 It then gets the previous sample. Key point 4 Wait on @(cb) instead, so the read happens after the clockvars change.

   • Lesson 6.3Clocking Blocks and Sampled Views
   • Problem 6.3.1The Monitor That Read the Next Beat
9. Scale ItKeeping a Large Testbench Race-FreeL3 SeniorL4 Staff

   You lead verification for a block with several UVM agents. How do you keep the testbench-to-DUT boundary race-free across the whole team?

   Reveal the Model Answer

   Every agent touches the DUT only through clocking blocks in its interface. Drivers write clockvars with <=, and monitors wait on the clocking event and read sampled values. No class code reads or writes raw DUT signals at an edge. Assertions sit in the interface or are bound to the DUT. Lint rules catch blocking writes in clocked blocks, and reviews treat raw signal access in a driver as a defect.

   Self-Check

   Tick each key point you covered in your answer.

   Key point 1 Every agent touches the DUT only through clocking blocks in its interface. Key point 2 Drivers write clockvars with <=, and monitors wait on the clocking event and read sampled values. Key point 3 No class code reads or writes raw DUT signals at an edge. Key point 4 Assertions sit in the interface or are bound to the DUT. Key point 5 Lint rules catch blocking writes in clocked blocks, and reviews treat raw signal access in a driver as a defect.

   Half-Truth

   "Add #1 delays to the drivers until the tests pass."

   A #1 means different times under different time precisions, and it breaks once gate delays appear. It hides the race instead of removing it.

   Source Spear & Tumbush, SystemVerilog for Verification (3rd ed.) ch. 4 p141

   Wrong Altitude

   A senior answer that lists UVM classes but never says where sampling happens.

   At this level the interviewer wants the mechanism and the team rule, not the class names.

   • Lesson 6.3Clocking Blocks and Sampled Views
   • Lesson 6.7Debug Case: A Racing Monitor