( ESNUG 380 Item 6 ) -------------------------------------------- [10/25/01]
Subject: ( ESNUG 377 #18 ) PrimeTime & Its New Interface Logic Models (ILMs)
> Has anyone used PrimeTime's new ILM capability? I'm interested in other
> people's experiences.
>
> - David Wang
> ATI
From: [ Not Dead Yet ]
Hi John,
Yeah, we having been using these ILM things for a while. For the most part,
ILMs are straightforward and easy to use. There was quite a bit of initial
confusion on how the various PrimeTime ILM options influence what logic is
kept/removed. We had to do our own matrix of experiments to figure that
out. We also have some concerns around how useful/accurate ILMs are if you
are trying to keep a handle on transition times.
Please keep me anonymous.
- [ Not Dead Yet ]
---- ---- ---- ---- ---- ---- ----
From: Ed Weber <ed_weber@agilent.com>
Hi, John,
We were using the ILM concept internally here years ago before we started
using PrimeTime. (We were HP back then.)
ILM's are a hierarchical design concept. When a child block's artwork is
complete, its timing is verified against its budgeted constraints using
extracted parasitics. When the child is timed in the context of a parent
block, the timing paths between internal registers of that child are checked
again. The idea of an ILM is to create a new netlist for a timing verified
child block which has all the internal register to register logic removed.
This netlist contains only the interface logic gates, hence the model name.
PrimeTime provides commands to write out the new netlist and a corresponding
SPEF file. Parent block timing and rebudgeting is then done using this
reduced model.
ILM's are absolutely accurate because they use the same gates and net
parasitics as the original netlist. Register to register paths within the
child block are however no longer there. So the parent must be run with the
same relevant clocks used in the child block timing verification.
Obviously an ILM model only works if there is internal register to register
logic to remove. A purely combinational child block will have the ILM
netlist identical to the original.
ILM's have allowed us to stay on 32bit workstations with 2M+ gate designs
with reasonable run times of a few hours tops. Without them we would have
been forced into using ETM's which are quite painful to produce and debug.
We've had quite a positive experience with PrimeTime's flavor of ILMs here.
It pretty much works as advertised. I've attached some data below. There
are some annoying aspects of reading multiple hierarchical DSPF/SPEF files
into PrimeTime (which is required with ILM's), but it is tolerable.
Chip A is about 500 kgate. It has 19 top level instances of 3 unique
blocks. This chip was tape released without ILM's and parts met timing.
Timing analysis runs in 42 minutes. ILM's were made for the top blocks
after tape release to verify ILM's. Timing analysis with ILM's was about
4 minutes. Results were close to identical.
Chip B is about 2 million gates. With ILM's, it is down to about 500
kgates. Timing analysis runs about 2 hours. Timing without ILM's was
never done but estimated to be about 20 hours based on similar designs.
This chip has been tape released. Parts are not back yet.
Chip C is in development. It is estimated to have 1.8 million gates. It
has 11 top level children for which ILM's were created. It times in about
20 minutes with the ILM's. Timing one of the top level children takes
about 2 hours.
I hope this helps your readers, John.
- Ed Weber
Agilent Technologies Fort Collins, CO
---- ---- ---- ---- ---- ---- ----
From: Bruce Zahn <bzahn@agere.com>
John,
We have tried using Interface Logic Models (ILM) on a few designs. We used
the ILM parasitic flow with our internal delay calculator. Our basic flow:
1 Read in the block level design and constraints,
2 Generate ILM netlist, list of cells/nets/pins in ILM, ILM constraints
3 Run a Perl script to process our parasitics to match the ILM
4 Verify the ILM generated.
We use the parasitic flow because it is more accurate than using the SDF
flow, where the block level ILM SDF is written out to be used at the top
level. This ILM SDF will have hard delays for boundary cells that will not
vary based on the block input slopes and output loads. So unless the block
level slopes and loads specified in the block level constraints match what
is seen at the top level, the delays will not be accurate.
We use an internal parasitic format (similar to SPEF RNET).
We use a Perl script that reads in a list of nets/pins/cells in the ILM and
processes the parasitic file. This script removes any object that is not in
the ILM plus do the proper 'escaping' for items in the ILM. Escaping is
needed since the ILM is a flat netlist (see below for more details). We
list nets/pins/cells in our ILM via a Tcl procedure using the get_ilm_object
command. This means long runtimes if the block is large.
Since the parasitic format used specifies a pi model for the entire net, our
delay calculations using ILMs will be correct even if the fanout differs in
the ILM as compared to the full block model. For example:
output port
FLOP1 U1 _
_____ |\ | \
| |-----| |-------|_/
| | |/ |
| | |
----- |
|
FLOP2 U2 |
____ |
| | /|----
| |-----| |
| | \|
----
When an ILM is generated, U2 will be removed since it is not in a timing
path to the output port. Therefore the pin capacitance of U2's input pin
will not exist in the ILM netlist. Since the parasitic format (similar
to SPEF RNET) specifies the pi model on the net, the capacitance of
U2's pin is incorporated in this pi model. Therefore the delay calculated
for U1 will see the correct load.
If detailed parasitic format such as SPEF DNET is used then all the pins
of the ILM nets must be retained. Use the -include_all_net_pins option of
the write_ilm_netlist command. We have not looked into this flow at this
time. It may have an effect on the size of the ILM, especially for
propagated clock signals.
ILM constraints are generated to be used during ILM verification. (That's the
process of comparing the block level ILM IO timing paths vs the full block
level netlist IO timng paths). We have not used the constraints generated
with write_ilm_script -instance for the top level, because the top level
constraints are not usually generated in a manor that seperates all the block
level constraints from top level.
Overall, we have seen good results generating ILM's for some designs. There
are some bugs/issues. Some designs are not suited for ILM's. Your blocks
must be synchronous, structured, and not too large. Here's some other issues
that we have run into:
- ILM is flat netlist - this can cause some problems!
Constraints
Any block level constraints that reference pins of a hierarchical block
will get modified when written out via write_ilm_script command. For
example, if a clock is defined on a hier pin (not good practice) it
will get pushed forward to the leaf level clock pins it drives. This
will cause the flight delay of the net to be lost.
Escaping
The parasitic file for the block needs to have any hierarchy character
escaped. We needed that Perl script that removed any object that is not
in the ILM and did the proper escaping for items in the ILM.
Even though we use an internal parasitic format, we looked at the SPEF
file written out from Design Compiler via write_ilm_parasitics that has
the hier characters escaped properly but has a bug where it escapes all
"[]" characters. SPEF has constructs to define bus delimiters, so
PrimeTime should only escape "[]" characters that are not busses.
Verification
Checking that the ILM netlist preserved the correct logic can be a pain
since the model is flat. For example, some designs have very complex
clocking structures. It is very difficult to verify that the ILM
preserved these complex structures.
- Issues with complex cells such as dual scan flip flops and cells without
timing arcs.
We have seen some strange behavior when generating ILM netlists on designs
with complex cells such as dual scan flip flops. However, these can be
worked around by disabling some of the arcs in these flops.
- Cells without timing arcs (tiehigh/low, bushold) are troublesome.
ILM generation is based on tracing the timing arcs of cells. There is
some different behavior in different releases of PrimeTime concerning
cells without timing arcs such as tiehigh/low cells. In earlier releases
of PrimeTime these cells would not get written out in the ILM netlist,
but would be in the ILM constraints as set_case_analysis command. In
PrimeTime 2001.08 they are in the netlist and some set_case_analysis
commands exist to items that are not in the ILM netlist!!! It results
in bogus errors when the constraints are applied.
- Model generation runtime & update_timing issues
ILM generation is usually fast providing the tool does not perform an
update_timing. This is because PrimeTime has problems handling
structures with many driver/load combinations, and issues a warning
(PTE-038) that performance degradation will occur. Many of our designs
have these structures. So we must ensure that we do not cause an
update_timing prior to removing these structures. So we:
1 Read in netlist and minimal constraints ( clocks, etc)
2 Generate ILM netlist via identify_interface_logic,
write_ilm_netlist
3 Remove the structures PrimeTime dislikes
4 Apply remaining constraints and generate ILM constraints via
write_ilm_script
- ILM works best on structured blocks
Blocks must be very structured for ILM generation. All block IO must be
single fanin/fanout. This is to ensure that the reg-reg paths verified
at the block level are not effected by the top level. Stuff like scan
optimization may violate to single fanin/fanout rule.
If you trace reset or scan type ports, you'll get a large ILM since these
signals typically go to all flip flops in your block. To avoid this,
these ports are marked as 'ignored' during model generation via the
-ignore_port or -auto_ignore option to identify_interface_logic command.
As a consequence, the recovery checks of asynchronous paths can not be
verified. In 2001.08, a new option "-keep_ignored_fanout" has been
added to identify_interface_logic to preserve the logic network to
boundary registers only.
- verification & dangling pins in ILMs
PrimeTime 2001.08 has been beefed up to contain commands to help verify
ILMs vs full blocks. Most of the discrepancies we've seen between an
ILM and a full block are due to cells with multiple inputs where some of
the inputs in the ILM are dangling. This causes a different output slope
calculation since most delay calculators take the worst input slope when
calculating the output slope.
To help speed up ILM verification, we write out the slope and load of
all dangling pins in the ILM. These are then applied in our delay
caculation run.
- Using ILMs in other EDA tools is difficult
In order to support other EDA tools, like our internal delay calculator,
the user may want a certain net/cell to be generated in the ILM netlist
even if it is not in the block IO timing paths.
I have requested an enhancement to have commands such as add_ilm_object
and remove_ilm_object. Commands like this would allow users to customize
the ILM model for uses in many other EDA tools. Synopsys has not agreed
to adding these commands.
- Floorplan Manager doesn't support ILMs either
We have not used ILM with Floorplan Manager. It seems like an excellent
match for ILM's. The main reason why we have not tried this is because
we have not had much sucess using Floorplan Manager (Layout Based
Optimization) to fix RC delay problems. Floorplan Manager seems to work
well for upsizing. We have had more success using physical tools to
address RC delay issues. PhysOpt is planning on supporting ILM flow.
Maybe this will help with timing closure.
Let me know if any of this is unclear. Some of the issues are hard to
explain without pictures. Overall I think ILMs are a good capability in
PrimeTime. However, ILM verification may be difficult if the block is not
structured well. We have one design with lots of clocks, many generated
clocks (and lots of MUXes), it would be very hard to verify that the
generated ILM understood the clock structure correct.
I would be very interested in hearing other people's experience with this.
By the way, I would also be really interested in knowing if others are able
to run PrimeTime in a hierarchical mode using detailed parasitics. This
involves using read_parasitics -increment to read in each block level
dnet.spef file and then the top level. I have tried this and the tool gives
a load of false errors since it has not gotten the full RC network yet.
The report_annotated_parasitic command does not work well, so you have to
write tcl scripts to figure out if all the parasitics are annotated.
The compete_net_parasitic command is also error prone and should not be a
global command.
I do not want to go on and on, but I am very interested in hierarchical
methodology. There was some of this at SNUG but it was very vague. It
also does not specify how many iterations and when the handoffs (block
level constraints, etc.) occur.
- Bruce Zahn
Agere Systems Allentown, PA
|
|
