( ESNUG 362 Item 9 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 361 #1 ) PKS Tape-out, Layout Staffs, Project Schedules
> I know your readers are design engineers, so I thought I'd send you my
> detailed experiences using PKS on a tape-out.
>
> I'm a chip designer but my sidebar task here at Geocast is to also be the
> methodology guy, too. I set up our PKS flow here and we recently did two
> 200 Kgate tape-outs to test the PKS flow with our in-house custom standard
> cell library. We used MOSIS TSMC 0.18 and TSMC's CyberShuttle service.
>
> We used PKS v3.0.19. The design was 200K gates of synthesized logic...
>
> - Thad McCracken
> Geocast Networks Systems, Inc. Beaverton, OR
From: [ Jake Buurma, Senior VP of Engineering at Cadence ]
To: John Cooley <jcooley@world.std.com>
John,
Wow, what a great PKS article! It's HOT!
I don't care what all the other EDA companies say about you, I think you're
alright.
Thanks
- Jake Buurma, Senior VP of Engineering
Cadence San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: John Ireland <John.Ireland@philips.com>
To: Thad McCracken <thad@geocast.com>
Hi Thad,
My name is John Ireland. I work for Philips Semiconductors in Southampton,
UK. I'm e-mailing in response to your mail to John Cooley, which was
included in the ESNUG post 361.
I read with much interest about your experiences involving the PKS Ambit
flow. We are about to use this flow, targeted at a VERY similar technology
so your experiences will be of much use to us. Our design is of a similar
size to yours, and with similar clock speed requirements. I have a couple
of questions and would really appreciate it if you could find the time to
answer them.
1.) Did your design include any SRAM instances / Analogue blocks (Apart
from PLL's)?
2.) This is the most important one. Could you put a rough estimate on
the timescales. Both from RTL to tapeout and on the smaller parts
of the design flow. We are working to reduce the time in layout, and
anything that helps this would be useful.
3.) What is the impact of a late design change (assuming you had one).
We nearly always have a small change as tapeout draws near and the
impact that has can vary wildly.
4.) Just so I can scale the answer to (2). How many people were dedicated
to the layout process. We will probably have 10 people working on it.
Any other useful information/pitfalls will be well received.
- John Ireland
Philips Semiconductors - CD/DVD Systems Southampton, UK
---- ---- ---- ---- ---- ---- ----
From: Thad McCracken <thad@geocast.com>
To: John Ireland <John.Ireland@philips.com>
Hi John, (& John),
I've attached my response to John Ireland's questions.
> 1.) Did your design include any SRAM instances / Analogue blocks (Apart
> from PLL's)?
The design had a DLL, clock multiplier, numerous register file instances
(not SRAM), and a CAM.
> 2.) This is the most important one. Could you put a rough estimate on
> the timescales. Both from RTL to tapeout and on the smaller parts
> of the design flow. We are working to reduce the time in layout,
> and anything that helps this would be useful.
The time it took to get from RTL complete to taped-out design (i.e. the
LVS/DRC clean GDS has been shipped) was about 6 weeks. The two big ticket
items we spent time doing were:
1.) Floorplanning the chip. The general order in which I did this was
as follows:
- produce pad-ring .def file, which places all the pads and
defines the size of the chip and serves as a starting point
for everything else.
- add standard cell rows to core of chip
- place hard macros (rams, cam, DLL, clock multiplier), cut
standard cell rows around these (i.e. make halos).
- power grid the whole chip. The way in which this is done
obviously varies. We build a "less dense" grid using M2 to
drive the M1 straps that are built into the standard cell
rows, and overlay that with a dense M5/M6 grid that redrives
the M2 grid as necessary, dependent on design requirements.
We find that this gets us decent placement densities without
overly impacting routing congestion. Other aspects of power
gridding are placing rings around the entire core and
the macros, and tying power/ground pins on the IO cells to
the core ring. Finally, we put endcap cells on each standard
cell row and tie them to the core/macro rings as well.
2.) Iterate this floorplan through PKS. If you have few to no
macros in your design then you may need only one or two iterations
to get an acceptable floorplan. I found that I needed to do
several iterations to get macro placements that were optimal
for general logic placment and for clock tree insertion. In general
it's best to put macros near the edges of the P&R block so that
the area in which standard cells are placed is as close to rectangular
as possible. As far as iteration time, a rough breakdown of
this was as follows:
- synthesize from scratch given new floorplan (7 hours)
- insert clock tree, hook up scan chain, add (1 hour)
filler cells
- route chip (4 hours)
- Extract RC (the fast way), timing analysis (1 hour)
- Extract RC (Hyperextract), timing analysis (5 hours)
So the total for an iteration (RTL synthesized, placed and routed
gates) was 13 to 17 hours, depending on whether you wanted to
Hyperextract that iteration or not. I typically didn't unless it
was looking good and wanted to verify that against more accurate
data.
Problems with a given floorplan usually showed up as timing
problems that could be traced back to routing congestion caused
by poor macro placements. Adjustment of macro placements obviously
requires at least some of the floorplanning steps enumerated above
to be redone. This analyze and adjust period was the major
time consumer in getting to a stable, usable floorplan. I eventually
got to a mostly automated collection of scripts to speed this
process, but have found it difficult to automate in a generic
fashion.
I found that #1 above was the biggest time consumer for this chip, for
various reasons. I probably spent 2-3 weeks of my time on #1 - most of it
constructing the power grid for the chip. Many could probably do this
faster, as I was learning a lot about SE's capability in this area, and also
learning how to represent power pins on I/O cells, etc. such that the power
router would automatically recognize them. The end result of this effort
was a set of scripts that constructed the pad ring, floorplan, and power
grid in about an hour.
Once #1 was completed, I spent another week or so iterating on it as
described in #2 until I was satisfied with the macro placements.
The remaining 2-3 weeks was spent doing a variety of things:
- designing, implementing, and validating any new RTL (most of the
RTL was taken from a previous chip)
- wrapping up specifics of our scan methodology and integrating it
into our flow
- Fault grading the chip
- Adjusting for a late design change (see answer to #3 below)
- LVS/DRC - we did several trial runs through this part of the
flow along the way to work it out.
> 3.) What is the impact of a late design change (assuming you had one).
> We nearly always have a small change as tapeout draws near and the
> impact that has can vary wildly.
We had to deal with several late design changes along the way:
- we were finishing up our RAMs in parallel with the rest of the chip,
and in one case had a RAM macro's size come out slightly bigger than
we estimated - just enough bigger to require the halo and power ring
around the RAM to need a change. I had anticipated this when
writing the scripts to do #1 discussed above, so this change amounted
to the ~1hour it took for those scripts to run and make a new floorplan,
followed by the iteration time to resynthesize, place, route,
extract, etc. So the entire impact of this change was about 1 day.
In this case the size change did not significantly impact standard
cell row utilization so no adjustments to the die size were necessary.
- Our clock multiplier was the last custom block to get finished, and
turned out to be significantly bigger than expected, and left the core
over-utilized. To adjust for this I had to increase the size of
the die by one pad width on each side and adjust the chip floorplan
accordingly. I had to tweak my floorplanning scripts a little to
deal with this, then re-synthesize, place, route, etc. The impact
of this change was on the order of 1.5 days.
In general if your design is meeting timing, the impact of a late design
change (assuming it doesn't introduce a new timing path or cause the design
to outgrow it's allotted area) will be the time it takes to run the design
through PKS, CTGEN, and SE. If the change does impact die size then the
impact will largely depend on how tolerable that impact is, and how easily
the floorplan can be tweaked to accommodate the change.
> 4.) Just so I can scale the answer to (2). How many people were dedicated
> to the layout process. We will probably have 10 people working on it.
I've listed below the number of people we had working on this chip, and what
their responsibilities were.
2 layout guys, on layout of custom macros and I/Os
2 circuit designers (circuit design of custom macros and I/O cells)
1 physical designer doing DRC/LVS, macros abstract generation, etc.
1 designer on logic design of DLL and clock multiplier
1 designer on formal verification of custom macros and ATPG
1 designer on RTL, full-chip floorplan, synthesis, P&R.
Some of the custom work (on the I/O cells and some of the arrays) started
prior to the six-week time frame in which we taped out this chip.
Had we finished all the "building blocks" (i.e. arrays, DLL, etc.) prior to
doing the logic design and implementation then the chip could have been
taped out in the same 6-week time frame with 1-2 designers and the physical
designer mentioned above. I mention this only because I'm not sure if you
guys are doing your own custom design, taking those blocks from a previous
chip, or getting them from a vendor.
On the flip side, most the RTL was taken from a previous chip, so there was
little new design and validation to do.
- Thad McCracken
Geocast Networks Systems, Inc. Beaverton, OR
( ESNUG 362 Networking Section ) --------------------------------- [11/30/00]
San Diego, CA -- Pre-IPO startup Astute Networks seeks ASIC design, verif.,
and layout engineers. Death to headhunters! "mike@astutenetworks.com"
Phoenix, AZ. -- Pre-IPO start-up Gain Technology seeks ASIC design engineer
for design and verification. No Headhunters, please. "mmonks@gain.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
