RE: [sv-ec] final block scheduling

The scheduling semantics of programs versus modules do not affect the
final block; it defines its own scheduling semantics outright. The only
difference would be the event that causes an implicit or explicit
$finish.

BTW, I believe that the 1364 committee was supposed to have the action
to define the empty event queue as an implicit call to $finish, but this
never happened. The other cases like $exit are defined to make an
implicit call to $finish.

When the 1364-2001 split statements into normal statements and
function_statements, it was more restrictive. I think 1364-2005 missed
fork/join non-blocking assignments, procedural-continuous assignments.

The final block was added to Superlog because of the DPI and for
coverage operations. When you move away from the PLI, you still need
some way of knowing when the simulation ends so the C-side can clean up.


Before covergroups were added to the language, people used existing data
types like associative arrays to do coverage and needed a final block to
dump that data out.

Dave


> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Clifford E. Cummings
> Sent: Wednesday, August 31, 2005 1:20 PM
> To: sv-ec@eda.org
> Subject: Re: [sv-ec] final block scheduling
> 
> Hi, All -
> 
> At 03:37 PM 8/29/2005, Steven Sharp wrote:
> >My opinion matches Arturo's and Gord's.  Once the last statement in
the
> >last final block executes, the simulator must exit.  Any $strobes
> scheduled
> >from the final blocks aren't going to happen.
> 
> If this becomes the prevailing opinion, then we should make any call
to
> $strobe from within a final block illegal.
> 
> >You might as well use $display instead of $strobe anyway.  You aren't
> going
> >to get any further changes to the signal values after the $display,
> because
> >the simulator will exit before those happen also.
> 
> $display misses nonblocking updates in the same timestep. I am
surprised
> at
> the number of very experienced Verilog users who don't know the
difference
> between $display and $strobe. $display is fine if it can be put in the
> same
> begin-end thread as the variables to be displayed but $strobe is
generally
> safer because it can be called from a parallel thread and catch the
final
> updated value. $display is also necessary in a 0-delay loop when you
are
> trying to display the most recent iteration of a loop variable.
> 
> >If you wanted to see what
> >the values would have been at the end of the cycle if you hadn't done
a
> >$finish, then you are going to have to wait until after the end of
the
> >cycle to do the $finish, just as you have been.  Final blocks aren't
> designed
> >to change that.
> 
> I thought final blocks were intended to fix this annoyance.
> 
> Best Known Methods suggest that final blocks be put into program
blocks
> and
> that they use the $display command. I believe ModelSim currently lets
me
> execute a $finish from either a module-initial-block or a
> program-initial-block and still execute final-blocks in the program
(this
> may not be correct for the module-initial-block per our recent
scheduling
> discussions??)
> 
> By using final blocks in program blocks, by using $display in the
final
> block, and by putting the $finish into a program block, I think I can
at
> least get the RTL nonblocking assignments to complete and get those
last
> updated values displayed in a reactive region without the #1 delays
that I
> use today. Thoughts??
> 
> >Note that the same issue would come up with a nonblocking assignment
in
> >a final block, which is similarly useless.  This gets ruled out
because
> >the 1364 LRM says that NBAs are illegal in functions.
> 
> Agreed. No nonblocking assignments allowed in final blocks.
> 
> >   It neglects to
> >make $strobe illegal in functions.
> 
> Which is why many engineers will try this and submit bugs to your
support
> groups (as I did with Mentor). Your support groups better get a
> template-response ready for this one or EDA vendors are going to spend
> lots
> of $$$ responding to these submissions.
> 
> >   There are probably other similar
> >cases.  For example, does the P1800 LRM say that fork/join_none is
> >illegal in functions?  This is another construct that technically
> produces
> >no blocking delay, but can schedule things off in the future (that
won't
> >ever happen if scheduled from a final block).
> 
> When I think of future event scheduling, I never think of future
events as
> being events scheduled into later event regions within the same time
step.
> I think most users would agree with this.
> 
> Per 1364-2005, section 11.3
> 5) Events that occur at some future simulation time. These are the
future
> events. Future events are
> divided into future inactive events, and future nonblocking assignment
> update events.
> 
> >Steven Sharp
> >sharp@cadence.com
> 
> Just a few more thoughts to consider.
> 
> 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
>