RE: [sv-bc] SVDB 1619 Examples

Cliff,

It is still not a similar situation.

A variable declaration assignment is a one-time assignment of a value to
a signal. Whether it occurs exactly as an initial block or precedes the
initial block is irrelevant. It is an operation which does not have a
physical equivalent in normal digital circuitry. At the very least, you
need a reset signal to be activated.

The default is something entirely different. It models a fixed physical
connection to VCC or VDD. It is fixed as elaboration time. It is really
no different than determining a parameter value depending on whether the
parameter has an override or not.

Regards,
Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Clifford E. Cummings
> Sent: Monday, October 15, 2007 2:29 PM
> To: sv-bc@server.eda.org
> Subject: RE: [sv-bc] SVDB 1619 Examples
> 
> Hi, Shalom -
> 
> More on the pipe2.v example below.
> 
> If Synopsys says that they intend to support synthesis of 
> this construct, and not just ignore the default assignment, 
> then I can approve.
> 
> In pipe2.v, your analysis below is correct for Verilog-2001 
> (you could replace the initialization with an initial block 
> assignment), but in SystemVerilog, the initialization 
> basically happens before time-0 and cannot cause a time-0 
> event, just like VHDL. I don't think all vendors have made 
> this change between V2K and SV syntax (some have and I 
> consider it to be a good change).
> 
> pipe2.v is the closest I could get to the new syntax and I 
> wanted to see what Synopsys would do for this example. If I 
> am not mistaken, Synopsys gives errors for initial blocks in 
> RTL (other tools ignore the initial blocks - generally bad) 
> so I wanted to see if Synopsys still gave errors for 
> initializations. Synopsys does not error, but warns that the 
> initializations will be ignored. Now the question is, if we 
> pass 1619 will Synopsys infer the default assignment logic or 
> ignore it. If the answer is they will continue to ignore 
> default initializations, then I would remain opposed to 1619, 
> otherwise I would support it. My opposition is to adding a 
> new way to generate a mismatch between pre-synthesis and 
> post-synthesis simulations; otherwise, I like the feature.
> 
> I would like to see Synopsys on record to support the feature 
> in DC before passing it.
> 
> Regards - Cliff
> 
> At 08:55 PM 10/14/2007, Bresticker, Shalom wrote:
> >Cliff,
> >
> >Again, the cases are not similar. No one argues with you 
> about today. 
> >Of course, DC does not implement 1800-2008 today. Five years ago, it 
> >did not implement SV either. And in 2001, it did not implement 
> >1364-2001 either.
> >
> >In pipe2.v, you have
> >
> >   logic        pu1 = 1'b1;
> >
> >That is like
> >
> >   logic        pu1;
> >   initial
> >         pu1 = 1'b1;
> >
> >and initial procedures are not synthesized.
> >
> >In pipe3.v, "a 1619 equivalent", you have
> >
> >   input        d, clk, rst_n, rst2_n='1);
> >
> >But it is not equivalent. rst2_n in this case has a default port 
> >connection value. I think maybe now I am beginning to 
> understand your 
> >difficulty.
> >
> >1619 does not propose something like a port pullup. What is 
> a pullup? 
> >In a pullup, you have a fixed internal driver to '1. When 
> the port is 
> >driven from outside, it overrides the pullup as long as the drive is 
> >strong enough. If the driver from outside stops driving, the 
> pullup is 
> >felt.
> >
> >1619 is different. It is just a shorthand for writing port 
> connections.
> >It means that in a port connection, if you wrote
> >
> >pipe3 pipe3 ( ..., .rst2_n(cucu), ...) ;
> >
> >then rst2_n is connected to cucu, and the '1 does not exist. 
> If cucu is 
> >not driving, i.e., it is 'z, then that is what rst2_n gets. 
> However, if 
> >you omitted rst2_n from the list of connections, then it 
> would be as if 
> >you had written
> >
> >pipe3 pipe3 ( ..., .rst2_n('1), ...) ;
> >
> >This latter is certainly synthesizable.
> >
> >Regards,
> >Shalom
> >
> > > -----Original Message-----
> > > From: owner-sv-bc@server.eda.org
> > > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Clifford E. 
> > > Cummings
> > > Sent: Monday, October 15, 2007 1:23 AM
> > > To: sv-bc@server.eda.org
> > > Subject: [sv-bc] SVDB 1619 Examples
> > >
> > > Hi, All -
> > >
> > > Attached is a tar-file with three 2-flop pipeline models.
> > >
> > > pipe1.v has reset going to the second flop but not the first.
> > > Synthesizes fine.
> > > pipe2.v has different resets going to the different flops.
> > > The first flop reset is internally tied through a continuous 
> > > assignment to a variable initialized in the declaration 
> (the closest 
> > > I can get to
> > > 1619 with current coding styles) while the second reset comes in 
> > > through a port. Try synthesizing that model and tell me 
> what you get 
> > > (I used DC and warnings about ignored initializations and 
> both flops 
> > > disappear).
> > > pipe3.v is the 1619 proposed equivalent to pipe2.v
> > >
> > > This is why I am concerned.
> > >
> > > Regards - Cliff
> 
> ----------------------------------------------------
> Cliff Cummings - Sunburst Design, Inc.
> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
> Phone: 503-641-8446 / FAX: 503-641-8486
> cliffc@sunburst-design.com / www.sunburst-design.com Expert 
> Verilog, SystemVerilog, Synthesis and Verification Training
> 
> 
> --
> This message has been scanned for viruses and dangerous 
> content by MailScanner, and is believed to be clean.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.