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

Shalom,

I think everyone whom I have heard an opinion is in agreement that all
combinational constructs (continuous assignments, combinational
primitives, etc) must all have executed at least once before the end of
time 0. The reason this issue is being sent to 1364 is because the
problem is the same for constants as well as 2-state variables
introduced by P1800. The problem with constants has been there since the
beginning of Verilog.

Adding this to 1364 LRM can not be backwards-incompatible because there
is nothing written in the LRM to be incompatible with.

Regarding initialization of variables, I think you need to be more
precise when you say "does not work" or "is not correct". If you are
talking about the 'correctness' of combinational constructs -
initialization is not a part of combinational correctness because it is
not a generally accepted synthesizable construct.

If you are worried about designers not having to remember intricacies of
the LRM, then trying to write code that depends on the ordering of
threads is not a good solution. The LRM has been clear from day one that
the ordering of always and initial blocks is not deterministic. 

There should be no semantic difference between

always block_of_code;

and

initial forever block_of_code


They both create concurrent threads of execution and the only difference
between the two is that the always construct can never be disabled
(die). If you want thread ordering, you should be using an explicit
construct like an event control to control the ordering.

Basically, if you are using SystemVerilog, you should not be using
always. You should be using one of always_comb, always_latch, or
always_ff

Dave




> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] 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
>