RE: [sv-ec] Mantis 890 Question - ##1 at time-0??

I was just about to type up my reply: I agree that there is no race.

My position has always been that clocking blocks could be just as useful
for design IP as well as verification IP. Also, one persons design
component is another's verification component. Plus, you can't expect
everyone to throw out their entire module based environment and change
everything to program blocks.

So it's good that we now have well defined semantics for using clocking
blocks in any situation. The only thing the user needs to be cognizant
of is how they get into their cycle-based environment.

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Wednesday, March 28, 2007 1:34 PM
> To: Neil.Korpusik@Sun.com; Clifford E. Cummings
> Cc: sv-ec@server.eda.org
> Subject: RE: [sv-ec] Mantis 890 Question - ##1 at time-0??
> 
> Cliff, Neil:
> 
> Neil Korpusik wrote:
> > I don't think your question is specific to time 0. Instead,
> > it is a question
> > about the reliability of using ## cycle delays within code
> > that executes in the Active region set.
> 
> I could easily be wrong, but I thought we had sorted this out.
> My understanding is that ##1 is indistinguishable from @(cb),
> and we have agreed that cb's implied event is triggered in
> the Observed region.  Consequently, it races neither with
> Active nor with Reactive code.  All that's required is that
> you are conscious of the relationship between your code's
> execution and the timeslot's passage through Observed.
> 
> In the following description I assume
> 
>   default clocking cb @(something);
> 
> and I refer to "something" as the clocking block's
> "source event" because I want to distinguish it from
> the clocking block event @cb.
> 
> If Active code does ##1 in the same timeslot (and even in
> the same pass through Active) as the clocking block's source
> event occurs, then @cb will be fired in the subsequent Observed
> region of that same timeslot.  Consequently we can reliably
> expect the Active ##1 to stall, but it will reliably
> be released *in the same timeslot* because @cb in Observed
> will put the code following ##1 back into Active.  Of course
> that will cause the outer scheduling loop to spin back to
> Active, but the resulting second pass through Observed won't
> do anything unless Bad Stuff happens and we get the clocking
> block's source event fired more than once in the same timeslot.
> 
> By contrast, if we do ##1 in Reactive code but the clocking's
> source event occurs in Active of the same timeslot, we can
> assume that the clocking event @cb has already fired
> in the preceding Observed region, before execution hits the
> ##1, so the delay will wait until the *next* clocking event.
> 
> Having said all that, my sympathies are with Neil's position:
> if we use a clocking block in any way other than the canonical
> scheme (event fired in Active, do ##N and manipulate clockvars
> in Reactive) the behaviour is confusing and perhaps undesirable.
> I'm not entirely sure why there is so much enthusiasm for
> exploring the use of clocking blocks in these non-standard ways.
> The 890 changes make it possible for us to predict the behaviour
> in such situations, but that doesn't necessarily make the
> behaviour useful.
> --
> Jonathan Bromley, Consultant
> 
> DOULOS - Developing Design Know-how
> VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW,
> UK
> Tel: +44 (0)1425 471223                   Email:
> jonathan.bromley@doulos.com
> Fax: +44 (0)1425 471573                           Web:
> http://www.doulos.com
> 
> This e-mail and any  attachments are  confidential and Doulos Ltd.
> reserves
> all rights of privilege in  respect thereof. It is intended for the
use of
> the addressee only. If you are not the intended recipient please
delete it
> from  your  system, any  use, disclosure, or copying  of this
document is
> unauthorised. The contents of this message may contain personal views
> which
> are not the views of Doulos Ltd., unless specifically stated.
> 
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.