Re: [sv-bc] RE: [sv-ac] sampled assertion function vs data types - refereing to prior simulation

>From: Gordon Vreugdenhil <gordonv@model.com>

>It may not be viable to get agreement on that in this round,
>if indeed agreement could ever be achieved.  Changes in such
>areas can require substantial time to try out in practice before
>reaching agreement in the standard.  Although such issues
>typically only show up in the presence of time 0 races (which aren't
>healthy in any case), customers tend to be quite unhappy about
>*any* such change in a particular simulator's behavior, particularly
>if they have designs that have worked for a long time with a
>given behavior.

In addition to changes in time 0 race behavior, there is the issue
of whether a given simulator's algorithm will even correctly
initialize a simulation without using the initial values it was
designed around.  That is rather more important than this assertion
issue.  I agree with Gord that this is an area where vendors will
be reluctant to change.


>I think that it would (likely) be reasonable to rely
>on preponed time 0 net state to be *either* x or z, but I really
>doubt that consensus would be reached on which one.  I wouldn't
>even count on having a single answer within a particular simulator
>(i.e. don't even assume that all nets will in fact be initialized
>in the same manner).

I believe that Verilog-XL initializes nets to z if they have no
drivers, and to x if they have any drivers (which creates the oddity
that a net driven with a constant z behaves differently from one that
is undriven).  There may be some other special cases that I don't know
about.  Then it has to jump through some hoops to get the simulation
initialized properly in some cases.  It is likely that some other
implementations have tried to match XL closely.  So it is likely
that a mix of x and z may occur in some implementations.

From the implementations that I know about, assuming x or z seems
reasonable.  And in most expressions they behave the same way.

There might be exceptions for things like supply nets.

Steven Sharp
sharp@cadence.com


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