Re: [sv-ec] final block scheduling

Thanks to Arturo, Gord, Dave and Steve for their replies.

Let me expound further. Notes below.

First let me say that if the final block does indeed block additional 
events from being scheduled and completed in the current time step, that 
$strobe commands will never execute and we should at least make them 
illegal within a final block or within a function that is referenced by a 
final block.

One could argue that $strobe within a final block should only be a warning 
because someone could code a function that is called both outside and 
inside of a final block, but I still think it should be an error to let 
engineers know that the $strobe command will never mature inside of a final 
block. This would force engineers to code two different functions, one that 
can be called outside a final block and one that could be called from a 
final block.

I have spent hours trying different final-block configurations and calling 
schemes to try to get my $strobe commands to work. I would like to save 
other engineers from making these futile attempts.

I also was asleep when this final-block section changed from SV3.1 to 
SV3.1a. SV3.1 used to list:

After one of the following conditions occur, all spawned processes are 
terminated, all pending PLI callbacks are canceled, and then the final 
block executes.
- The event queue is empty
- Execution of $finish
- Termination of all program blocks, which executes an implicit $finish
- PLI execution of tf_dofinish() or vpi_control(vpiFinish,...)

Starting with SV3.1a and P8100, we now just list:

Final blocks execute when simulation ends due to an explicit or implicit 
call to $finish.

Does "implicit call to $finish" include all of the previous conditions, 
plus more?

More below.

At 08:39 PM 8/26/2005, Gordon Vreugdenhil wrote:
 >
 >Just to clarify here -- I don't think that I claimed to Cliff
 >that final blocks are reactive (I certainly couldn't find such
 >a claim in the email history).  This is a good thing because
 >they don't execute in the reactive region or really in any
 >region.  In Cliff's specific example, the process containing
 >the $finish is reactive so the NBA in the module is guaranteed
 >to mature prior to the $finish being encountered in the
 >reactive process.
 >
 >Certainly once a $finish is encountered no further activity
 >occurs in the sequential block nor can any activities be
 >scheduled.  It could be open for discussion whether pending
 >scheduled activities should be permitted to mature, historically
 >that hasn't been permitted and I suspect that this would be
 >more confusing than helpful in general.

This has always been true in Verilog and it has also always been the 
problem. It's too late now, but if $finish had been scheduled into a 
post-postponed event region when Verilog was first invented (finish after 
all events in the current time step have completed), we would have no need 
for a final block. As things stand now, I typically put a #1 in front of my 
$finish to get all activity completed and reported before terminating 
simulation (this is rather ugly in a cycle-based simulation environment).

The problem today is that $finish executes in the active events regions and 
races against all other end-of-simulation wrap-up and $display commands.

I had hoped that the presence of a final block would change the behavior of 
a $finish to allow all pending events (and even new events created within 
this same time step) to complete and then terminate simulation before 
advancing simulation time.

This is still fully backward compatible if you do not use final blocks, but 
it does give different $finish-behavior if final blocks are introduced (in 
my opinion, this is a very favorable change and one that design & 
verification engineers would applaud).

 >I believe that Arturo's opinion is in line with mine -- once
 >$finish occurs, the current thread terminates immediately, no
 >further actions are scheduled or permitted to mature, and the final
 >blocks are run.  Clearly there is enough room in the interpretation
 >of the spec that activities such as continuous assign updates
 >that would be activated from the sequential block prior to the
 >$finish may or may not mature.  In fact, any pending same-region
 >activity may or may not mature since that is up to the simulator's
 >decisions about thread interleaving.

I guess I would have to agree that this interpretation is valid, but ugly. 
We are now introducing a whole new set of race conditions, which is what I 
thought we were solving with the final block.

Again, re-reading the very terse (and now obviously ambiguous definition) 
of a final block:

10.7 Final blocks
The final block is like an initial block, defining a procedural block of 
statements, except that it occurs at the end of simulation time and 
executes without delays.
A final block is typically used to display statistical information about 
the simulation.

