RE: [sv-ec] Clocking blocks: terminology and clarifications

 

> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com] 
> Sent: Thursday, September 21, 2006 5:39 PM
> To: Warmke, Doug; sv-ec@eda.org; jonathan.bromley@doulos.com
> Subject: RE: [sv-ec] Clocking blocks: terminology and clarifications
> 
> 
> >From: "Jonathan Bromley" <jonathan.bromley@doulos.com>
> 
> >Once we accept that they are different, we must specify
> >how C.L is updated.  Doug did so very clearly in SV-890-2
> >(update for clause 15.12) - this appears as part of a 
> >description of the special behavior of #0 sampling, but 
> >I assume it's intended to apply to any clocking input:
> >
> >  when the clocking event occurs, the sampled value 
> >  shall be updated and available for reading the 
> >  instant the clocking event takes place and before 
> >  any other statements are executed.
> >
> ...
> >I have a big, big problem with this stipulation that the 
> >updating take place before any other statements are executed.
> 
> I also have a big problem with this stipulation.  I think it
> is a completely inappropriate constraint on event ordering.
> It is questionable enough that the LRM allows interleaving
> of procedural code with other processes.  If such interleaving
> were actually done in practice, it would become impractical
> to write code that worked.  To *require* such interleaving
> of processes is inappropriate.

Well, the cat's already out of the bag with covergroup
sampling here.  But as I wrote to Jonathan, this precise
stipulation is not critical, as long as the basic ordering of
operations is guaranteed to be correct, predictable, and useful.

> 
> The stipulation also seems to assume that clocking events
> will always be created by the execution of statements, and
> read by other statements.  It seems to ignore the possibility
> of clocking events driven by nets or by clocking outputs.  Also,
> if clocking events can be expressions, then those must be evaluated
> to determine whether an event has taken place.  Trying to specify
> how that is done would again be getting into inappropriate areas.
> I would guess that if the "solution" offered by this proposal
> does not account for these more general situations, then it is
> not a general solution.

It wasn't the intent to assume clocking events would always
be created by the execution of statements.  I agree that other
constructs (continuous assigns, gates, force, etc.) can drive
clocking events.  I don't really think any of that matters, though.
The existing stipulation was based on the precedent of covergroup
sampling.  All the same issues exist there, and they have proven
tractable in at least one implementation.

When we get into program blocks soon (the new 1604), maybe we can
head in the direction of saying that continuous assigns and gates
are actually "region-free" constructs, and simply are scheduled to
evaluate as they always have been.  That would mean no requirement
to schedule them onto the reactive list if you are currently in
the active region, as you have to do when scheduling program
constructs such as ##1 statements.

Regards,
Doug



> 
> 
> Steven Sharp
> sharp@cadence.com
> 
>