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

Thomas,

I'm sure others can reply more authoritatively than I, but here's my take 
on 
the situation as clarified in the 1800-2009 drafts (see Mantis 890 and 
1604).

> My understanding of the LRM is that for testbench (TB) inputs, when 
> I use programs and clocking blocks (CB), I am guaranteed to avoid 
> race conditions.  If I have two signals coming from my DUT into my 
> TB, one of which is a clock and the other of which is a non-clock 
> input, how is this guaranteed to not be a race condition if I am 
> using #0 on this non-clock input signal?  If the non-clock input 
> signal is seen in the observed region, this means that the clock and
> the non-clock input are seen at the same time in the TB and would 
> hence be a race.

You get some protection from this (draft 7, clause 14.13):

Upon processing its specified clocking event, a clocking
block shall update its sampled values before triggering
the event associated with the clocking block name.

The clock signal is not itself made available through the clocking block.
Rather, the CB makes available a modified version of the clocking event,
@(clocking_block_name), with the extra guarantee that this modified 
event is certain to be emitted after all the input clockvars (sampled
clocking_block_name.signal values) have been updated with the
results of that cycle's sampling.  This is true even if you use #0 input
(of which more below).  However, if you trigger some TB code 
directly on the clock transition using something like 
@(posedge clock), then your TB code may execute before the
input clockvars have been updated by the clocking block - and
you have races.

> Would I be correct in assuming that had I not had a CB, that there 
> really would be a race condition with the clock and the non-clock 
> input? 

Not necessarily; it depends on how the non-clock signal was updated by the
clock.  Clocking blocks allow you to free yourself from that "it depends" 
and
get some certainty, but ONLY if you are scrupulously careful to avoid 
using
the raw clock signal or clock event in your TB; you MUST use only the 
clocking-block event to synchronize your TB activity.

> Would I also be correct in assuming that by virtue of using 
> a CB and putting the non-clock input in it, that the non-clock input
> will be seen by the rest of the TB program code _after_ the clock 
> event of the clocking block?

Yes; see my LRM quote above.

Post-script on input#0:  Although the behavior of input#0 is
pretty well defined now, I still regard it as a disaster waiting
to happen.  If your DUT has no non-zero delays in its clocked
signal updates, then input#0 gives you the next-state value
of DUT signals.  Introduce even the very slightest non-zero
time delay into the DUT, and suddenly your input#0 sampling
will give you the current-state value of any DUT signal that is
so delayed.  That doesn't sound very robust to me, especially 
when you consider that many RTL designers choose to 
introduce small NBA intra-assignment delays in order to 
model clock-to-output delay more realistically in their RTL.
So I have publicly stated my extreme distaste for input#0,
and will do so again whenever I get the chance.
-- 
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.