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.