( ESNUG 370 Item 11 ) ------------------------------------------- [05/17/01]
Subject: Get Cadence Silicon Ensemble Parasitics Into Synopsys Design Power
> I have some problems during the back-annotation of parasitics from Cadence
> Silicon Ensemble to Synopsys Design Power. After having completed
> floorplanning and P&R with Silicon Ensemble Ultra, I generate a Verilog
> netlist (including a clock tree). Additionally, I extract parasitics
> (setload file) from the layout within Silicon Ensemble Ultra/HyperExtract.
>
> I read in the Verilog netlist in Synopsys DesignAnalyzer & Design Power
> and try to back-annotate the setload file, but I get errors, because the
> names of clock nets in the Verilog netlist and the setload file differ.
> e.g. in Verilog netlist:
>
> clk_L1_I1__5 , clk_L2_I1__4 , clk_L3_I1__3 , clk_L4_I1__2 ,
> clk_L5_I1__1
>
> in setload file:
>
> clk_L5_N1, clk_L4_N1, clk_L3_N1, clk_L2_N1, clk_L1_N1
>
> Has anyone an idea, if there have to be set variables within Silicon
> Ensemble or to solve the problem in an other way?
>
> - Armin Windschiegl
> Technische Universitaet Muenchen Germany
From: Gary Nunn <garyn@cadence.com>
Hi Armin,
If the set_load file is coming from Silicon Ensemble's extraction or
estimation then you can use the following envar to have SE output a
pin-based set_load file:
SET VAR REPORT.SETLOAD.USE.NETNAME FALSE ;
I don't think that HyperExtract has the same feature.
- Gary Nunn
Cadence
---- ---- ---- ---- ---- ---- ----
From: Armin Windschiegl <arminw@lis.e-technik.tu-muenchen.de>
Hi Gary,
You are right - HyperExtract doesn't have this feature. I could not create
a setload file, which uses the same names for clock nets like given in the
Verilog netlist.
The problem's roots seems to be in the step "Export Verilog". When
selecting the clock nets in the my routed design, I can see that their
names are the same like given in the setload file. But how it creates the
command "Export Verilog" other clk-netnames, than given in the Silicon
Ensemble database? In the export Verilog form sheet there can only be set
a variable for VDD and GND pins.
The back-annotation of a Verilog netlist with a clock tree and a setload
file into power estimation tools should be a very common design flow. I
would be very grateful, if anybody could help to solve the problem.
- Armin Windschiegl
Technische Universitaet Muenchen Germany
---- ---- ---- ---- ---- ---- ----
From: Ralf Leisner <leisner@cadence.com>
Hello Armin,
There is a inconsistancy concerning the naming of inserted nets in our
layout tools on one hand and the 'hierachical-verilog-out-procedure' on
the other hand. If you do exchange files with netname references (like
RSPF) to tools outside Cadence, you may run in this kind of issues you
described. There are 2 solutions to get a consistant Verilog/RSPF-Pair:
1) Write out a flat Verilog netlist, because it is built up based on
the flat layout database and should reflect the flat representation
100% (including netnames).
2) Write out the hierachical Verilog netlist and read it back by ECO.
That would force the tool to syncronize the flat layout database with
the hier. Verilog netlist (including netnames). Repeat the RSPF
generation, and now the netnames should fit. Important:
- Write out the ECO report file after ECO and check it carefully
to ensure it reflects the changes you are expected.
- Set following variable: 'set v DEF.ECO.TRYRENAME TRUE;' It prevents
the tool (SEW/GE) from deleting routing informations of the
concerning nets.
Otherwise you would need to reroute the nets for which the names have been
changed.
- Ralf Leisner
Cadence Design Systems GmbH Haar, Germany
---- ---- ---- ---- ---- ---- ----
From: Gary Nunn <garyn@cadence.com>
The latest versions of SE have an "auto-resync" feature to update the net
names to be consistent with the hierarchical Verilog netlist. (As Ralf
noted, you need to run the parasitic extraction *after* the resync).
One minor change, the correct envar to set to allow the net renaming to
leave the routing intact is INPUT.DEF.ECO.TRYNETRENAME.
set var INPUT.DEF.ECO.TRYNETRENAME TRUE ;
The main issue with "net name based formats" is that there is no "standard"
defined for how flattened names will be stored. All of the companies agree
on the simple cases, but there are still a boundary case or two that differ
(I think that they are all associated with ports of intermediate modules
that have no connection at the instantiated level).
I definitely prefer Ralf's option #2. (The hierarchical netlist is more
readable/debuggable.)
- Gary Nunn
Cadence
|
|
