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

Dave,

On Wed, 13 Apr 2005, Rich, Dave wrote:

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

So what is the problem to say explicitly that they execute like always_comb?
In concept, they are exactly the same.
It is a problem if they will execute before initializers and then 
initalizers will not create events.
I agree that we can separate between 'always @' and the other combinational
constructs.


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

I agree that the problem has been there since the beginning.
But I have not heard that the issue is being sent to 1364.
I only heard that Brad asked why it is not being sent to 1364.


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

Adding what?
That the combinational constructs must execute at time 0?
I would probably agree to that.

But 1364 also says that initializers do create events
(and I think they should, but I have no problem with initializers
executing before initial constructs, nor does anyone else.)


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

What about testbench code?
What about a non-synthesizable model?
What if a synthesis tool supports it tomorrow,
e.g, for a variable which never changes, like a constant?

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

But now you break that by saying that on the one hand, initializers gets
executed first, but on the other hand, they don't create events, so my
always block executes afterwards, but still doesn't see the initialization.
That is a recipe for sure confusion.


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

Forever is not synthesizable.
I can write dozens of always blocks in parallel.
With forever, I have to choose fork-join which is much less readable
code.
Simulators don't do the same optimizations on forever.


> 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

What about legacy code?
Or, a project which writes design using Verilog-1995 or Verilog-2001
but uses SystemVerilog for verification? The entire thing then runs 
under SystemVerilog.

Etc.

'Always' is just not going to go away!

I still don't understand why not to fix it.
Why is it so bad to fix it???

I would also not be too worried about "time 0 efficiency".
Time 0 is just one time point, even if it does affect the entire model.
Considering the time taken up by compilation and elaboration,
execution of the design reset and intialization sequence, and 
execution of the rest of the simulation, I don't think a little difference
in time 0 efficiency is too significant. 

I would much rather have the execution semantics be more intuitive.
Remember the Priniciple of Least Surprise!

Shalom

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