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.

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.


Steven Sharp
sharp@cadence.com