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

> You again talk about having variables be initalized in a 
> deterministic way.
> I have no argument with that. The proposal is no less deterministic.

The proposal B requires procedural always blocks to execute before 
"initialization" of variables takes place. I don't think that is
initialization. Initialization should take place before any code 
executes.

You seem to be arguing that "initialization" is a shorthand for a 
procedural assignment that takes place sometime at time zero, and 
it is ok if some procedural code executes before that assignment. 

If you really want to make a procedural assignment at time zero, you 
can do that from an initial block. There is no other language feature
to allow an assignment that is guaranteed to take place before
any procedural statement. I think the language needs to guarantee 
that all variable have their initial values before any line of 
procedural code executes.


> -----Original Message-----
> From: shalom@fil.ea.freescale.net 
> [mailto:shalom@fil.ea.freescale.net] On Behalf Of 
> Shalom.Bresticker@freescale.com
> Sent: Wednesday, April 13, 2005 10:24 PM
> To: Mark Hartoog
> Cc: sv-bc@eda.org
> Subject: RE: [sv-bc] Proposal on striking the 2 paragraphs
> 
> Mark,
> 
> I am not talking about synthesizability. Verilog is not just 
> synthesizable logic.
> HW descriptions are not only synthesiazable models.
> Besides which, I can and do have testbench constructs driving 
> my design.
> Nearly everyone does that.
> Combinational always@ blocks are not used only in 
> synthesizable models.
> 
> You again talk about having variables be initalized in a 
> deterministic way.
> I have no argument with that. The proposal is no less deterministic.
> 
> I am a user, both a designer and a verifier, and I say I do need it.
> 
> I still don't see the objection.
> 
> At most, you say you don't see the need for it, but you don't 
> present an argument to say that it is a problem.
> 
> Shalom
> 
> 
> On Wed, 13 Apr 2005, Mark Hartoog wrote:
> 
> > > 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.
> 
> -- 
> 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
>