( ESNUG 430 Item 9 ) --------------------------------------------- [06/16/04]
Subject: ( ESNUG 429 #5 ) AstroRail Uses Power Sources At Multiple Levels
> The AstroRail form that generates the CSF file has several check boxes in
> the "Intersections Types" area : polycont, M1-2, M2-3, M3-4, M4-5... This
> tells it where to create current sources. AstroRail allows me to select
> several Intersection Types at one time. I don't understand this. It
> should allow only one check box because if there are several Intersection
> Types there are current sources at different layers? The assumption that
> the transistor-level power having current sources at more than one layer
> seems excessive (too much). One layer current source should do.
>
> What do you know about this? Where can I get detailed info of the way the
> algorithm of the "rail analysis" of hard macros work? How does AstroRail
> use the supplied current source file?
>
> - Gal Gottlieb
> DSP Group, Inc. Hertzelia, Israel
From: Michael Zaslavsky <michael.zaslavsky=user domain=intel got calm>
Hi, John,
I believe you can see what CSF data AstroRail will be using by dumping them
into a file with "poDumpCurrSource" command. By default, all interesection
nodes are assigned with the same value of 1, which means the total current
will be equally distributed between them.
You can change this by editing the file and reading it back into the
Milkyway DB with "poGenCurrSource" command. For example, you can make some
areas of the block to be assigned bigger current.
As for the fact the tool allows you to choose the intersection nodes at
different levels simultaneously, I can only guess that in some cases one
may want to have such a freedom.
- Michael Zaslavsky
Intel Corp.
---- ---- ---- ---- ---- ---- ----
From: Vishal Sharma <vishal=user domain=genesis-microchip got calm>
Hi, John,
For any power analysis tool, two factors are paramount: the PG rail
network, and the current sink (the term "current source" is a misnomer)
points. AstroRail cannot do transistor level extraction, and thus
resorts to "smart approximations" to be reasonably accurate for current
sink points.
In the AstroRail flow, dealing with std.cells is pretty straightforward,
as std.cells will have only one power/gnd pin. AstroRail assumes all
power consumption of a std cell to be centered at the mid-point of the
std cell power pin (as given by the FRAM view). This is acceptable as
std cells are not that big (area-wise), and this approximation works
well.
But for hard macros (memories, etc.), which are huge in size (area-wise,
as compared to std.cells), this is no good. By default, AstroRail
assumes that power consumption of a hard macro is evenly provided by all
the power pins of that macro. This is a very crude approximation, which
will give erroneous results. To make the PG-rail analysis (and the
eventual power analysis) more accurate, AstroRail provides a way out by
creating CONN views/CSF files for macros.
CONN view of a macro has the power/gnd network inside the macro. This
helps AstroRail have a look inside the macro for the PG rail structure
(which blends seamlessly with the fullchip PG-rail structure), and do a
proper analysis. The only problem remaining now is determining the
current sink points for the macro. As mentioned earlier, AstroRail does
not have the capability of doing a transistor-level extraction. Instead,
it uses a pretty smart way of coming up with current sink points of a
macro at all metal-metal intersections (this information is generated in
a CSF file).
CSF file creation just checks for metal-metal intersection points inside
the macro, and every intersection is assumed to a current sink. The CSF
files are stored under the CONN sub-directory of the Astro library
directory, and these are text files which can be viewed (check files
under CONN sub-directory with _1, _2, etc. suffixes). Each of these
files will represent a particular power/gnd net, and list its current
sinks for the macro. Checking any of these CSF files will reveal that
each and every via of the power net is taken as a current sink.
Allowing the user to select several intersection types (met3-met4,
met2-met1, etc.) is reasonable. The tool is trying to distribute the
current sinks as much as possible within the macro, since it cannot do a
transistor level extraction. Any PG network (within a macro, or
otherwise) will be a mesh of wires of different metals. AstroRail simply
distributes all the hard macro power among these metal-metal
intersection current sinks. Of course I don't know the algorithm working
behind this (maybe somebody at Synopsys can shed some light on this).
Still it seems reasonable that the tool is trying to distribute the
total power to as many points within the macro as possible.
On a relevant note, VoltageStorm is a much stronger/better tool for
power analysis. It has a transistor-level extractor built into it, so it
does not need any "smart approximations" (CONN views/CSF files of
AstroRail). But if your basic P&R tool is Astro, then the database
conversion back-and-forth between Synopsys (Astro P&R) and Cadence
(VoltageStorm power analysis) formats is a big pain, and could be
critical (time wise) for fast Layout cycles of relatively smaller chips.
- Vishal Sharma
Genesis-Microchip Bangalore, India
|
|
