( ESNUG 265 Item 3 ) -------------------------------------------- [9/10/97]
Subject: (ESNUG 264 #3) 1.5 Hrs "Design Rule Compile" Now Takes 24 Hrs!
> I have a design, the top level of which compiled under synopsys3.4b in
> roughly 1.5 hours. ... In both 97.01 and 97.01-01_44683, that same
> compile takes over 24 hours (basically 24 hours fixing design rule
> violations). I have tried this using vendor libraries which were designed
> for 3.4b and new vendor libraries designed for 97.01. Again, most of the
> time (basically 24 hours) is spent fixing design rules. I've tried a
> number such as always using "best case tree", turning off automatic
> wireload selection which chose a chip level wire load (enclosed mode) and
> instead chosing a very small wire load. Any ideas?
From: Maurice_Labedan@hp.com (Maurice Labedan)
Hi John,
I experienced the same kind of problem; in my case the reason was very
simple but took some time to come out. In 3.4b, my library had asynchronous
FFs (and so the reset signal was declared as false path). In 1997-01, my
library had synchronous FFs only (and so the reset signal was no more
declared as false path). The difference in timing run was from half an hour
to 24 hours. And first of course I thought it came from the new Synopsys
revision ... It might look stupid, but may be have you got the same kind
of pathes !!
- Maurice Labedan
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: agelman@metaflow.com (Anatoly Gelman)
Hello, John.
I've had similar experience though not as dramatic as reported above.
Here are the results of experiment I've performed five monthes ago for one
module in my design. I did not try any other modules, and I don't know
if the noticed increase in run-time is a common experience with 1997.01.
My application is a high-speed microprocessor design.
Based on this experiment my basic conclusion was that 1997.01 barely
beats 3.4a at the expense of 2x increase in run-time. And this is true
only when the two major new features of 1997.01 were disabled. If enabled,
results were much worse.
Here are the results:
slack area run_time
----------------------------------+--------+------+---------
1997.01
new_sizing=true new_boolean=high -0.95 329700 ~2hrs
new_sizing=true new_boolean=med -1.31 326730 ~2hrs
new_sizing=true new_boolean=low -0.76 329025 ~2hrs
new_sizing=true new_boolean=false -0.63 326250 ~2hrs
new_sizing=false new_boolean=false -0.62 325635 ~2hrs
3.4a -0.64 327645 ~1hr
"New_sizing" reflects the state of "compile_new_gate_sizing" variable.
"New_boolean" reflects the effect of "compile_new_boolean_structure"
variable and "set_structure true -boolean true -boolean_effort <effort>"
command.
I am guessing that this user might want to try the following before doing
the compile:
set_resistance 0.0 find(net,"Logic0");
set_resistance 0.0 find(net,"Logic1");
It's possible that you are dealing with high transition times due to
fanout-driven computation of wire resistance value. I would guess the
Logic0/Logic1 nets have huge fanout in your case. You might also try this
instead before you start the compile:
set_max_fanout 15 current_design()
Just an idea. Have no clue though what changed in 1997.01 compared
to 3.4 in light of your problem.
- Anatoly Gelman
Metaflow Technologies
---- ---- ---- ---- ---- ---- ----
From: Terry_Hussey@3com.com
Hi John,
Apparently synopsys has changed the set_driving_cell command so that it
now annotates design rule constraints. I have the following command in my
compile script:
set_driving_cell -library (lib name) -cell(driving cell name) -pin
(driving pin name) all_inputs
Apparently this will take the max_transition design rule from my library
for that driving cell and apply it to all_inputs. However, it is somehow
placing that constraint on the logic0 and logic1 nets. Synopsys has not
been able to explain why this is happening. I did an "all_connected"
on logic0 and logic1 and verified that none of the input ports of my design
were inadvertantly connected to those nets (which was a possible
explanation); none were.
So, logic0 and logic1, which have many many loads, are now being targeted
for a design rule fix because they violate the library max transition of
2 ns. The large transitions on logic0 and logic1 also propegate to other
combinatorial logic to which they are connected. Hence there are alot of
design_rule constraints to fix.
Synopsys has a switch, however, called "-no_design_rule" which causes
set_driving_cell to revert to its old behavior. Sure enough, using that
switch caused a big improvement (down to about 7 hours of design_rule
fixing from 24 - not quite to 1.5 hours though). There are still
some things about the compile that look weird but I don't have my arms
around the issues yet.
Hopefully this is not the best that 97.01 can do.
- Terry Hussey
3Com Switching Division
|
|
