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.