Editor's Note: One of the neat things that goes on at SNUG is that
Synopsys tapes the SNUG tutorials and updates so that Synopsys R&D can
later give additional detailed answers to any user questions that
come up. (Now *that's* taking users seriously!) Here's this year's
Synopsys SNUG'02 R&D Q&A. (You can get the tutorial/update slides
mentioned here by going to http://www.snug-universal.org )
- John Cooley
the ESNUG guy
( ESNUG 392 Subjects ) ------------------------------------------- [04/18/02]
Item 1: Synopsys R&D Q&A To The SNUG'02 Design Compiler Tutorial (Day 1)
Item 2: Synopsys R&D Q&A To The SNUG'02 Design Compiler Tutorial (Day 2)
Item 3: Synopsys R&D Q&A To The SNUG'02 DC-Ultra Tutorial (Day 1)
Item 4: Synopsys R&D Q&A To The SNUG'02 DC-Ultra Tutorial (Day 2)
Item 5: Synopsys R&D Q&A To The SNUG'02 ACS Tutorial (Day 1)
Item 6: Synopsys R&D Q&A To The SNUG'02 ACS Tutorial (Day 2)
Item 7: Synopsys R&D Q&A To The SNUG'02 PhysOpt Tutorial
Item 8: Synopsys R&D Q&A To The SNUG'02 PhysOpt Update
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 392 Item 1 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 Design Compiler Tutorial (Day 1)
1. You mentioned that ILM keeps only the interface logic. What do you
mean by "maintaining logical hierarchy"?
Some designs have combinational logic through several levels of
hierarchy before it reaches a register, Design Compiler ILM is able
to extract all of that.
2. Can you view ILMs in Design Vision and Design Analyzer?
Yes. ILMs are treated as any other regular netlists in Design Vision
and Design Analyzer.
3. How are latches handled in ILM? Does it support time borrowing?
Latches are handled as combinational logic by default. However, you
can control it and specify the levels of latches allowed for time
borrowing. This is discussed in more detail below.
4. If you have a synchronous reset in your design that fans out to many
flip-flops, how does ILM accurately account for this if you use
ignore_port on it?
The fanout information is preserved when you set the -include_side_load
option to boundary (default) or all.
5. Why would you use a top-level compile with ILMs if your reset fanout is
removed? In this case, the reset net is not going to be buffered up,
correct?
The reset fanout is preserved unless you choose not to include the
side_loads.
In this case, the reset net is not going to be buffered up.
6. Does ILM's boundary logic get optimized during compile?
No, this is a future enhancement that we are working on.
7. Is the side load the lumped load or the actual load of the cell?
The side load is the actual load of the cell, not the lumped load.
8. Is transition time of the nets preserved for ILM?
No, transition time is not preserved. It is recalculated during
timing analysis.
9. If I perform scan insertion in the top level, can I do DRC fixing
with ILM?
Yes. DRC fixing and scan insertion work independently of each other.
10. Will clock-gating information and structures inserted by Power
Compiler be preserved in ILM?
They will be if they are part of the interface logic.
11. What about handling for clock tree delays in the ILM models after
layout?
Not currently available. These are possible future enhancements,
which we are looking into.
12. Does Design Compiler pull a HDL Compiler license when it reads in a
structural netlist with the Verilog netlist reader?
No HDL Compiler license is required to read a gate-level netlist with
the explicit -netlist option. However, if the netlist reader is used
via the new scanner, a HDL Compiler license will be pulled.
13. Does Design Compiler require that you recompile the vender libraries
with the added "when" constructs?
In most cases, no. Most vendors already have this information in
their libraries (for PrimeTime). Design Compiler was just not using
it in the previous releases.
14. Are you forced to use case analysis for conditional arcs?
Not necessarily. Logic constants will work, too. The baseline is
that a conditional arc does not make any sense if the input pins are
not constants.
15. Are conditional arcs accounted for during the optimization phase or
only during timing analysis?
Conditional arcs are also accounted for in the optimization phase.
16. For the new bidirectional enhancements, does it mean that designers
have to determine those paths are actually false paths?
Yes, designers need to make sure those are indeed unwanted paths in
their designs.
17. Does Design Compiler also disable the timing arcs through Enb to FF2
(slide 44 in the tutorial)?
Yes. Both loop-through timing paths to FF2 are disabled.
18. Where does ideal_network stop?
It stops at registers or cells that have non-ideal or non-constant
inputs.
19. What is the difference between don't_touch_network and
ideal_network?
Dont_touch_network still has actual delay and transition, whereas
ideal_network by default has zero delay and transition.
20. What is the difference between auto_disable_drc_net and ideal_net?
Auto_disable_drc_net disables drc fixing, whereas ideal_net disables
both DRC and timing fixing.
21. Does ideal_network apply only to input ports? What happens when you
apply it to output ports?
Applying ideal_network to output ports is not useful because the
command helps timing and optimization of logic within the design.
However, you can apply ideal_network to hierarchical output pins
driving other subblocks.
22. Is transition time calculated in ideal_network?
Ideal_network assumes ideal_transition and defaults to zero, but you
can change the value.
23. Should U4 be a boundary cell (slide 54 in the tutorial)?
No, because both of the inputs are ideal.
24. Can high_fanout_net_threshold be set on individual nets?
No. High_fanout_net_threshold applies to your current design, not on
a per-net basis.
25. Do extracted timing models (ETMs) extract timing arcs only? How would
ETMs apply to internal pins?
Yes, ETMs have timing arcs. However, it is possible to have timing
arcs to and from internal pins in ETMs.
26. Does PrimeTime use the trip points only from the very first library
in the link path or does it search for the first library that has trip
points?
Version 2001.08 of PrimeTime uses the trip points only from the first
library specified in the link path. However, version 2002.03 of
PrimeTime has multithreshold values from different libraries by
default.
If you want to go back to the previous behavior (version 2001.08),
you can set the following variable to false:
set lib_thresholds_per_lib false
The default setup of this variable is true.
27. Is the new sequential mapping similar to set_prefer?
No. Using set_prefer is a manual way of setting the preferred
lib_cells in the library so that so that the sequential mapper can
choose those cells first. It still does not guarantee that the
mapper uses the sequential cells correctly.
For example, it might use D-FF with sync_reset, but it might hook up
constant to reset input of the cell (and AND gate to D input of the
FF). The new sequential mapper can recognize complex registers.
28. What registers do you get if you leave out the Synopsys compiler
directive in your example slide 69 in the tutorial)?
It depends. It is not the function of the sequential mapper. Rather,
it is the function of HDLC, which might pick out a correct sequential
element. But in many cases, it generates unexpected results. For
example, it ties D signal to sync_reset input and combinational
circuit to D input. It's functionally is correct, but it may not be
what you expected.
On the complex sync registers (set_FF, reset_FF, set_reset_FF,
load_set_reset_FF, and so on), all of the sync inputs are considered
similar (except for timing). Unless HDL Compiler recognizes which
signals are for which, you might get unexpected results.
29. Are all the new optimizations/commands you have mentioned also
supported in Physical Compiler?
Most of new optimization features and commands are supported in
Physical Compiler. However, some are specific to logic synthesis
only and are not applicable to the physical spectrum. Some commands
do have options for Physical Compiler only, for example,
extrac_ilm -physical.
( ESNUG 392 Item 2 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 Design Compiler Tutorial (Day 2)
1. Can Automated Chip Synthesis be used with Physical Compiler?
Currently, Synopsys does not support the use of Physical Compiler
integrated with Automated Chip Synthesis. We are planning to make
this enhancement in the future.
2. How does acs_read_hdl compare to Presto?
The acs_read_hdl command uses Presto to analyze Verilog. In addition to
analyzing Verilog of specific files, the acs_read_hdl command is able to
search multiple directories to find all files required to analyze a
complete design, and it elaborates the complete design and leaves it in
memory.
3. In previous releases, if you had more than 10 libraries in your link
path, Design Compiler would crash. Is this still the same in the latest
release?
We are not aware of this problem. There are no new changes for this
release, in terms of handling libraries in your link path. If this
problem still exists, a possible workaround is to merge several
libraries into a single library.
4. Does Design Compiler keep the original hierarchy structure after
auto-ungrouping?
The original hierarchy structure is kept except for the blocks that
have been ungrouped by auto-ungrouping.
5. What are the differences between the two budgeters?
Design Compiler budgeter can budget RTL (elaborated .db) or mixed RTL
and gate logic in addition to pure gate logic. Design Compiler
budgeter also provides an added benefit of reduced file I/O because
you never need to exchange files (.db files, constraints) between
PrimeTime and Design Compiler.
There is an application note that provides more detailed information.
Please request this application note from your supporting AC.
6. How does budgeting handle high fanout nets to ensure no buffers will
be added during compile?
Budgeting propagates such attributes as dont_touch_network and
ideal_network the same way as characterize. Therefore as long as
your network is properly constrained at the top level so that
Design Compiler does not optimize it, the required attributes will be
passed down to the lower-level modules being budgeted.
7. Does ILM contain area and gate info?
Yes. For Design Compiler, the original netlist area is used for the
basis of wire load selection if area-based automatic wire load
selection is used. All interface cells, nets, pins, and logical
hierarchy are maintained.
8. In version 2002.05, is Presto enabled for VHDL?
No. It is planned in the U-release for beta.
9. Is the area information stored in the ILM .db file?
Yes; see question 7. Run report_area to see both the original netlist
and ILM area statistics that are stored in the ILM.
10. Are extracted timing models (ETMs) also context-independent?
No, ETMs are tied to a specific operation condition.
11. Do ILMs contain scan and test information?
Yes. The flow we recommend using is the test model flow (CTL - IEEE
Test Model standard), where scan and test information are supported
with ILMs.
12. Do ILMs contain power arcs information?
Only the information that is defined in the target library for the
library cells and macros.
13. Is the -physical option of extract_ilm available only in psyn_shell?
Yes.
14. Can you read a Design Compiler ILM into PrimeTime?
Yes, but the Design Compiler ILM does not support the use of
distributed parasitics (that is, DSPF, SPEF, and RSPF), whereas the
PrimeTime ILM does.
15. Do you have to remove_design before you read in your ILM?
Yes.
16. Can Design Compiler create extracted timing models (ETMs)?
No. ETMs can be generated only in PrimeTime.
17. If I have a STAMP model for an analog block, can I read that into
Design Compiler?
STAMP models can be used in Design Compiler.
18. Do ILMs have don't_touch attributes?
Yes, ILMs are marked as dont_touch and dont_touch_placement.
19. Would you lose loading information with -ignore_port?
Yes, which is why we will be coming out with an option to only pull
in all boundary loads for user-specified ports such as reset and
scan_enable. It is recommended to use -ignore_ports for reset and
scan_enable to avoid pulling in all registers in your original
design into the ILM.
20. Does Design Compiler include the transition of net n1? (slide 26,
side_load diagram)?
Yes.
21. Is U0 part of the interface logic (slide 26 in the tutorial) ?
Yes, it is part of the interface path from Reg1 -> U0 -> Out1
(Output Port).
22. Why would anyone want to exclude side_loads?
To create the smallest ILM model and speed up runtime; for example,
for a top-level optimization run.
23. Are ILMs going to be supported in the PSYN-Jet release?
Yes. They are supported in this release.
24. Can you read in Power Compiler generated ILMs into Design Compiler?
Yes, but without the physical information.
25. Are there any attributes that can be queried for ILMs?
You can check if a cell, net, or pin has the is_interface_logic
attribute.
26. How can Design Compiler balance the scan chain with the scan
inserted on the top- level with ILMs?
Each scan segment is kept in the test model that is part of the ILM.
27. Do ILMs contain scan information?
Yes. Scan information is in the test model that is part of ILM.
28. Does boundary optimization apply on ILMs?
No. All ILM cells are marked with a dont_touch attribute and cannot be
optimized in the current release. Optimization of ILMs (resizing /
buffering) will be addressed in a future release.
29. Can we remove the don't touch attribute on an ILM?
No.
30. Can we bring up an ILM in Design Analyzer or Design Vision?
Yes, just as you would with any structural netlist.
31. Does ILM work with reoptimize_design?
Remember that all ILM cells are marked with a dont_touch attribute, so
you cannot optimize an ILM with the current release (2001.08-PSYN-Jet).
32. Is there a way to force the RTL reader?
The -netlist option uses netlist reader only. The -rtl option uses
the Presto/HDL Compiler RTL reader.
33. Are you going to release the 64-bit VHDL reader?
No. It will be available with Presto-VHDL, which is planned in the
U-release for beta.
34. Now that Presto is the default, has the hierarchical defparam bug
fixed?
Presto supports defparam statements. You can change the value of a
parameter through a hierarchy of instantiations.
35. Is set_case_analysis new in version 2002.05?
No. Case analysis was introduced in the 2000.11 release.
36. Can you use multiple operating conditions in addition to multiple
trip points?
Operating condition consists of voltage, temperature, and process.
Among these three, on a working design at a particular time, voltage
can vary from block to block. Currently Design Compiler does not
support multivoltage.
Therefore, for single voltage support, there is no need for setting
multiple operating conditions. For min-max analysis, you might want
to use a different operating condition; Design Compiler can do that.
37. Since the default for trip points has been changed, will the delay
change as well?
It might change the delay with back-annotation information. But you
can reset the variables if you need to.
38. When the port has only one fanout, is port isolation still applied?
Yes. An input port can be isolated, regardless of its fanout.
However, if the port is already driving a buffer or an inverter, no
port isolation will be performed.
39. Would using set_isolate_port for the input port be the same as using
set max_fanout 1 on the port?
Regardless of its fanout, the set_isolate_ports command simply places a
buffer or inverter immediately AFTER an input port. The entire fanout
of the input port will then be driven by that buffer / inverter.
40. Do the Tcl enhancements include a warning (when using foreach) before
Design Compiler removes the collection from memory?
Not by default. There is a hidden variable, though, that you can set
in order to see a message whenever a collection gets deleted by using
foreach instead of the appropriate command foreach_in_collection. The
variable name is collection_debug_level; you have to set it to true.
41. Do the same improvements apply to non-Tcl commands?
No, the improvements are in the Tcl shell only.
( ESNUG 392 Item 3 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 DC-Ultra Tutorial (Day 1)
30. Now that the FSM Compiler is auto-inferred by default, what changes
do you expect to see compared to regular compile without FSM Compiler?
Does it create a new hierarchy for the finite state machines (FSMs)?
No new hierarchy is created. Without FSM Compiler, the optimizations
specific to finite state machines are skipped.
31. Do you need to set_ultra_optimization for the new FSM flow?
Yes, the new FSM flow is a DC Ultra feature.
32. Does FSM Compiler optimize for power, based on the state transition?
No. The optimizations in FSM Compiler do not specifically take care
of area, timing, or power; the optimizations are independent of the
constraints.
33. Does FSM Compiler by default assign the state encoding automatically?
Yes. This can be changed by using the variable set_fsm_encoding_style.
By default, this is set to auto. It can be set to binary, gray, and
so on.
34. Do you need a Module Compiler license for the new data-path
optimization?
No Module Compiler license is needed.
35. Do you need a DesignWare Foundation license for the new data-path
optimization?
Yes, you need a DesignWare license.
36. Now that Design Compiler incorporates so many Module Compiler features,
are there any reasons to use Module Compiler separately?
Yes. For data-path intensive designs you might still want to use
Module Compiler. Certain features of Module Compiler such as like
internal rounding and auto-pipelining of the data path are not
available in Design Compiler.
37. How does the new data-path optimization engine handle instantiating
pipeline components from the DW Foundation library?
The new data-path optimization does not affect instantiated
DesignWare components.
38. How about using pipeline_design, balance_registers, and
optimize_registers with the new data-path optimization?
These commands work independently of the new data-path optimization.
39. How does auto-ungroup handle the different wire load model scenarios
in Physical Compiler?
Wire load models do not apply in Physical Compiler; they have no
effect on auto-ungroup in Physical Compiler.
40. Does auto-ungroup ungroup the entire hierarchy or only the cell?
Auto-ungroup ungroups the entire hierarchy of the subblock
41. How does auto-ungroup compare to boundary optimization?
Auto-ungroup allows Design Compiler to work on a larger cone of
logic. It is more powerful than boundary optimization.
42. Does set_ungroup false on a block affect boundary optimization?
No, they work independently of each other.
( ESNUG 392 Item 4 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 DC-Ultra Tutorial (Day 2)
42. Is compile_ultra supported as part of compile_physical?
Not currently. We are planning to support it in a future releases.
43. Could the finite state machine (FSM) optimization extract the logic
that is not part of the FSM by mistake?
The FSM logic consists of FSM flip-flops and associated combinational
cells. The extraction process knows which flip-flops are FSM; for
associated combinational logic, the process uses its own algorithm to
determine which cells are part of FSM. The new FSM flow has a more
sophisticated partition algorithm, which extracts less combinational
logic than the old flow.
44. Is there a report command for the FSM?
Yes: report_fsm.
45. Does the new data-path optimization require a Module Compiler
license?
No, it does not require a Module Compiler license.
46. Does compile_ultra support the auto-ungroup option?
Auto-ungroup is turned on by default for compile_ultra. You can turn
it off with the -no_autoungroup option.
47. Is SOLD for version 2002.05 available now?
It will be available with the release.
48. Is there an attribute to query from your script on what version of
the tool you are using?
There is no attribute to query; however the compatibility_version
variable can be used to determine the version you are using.
49. What about support for multiple operating conditions?
We are planning for multiple voltage support in a future release.
50. Current installation results in errors with the 64-bit executable
files. Is it being fixed?
We are not aware of this problem. Please check with your AC for
updates.
( ESNUG 392 Item 5 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 ACS Tutorial (Day 1)
43. If I run acs_compile_design followed by acs_refine_design and then I
modify one of the blocks, do I need to recompile the entire design?
No. Each of the three compile commands has an -update switch that
allows you to specify a list of designs to update. When you set this
switch, Automated Chip Synthesis recompiles only the designs you
specify and their parent designs.
44. How does Automated Chip Synthesis handle include file dependencies?
In version 2002.05, the Automated Chip Synthesis front end has been
enhanced to recognize and include file dependencies.
45. Does Automated Chip Synthesis support mixed Verilog and VHDL source
files?
The acs_read_hdl command requires that all source files use the same
format. If your design has both Verilog and VHDL source files,
analyze the designs by running acs_read_hdl twice, once for the
Verilog files and once for the VHDL files. When you have mixed-format
RTL source files, you must manually elaborate the designs.
46. Can you control multiple jobs on a single machine and/or across
multiple hosts?
You can control multiple jobs on a single host with multiple CPUs by
using the acs_num_parallel_jobs variable. If you want to run across
multiple hosts, you must use GRD or Load Sharing Facility (LSF). The
way to use LSF with Automated Chip Synthesis is described in the
Automated Chip Synthesis User Guide, and the way to use GRD is
described in SolvIt article 903410.
47. I've noticed that the Design Compiler budgeter uses 8G of memory on a
400K design, versus 1G with the PrimeTime budgeter. Is this normal?
No. Design Compiler budgeter offers many advantages for synthesis
(faster, accuracy, RTL budgeting, and so on). However, it might
require more memory for some designs. For large designs a 50 percent
increase in memory might be normal, but an 8x increase is definitely
not normal and should be reported.
( ESNUG 392 Item 6 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 ACS Tutorial (Day 2)
51. Does a top-down compile invoke budgeting "under-the-hood"?
No. In a top-down compile, Design Compiler views all hierarchical
designs and interconnects at one time. This process is the same
as compiling a single module except that Design Compiler must
respect the interconnects across design hierarchy. Therefore, only
the constraints (or budget) assigned to the top level are used.
Lower-level budgets are ignored.
52. Does acs_recompile_design go back to RTL for optimization?
The acs_recompile_design command uses the pass0/precompile .db files
by default for optimization. In a usual Automated Chip Synthesis
flow, pass0/precompile .db files are the elaborated GTECH .db files.
However, for budgeting purposes, the acs_recompile_design command
uses the pass0/postcompile .db files by default. This enables the
acs_recompile_design command to create better budgets, but by using
the elaborated .db files, have a better starting point for
optimization.
The acs_recompile_design command has switches (-budget_source and
-source) that allow you to separately specify what pass the .db files
should come from for budgeting and for optimization. Therefore you
use another .db file besides the elaborated .db as an input to
acs_recompile_design.
53. What is acs_merge_design?
The acs_merge_design command must be used when you use the default
Automated Chip Synthesis directory structure for incremental design
updates. Using pass0 as an example, a regular acs_compile_design
will use the .db files in elab/db as input and produce output .db
files in pass0/post_compile.
The first time acs_compile_design -update is used, it will copy the
.db files not changing from pass0/postcompile to pass0_incr/precompile
and copy the .db files to be updated from elab/db to
pass-incr/precompile. New results will be stored in
pass0_incr/postcompile.
From this point on, each time acs_compile_design -update is used,
acs_merge_design must be used to combine the latest changes from the
pass0_incr/postcompile directory with the new elaborated .db files and
create a valid pass_incr/precompile .db. If acs_merge_design is not
used, previous design updates could be lost and your postcompile .db
will become out of sync with your RTL.
To avoid the need to use acs_merge_design and to simplify the directory
structure, you can simply not use the pass0_incr directory. Just
redirect acs_compile_design -update to use the pass0 directory for
input and output using the -update_source and -destination switches.
54. What is the recommended design size for Automated Chip Synthesis at
the top level?
There is no specific recommendation. Most users of Automated Chip
Synthesis find that partitions of 50K to 150K gates are reasonable.
Ideal size varies significantly with design style, workstation
configuration, design constraints, and so on. If you are trying to
take advantage of parallel synthesis of multiple partitions, then
ideally you should keep the load balanced between partitions.
Larger partitions result in better the QOR but longer runtimes.
55. Does Automated Chip Synthesis have the ability to check out a
license needed beforehand or must it wait for the required license?
The Automated Chip Synthesis variable acs_lic_wait allows you to
specify the number of minutes to wait for a license before quitting.
For more information about the use of this variable, see the
acs_variables man page.
56. What is the percentage of customers that have adopted Automated Chip
Synthesis?
We know of several customers that are successfully using Automated
Chip Synthesis in their standard production flow. Because Automated
Chip Synthesis is not a separate feature license, we do not have
detailed usage information.
( ESNUG 392 Item 7 ) --------------------------------------------- [04/18/02]
Subject: Synopsys R&D Q&A To The SNUG'02 PhysOpt Tutorial
1. Which version of Physical Compiler will work with ClockTree
Compiler and Route Compiler? When will they be available?
ClockTree Compiler and Route Compiler are in Beta now. When they are
available, they will interact with Physical Compiler.
2. Will Physical Compiler change ports at a lower-level hierarchy
during optimization? For example, a reset signal.
Yes, it allows boundary optimization, but only in the
RTL-to-placed-gates flow.
3. What is the sweet spot for the number of gates in
gates-to-placed-gates and RTL-to-placed-gates?
The sweet spot is 400K instances or less for gates-to-placed-gates and
300K gates for RTL-to-placed-gates.
4. (Slide 51) Can you make set_delay_estimation_options pessimistic to
help routing?
Yes, the command is there to help you influence the delay calculation
used in placement and routing estimation, allowing you to override
values derived by Physical Compiler. However, you might not want to
make it too pessimistic as it can have significant runtime impact.
5. (Slide 49) Why is set_load file required when you have SDF for
post-route incremental optimization?
The capacitive loads are required for design rule fixing.
6. How is the Physical Compiler flow different from the Floorplan
Manager flow? Is this going to obsolete the reoptimize_design
function?
The Physical Compiler flow takes more physical information and the
results are more accurate. The tool demand is market driven. There are
still many customers using Floorplan Manager and enjoying great
success with this product. Floorplan Manager will be supported into
the future.
7. What is the runtime comparison between Physical Compiler and Design
Compiler for noncongested designs?
For noncongested designs, typical Physical Compiler runtime is about
1.5 times that of Design Compiler. It also varies with tighter or
looser constraints.
8. Is there going to be a more automated RC correlation flow?
The current RC correlation flow is as automated as you can get with
the current environment. It can be further automated only when we have
detailed router and RC extraction tools integrated.
9. Can you explain what RC correlation is?
RC correlation flow is the process of comparing RC parameters before
and after routing, and then tuning RC parameter values to reflect the
true wire delay values.
10. Will Physical Compiler be able to read SPEF?
Yes, Physical Compiler will be able to read SPEF. However, Physical
Compiler uses Elmore as its delay calculation algorithm. The algorithm
is very fast but can produce more pessimistic results. The current
recommended flow is to read SDF and set_load files generated by your
preferred extraction tool for back-annotation.
11. How do you handle I/O placement?
I/O placement is done in a floorplanner such as Chip Architect.
12. Is there any plan to support ACS in Physical Compiler?
No, there is no plan to support ACS in Physical Compiler.
13. (Slide 20) What kind of timing information does PrimeTime use from
Physical Compiler at the post-route stage? Is this a pure design.db
or does it have parasitic information?
At the post-route stage, PrimeTime needs a design.db generated by
Physical Compiler and some parasitic information (SPEF/DSPF/rSPF)
produced by a routing tool. For pre-route stage, PrimeTime can read
the post Physical Compiler design.db and time your design with no
further information being required. The results from PrimeTime will
match the results from DesignTime (in psyn_shell).
14. (Slide-20) If you don't use wireload models, what do you use for
the first netlist?
In this slide, we are showing the RTL-to-placed-gates flow. The first
netlist we will produce is by using Design Compiler. If you have
wireload models in your technology library, they are used. Otherwise,
it is OK too. The purpose of generating the first netlist is for
floorplanning. A floorplan is required for the Physical Compiler flow.
At compile_physical stage, no wireload model is required.
15. (Slide 20) Is the netlist after compile a Gtech or mapped?
The netlist is mapped to the target library.
16. (Slide 46) What are the inputs to an ECO flow?
The inputs are a new netlist and the old placement file.
17. What options can I try to minimize changes for physopt -inc
-post_route?
You can use the -effort low and -size_only options to minimize
changes.
18. Does it produce a change list file after physopt -incremental?
Yes. You have to set the variable 'physopt_change_list' to true (the
default) before running incremental physopt. After the incremental
run, you can use the command 'report_change_list' to report the
changes.
19. Why do you need to be pessimistic in constraints for Design
Compiler and realistic in constraints Physical Compiler?
The reason is simple: Design Compiler uses wireload models and they
are statistical and inaccurate. The pessimism added to the constraints
is to allow some margin for the backend tools. Similarly, concurrent
placement and synthesis in Physical Compiler accounts for the wire
delays quite accurately already. There is no need to be pessimistic.
20. Do you have to have a floorplan .pdef file to go into Physical
Compiler? Can you do it in Physical Compiler itself? Are there
sufficient commands in Physical Compiler to do the floorplanning
in Physical Compiler?
Yes, you do need to have a floorplan for Physical Compiler, whether
input from some PDEF file generated by other tool or created by
Physical Compiler floorplanning commands. Physical Compiler does have
sufficient commands to create necessary floorplan objects.
21. In a hierarchical Physical Compiler flow, some blocks are multiply
instantiated. How is the optimization handled?
The logical hierarchy in Physical Compiler is maintained throughout
the optimization. Physical Compiler handles the physical hierarchy of
the design as a flat entity. There will be no conflict in the logical
hierarchy and the physical hierarchy.
22. Routing on different metal layer gives different RC. Does Physical
Compiler take into account the different metal layers during
optimization?
Yes, it does.
23. Can Physical Compiler replace Design Compiler and Floorplan
Manager?
You can look at it this way: Physical Compiler is a superset of Design
Compiler and processes more detailed information than Floorplan
Manager.
( 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
|
|
