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