( ESNUG 157 Item 1 ) ---------------------------------------------- [10/93]
Subject: (ESNUG 156 #1) was: 'Too Many Nets' now: 'Wire Models Having Area'
> do you have your own library? then make sure that your wire model uses
> area! you don't have your own library? then tell your asic vendor that
> you want the area field of the wire model to be adjusted.
--- --- --- ---
From: brad@hdls.COM (Brad Eltman)
John,
The whole idea that wire takes area and they should factor this into the
cost function is something people have been telling Synopsys to do since
version 1.0beta.
Because of a highly critical multiplier design, we went off and built our
own wire load library for a 0.5 micron technology library. As an experiment
we built identical wire load models with the "area" parameter set from
0.0 to 0.25 in 0.05 increments (0.0, 0.05, 0.10 ...).
Then we took several small critical circuits and pushed on both timing and
area and ran these with the base library and then our wire loads, and saw
no difference between any of the compiles. We even set the timing to be not
critical and the "max_area" to be 0 and saw no difference.
The question is does Synopsys use this information during optimization? I
would like to know if I am wasting time with this or if the circuit is just
too small to be affected by wire area. (The test circuits range from 50 to
200 gates).
By the way, if anybody has a pointer to the fastest signed multiplier design
please send it to me. Thanks in advance.
- Brad Eltman
HDL Systems, Corp.
--- --- --- ---
From: Brian Arnold <bka@hpesbka.fc.hp.com>
John,
After reading the posting concerning area in wire models I tried inserting
various area numbers into a wire model description and found this had no
effect on the results, and in some cases the synthesis was actually worse.
The constraints I am using are very tight and am not having a problem with
Synopsys not selecting composite cells over a plethora of smaller input gates.
Consequently, I too feel the area parameter in a wire model is a don't care.
- Brian Arnold
Hewlett Packard
[ Editor's Note: Then what explains the different results Cindy got when
she synthesized with and without wires having area? - John ]
( ESNUG 157 Item 2 ) ---------------------------------------------- [10/93]
From: [ Synopsys R & D ]
Subject: (ESNUG 156 #3) "3.0b Fatal During Charaterize"
> Turns out that "Error code=10" means nothing and the long string of numbers
> got me to the point where the Hotline says there's a fatal in Synopsys 3.0b
> that causes this during characterize and to map everything in the hierarchy
> without constraints first before doing any characterizing.
"Error code=10" -- this is a general UNIX code that comes up when the
UNIX operating system decides to kill the Synopsys run.
"Error id=564789" -- this tells us exactly where the program failed and
appears when Synopsys decides to kill itself.
These are obviously mutually exclusive deaths. Either way this is useful
info for R & D to have in tracking down a problem.
But the most useful information, though, is the long string of following a
Synopsys fatal because it's a stack trace. e.g.
'8485776 8486060 8704860 3553632 3708536 3708776 3708824 3709200
1893304 7698940 7698564 7703452 ... '
It extremely helpful to send the stack trace along with any error codes or
error ids that appear in a fatal. Please save and include them when you're
reporting bugs.
- Synopsys R & D
( ESNUG 157 Item 3 ) ---------------------------------------------- [10/93]
From: rjv@cypress.com (Rick Veres)
Subject: Non-linear Delay Models Are Great
Hi John -
We recently installed v3.0b design compiler and I was pleasantly surprised at
the non-linear delay model. I am in the process of creating and modeling a
new sub-micron standard cell library, and would appreciate any insights on
building non-linear delay models for the cells. In the past, I was a strong
proponent that a standard cell library should be designed to ensure balanced
rise and fall times. This requirement resulted in n and p transistor ratios
on the order of 2-3 to 1 (depending on process), and also resulted in cells
with larger areas. Now with the improved modeling of transition times in
v3.0b, I question the balanced rise and fall time requirement. The improved
accuracy of the non-linear delay model should easily support cells with
transistor ratios of 1 to 1 ). So then, how should one design a standard
cell library, given the v3.0b non-linear delay model??
- Rick Veres
Cypress Semiconductor
( ESNUG 157 Item 4 ) ---------------------------------------------- [10/93]
From: uunet!uranus!splinter!flieder (Jeff Flieder)
Subject: V3.0b Latch Inferencing & Using Variable Results Bugs
John,
I wanted to post a few bugs that I have recently discovered in V3.0b.
The first has to do with latch inference with asynchronous reset. In V3.0a,
you could infer latches on a "slice" of a register bank and get predictable
results. In V3.0b, the latch inference does not recognize asynchronous resets
on register "slices". An example will probably make this as clear as mud, so
here goes.
reg [15:0] data;
always @(data or gate or reset) begin
if (!reset)
data[7:0] = 0;
else if (gate)
data[7:0] = someNewData;
end
You would expect this to give you 8 latches with the reset signal tied to an
asynchronous reset pin. In 3.0a, that is exactly what you will get. In 3.0b,
you will get the gate and reset signals gated into the gate input, and the
someNewData and reset signals "muxed" or "AOIed" into the data input. Not at
all what you wanted.
--- --- ---
The second bug is for more advanced users of dc_shell. There is a problem
with assigning values to variables based on the results of a command. If the
response to a command changes after the variable is set, the variable gets
set to the new response. It seems that the variables are connected to the
command that generated them a little too tightly. Again, an example should
help.
Suppose you have three designs in memory called des1, des2, and des3. If you
issue the command:
designNames = find(design)
the variable designNames will be set to {"des1", "des2", "des3"}. If you
then delete des2 and des3, -- designNames now equals {"des1"}! Not exactly
what you had in mind (saving all design names for later use). There is
a workaround for this, although it is rather ugly. The solution is to save
the command for defining the variable in a file and then reading in the file.
For example, to save the above variable:
designNames = find(design)
list designNames > designs.scr
include designs.scr
This will now preserve the variable designNames regardless of what designs are
really in memory.
- Jeff Flieder
Ford Microelectronics
( ESNUG 157 Item 5 ) ---------------------------------------------- [10/93]
From: schooler@boilerbob.corp.mot.com (Tony Schooler)
Subject: max_edge_rate Bug and Solution
Hi John,
I ran into this problem using synopsys v3.0b, and thought I would pass the
solution on to everyone.
To the hotline, I sent:
I have switched from synopsys v3.0a to v3.0b, and I now get these errors
that I have never got before:
Net: stg/setqfin[1]
max_edge_rate 0.00
- Actual Edge Rate 279.01
------------------------------
Slack -279.01 (VIOLATED)
I have looked in all the documentation, but I couldn't find it anywhere.
Can you tell me more info about this, and what command to use to set the
max_edge_rate?
I already have sets for maximum transition (does this have anything to
do with max_edge_rate?). I use the following commands:
set_max_transition 2000 current_design
set_max_transition 1000
find(pin,/synopsys.libs/noncombinatorial_udr2_85_wcs_v3t15
0.db:noncombinatorial_udr2_85_wcs_v3t150/*/D)
I am using a custom library.
- Tony Schooler
Motorola AIEG
And the Hotline replied with:
This is a known problem (see STAR B3#13698). The problem occurs if
there is no default_max_transition specified in a library using the
cmos2 delay model. In this case, the tool incorrectly assumes a
max_transition of 0.0 on output ports which do not have an explicit
max_transition set. The workaround is to set a valid
default_max_transition in the library. Set it to any high value,
e.g. 18. If you do not have access to the library source, you can also
do the following:
set_max_transition 18 all_outputs()
Following is the workaround for the STAR 13698 add the following to the
.lib file:
default_max_transition : 18;
Or, until the vendor updates the library, the user can do this:
set_max_transition 18 all_outputs()
- Synopsys Hotline
[ Editor's Note: Thanks Tony for sending this combination Question-You-Had
and the Answer-Synopsys-Gave-You. I'd like to encourage the ESNUG community
to send more of these types of posts along with the usual single questions and
responses to others questions. Why? Because it means that everyone doesn't
have to duplicate this work if it's published. - John Cooley ]
|
|
