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