RE: [sv-bc] Sampling semantics in clocking blocks

Gordon Vreugdenhil wrote:

> I absolutely agree that the behavior of #0 input skew needs
> to be more clearly defined with particular care paid to
> the implications of potential races.

Thanks for your response.

Personally I think it's worse than that.  I suspect that "input #0"
should not be permitted at all, or should be mapped to "input #1step",
because there is a violent discontinuity between the sampling semantics
of "input #0" and any other value: any other value whatever will report
the sampled value of signals as they were *before* the action of 
a clock, whereas "input #0" reports the sampled value of signals
*after* the clock edge has taken effect, if the DUT being sampled 
is a zero-delay RTL model.  

What, for example, would happen if we ask for "input #1ps" and then 
set the timestep to 1ns?  Presumably, #1ps is then rounded-down to #0.  
Consequently, merely changing the timestep has shifted the sampling 
point effectively by a whole clock cycle.

> My understanding is that the update 
  [of the resampled value of an "input #0" signal in a clocking]
> happens in the Observed
> region.  This is a bit problematic since there is an assumption
> that there is value stability upon entry to the observed region

I agree

> and that assumption is not correct for input #0 clocking block
> variables.  Having an assertion read a value like M.C.q is definitely
> an issues since there is a race with the assertion evaluation.

I don't fully understand this, though.  Assertions *execute* in the
Observed region but they evaluate sampled values *captured* in the
Preponed region.  So I don't think there is a race between "input #0"
and assertions, unless the assertions do some very bizarre things.
I do, however, suspect that the results could be highly counter-
intuitive; at the timestep of an active clock edge, assertions 
will report/sample the pre-clock value of signals captured
by "input #0" in a clocking, even though the definition of
"input #0" suggests sampling of the post-clock value.

> Unfortunately, I don't think that changing the update time to
> NBA or Active helps that much since other kinds of races
> show up in those cases.  I think that a reasonable solution
> would be the clarify that input #0 skews are defined to update
> in the observed and to disallow and observed region reading
> of such clocking block variables.  Still not great, but
> at least it would be defined.

It isn't only "input #0" that worries me.  I simply don't 
see in the LRM any definition of how and when the resampled
(clocking-block member) input signals are updated, nor of when
clocking-block member output signals are sampled.  I am fairly
sure that there is some implied assumption about the way the
whole thing operates, but that implied assumption is quite
opaque to me - and, as I've pointed out, tool implementors
seem to disagree about it.
-- 
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 e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.