ADMIN NOTE: To keep life interesting, after dealing with all the bugs
involved with a system upgrade, we had a company wide power failure on
Friday. Recovery from that has delayed the installation of new mailer
software until Wednesday, July 1st. So if you're having problems getting
mail to jcooley@sds.sequoia.com, please try again or wait until Wednesday.
( Post 48 ITEM # 1 ) -----------------------------------------------------------------
>From: mills@hwcae.az.honeywell.com (Don Mills)
>Subject: Error in Post 42 Item #2
>
>The error that you forward to us about the verilog netlister (Post 42 Item #2)
>(write -f verilog) will change all buffers to assign statements is not true.
>I looked in some of my hierarchy verilog block which consists of buffers, the
>verilog netlister did not change buffers to assign statements.
[ jcooley@sds.sequoia.com replies: ]
Good catch Don!
I called my chip vendor (because he was the source on this bug) and it turns out
that the field alert that his company sent out was worded in a misleading way.
It's the DESCRIPTION of the bug that's wrong, the CURE for it remains the same!
What the bug he was trying to describe really was:
[ Test input module to demonstrate this bug: ]
> module fooby ( in_1, in_2, out_1, out_2, out_3, out_4 );
> input in_1, in_2;
> output out_1, out_2, out_3, out_4;
> wire in_1, in_2, out_1, out_2, out_3, out_4;
>
> /* some trivial behavioral function */
>
> assign out_1 = in_1 || in_2;
>
> /* three additional ways to output results of behavioral function */
>
> buf (out_2, out_1); /* standard Verilog "buf" function */
> assign out_3 = out_1; /* standard Verilog "assign" statement */
> BUFF U2 (.Z(out_4), .A(out_1)); /* direct ASIC library instantiation */
>
> endmodule
[ Characteristic warning message found during compiling: ]
>
> Warning: In design 'fooby', there are 2 output ports shorted to other
> output ports. (LINT-30)
>
[ Results of writing the design out in Verilog format: ]
> module fooby ( in_1, in_2, out_1, out_2, out_3, out_4 );
> input in_1, in_2;
> output out_1, out_2, out_3, out_4;
> wire net94;
> assign out_2 = out_1;
> assign out_3 = out_1;
> assign out_4 = out_1;
> BUFF U2 ( .Z(out_1), .A(net94) );
> OR2 U3 ( .Z(net94), .D0(in_1), .D1(in_2) );
> endmodule
My chip vendor says that this occurs in Verilog and VHDL and that Synopsys
has told him that this bug has not been fixed in rev 2.2b of Synopsys but
should be fixed in the release after that.
Until that time, the workaround is that you basically have to go in and hand
edit out each "assign" statement and replace it with a buffer from the
technology library. (Be sure to check that you're not violating some fanout
rule along the way, though!)
( Post 48 ITEM # 2 ) -----------------------------------------------------------------
[ From: j9@brahms.amd.com (Jeanine Valadez) ]
Subject: Asking If Anyone Has Done User Metrics
At the risk of outcry that this shouldn't belong in an ESNUG posting, here's
a question from a manager-type (aaaack) about the economics of using Synopsys
in a design method/flow.
Have any of you studied and formed any metrics to help anticipate schedule
and labor costs for a given design? If you haven't, maybe your bosses
have...?
We just started designing using RTL Verilog and Synopsys (for synthesis, we'd
used it before for translation and optimization) and it has proven to be kind
of tough to plan out project schedules without some empirical data. I thought
this user group would be a great source of experience.
( Post 48 ITEM # 3 ) -----------------------------------------------------------------
[ From: jaa@beret.ess.harris.com (John Auer) ]
Subject: Post 47, Item #1 (Schematics)
Concerning Synopsys generating feedthroughs in blocks (which might not be
acceptable to some vendors/CAD systems), Use:
compile_fix_multiple_port_nets = true
This will force Synopsys to add extra buffers to the design to eliminate
feedthroughs and shorted output ports (same net drives two or more ports).
Concering Synopsys using PWR/GND to drive output ports of hierarchy. There
is a variable you can set:
lsiout_inverter_cell = "...name of inverter here..."
which will use an inverter to drive the ports in question (tying the inverter's
input one way or the other). However, this only has an effect if you
write -f lsi ...
If you're not normally using the lsi format output, maybe you could
write -f lsi -o junk.net
read -f lsi junk.net
write -f (normal output stuff)
Hope this helps.
John Auer
Harris GASD, Melbourne, FL
jaa@mongoose.ess.harris.com
|
|
