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

From: Brad Pierce <Brad.Pierce@synopsys.com>
Date: Fri Dec 03 2004 - 18:58:08 PST

According to 3.5.3 of (15 May 2003)

    http://www.eda.org/sv-ec/SV_3.1_Web/SVChairsChampionsResponse.pdf

-------
The latest example ... seems to imply that in order for the evaluation
of a continuous assignment, an event on the RHS must be generated,
including at time 0. However, a continuous assignment does not require
an event on its RHS. For example:

    module init;
      wire w;
      assign w = 1;
      initial #1 $display( "wire is %b", w );
    endmodule

The code above must also show '1' as the value of wire w, and no
event is generated by the constant 1.

At least two separate implementations of the SystemVerilog initialization
semantics exist and both are 100% backward compatible with respect to
continuous assignments.
--------

-----Original Message-----
From: Jay Lawrence [mailto:lawrence@cadence.com]
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 Fri Dec 3 18:56:39 2004

This archive was generated by hypermail 2.1.8 : Fri Dec 03 2004 - 18:56:46 PST