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

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

Initialization is not a synthesizable construct. Hardware does not 
perform initialization. You are arguing that the P1800 LRM be changed 
to make deterministic a behavior that is not deterministic in real 
hardware. How can you say that the P1800 LRM value is not correct, 
when real hardware will not produce the perform the initialization
in the first place.

Initialization is a test bench concept, and the test bench would
like initialization to actually initialize variables in a deterministic
way before the simulation starts. The feed back I have gotten 
from the test bench people is they do not need events generated
for initialization, they just want it to take place before the
simulation starts so they can rely on it.


> -----Original Message-----
> From: shalom@fil.ea.freescale.net 
> [mailto:shalom@fil.ea.freescale.net] On Behalf Of 
> Shalom.Bresticker@freescale.com
> Sent: Tuesday, April 12, 2005 11:09 PM
> To: Mark Hartoog
> Cc: sv-bc@eda.org
> Subject: 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
> 
>