RE: [sv-bc] Errata: variable initializers don't match Verilog-2001

All,

Personally, I do not feel that the backward compatibility issue is really an
issue at all. LRM 3.1a Section 5.4 says:

"In SystemVerilog, setting the initial value of a static variable as part of
the variable declaration (including static
class members) shall occur before any initial or always blocks are started,
and so does not generate an
event. If an event is needed, an initial block should be used to assign the
initial values."

The LRM already resolves this issue. If the design is dependent on a time 0
event, then use an initial procedure instead of in-line initialization.

On the hand, SystemVerilog's rules for in-line initialization do ensure
race-free conditions between in-line initialization and time zero
assignments to a variable. Consider the following overly simplified
example:

  bit foo; // 2-state type starts simulation with a 0
  bit bar = 1; // 2-state type starts simulation with a 1 -- or does it?

initial foo = bar;

At the end of time zero, according to Verilog-2001 rules, foo could have
either a 0 or 1. SystemVerilog ensures that foo will have a value of 1. If
any of my code triggers on a transition on foo, Verilog rules mean my design
might or might not trigger (foo might or might not transition from 0 to 1 at
time 0). With SystemVerilog, I am guaranteed that there will be a positive
edge on foo at time 0. SystemVerilog rules for in-line initialization are
intuitive, and, in my opinion, the only right way simulation should behave.

I think there is a simple compromise that will make everyone happy --
except, perhaps, companies that already implemented in-line initialization
according to the SV 3.0, 3.1 and 3.1a standard. However, this compromise is
functionally fully backward compatible with both Verilog-2001 and all
versions of SystemVerilog.

I suggest that the fourth paragraph of Section 5.4 be changed FROM:

"In SystemVerilog, setting the initial value of a static variable as part of
the variable declaration (including static
class members) shall occur before any initial or always blocks are started,
and so does not generate an
event. If an event is needed, an initial block should be used to assign the
initial values."

TO (all caps used only to emphasize changes):

"In SystemVerilog, setting the initial value of a static variable as part of
the variable declaration (including static
class members) shall occur DURING SIMULATION TIME ZERO, before any initial
or always blocks are started."

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Jay Lawrence
> Sent: Wednesday, September 01, 2004 1:27 PM
> To: Brad.Pierce@synopsys.com; Shalom Bresticker
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Errata: variable initializers don't
> match Verilog-2001
>
>
> The new initialization semantic does create a backward compatibility
> problem as described below:
>
> The argument made in favor of this change is that it simply makes the
> use of variable initialization in a procedural context deterministic.
> This argument has nothing to do with why we believe this is a
> nonbackward compatible change. The problem with this change of
> initialization is that in the Verilog-2001 method an event is
> generated.
> In the SystemVerilog method, no event is generated. This
> difference has
> a severe impact on gate-level models and the behavior of continuous
> assignments, not procedural contexts as argued.
>
> Consider the following example:
>
> module init;
> integer var_i = 1; // A variable with an initial value
> wire [31:0] wire_i; // A wire
>
> assign wire_i = var_i; // Continuously assign the wire
> the variable's value
>
> initial #1 $display("wire_i is %d\n", wire_i); //
> display the wire
> endmodule
>
> In Verilog 1364, the initial value on var_i is guaranteed to
> produce an
> event. This event is critical because it causes the continuous
> assignment to the wire wire_i to execute. Without this event, the
> continuous assignment does not execute at time 0 and therefore the
> initial value of the variable would not propagate to the wire, leaving
> the wire at the default value of 32'bz. The exact same problem would
> occur if a gate were substituted for the continuous assignment above.
>
> In Verilog 1364 the code snippet above would produce a 1 on
> the wire_i,
> in SystemVerilog a 32'bz would be produced. This is not a trivial
> problem. The vast majority of Verilog modules have this style of code
> wherein an internal value is calculated and stored in a register and
> then the value is propagated either through a continuous assignment,
> buffer, or port onto a wire. Any of these forms of interconnect would
> not propagate the initial value in SystemVerilog. This would
> cause most
> devices to propagate the default value of 'z' on a wire
> instead leading
> to catastrophic simulation failures.
>
> Jay
>
> ===================================
> Jay Lawrence
> Senior Architect
> Functional Verification
> Cadence Design Systems, Inc.
> (978) 262-6294
> lawrence@cadence.com
> ===================================
>
> >-----Original Message-----
> >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> >Behalf Of Brad Pierce
> >Sent: Wednesday, September 01, 2004 1:04 PM
> >To: Shalom Bresticker
> >Cc: sv-bc@eda.org
> >Subject: RE: [sv-bc] Errata: variable initializers don't match
> >Verilog-2001
> >
> >Shalom,
> >
> >As in well known, Verilog-2001 variable initializations are
> >nondeterministic. For example, a is not necessarily initialized
> >before the initial block in the following
> >
> > module test;
> > reg a = 1;
> > reg b;
> > initial b = a + 1;
> > endmodule
> >
> >so b is not guaranteed to get a value of 2.
> >
> >This follows from sections 6.2.1, 3.2.2, and 9.9, which say
> >
> > Variable declaration assignment is a special case of procedural
> > assignment as it assigns a value to a variable. It allows
> >an initial
> > value to be placed in a variable in the same statement
> >that declares
> > the variable.
> >
> > If a variable declaration assignment is used, the
> >variable will take
> > the value as if the assignment occurred in a blocking
> >assignment in
> > an initial construct.
> >
> > The initial and always constructs are enabled at the
> beginning of
> > a simulation. The initial construct shall execute only once and
> > its activity shall cease when the statement has finished. ...
> > There shall be no implied order of execution between initial and
> > always constructs. The initial constructs need not be scheduled
> > and executed before the always constructs.
> >
> >The original SystemVerilog 3.0 donation from CoDesign fixed this
> >problem by eliminating the nondeterimism --
> >
> > Variable declaration assignments are initialized before any
> > initial constructs.
> >
> >This is totally backward compatible, because, obviously, no design
> >that already works under Verilog-2001 will be broken by the
> elimination
> >of the nondeterminism.
> >
> >In SystemVerilog, the example above is guaranteed to assign b an
> >initial value of 2.
> >
> >-- Brad
> >
> >
> >-----Original Message-----
> >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org]On Behalf Of
> >Shalom Bresticker
> >Sent: Wednesday, September 01, 2004 4:51 AM
> >To: Steven Sharp
> >Cc: sv-bc@eda.org
> >Subject: Re: [sv-bc] Errata: variable initializers don't match
> >Verilog-2001
> >
> >
> >What was this referrring to?
> >
> >Shalom
> >
> >
> >Steven Sharp wrote:
> >
> >> This is well known, but has not been addressed in P1800.
> >>
> >> The semantics of variable initializers in SystemVerilog do
> >not match the
> >> semantics defined in Verilog-2001. This is even explicitly
> >acknowledged
> >> in the LRM.
> >>
> >> Steven Sharp
> >> sharp@cadence.com
> >
> >--
> >Shalom Bresticker Shalom.Bresticker
> >@freescale.com
> >Design & Reuse Methodology Tel: +972
> >9 9522268
> >Freescale Semiconductor Israel, Ltd. Fax: +972
> >9 9522890
> >POB 2208, Herzlia 46120, ISRAEL Cell: +972
> >50 5441478
> >
> >[ ]Freescale Internal Use Only [ ]Freescale Confidential
> >Proprietary
> >
> >
> >
> >
> >
>
>
>
Received on Wed Sep 1 18:31:49 2004