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

I believe we should define what shall happen just before the big bang
of simulation; that the time has come to remove this useless
ambiguity.

1: when execution begins, all of the wires are z and all of the
registers are x. There is darkness on the land.

2: All processes that are in the active region are executed, and hence
become sensitized to any changes to the values of registers and wires.

  For Cliff's benefit, :-) given:

  always @ (a) begin // p1
    b = a;
    @c; // p2
    d = c;
  end

we have two processes, one (p1) which starts out in the active region,
and will execute if 'a' changes in value; and one (p2) that starts out
inactive, but when activated, will execute when c changes.

3: at this point any tf_misc routines are called with
reason_begin_of_simulation, and the pli can execute, and the cli can
execute.

4: then the initial blocks are executed, in no particular order, and
an organized chaos emerges, transforming the values of the wires and
registers in the familiar dance we all recognize as SIMULATION!!!

-mac

-- On Dec 8 2004 at 21:34, Steven Sharp sent a message:
> To: sv-bc@eda.org, Shalom.Bresticker@freescale.com
> Subject: "Re: [sv-bc] Errata: variable initializers don't match Verilog-2001"
>
> >Date: Mon, 6 Dec 2004 11:56:25 +0200 (IST)
> >From: Shalom.Bresticker@freescale.com
> >
> >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."
>
> I suspect that the execution of (most) always blocks before initial blocks
> may be the result of a common optimization. The fact that combinational
> always blocks will generally fall into this category gives a nice benefit
> in event ordering. It ensures that the always blocks will respond to the
> initializers and have correct combinational output values starting from
> time zero. Some simulators might execute all always blocks before initial
> blocks to get this benefit. The 1364 LRM does not guarantee this, but it
> allows it.
>
> >This is opposite from what appears now in the 1800 LRM, that declarations
> >occur before always blocks.
>
> Which means that the 1800 LRM is forbidding simulators from using the
> order that makes Verilog combinational always blocks work properly.
>
> >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?"
>
> This could be done for continuous assignments and gates (and SystemVerilog
> always_comb blocks), but not Verilog always blocks. How can you define
> what it means to "evaluate an always block" when they can contain event
> controls and delay controls at arbitrary places, and the language semantics
> require the processes to wait at those specific points in the code? What
> does it mean to "evaluate" it, if there is an event control halfway down
> the block? Do you just ignore all event controls during this "evaluation",
> which could violate the existing language definition and break existing
> code? Do you treat an event control at the beginning differently from
> ones elsewhere, making the definition inconsistent? I think that Cliff
> has been using only synthesizable always blocks for so long that he has
> forgotten that the Verilog language allows anything else.
>
>
> >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.
>
> Yes, those can be dealt with by requiring them to evaluate once at
> time zero. But Verilog combinational always blocks are just a subset
> of general always blocks, and should behave consistently with how those
> are defined. There isn't a way to define "evaluation at time zero" for
> always blocks in general.
>
> I think the best thing you can define for them is to require them to
> execute before initial blocks (and initializers) at time zero. And the
> P1800 LRM actually forbids that.
>
>
> Steven Sharp
> sharp@cadence.com
Received on Wed Dec 8 21:36:20 2004