>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 18:34:17 2004
This archive was generated by hypermail 2.1.8 : Wed Dec 08 2004 - 18:34:28 PST