( ESNUG 422 Item 3 ) -------------------------------------------- [02/19/04]
From: Rune Jensen <rjensen=user domain=reshape spot calm>
Subject: Some PrimeTime Guidelines For Logical & Physical Design Hierarchy
Hi John,
We have been supporting timing analsysis for several large SoCs. These
designs are typically combining two or three previous chips. One of the
biggest headaches in these designs is that the designers are trying to
reuse the PrimeTime scripts from the previous designs in a "bottom-up"
approach. It has been difficult, to say the least.
Keep in mind that PrimeTime constraints need to support the following:
- Timing analysis of the logical hierarchy design
- Timing analysis of the physical hierarchy design
- SDC generation for the timing closure of place and route blocks and
starting points for clock tree synthesis
- Easy migration for use in a different chip
We've developed some simple PrimeTime scripting guidelines that may help
alleviate the problems associated with logical-physical hierarchy in any
one given design and reusing the PrimeTime constraints for future designs.
These guidelines are a result of designing several 1 million+ instance
hierarchical SoCs. Here they are so that the ESNUG community can be more
physical design aware!
Logical and physical hierarchy support:
During physical design implementation, your design is likely to be
repartitioned and flattened such that the logical and physical hierarchy
does not match. Also, logical design optimizations like instance removal
and net removal or name changes are happening. This creates problems when
reusing the logical design scripts for the physical design hierarchy. The
guidelines to ensure compatibility are as follows:
- Avoid applying constraints and clocks on hierarchical ports.
Most physical implementation tools work significantly better on a
flattened design. These hierarchical ports from the logical hierarchy
likely do not exist in the physical hierarchy. Of course, if there is
a 1:1 mapping between the logical and physical hierarchy, then
constraints on hierarchical ports are okay.
- Do not apply constraints on logic that is likely to be transformed or
removed during the physical design process. This especially applies to
buffers, inverters in an inverter tree, etc. Apply the constraint on
logic that cannot be transformed: registers, latches, macros & chip IOs.
- Avoid netname references.
Netname consistency cannot be guaranteed after the netlist is read into
the physical design system. During physical design implementation nets may
get renamed or optimized away.
- The location of the "main modules" (e.g., uart, usb, vmpg decoder, etc.)
in the chip should be referenced via variables in the PT scripts. These
variables should be defined in two separate files - one for logical
hierarchy and one for physical hierarchy. These two files should be the
only difference between the logical & physical design hierarchy scripts.
As an alternative to seperate files, procedures could be used for
conditionally setting the variables.
The following guideline is essential when migrating the constraints to a
different project/chip:
- Apply all IO constraints on chip pins as opposed to the logic just
before the chip pins.
The chip pins can be referenced consistently throughout the design process
but the IO logic is likely to change instance name during design
partitioning.
Block-level SDC file generation:
Most physical implementation tools only support optimization towards one
functional mode of operation. Another point to consider is that during
physical implementation, nets that are defined as clocks in the SDC file
are only touched during clock tree synthesis, if specified, and not by
any other optimization. I.e., if you neglect to specify CTS for a clock
net, it will not be optimized at all.
The following guidelines can help overcome these limitations:
- Ensure that all clocks are defined. Only nets defined as clocks can be
clock tree synthesized.
- Ensure that all clocks defined in the SDC file are CTS'ed. If a
net is defined as a clock but CTS is not intended to be specified for
that net, remove the net clock definition.
- Apply the constraints that are hardest to meet.
It may be that you have different scripts for different operating modes.
In the script for your main functional mode, ensure that it has the most
difficult constraints out of all the scripts. This generally means:
- Specify the maximum clock frequency
- Apply as few exceptions (set_false_path, set_case_analysis) as possible.
- If two clocks require phase alignment, specify that in the constraints,
i.e., there should be a setup/hold uncertainty between the two clock
domains. Thereby the physical implementation tools will attempt to meet
the constraint.
- Constrain all IOs at the block level. This helps "anchor" the logic
close to the IO pins of the blocks and helps achieve consistency between
each build of the block.
Some general hints / pitfalls when using PrimeTime for SoC signoff:
- For clocks that require phase alignment, define the clocks at leaf cell
inputs.
This ensures accurate delay calculation in PrimeTime and PrimeTime-SI. If
a clock is declared on a hierarchical port, the net delay calculation in
PrimeTime and PrimeTime-SI will be inaccurate, which can be fatal for clocks
that have to be phase-aligned.
- Consider constraining asynchronous interfaces if the interface clocks
are faster than ~200 MHz. The assumption for most asynchronous interfaces
is that the strobe is not more than one clock cycle faster than the data.
This can usually be assumed and achieved for low frequency, but not for
high frequency, asynchronous transfers.
- Design rule violations like max capacitance and max transition time must
be checked before applying any constraints to the design. Constant value
nets are not checked. External load and drive constraints should be
applied before DRVs are calculated though.
- Clocks should be created at the very start of the clock network (eg. PLL
output or chip IOs) do the maximum delta delays for the clock propagation
will be used in PrimeTime-SI analysis.
- To enhance the runtime and minimize the effort for checking log files,
warnings should be removed from the check_timing reports. Especially lot
of unnecessary "expanding clock warnings" will cause excessive run-times.
- Avoid modifying constraints between report_timing as this introduces a
new timing consuming update timing.
We have now followed and improved these guidelines for three designs. Our
experience with these guidelines is that they are very helpful in getting
the PrimeTime scripts completed in a timely manner and for getting to
physical design timing closure and sign-off fast.
I hope these guidelines will help other ESNUG readers!
- Rune Jensen
ReShape, Inc. Mountain View, CA
|
|
