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

Hi Jonathan, Further clarification wanted below.  Thanks, -Tom

 

-----Original Message-----
From: jonathan.bromley@doulos.com [mailto:jonathan.bromley@doulos.com] 
Sent: Monday, September 22, 2008 12:47 PM
To: Alsop, Thomas R
Cc: owner-sv-ec@server.eda.org; sv-ec@server.eda.org
Subject: 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.

[Alsop, Thomas R] So this is going to the root of my question.  I have a
clock which is the event that _triggers_ the CB.  Is this stating that
upon entering the ReActive region the _first_ thing that happens is this
CB gets triggered?  And that upon triggering the CB two things happen.
First all the variables inside the CB, which you refer to as clockvars,
do their sampling.  This will be either from the Postponed region of the
previous time slot (1Step which is default) or from the Observed region
(#0 override).  Second it will create another event, which we you call
the "modified event", or the @(clocking_block_name), which is also short
scripted and used at the ##<number_of_cb_events>.  In essence, when I
run my program block, all the input values will be the new sampled
values because I am using the modified event as my trigger everywhere
that needs it. Did I get that right? If that is right, it basically
eliminates a race condition between the clock input to the TB and the
inputs from the DUT if I make sure I don't use the real clock event of
the CB anywhere in the program. I think you mention this below.

 

> 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.

[Alsop, Thomas R] Yes, you mention it here.  I am safe if I don't use
the "raw" clock signal.

 

> 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.

[Alsop, Thomas R] Okay, I'm not entirely sure that I agree with this so
convince me.  In my mind I have this picture of a DUT driving out
combinational logic relative to a specific clock and the TB reacting to
the change in that time slot.  I picture the TB having a clock and
driving logic from that clock too.  If I use #1step, then I am getting
old data.  Or to put it another way, I am getting delayed or flopped
data as inputs to my TB relative to the DUT.  You convinced me above
that if I use CB's, I am not going to see race conditions on my input
clock and input from DUT paths, even if I use #0.  Why would I want to
model an additional flop in the DUT to TB path that's really not there?
And to help you in your argument, we actually use #1 delays in our RTL
to fix some rare race conditions.  So let's say I'm sampling one of
these #1 delay values in my TB using #0 in my CB.  Does this just mean I
will not get this sampled value until the next timeslot? If I have 50
timeslots that represent a clock phase in the design, does it matter?
In the current timeslot I'll just miss the #1 anomalies, but they will
rectify themselves in the next timeslot which is way before my next
clock change.

 

Thanks for your help Jonathan!! -Tom

 

-- 

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.