Re: [sv-ec] final block scheduling

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.

I believe that Arturo's opinion is in line with mine -- once
$finish occurs, the current thread terminates immediately, no
futher 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.  However, what I think is
pretty definite is that once a $finish is evaluated, no futher
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.
> 
> 	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