Layout Magnification

I need in SKILL function for magnification (scaling/shrinking) the
layout (all objects in layout).

How do it ?

 

Maybe you can export the layout to GDSII stream and then import it back into
Cadence. During either the import or the export you can change the scaling
parameter (Scale UU/DBU), and that should scale everything in the layout.
Maybe you can even change the DBUperUU parameter in SKILL without streaming
the layout in and out. This seems like the easiest thing to do and it works
with hierarchy and an entire library, but if might cause other problems.

Frank

 

Or you could use the "scale" UNIX command (this is documented somewhere
in the documentation) - if you just type "scale" it will prompt you for a
library name, view name, and a new DBUperUU. It will then change all
cellViews with a matching lib and view name - scaling the data units
appropriately.

Andrew.

 

Andrew Beckett wrote:

Ok, thanks!

 

Most translators handle scaling & database units per user unit.
For example, "PIPO" & "Scale" have already been mentioned.
File->Import/Export, LEF, DEF, etc. also handle scaling if
I remember correctly. But, it may be better to separate these
two different (yet related) tasks of sizing & resolution.

<SOAPBOX>
The problem with all of these, I think, is that they mix
magnification with database units (DBUperUU). In a fundamental
sense, these are totally different concepts (albeit related).
DBUperUU is fundamentally resolution.
Scaling is fundamentally size.

A bit more precisely, DBUperUU is the number of DB units in one
user unit (for historical reasons a user unit is almost always
a micron, though in theory it could be other values).

The manufacturing grid determines which DB units are possible.
The manufacturing grid must be an even multiple of the internal
units. This is needed so that objects defined in terms of their
centerlines (such as wires and vias) can have their centers
represented as an integer number of DB units.

For reasons of dynamic range, coordinates shouldn't exceed
the size of a 32 bit integer. The smallest practical value
is desired, so don't just set the DBperUU to some huge value
and be done with it. Choose the DBUperUU wisely.

For reasons of compatibility between custom & digital flows,
DBUperUU values are typically restricted to values of 100,
200, 1000 and 2000 (which, not surprisingly, are the only
values supported officially in LEF).

To pick a DBUperUU, refer to the following (abbreviated) table:

MFG_GRID: Possible_DBperUUs: Recommended_DBUperUU:
0.1 micron (100 nm) 100, 200, 1000, or 2000 1000 (1.0 um & above)
0.05 micron (50 nm) 200, 1000, or 2000 1000 (0.5 um & above)
0.01 micron (10 nm) 200, 1000, or 2000 1000 (250 nm & above)
0.005 micron (5 nm) 2000 2000 ( 90 nm & above)
0.002 micron (2 nm) 1000, or 2000 2000 (experimental)
0.001 micron (1 nm) 2000 2000 (not yet needed)

Separating DBUperUU from sizing makes good sense most of the time.

The good news is there is a new DFII "XScale" command, shipped
only with the DFII on OpenAccess CDROM, which JUST does sizing.

The (unrelated really) DBUperUU modifications, admittedly less
confusing in OpenAccess than in CDBA, can be done simply by
spitting out the techfile, changing the DBUperUU setting, and
reading the OpenAccess techfile back in. This works because,
in DFII on OpenAccess, the DBUperUU is stored only in 1 place
(unlike DFII on CDBA, which has multiple locations for DBUperUU,
including environment variables, techfiles, cellviews, etc.).

I haven't used XScale personally, but members of my flow team
have used it extensively in getting 30-million transistor SoCs
designed and built to test the EDA software (shown at DAC in
San Diego this year). We constantly mix 90nm OpenAccess designs
built at 1000 DBUperUU and 2000 DBUperUU (preferred) with
digital blocks, typically built at 2000 DBUperUU in the Virtuoso
Chip Editor, Assura DRC/LVS/RCX, and related tool sets.

We employ "XScale" (not "Scale" or "PIPO" or "LEF/DEF in/out)
when we mix those OpenAccess custom and digital blocks.

In summary, instead of using the traditional mix of both sizing
and resolution in the same command, separating the two (which
can easily be done with DFII on OpenAccess) may be a better,
simpler, less error prone approach in the future.

</SOAPBOX>

John Gianni