This sounded like the fix to the $finish-race that we have tolerated forever.

 >However, what I think is
 >pretty definite is that once a $finish is evaluated, no further
 >action in that thread is permitted and no further region changes
 >occur.  The only possible activity would be activity that the
 >simulator *could have* scheduled prior to the $finish being
 >executed.
 >
 >Gord.
 >
 >
 >
 >Arturo Salz wrote:
 >>Cliff,
 >>I'm not sure whether a final block should execute in the Reactive region, or
 >>execute as a function that is called from within $finish. However, I do
 >>believe that if the final block creates additional events then those events
 >>should not be allowed to mature (i.e. execute). I suspect this what you are
 >>observing when you execute your example: the $strobe calls are essentially
 >>posting events into the Postponed region, which are never executed.

The problem is that most engineers do not even understand the different 
event regions and event scheduling. It is very poorly taught in most 
training classes and it is not even touched in many "professional" and 
university training classes.

Engineers who do understand event scheduling understand that there are 
multiple event regions that are executed before advancing simulation time, 
so when the spec talks about executing all events at the end of simulation 
time, we think of all events in the same timestep as the final block, 
without advancing simulation time.

Gord once asked if my interpretation meant that commands after the $finish 
should also be executed, something that Verilog does not do today. I could 
go either way on this one. For ease of implementation, I could say yes. 
99%+ of all Verilog code written does not include any commands after the 
$finish and if somebody does this, I would be willing to say "figure it out!"

You have all given answers that address our knowledge of event scheduling 
and events being placed in separate event regions. This is not common 
knowledge among engineers and will be hard for most engineers to pick up. 
It would be a whole lot easier to teach engineers that final blocks execute 
at the end of the simulation time step and that any procedural assignments 
in a final block do not trigger any other procedural activity. This would 
be trivial to teach and understand (I have a feeling that I am not going to 
get the trivial solution and that I will be teaching multiple exceptions to 
statement execution regarding final blocks :-)

Regards - Cliff

 >>      Arturo
 >>-----Original Message-----
 >>From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Clifford
 >>E. Cummings
 >>Sent: Friday, August 26, 2005 5:08 PM
 >>To: sv-ec@eda.org
 >>Subject: [sv-ec] final block scheduling
 >>Hi, All -
 >>I have attached a final block example that I have run on ModelSim. I 
don't think it is working yet on VCS (forgive me if this is a 
mis-representation).
 >>The example did not work as I expected.
 >>10.7 Final blocks
 >>The final block is like an initial block, defining a procedural block of 
statements,
 >>except that it occurs at the end of simulation time and executes without 
delays.
 >>A final block is typically used to display statistical information about 
the simulation.
 >>
 >>Based on this definition, I thought I could put $strobe commands into a 
final block
 >>and have the strobes execute before simulation finished. Gord and I have 
exchanged
 >>email messages on this and he believes the final block should execute in 
the
 >>Reactive region(s), and complete the $finish before the $strobes can 
execute in
 >>the postponed region. I wanted to see the $strobed results too since I 
frequently
 >>$strobe final simulation results (then do a #1 $finish; - I have always 
hated the #1
 >>in front of the $finish and I thought the final block could get me away 
from this
 >>ugly extra delay).
 >>Opinions? The final block can have any command currently legal in a 
function, but
 >>if $strobe is never executed in a final block, then it should be an 
error to avoid final-
 >>block-usage confusion.
 >>Regards - Cliff
 >>----------------------------------------------------
 >>Cliff Cummings - Sunburst Design, Inc.
 >>14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
 >>Phone: 503-641-8446 / FAX: 503-641-8486
 >>cliffc@sunburst-design.com / www.sunburst-design.com
 >>Expert Verilog, SystemVerilog, Synthesis and Verification Training
 >>
 >>
 >>--
 >>--------------------------------------------------------------------
 >Gordon Vreugdenhil                                503-685-0808
 >Model Technology (Mentor Graphics)                gordonv@model.com
 >
 >----------------------------------------------------
 >


----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training