( ESNUG 382 Item 4 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #1 ) More On Crazy DC Net Names & Grouping In PhysOpt
> ... oddities with DC 2000.11 and 2001.08-1 when going into our PhysOpt
> flow (gates-to-placed-gates). DC appears to keep multiple names of
> particular items within the database for nets and ports and may write out
> a different name to a Verilog file vs a .db file.
>
> What may be called port "foo" in Verilog could be referenced as "nm156"
> in the .db file. Your chances of finding the right one is about as lucky
> as hitting a home run into the right-field pool off Schilling or Johnson.
>
> - Gregg Lahti
> Corrent Corp. Tempe, AZ
From: "Gregg Lahti" <gregg.lahti@corrent.com>
Hi, John,
To recap, sometimes designs in PhysOpt need to get grouped into different
hierarchy for various reasons, such as feeding PhysOpt with a sweet-spot
gate count of about 150K gates or globbing designs into clock domains. DC
will allow grouping, but signal names may get changed into weird nXXXX
values. This makes downstream operations such as debugging, budgeting, etc.,
difficult. I posted the switches we used to keep this 'feature' of DC down
to a minimum using only Verilog netlists in ESNUG 381 #1.
However, using Verilog-only netlists isn't always feasible. Case in point:
working with scan or clock-gating designs. DC makes full use of the
attributes fields and attaches clock-gating attributes on the clock gating
cells of the netlist. Going to a Verilog netlist from the .db file
eliminates these attributes and will cause serious pain during an
"insert_dft" operation in PhysOpt when it fails to find a scan enable pin on
your clock-gating latch. The .db file(s) must be used when going from DC
to PhysOpt for G2PG operation, but that crazy naming issue still requires
resolution at grouping to yield a useful netlist.
A workaround is to: 1.) write out the top-level of the hierarchies that you
want to keep naming convention boundaries on into a netlist, 2.) remove
the design, and 3.) then read it back. This method works well in the case
of grouping designs together where DC forgets about the actual name and uses
the (infernal) internal nXXXX name. Sounds odd, but here's the steps:
current_design rush;
change_names -hier -rules layout_friendly_verilog -verb;
group -design_name signals -cell_name signals {neil geddy alex};
write -f verilog -o signals.v signals; #NOTE! no -hier option!
remove_design signals;
read_file -f verilog -netlist signals.v;
link;
write -f db -h -o rush.db rush;
The first change_names step is customized to our back-end layout tool. The
last write step is to write out the entire netlist, but with the hierarchy
boundary netnames and the cell attributes preserved. We write out the
clustered items out so we can separately send these through our PhysOpt flow
while taking the entire netlist through our layout tools or RTL floorplanner.
This also works pleasingly well in our DC/PrimeTime/DC/PhysOpt gyration when
applying constraints or budgeting in the PrimeTime operation, since the port
names are now set back to the original design. (It would sure be nice for
PrimeTime to write out a constrainted .db file and eliminate the step back
to DC.)
I've also used the above method to effectively remove unconnected ports in
sub-hierarchy designs. For those that haven't tried, DC will error on the
link command if you do a remove_port on an unconnected port of a sub-design.
(I found a STAR on this dating back to ver 3.0 with the resolution that it
wouldn't be fixed.) The design at that point may not even write out
correctly, and I've had it not write out the sub-design of the removed port
on a 'write -hier -f verilog' command. The remove_unconnected_ports command
didn't work in my situation since the design had multiple instances of a
design and wasn't non-unique.
- Gregg Lahti
Corrent Corp. Tempe, AZ
|
|
