( ESNUG 405 Item 2 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #7 ) Rectilinear Blocks In PhysOpt/Apollo/Astro Flows
> For our upcoming hierarchical design chip, I see that our blocks will be
> well utilized based on the connectivity and functionality -- if our blocks
> are allowed to be rectilinear (non rectangular) in shape -- rather than
> the conventional rectangular shapes. Even though the EDA tools out there
> claim that they can handle rectilinear shapes, I am very positive that I
> will run into a lot of implementation and integration issues in doing so.
> So I am wondering if your readers have experience in handling rectilinear
> blocks, especially with Synopsys (PhysOpt)/ Avanti (Jupiter/Apollo) tools.
>
> Some stuff that I am curious about are
>
> 1. How difficult is it in getting the pins assigned when the number of
> edges exceeds 4?
> 2. Is power routing capable of dropping straps of different lengths
> because of different dimensions in one direction or do I have to
> manually alter the lengths?
> 3. Will writing out the GDSII have any problems?
> 4. Can the parasitic extractor handle arbitrary shaped blocks?
>
> Plus is there anything else that would make my life miserable here?
>
> - Jay Pragasam
> Brecis Communications San Jose, CA
From: Jon Stahl <the.one=jstahl the.many=avici pot domme>
Hi John,
We taped out a design last April using Jupiter/Physopt/Apollo and one "U"
shaped rectilinear block. The block had pins on 6 of the 8 sides. We taped
out with Avanti version 2000.2.3.4.0.8.4_64.
Surprisingly we found only one problem with the entire rectilinear flow. At
the time, the Jupiter function to align the pins of adjacent blocks didn't
work on our "U" block. I don't know if this has been fixed or not in later
rev.'s.
- Jon Stahl
Avici
---- ---- ---- ---- ---- ---- ----
From: Joerg Landmann <user=lama domain=oaktech.de cowcowcow>
John,
Here's some info about the rectilinear topic. In one of our latest designs,
we had done a U-shape core in a PhysOpt/Apollo flow.
- Pin assignment was semi-automatic using Jupiter and hand-placements.
Jupiter is hard to use, so we had to do a lot of manual tweaking.
- I can not remember any power routing problems. But since this can vary
so dramatically, this is not representative.
- GDSII: no problems.
- StarRC-XT: no problems.
But generating the keepout regions for PhysOpt (especially wiring) can be
a bit tricky.
- Joerg Landmann
Oak Technology Germany
---- ---- ---- ---- ---- ---- ----
From: Neel Das <mongol=neel.das horde=corrent squat qualm>
Hi John,
I wanted to send in my 2 cents in response to this query on rectilinear
clusters.
We at Corrent have the dubious distinction of having to deal with numerous
such clusters, using Cadence First Encounter (for tapeouts) and Synopsys
FloorPlan Compiler (currently in eval). We use a PhysOpt/Apollo flow to
implementation our clusters themselves.
My advice is to avoid them altogether and simplify your life. If you can't
do that,
a. don't trust marketing slides from your EDA vendor: make sure you
review pin assignments thoroughly on these.
b. make sure whatever floorplanner you're using has manual editing
capabilities(pin locations/geometries/layer etc).
c. if you have 'over-the-cluster' routing channels, make sure they're
getting built properly and are getting pushed down properly for
cluster implementation.
d. neither of the two design planning tools (Cadence nor Synopsys) I
mentioned above could deal well with multiply instantiated blocks
initially. We've had to spin mega hours with lots of people from
both companies concerning on this issue; fortunately the tools do
a pretty decent job for most cases.
e. if you have pins that are unconnected (or reserved for future logic,
eg. scan pins), prepare to place these by hand.
f. PhysOpt has trouble handling repeater-insertion type problems in
some cases, for long, thin floorplans. I've posted on this issue
in ESNUG 385 #11. What we do is place a max_cap constraint on the
design: PhysOpt seems to work better with a DRC constraint rather
than a timing constraint in such cases.
g. a general comment: watch out for congestion! Post-route optimization
doesn't work well (particularly for DRCs) if there is congestion.
This will continue to be the case until the routing algo's within and
outside PhysOpt converge.
h. we didn't run into specific issues wrt extraction/ phys verification
on these. Our issues were in the areas of design planning and
implementation (PhysOpt).
Hope this helps: good luck!
- Neel Das
Corrent Corp. Tempe, AZ
---- ---- ---- ---- ---- ---- ----
From: Andy Tan <wolf=atan pack=synopsys yacht palm>
Hi John,
PhysOpt supports rectilinear macros that is described as combination of
multiple rectangles. Each rectangle must be modeled as overlap layers
in the physical library. A rectilinear outline around the multi-rectangle
shape is created and areas around the shape can be used to place cells.
You specify keepout margins for the resulting rectilinear shape as well.
The rectilinear outline and keepout margins are used for placement and
legalization of leaf cells around the macros.
The variable that supports rectilinear shapes is
set physopt_rectilinear_macros true
By default, this variable is FALSE in version 2001.08. This variable will
be set to TRUE in version 2002.05, and onwards.
To handle these macros, a special library syntax is needed. We need to use
LEF OVERLAP syntax to model the strange shapes. This defines a "placement
blockage layer" in addition to the standard routing layers that are
normally declared.
A MACRO OBS statement can contain an obstruction with a LAYER type of
"OVERLAP". If a MACRO has a OBStruction of a layer with type OVERLAP, this
forms the placement obstructions for the MACRO and the MACRO bounding box
is no longer applicable for placement obstructions. This is usually already
described in your Physical Library (LEF) that you get from your ASIC vendor.
The number of RECT statements in the OBS construct can be 1 or more. Using
more than 1 RECT statement forms a rectilinear shape that defines the
placement region for the macro. LEF syntax (and PLIB syntax) also allows
for the use of POLYGON statements to describe the OVERLAP outline.
1) Layer declaration LEF:
------------------------
Declare a layer of type OVERLAP along with the other layer declarations
in the LEF. Here a layer BLOCK_OVLP is declared, which is of type OVERLAP.
LAYER BLOCK_OVLP
TYPE OVERLAP ;
END BLOCK_OVLP
2) Placement Obstruction
------------------------
Inside the MACRO definition, along with the obstruction declaration for
all the metal layers, also put the obstruction for the above declared
layer. This layer obstruction is treated as a placement obstruction.
MACRO BLOCK
:
:
:all pin location declarations
:
:
OBS
LAYER MET5;
:
: all metal layer obstructions in layer 5
:
:
:
:other Layer obstructions
:
:
LAYER BLOCK_OVLP
RECT 0.0 0.0 440.0 4386.0 ;
RECT 440.0 559.875 2443.0 4386.0 ;
RECT 2443.0 312.0 4546.0 4386.0 ;
RECT 4546.0 2186.0 5292.0 4386.0 ;
END
END BLOCK
When the LEF is converted to PLIB format, the OVERLAP statements also are
translated. Then, when PhysOpt uses the cell, it recognizes the placement
obstruction being rectilinear and correctly handles the cell's rectilinear
outline. You can see this by looking at the leaf cell(s) using psyn_gui.
- Andy Tan
Synopsys
---- ---- ---- ---- ---- ---- ----
From: Yung Wuu <teacher=yung school=synopsys ought bomb>
Hi, John,
Here's the Astro/JupiterXT flow on the blocks with rectilinear floorplans:
. Readnetlist/expand/bind
. Create rectilinear floorplan: axgRectiPlanner
. Automatic shape generation for L shape, T shape, U shape and
Cross shape
. User can draw (or using Scheme) for other rectilinear shapes
manually.
. Specify pin location in TDF file
rPin "urcs" 28 0.28 0.28 1 1 4.9
rPin "addr[10]" 28 0.28 0.28 1 2 6.02
rPin "addr[7]" 28 0.28 0.28 1 3 7.14
rPin "addr[5]" 28 0.28 0.28 1 4 234.5
rPin "addr[4]" 28 0.28 0.28 1 5 238.98
rPin "addr[3]" 28 0.28 0.28 1 6 240.1
rPin "addr[2]" 28 0.28 0.28 1 7 244.58
. Place pins on rectilinear boundary in scheme command
(axRectiPinPlacement (geGetEditCell))
. The down stream commands support the rectilinear floorplan
. Power/Ground Routing (axgCreateCustomWires)
. placement
. optimization
. routing
. PARA view
. gdsII out
. netlist out
In JupiterXT:
. customer can generate the above shapes during the hierarchical
floorplanning.
. do pin assignment/opt for chanel-based or abut-based for the
rectilinear shapes
. cut PG down for the rectilinear shapes
Hope this helps.
- Yung Wuu
Synopsys
|
|
