( ESNUG 434 Item 9 ) -------------------------------------------- [11/18/04]
Subject: ( ESNUG 433 #11 ) Magma, Hierarchy, Voltage Islands, and Astro
> I need HELP getting Magma to retain Verilog netlist hierarchy.
>
> We have a 0.18 micron (okay, no laughing) design utilizing voltage
> islands to shut off power to unused logic to eliminate leakage for
> our ultra-low power baseband. Our layout contractor (Qthink in San
> Diego) insists that their previous Magma customers have not needed
> to retain hierarchy (imagine closing on STA without it!)
>
> Magma thinks their tool should retain hierarchy without any issues
> even with the options needed for voltage islands and seem puzzled that
> their tool isn't working. Magma has offered an elevation call between
> our VP Engr and theirs which amounts to really nothing more than a
> fireworks display. So, I'm working the industry flagpole with 'real'
> folks who are actually solving problems like this.
>
> - Cindy Liebeck
> u-Nav Microelectronics Irvine, CA
From: Aishwarya Dubey <aish=user domain=ti spot calm>
Hi, John,
We have been using the Magma hierarchy preservation successfully for
some time now (also on mulitple voltage island devices). Basically, it
is all about using a sequence of "force maintain" and "force keep"
commands on required hierarchical boundaries while importing the netlist.
For example if I have a design netlist TOP.v :
module TOP (......)
output ......;
input ......;
TO_BE_PRESERVED inst ( ....... );
endmodule
module TO_BE_PRESERVED (...)
output ...;
input ...;
AND2 and_gate (...);
level_2_hier_module inst (......);
endmodule
And, requirement is to preserve hierarchy for TOP/inst and all the
hierarchies below it then one needs to do :
import netlist <TOP.v>
force maintain /work/TO_BE_PRESERVED/TO_BE_PRESERVED -hier
Alternatively, if no optimization is required on a particular module
(though I do'nt know why one would like to do this), then :
import netlist <TOP.v>
force keep /work/TO_BE_PRESERVED/TO_BE_PRESERVED
Post optimization, modules that were initially "maintained" come out as
a module (and not flat) in the output verilog netlist.
Please note that rest of the flow for importing netlist and constraints
i.e. (data flatten) etc. are to be done normally and Magma internally
maintains the "hierarchy preserve information".
This has been working for us since Magma 3.x.
- Aishwarya Dubey
Texas Instruments Bangalore, India
---- ---- ---- ---- ---- ---- ----
From: Rune Jensen <runej=user domain=microsoft spot calm>
Hi, John,
I also encountered the problem in Magma/Astro of doing netlist hierarchy
manipulations when partitioning the netlist into layout blocks that are
on separate power domains. It is a very efficient strategy for reducing
the power consumption of your design, but indeed can create significant
problems for the static timing analysis scripts, timing closure, timing
sign-off and LVS.
Implementing voltage islands have several problems -- among them the most
significant may well be:
1) Netlist partitioning to ensure the netlist matches the 'voltage
islands' creates problems for timing:
- The sdc files used for timing closure of each of the place and
route blocks in Magma/Astro need to be manually created.
- The STA scripts that matches the logical hierarchy, and as Cindy
pointed out, cannot be used for timing signoff.
2) You must ensure that repeaters used for buffering signals between 2
blocks are only placed in blocks on the same power domain. (i.e. the
repeater cannot be on a power domain that is suddenly turned off).
3) LVS requires explicit netlisting of the power nets for each of the
seperate power islands.
I see a 2 ways you can deal with this.
a) Manually:
This is what we originally did - and it is not a bad approach.
We changed the STA scripts such they could work for both the logical
hierarchy and the physical hierarchy (voltage island based). I posted
Primetime script guidelines to help accomplish this in ESNUG 422 #3 --
"PrimeTime Guidelines For Logical & Physical Design Hierarchy". Based
on Cindy's email it seems her problems with 2 and 3 have been solved
which is good. Indeed - a manual approach for 2 or 3 is possible and
will get you to tapeout in Magma or Astro.
b) Automated Approach.
While Astro can do hierarhical verilog generation, it has no options
to recreate hierarchy -- and also no options to manipulate the spef
to match the netlist. The only automated approach I know is available
from ReShape. Here is their approach to the problems listed above:
1) Netlist manipulations leads to STA problems.
1.1 SDC files for place and route block timing closure are
automatically generated from the STA scripts based on logic
hierarchy. This is done by tracking the hierarchy changes and
using that information in the sdc file generation.
1.2 For timing signoff -- ReShape recreates the netlist to match the
logic hierarchy. This means your STA scripts will work.
2) Placement of repeaters for interblock signals only in allowed voltage
island. During global repeater insertion you can put repeater
blockages in areas where the power supply cannot be guaranteed all
the time.
3) LVS netlisting -- The LVS netlist is done with power signals
explicitely netlisted. This allows you to tapeout without manually
doing changes to the power nets in your netlist.
So, in short, if you can 'get by' with the approach you have right now
and need to tapeout in 2 months I would consider changing your timing
scripts manually.
I would not be looking for Magma/Astro alone. I think your best bet is
the consider enhancing eg. an Astro environment with the ReShape tool
set. It should be noted though, ReShape's "hierarchical Verilog output"
feature is still new and -- like anything new -- still needs some mileage
and more tapeouts.
- Rune Jensen
Microsoft XBox Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Andrew Saunders <andrews=user domain=magma-da spot calm>
Hi John
Cindy did see some problems related to hierarchy maintenance when using
voltage islands. She reported 2 main issues:
- Crash during CTS
- Runtime issues
These were brought to Magma R&D's attention and they immediately jumped to
address them. The first issue was caused by a simple bug that has since
been fixed. The runtime issues were caused by the significant amount
(>3000 modules) of maintained hierarchy.
In Magma's system, the hierarchy boundary of a module can be maintained
using the 'force maintain' command before flattening. When the design
is eventually flattened internally we mark where the original hierarchy
was so that we can recreate it when exporting data later in the flow.
Here Cindy had used the -hier option of 'force maintain' because she
wanted to maintain the entire hierarchy.
In her particular case, after flattening the design there was a
significant runtime penalty in the code that traces thru the preserved
hierarchy boundaries to determine the voltage domain a net was associated
with. A workaround has been provided that reduces this runtime from hours
to minutes. R&D is also working on the native fix to handle these issues.
The fixes were provided to Cindy and subsequently everything has gone
smoothly. No new issues have been reported.
Finally, we would like to emphasize the fact that Magma's multi-Vdd
solution has been used by several customers successfully. Magma takes
pride in providing outstanding customer support and our customers
continue to vouch for that.
- Andrew Saunders
Magma Design Automation, Inc.
---- ---- ---- ---- ---- ---- ----
> We're rapidly closing on a December tapeout with no solution in sight
> from neither Magma nor Qthink other than go back to Astro. We know Astro
> has no problem retaining netlist hierarchy for designs withOUT voltage
> islands, but we have no experience with BOTH voltage islands and
> retention of hierarchy in Astro. I'm hoping that one of DeepChip's 90
> nanometer layout experts can help so I'm throwing out a rope for
> assistance. Help!
>
> - Cindy Liebeck
> u-Nav Microelectronics Irvine, CA
From: Hong-Nan Wu <hong-nan.wu=user domain=synopsys spot calm>
Hi, John :
In response to the question of whether Astro can preserve hierarchy in
design with Voltage Islands (ESUNG 433 #11):
Astro has the ability to preserve hierarchy for both single-vdd and
multi-vdd designs.
After the Verilog netlist is read into Astro, Cindy can specify the
modules for which hierarchy has to be preserved by using the commands
"astInitHierPreservation" and "astMarkHierAsPreserved". In multi-vdd
designs, voltage islands are used and hierarchy is preserved if the
modules are marked for hierarchy preservation. There are no new ports
added during optimization. Hierarchy is preserved for all the signal
nets. Cindy has to consider the reduced scope of optimization while
preserving module hierarchy.
1. Input the netlist.
2. Create a cell.
Create a cell view (.CEL) and bind the netlist view (.EXP).
3. Use Cell > Initialize Hierarchy Preservation
(astInitHierPreservation).
4. Mark the module instances in the design that are to be
preserved. Use Cell > Mark Module Instances Preserved
(astMarkHierAsPreserved), and save the cell. This command
provides options that you can use to selectively mark
module instances to be preserved.
Sometimes in order to preserve hierarchy, physical topology can create
segments where buffers cannot be inserted. In such cases, optimal
physical topology can be achieved by port punching (adding ports) during
optimization. The user can intentionally adds ports (buffers) to improve
optimization. Hence in the netlist, ports have to be added to match the
physical topology. Also during clock tree synthesis, Astro ignores
this directive of hierarchy preservation if there is a negative impact
on QoR. In order to improve QoR, clock ports may be added in certain
cases. Astro's behavior of adding clock ports to improve QoR is nothing
new and has been well received by the user community.
In order to preserve hierarchy in multi-vdd designs using voltage
islands, Cindy has to specify the modules for hierarchy preservation.
- Hong-Nan Wu
Synopsys, Inc.
|
|
