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

The following mail from Mac bounced, because of a filtered phrase,
which I've tranformed from "exe" to "ee-eks-ee". -- Brad

-----Original Message-----

From: Michael McNamara <mac@verisity.com>
Message-ID: <16820.36808.166328.4141@gargle.gargle.HOWL>
Date: Mon, 6 Dec 2004 08:58:48 -0800
To: Shalom.Bresticker@freescale.com
Cc: sv-bc@server.eda.org
Subject: Re: [sv-bc] Errata: variable initializers don't match Verilog-2001
In-Reply-To: <Pine.GSO.4.10.10412061133320.1460-100000@eagle>
References: <200408312310.i7VNA9l28846@quicksand.Cadence.COM>
        <Pine.GSO.4.10.10412061133320.1460-100000@eagle>

While we are defining the Right Thing to Do, we should also consider
defining ordering between always block sensitization and time zero PLI
/ CLI.

This can be seen easily in the CLI; if you run a simulation executable
with a -s switch, which takes you to the command line interface, are
the always @(a) blocks sensitive, or insensitive?

module foo;
  reg a;
  always @(a) begin
    $display("At %d a is %b",$time,a);
  end
endmodule

Do you get:

% compile foo.v -o foo.ee-eks-ee
% foo.ee-eks-ee -s
1 > set a = 1
2 > #1
3 > .
At 0 a is 1
4 >

or:

% foo.ee-eks-ee -s
1 > set a = 1
2 > #1
3 > .
4 >

-- On Dec 6 2004 at 11:56, Shalom.Bresticker@freescale.com sent a message:
> To: sv-bc@eda.org
> Subject: "Re: [sv-bc] Errata: variable initializers don't match
Verilog-2001"
> I did not remember the issues here, since it was three months ago, and
> only yesterday did I have time to study the recent and previous mails.
>
> I think that first we should decide what is the Right Thing to do.
> Only afterwards to look at whether or not it is compatible with the past.
>
> I feel the claim presented by Jay Lawrence is legitimate.
>
> If there are implementations that "do it right", that does not prove that
> the LRM gets it right. In fact, if implementations have to do something
> additional to order for it to work, that is a sign that the LRM is not
> complete.
>
> I don't accept the approach of writing
> "If an event is needed, an initial block should be used to assign the
> initial values," unless there is no alternative.
>
> That is doing something which you know is going to cause problems
> and people are going to fall into traps.
>
> Cliff wrote on Sep 1:
>
> "I am pretty sure that at least xxx simulators (and perhaps all
simulators)
> execute initial blocks and now declaration initializations after all
> continuous assignments, gates, and always blocks become active, which is
> actually a pretty smart thing to do and probably should be codified."
>
> This is opposite from what appears now in the 1800 LRM, that declarations
> occur before always blocks.
>
> Cliff also wrote,
>
> "Is it time to specify that declaration initialization happens in the
time 0
> preponed region and then take the VHDL approach of requiring all
procedures,
> contiuous assignments and gates to evaluate once at time 0?"
>
> Stu suggested that these declaration initializations occur "during
> simulation time 0", although he left it as happening before initial and
> always blocks, which I think does not solve the problem.
>
> What Cliff writes about "always blocks" might not apply to all always
blocks.
> While it certainly applies to always_comb and always @*, it might not
apply
> to always_ff and always_latch, and maybe not to a general always.
>
> I previously noted that certain other constructs are equivalent to
> continuous assignments, and therefore should be treated the same way,
> namely always_comb, port connections, and combinational UDPs.
>
> It seems to me that the current Verilog and SystemVerilog specifications
are
> buggy and cause problems for the user. Implementations have to do special
> things not specified in the LRM in order for it to work as desired.
> It should not be that way. The LRM should get it right.
>
> I think Cliff's suggestion is the closest to being right and deserves
> serious consideration.
>
> Shalom
>
>
> On Tue, 31 Aug 2004, 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.
>
> --
> Shalom Bresticker Shalom.Bresticker @freescale.com
> Design & Verification 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 Mon Dec 6 09:22:58 2004