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

I was searching specifically for answers where the TB was in the program
code. I interpreted the 1800-2005 spec as stating what Jonathan said
about there being a race condition between the raw clock and TB inputs
if the program code indeed used the raw clock. There is a sub-clause
that specifically stated to not use the raw clock and to always use the
modified event.  I assumed this advice was for the race condition reason
that Jonathon pointed out.  Correct me if I am wrong and thanks for the
quick response. -Tom

-----Original Message-----
From: Gordon Vreugdenhil [mailto:gordonv@model.com] 
Sent: Monday, September 22, 2008 2:31 PM
To: jonathan.bromley@doulos.com
Cc: Alsop, Thomas R; owner-sv-ec@server.eda.org; sv-ec@server.eda.org
Subject: Re: [sv-ec] Clocking Blocks and #0 Semantics



jonathan.bromley@doulos.com wrote:
....
 > 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.


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"?

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.

I don't really consider that a race in the same sense as
a race between two active region processes triggered by
the same event.  From a design perspective, you do need
to be concerned about which way you are synchronizing
activity and do need to be very aware of mixing regions
and/or update assumptions, but I don't think there is
arbitrary choice with respect to a #0 input clockvar versus
program or module use.

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.

Gord
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.