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

Steven,

You're correct about always_comb executing "once at time zero, after
all initial and always blocks have been started." I had forgotten that.

(Strictly speaking, that might not be enough. 1364-2001 5.4.2 says,
"At any time while evaluating a behavioral statement, the simulator may suspend execution and place the partially completed event as a pending active event on the event queue. The effect of this is to allow the interleaving of process execution."
I did not see a statement in SV that contradicts that.
So an initial or always block might be started, then suspended,
then an always_comb executed, then the initial or always block continued.
But that is a digression.)

If we activated all the always blocks, but including always_comb, at the start
(and the other stuff
we talked about, like continuous assignments, port connections, etc.)
and then did the initializations, wouldn't that be enough?
And then there would be no need to treat always_comb specially?
Conceptually, it does not make sense to treat always_comb and always @*
and continous assignments differently.

Shalom

On Thu, 9 Dec 2004, Steven Sharp wrote:

>
> >Date: Thu, 9 Dec 2004 23:35:47 +0200 (IST)
> >From: Shalom.Bresticker@freescale.com
>
> >When you write that always constructs should 'execute' before initial blocks
> >and initializations at time 0, that term 'execute' could be misunderstood.
>
> Yes, misunderstandings about how always blocks are defined to work are
> widespread enough that I should be careful to be clear.
>
> >You mean if you have
> >
> >always @(a or b) or always @(posedge clk), then you enter the always
> >and start waiting on the @(a or b) or @(posedge clk).
>
> Yes. The goal in executing the always blocks first is to get them
> to reach the event control and start waiting there, so that if an
> initial block causes one of those events, the always block will
> be ready to respond.
>
> The grouping in these partial examples might mislead someone into
> thinking the event controls are somehow associated with the always,
> when in fact they are associated with the statement that follows
> the event control. This is part of the most common misunderstanding
> about always blocks.
>
> Executing the always block means to start executing the statement
> inside the always block (which might be a sequential block). And
> in these cases, the statement is preceded by an event control, so
> execution would immediately suspend to wait for the event to occur.
> If the statement were not preceded by an event control, execution
> would continue until it reached an event control or delay control.
>
> > For always_comb, you
> >mean to wait on the implicit sensitivity list.
>
> No, at least not the way you probably mean it.
>
> The simplest way to view an always_comb, with its requirement to
> execute the body once at time zero, is to recognize that this is
> equivalent to putting the event control at the *bottom*, instead
> of the top.
>
> A typical Verilog combinational always block is coded like
>
> always @(a)
> b = ~a;
>
> which happens to be semantically equivalent to
>
> initial
> forever begin
> @(a) b = ~a;
> end
>
> A SystemVerilog always_comb, coded like
>
> always_comb
> b = ~a;
>
> is semantically almost equivalent to
>
> initial
> forever begin
> b = ~a;
> @(a);
> end
>
> Notice that here the event control appears at the bottom of
> the loop implied by the always_comb. This means that it will
> execute the always block body once before it starts waiting for
> input changes. It is much like the difference between a while loop
> and a do-while loop. The fancy wording about "triggering once at
> time zero" just comes down to this change in the position of the
> implicit event control from the top to the bottom.
>
> The reason I wrote "almost equivalent" instead of "equivalent", is
> that always_comb also has a special rule requiring it to execute
> *after* all of the initial and always blocks. This rule is not
> actually needed to make it behave like combinational logic. Putting
> the event control at the bottom is sufficient to ensure that it will
> behave correctly from time zero. If it executed before the initial
> blocks, the worst that could happen is that evaluates again if an
> initial block changes an input. And if it really is combinational
> logic, that should not cause any harm.
>
> So anyway, executing an always_comb would not involve immediately
> waiting on the implicit "sensitivity list" or event control. It
> would involve executing all of the statement inside the always_comb,
> and then waiting on the implicit event control at the bottom. But
> an always_comb doesn't need to be executed before initial blocks
> anyway. It could be executed then, or when SystemVerilog says it
> must be executed, and it will still work like combinational logic.
>
> However, Verilog combinational always blocks, when coded the usual
> way with the event control at the top, only work properly when inputs
> change at time zero, if they start executing before the input changes.
> It is the only way to make them act the way so many people believe
> they do: sensitive to their inputs from the very start of simulation.
>
> Steven Sharp
> sharp@cadence.com
>

-- 
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