( ESNUG 379 Item 13 ) ------------------------------------------- [10/11/01]
Subject: ( ESNUG 377 #10 ) Extract A Hierarchy From A Flat Gate Netlist
> When we do minor (typically metal-only) re-spins of our devices. We make
> our changes by hand at the gate level. We've gotten good at specifying
> the gate changes, but have run into a roadblock in verifying them. In the
> old days, our gate level netlists preserved hierarchy, and so it was easy
> to extract the module containing the fix and either use it to replace the
> RTL block in simulation, or (more recently) re-synth the RTL and
> Formality-check the synth'd gates to the hand-fixed gates. However,
> things like clock-tree-insertion and scan-reordering are now causing our
> gate-level netlists to be totally flat. Extracting a block of gates
> that's bristle-equivalent to an RTL block has become a non-trivial task.
> I was wondering if anyone out there had licked this problem?
>
> - Jeff Winston
> Mindspeed Technologies
From: "Sanjeev Patel" <sanjeev.patel@wipro.com>
John,
I have a couple of ideas:
1. If the gate instance names reflect the hierarchical block name, one
can *create the hierarchy by instance name* in synthesis tool. For
example, if all instances in block A are called uA_g1, uA_g2 etc in
the flat netlist of say design mychip, you can use a command to
"group mychip_uA_* " to re-create hierarchical block A in the netlist.
Then, write netlist for this block and use it in simulation along with
the rest of the blocks in RTL.
You have to be careful however to use switches that allow "preserving
of buses" and "avoiding feedthroughs" so that you get exactly the same
port list back as that in the RTL of that block. Also, you may need
to run sed commands to remove the prefixes that will appear in the port
names (legacy flat netlist.)
(I am using terms from Ambit, like create_hierarchy, preserve_busses
and -no_feedthrough, but I'm sure similar commands exist in Design
Compiler, too.)
This method is not my choice though. I would go the rather clean way,
enabled by logic equivalence checking. See below.
2. Make required changes to the netlist. Make equivalent change to the
RTL of the correspoding hierarchical block. Then perform a *new RTL
(full chip) to changed netlist* equivalence check. (Or alternately,
synthesize the new RTL and perform *newly synthesized chip netlist to
hand-edited chip netlist* compare.)
Here we simulate only RTL, no gates and hence is faster and cleaner.
Once RTL is found functionally okay, it's just a matter of a few hours
in equivalence check to validate the manual edits in netlist. The
process can be made even faster by selectively comparing only the
instances of interest while ignoring the others.
This is a good method for ECOs. Verplex easily handles RTL to netlist
equivalence check for large designs.
I can explain more if there are any questions.
- Sanjeev Patel
Wipro Technologies Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <gzimd@improvsys.com>
Hi, John,
I ran into the issues with a flattened layout and a hierarchical
design way back in my Big Yellow Box (read Kodak) days when we first
started working with Motorola as a vendor.
At that time after getting back a flattened design from their tools, I
created some scripts that used DC to re-group the parts in the flat
netlist back into their hierarchical "containers". This was possible
since with the Moto flow back then, the instances in the flattened
design had their names modified to contain their entire original path.
I started parsing the netlist and found all of the hierarchical block
names and then performed "group" commands working top down to generate
a "hierarchical" post layout netlist. This was done via a lot of
brut force techinques since back then I didn't know much Perl.
My basis for performing this task was to make life easier for me in
post-layout simulations so that I could make sense of nets that I was
tracing for timing. Even back then tracing through a flattened 100 K
gate netlist was absolutely NO fun... ;-)
Now working out this back-end flow was the last thing I was able to
complete before leaving back in '96 and I'm sure that there's better
ways to do it than the way I hacked together then. But suffice it to
say that DC and "group" using "find" and instance names makes the task
pretty quick and painless (after getting that first script together).
Anyway, I've thought for a long time that this should be a service
provided by the place and route tools. What designer just LOVES tracing
through a flat netlist to find a timing problem after working for months
on a hierarchical design to keep DC happiest??? Would be nice if after
P&R the tools could spit back a hierarchical netlist that was guaranteed
equivalent to the flattened one, generate hierarchical SDF to match and
feed THOSE files back to the designer for simulation and post-layout
verification, no??? (Speaking of SDF, I think that if the instances keep
their hierarchical names after flattening, you can end up using the same
SDF on both versions of the netlist, flat and hier.)
- Gzim Derti
Improv Systems, Inc. Rochester, NY
|
|
