On SystemVerilog Scheduler-1
Behind the grand scheme of things…
You have written a SystemVerilog/Verilog code.
It compiles. Awesome.
Simulate the code.
“PASS” flashes on the screen. What could be better?
How does the simulator conspire to get you that output? Where do blocking and non-blocking statements fit? Is the HDL code really a concurrent implementation? What is the funda behind those “good HDL coding practices”?
This set of articles answers above questions from a simulator scheduler’s perspective.
The scheduler of a simulator decides how to efficiently execute program statements. Who comes after who?
Simulation Time
Time is relative. The simulator’s notion of time is different from ours. Like various scales of time we use, the simulator has it’s timescale, smallest unit called a time slot. A set of events might be listed for each time slot. For an event based simulator, time moves only if all events supposed to happen at that time slot are done. Hence, simulator’s one time slot takes several units of our time and each slot might not take the same amount of our time (Profound and kinda difficult to grasp at first!)
Event Regions
Every time slot has a set of regions. Different types of statements (scheduled for the slot) are executed at different regions of the same slot.
Now, why do we do this?
Remember that old dude in class telling you HDLs are meant to parallelise? The scheduler does only ONE thing at a time (but does it really really well :P). These regions help it wear the disguise of parallelism. By spreading statements across these regions, the scheduler eliminates possible simulator race conditions (When all of those parallel assignments simultaneously bombard our poor scheduler’s fort) .
And, this is precisely where the army of “good coding practices” arrive to the scheduler’s aid. They deliberately divert various statements to different regions and the scheduler calmly takes them as they come, thus giving it some breathing space.
Let’s look at this in more detail.
SV Event Regions
The official SV reference manual talks of 17 event regions in each time slot. But let’s look at it from a higher abstraction. Largely, the regions can be split as shown below:
Preponed region: Assessing the fort’s situation before any attacks in the particular time slot. This read-only region is used for assertions and sampling.
Active region set: The RTL code assignments are the first to greet the scheduler.
Observed region: Assessing damage caused by the RTL assignments. This evaluates the assertions sampled in the preponed region.
Reactive region set: Here come the verif code assignments to take on the scheduler.
Postponed region: Final damage assessment of the fort before we move to the next time slot. Used by $monitor, $strobe functions.
Point to be noted is the complex iteration of army reinforcements that might come from RTL and verif code assignments in the same time slot! The scheduler stolidly goes over every single one of those iterations before moving on to the next time slot.
Further, the “Active” and “Reactive” region sets are split as shown:
Active/Re-Active: They are most enthusiastic for the onslaught with scheduler. The following things happen here:
• Execute all module blocking assignments.
• Evaluate the Right-Hand-Side (RHS) of all nonblocking assignments and schedule updates into the NBA region.
• Execute all continuous assignments
• Evaluate inputs and update outputs of Verilog primitives.
• Execute the $display and $finish commands.
Wondered why all combinational assignments are said to be blocked? So that they fall into the active region and model real hardware behaviour.
Inactive/Re-inactive: They are second in line and contain #0 blocking assignments (More on this while we see example codes).
NBA/Re-NBA : The last in line and consist of the LHS updates to variables with NBA (whose evaluation happened in the active/re-active region)
All sequential logic assignments generally go here in order to exhibit correct pipelined nature.
A consolidated event region diagram will look like this:
(Source: SystemVerilog Event Regions, Race Avoidance and Guidelines by Clifford. E.Cummings, Arturo Salz)
Let’s stop here. In the next article, we’ll articulate more on this with some lucid examples.
The link to next article is here.
Meanwhile, this PDF would be an interesting read for the curious folks.