RE: [sv-bc] Proposal on striking the 2 paragraphs

Mark,

The issue is not just 'always @' blocks, although that is by itself sufficient to require a change,
as the current 1800 text GUARANTEES that legacy code will not work correctly.
I am not discussing back-compatibility with 1364-2001 at all.
I mean that combinational logic written with 'always @' will not generate the correct values.

But the problem is equally with continuous assignments, port connections, and combinational UDPs.

And there IS a solution, which is to require evaluation of the combinational constructs, like 
always_comb, at time 0. 

If 2-state initializations do not generate events (although they could still be defined to do so),
then my Proposal B is the way to go.

"Proposal B: 

Activate always constructs at time 0, BEFORE both variable initializations and initial constructs. 
Variable initializers will still execute BEFORE initial constructs, but they WILL generate events. 
All the other combinational constructs will unconditionally execute at the
end of time-0 and then wait for events on their events, just as always_comb does now. "

It is true that this still does not solve the problem with 'always @' for 2-state variables,
but it does solve it for 4-state variables for 'always @', and it solves the problem for
both 2-state and 4-state variables for all the other combinational constructs.

With this proposal, 2-state logic will still work better than currently defined in 1800.

You yourself admit that with 4-state logic, the current definition does not work.

I think correctness needs to be the #1 criterion.
I don't need an efficient implementation which gives the wrong results. 
I don't need an efficient implementation which gives the wrong results with older code.
I don't need an efficient implementation which forces all my designers to remember 
intricacies of the LRM and to decide all the time whether initializers will work for them or not.

No one has yet refuted the claim that the current definition gives wrong results.

As a side note, why nothing has done on this in 1364:
There are (at least) two definitions of back-compatibility, and people are confusing them.
Assuming you have 1364 code, 
1. Are all legal 1800 executions of that code legal under 1364 as well?
2. Are all legal 1364 executions of that code legal under 1800 as well?
Usually, under other standards, you don't have this question of non-deterministic behavior
that becomes deterministic, so the question does not arise.
You could look at it as whether old code remains legal under 1800 vs.
whether old implementations remain legal.
In this case, old code remains legal, but old implementatiions do not.

The point is, I think a major consideration in not touching this under 1364 was to avoid 
making legal 1364-2001 implementations incompliant to 1364-2005.

1800 was considered a major revision of Verilog, so there was much less reluctance to make such a
change, it even has a different IEEE Std #. 1364-2001 to 2005 is just a relatively minor revision
of the same standard, and we did not want to invalidate existing implementations.

Shalom


On Tue, 12 Apr 2005, Mark Hartoog wrote:

> The other issue here is 2-state variables/wires and combinational logic. Even without
> initialization, 2-state variables are a problem at time zero. P1800 has 2-state variables, 1364 does
> not. The 1364 time zero initialization works ok for 4 state variables, but it just does not work at
> all for 2 state variables. The P1800 time zero initialization works with always_comb for both 4
> state and 2 state variables. The P1800 initialization/time zero behavior for 2 state or 4 state
> variables with traditional always @ blocks for combinational logic does not work very well, which is
> what the ballot issue is about.
> 
> Consider this example.
> 
> bit x, y, z;
> 
> always_comb y = ~x;
> 
> always @(x) z = ~x;
> 
> The problem here is that the default values of x, y, and z is 0. If the always_comb and always @(x)
> blocks are going to function as combinational logic, then y and z should transition to 1 at time
> zero, but there is no event to trigger either block.
> 
> With the P1800 time zero behavior all always_comb blocks run at time zero, and so y will correctly
> go to 1, but there is never an event to trigger the always @(x) block in either P1800 or 1364. 
> 
> With the 1364 time zero behavior, neither the always_comb or always @(x) blocks are triggered.
> 
> Short of forcing events on all 2 state variables after all always blocks are started, there is no
> way to extend the 1364 time zero behavior to work for 2 state variables. 
> 
> When we have discussed this in the past we concluded that the current P1800 time zero/initialization
> behavior is the best compromise between strict backwards compatibility with Verilog simulator
> implementations (it is technically compatible with the 1364-2001 LRM), efficiency at time zero and
> the new requirements of the P1800 language.

-- 
Shalom.Bresticker @freescale.com                     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