( ESNUG 392 Item 8 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 PhysOpt Update
1. When we do congestion analysis, do we consider power structure,
test structure, clock trees, etc.?
We consider whatever is available in the netlist and the floorplan. If
you already have test structure and clock trees, that will be in your
netlist. If you have the power structure, that will be in your
floorplan. We will use all that information for the analysis of the
design.
2. How is congestion quantified?
Congestion is quantified as the ratio between the number of wires
passing through an area versus the available number of tracks or
routing resources.
3. How do you specify double-width wires?
Currently, Physical Compiler does not do detailed routing. It does not
have specific information of which nets are wide wires or not. One
method you can apply is to adjust the congestion threshold to allow
the tool to work harder on resolving congestion issues.
A new method is to specify nondefault routing rules in v2002.05. The
tool takes the specified width into consideration in delay and
congestion calculation.
4. Why is it important to fill up the valleys (Slide 18: High-Effort
Congestion Removal) in fixing congestion?
In some cases, it is not important to fill up the valleys as long as
none of the congestion peaks is higher than 100 percent. Filling up
the valleys is just some congestion relieving tricks (algorithms) that
high-effort congestion fixing applies.
5. In which version of Physical Compiler is the command
'set_congestion_options -coordinates' (that allows the tool to work on
some particular area on the design for congestion fixing) available?
The command is in v2001.08.
6. Does the command 'set_congestion_options -coordinates' change the
structure of your netlist?
No, it does not change the structure of your netlist. The logical
hierarchy of your design is maintained.
7. At what specific time do you apply 'set_congestion_options'
command?
You need to apply this command before the first use of physopt,
compile_physical, or create_placement command with -congestion or
-timing_driven_congestion option. Subsequent runs with -congestion or
-timing_driven_congestion option take the same values set by the
'set_congestion_options' command.
8. Can 'set_congestion_options -coordinates' be used with setting both
horizontal and vertical thresholds at the same time?
Yes. There is no conflict.
9. (Slide 33: Floorplan and Placement) Why do we have to worry about
placing cells with pins on METAL2 underneath the METAL4 and/or METAL5
power nets? (In this case, the power nets are covering a long and thin
channel created by two macros -- RAMs.)
METAL2 not colliding with METAL4 and METAL5 is true. However, the
point we want to make here is that by this configuration (long and
thin channel with power nets on top), you are reducing the amount of
routing resources, and therefore creating congestion problems.
10. Are ideal nets and DRC free nets the same?
They used to be the same but now they are not. No optimization is done
on ideal nets, whereas only timing optimization (but not DRC fixing)
is done on DRC free nets.
11. What kind of guidelines do you have whether to use Physical
Compiler or other tools (such as clock tree synthesis) to work on
high-fanout nets?
Clock tree synthesis is a separate topic and we do actually have a
product that can do clock tree synthesis. For other high-fanout nets,
we recommend that any nets of fanout up to 100 can just be run through
physopt or compile_physical. Anything above that, you should mark it
as an ideal net so that Physical Compiler does not try to optimize it.
Then, we have a separate command called create_buffer_tree which has
specific algorithms to deal with high-fanout nets. Please note that
create_buffer_tree is NOT a clock tree synthesis command; it does not
deal with clock skews. It merely improves the timing of high fanout
nets.
12. Does 'physopt -quick' give you a report only or actually do
optimizations?
It does optimizations, but it does not do DRC fixing or slew
degradation calculation is turned off. The idea is to do a quick
physopt run to quickly find out whether the design is sensible or not.
If it is not sensible, you would be wasting your time applying full
power on the physopt command.
13. Can you do 'physopt -quick' and then 'physopt -inc'?
Yes, you can, but don't. 'physopt -quick' runs through and gives you
quick results, but the QoR is not so good. The resulting netlist and
placement are not be a good starting point for further (incremental)
optimization.
14. Do you need a floorplan for 'physopt -quick'?
Yes.
15. Is there a way for Physical Compiler to place macros and standard
cells concurrently?
Yes, there is a beta-feature called minimal physical constraints (MPC)
to be production-released in the middle of this year.
16. Does RTL-to-Placed-Gates always produce better results than
Gates-to-Placed_Gates?
No, it does not always produce better results. For example, in some
designs, all the heavy lifting has already been done -- creating
scripts, wireload models -- producing a good starting point.
RTL-to-Placed-Gates does not show much benefit in those examples. If
you are taking a new design, out of the box, no wireload models,
RTL-to-Placed-Gates gets you to timing closure much faster.
17. Why does 'physopt, save the result, physopt -inc' give better
results than 'physopt, physopt -inc'?
It should not although it is possible because of some internal physopt
algorithms. If it happens, please report to us and we should treat it
as a bug and fix it.
18. Is there any better way besides modifying RC parameters manually
for different process corners?
Unfortunately, there is no better method. We are working on improving
the RC calculation issue and also deriving better information from
physical libraries to apply to different parts of your design.
19. What is the speed up with -num_cpu?
It depends on the number of CPUs you specify. Typically, we see a
speed up of 2.5 to 3 times if you specify '-num_cpu 4', and it scales
if you have more than 4.
20. If you add more link_libraries into your script, will Physical
Compiler use all of them?
Yes, it uses all of them on a first-listed basis. Physical Compiler
uses your timing, DRC, and area costing to choose the cells. If you
are trying to target some specific cells, you might have to specify a
'dont_use' on other cells.
21. What are the circuit limitations for RTL-to-Placed-Gates and
Gates-to-Placed-Gates?
The maximum circuit size for RTL2PG is 300K gates, and for G2PG is
400K instances.
22. Is creating a lot of regions (bounds) recommended?
Creating a lot of regions is not recommended because run time
dramatically increases, and in many cases you might be fighting
against what Physical Compiler wants to do in terms of placing those
cells. The general recommendation is to give the tool as much
flexibility as possible to allow it to use the timing constraints to
drive the placement optimization. Therefore, you try to reduce the
number of regions (or bounds) specified.
23. How do 'set_bounds' and 'set_congestion_option' interact?
'set_bounds' pulls cells together and 'set_congestion_option' spreads
them apart. This is why you have to be very careful dealing with these
kinds of situations. You can end up giving the tool conflicting
constraints, and it fights against itself. Again, try to give the tool
as much flexibility as possible and interact with it whenever possible
but not too much.
24. I heard something about reading RTL without floorplan. Can you
explain?
We have a project called minimal physical constraints (MPC) that can
take a design with zero physical information and start to create that
information and make recommendation as to what the floorplan should
look like. The feature will be released in the middle of this year.
25. Does the tool take into account the routing resources for clock
tree, scan structure, and so forth, that might come into the picture
later?
No, it does not guesstimate what comes next. If the scan chain is
connected, those nets will be part of the netlist and those will be
part of the routing requirements of the design. Similarly, if the
design has clock buffer trees incorporated, Physical Compiler will
consider the buffer tree routing as part of the routing estimation.
26. How can I place some specific gates near some ports using
RTL-to-Placed-Gates flow?
You are not be able to do that in RTL-to-Placed-Gates because those
instances do not exist at the beginning. In order to place some
specific gates at specific locations, you have to produce some
gate-level netlist. Then, you have specific instances to place
wherever you want. With the existing gate-level netlist, you can use
Gates-to-Placed-Gates for further optimization.
27. Is Synopsys pushing RC estimation problem from the interface
between synthesis and placement to placement and routing tools?
Yes. The reason is that we now have more accurate information and it
is appropriate to do it at the placement phase, but there are still
issues trying to resolve timing discrepancies between placement and
routing. The solution would be a much more integrated one for
placement in global routing and placement in detailed routing.
Synopsys could buy some place and route company and might be able to
solve that problem! 8^)
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 13,958 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
