Re: [sv-ec] Clocking Blocks and #0 Semantics

Gord

> Hmmm - if you write your TB as a module I think the above is
> correct in the sense that the TB can see the old (preponed)
> value of the input clockvar versus a new value computed
> by the DUT.  If the TB is a program then the TB should be scheduled
> in the re-active region and the input clockvars should have
> already been updated.  But is that really a "race"?

I completely agree; if the TB is a program (or, to be nit-picky,
if the TB does its clock wait in a thread whose ultimate 
parent is a program) then its clock wait will wake up in 
the Reactive region, by which time it is certain that all 
input clockvars have been updated.  In that case it does
not matter whether the program waits on @(posedge clock)
or @(clocking_block_name).

I had silently assumed that the TB might be in a module,
since a lot of people are now using the Mantis 890 changes
as a reason/excuse to avoid the use of program blocks
altogether.

> Tom's specific question was related to #0 input skews and
> I don't think there are any real races there; it's just that
> there are two cases to consider.  If the TB is in the active region
> the TB will see the clock strictly before the #0 input clockvars
> are updated (since they are updated in the Observed region);
> if the TB is in the re-active region, it will see the clock
> strictly after the #0 input clockvar updates.

Again I completely agree; any race between the clocking block
updating its input clockvars and the TB reading those clockvars
has nothing to do with whether you use input#0 sampling.  But
the mere fact that input#0 sampling is possible means that
the updating of clockvars is _potentially_ delayed until the
very end of the Observed region, which (in my experience) 
tends to provoke the kind of question that Thomas asked.

> BTW, all of the above relies on the assumption that the
> "clock" is well behaved and doesn't change in the reactive
> region of the current time and feed back into the DUT; ie.
> that the "clock" changes in first round of evaluation of
> the active region for a time and doesn't glitch/change later.
> That particular issue was discussed and was agreed
> to be such pathological behavior that no one wanted to
> try to deal with that.

Again, fully agreed.  I'm sure Tom's designs don't have
anything as unpleasant as glitchy clocks :-)
-- 
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 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.