Forwarding another email from jonathan.bromley -------- Original Message -------- Date: Thu, 28 Jul 2005 08:24:09 -0700 (PDT) From: "Jonathan Bromley" <jonathan.bromley@doulos.com> To: "Gordon Vreugdenhil" <gordonv@model.com>, <sv-bc@server.eda.org> Cc: <sv-ec@server.eda.org> 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. -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------Received on Thu Aug 4 16:18:21 2005
This archive was generated by hypermail 2.1.8 : Thu Aug 04 2005 - 16:18:24 PDT