With an early
December tapeout looming, I've found myself too busy to write a post this week.
But then I thought, "Why not write about tapeout?". Here are some
things I try to do during a project so that those last few weeks before a
deadline are as stress-free as possible:
Run an early DRC as soon as you get all the library data.
have three phases of a project: preliminary, stable, and final. I don't feel
that a DRC run during preliminary is too soon. I usually pick an easy block
(but one that contains a representative sample of IP), and just get it placed
and routed with filler cells, so I can send it through DRC. (DRC doesn't care
if you're meeting timing.) This will be a good way to qualify the library data
you've received and make sure that the tech LEF matches the requirements of the
DRC deck. This way, if there are library issues, you have uncovered them in
time to get a fix from the vendor.
Run a power-grid only DRC of your top-level as soon as the grid is mostly
The majority of top-level DRC violations are due to the power grid:
via arrays, wide-metal spacing, etc. You can stream out a top-level design that
has just your power grid and the placement (including filler cells). If you can
get the power grid DRC-clean early on, you will save yourself a lot of time in
those last couple of weeks before tapeout.
About a month before tapeout, start running top-level DRC and fixing
By non-volatile errors, I mean ones that will stay
fixed once you fix them. There's no sense fixing a nanoroute violation if you
are still closing timing and doing ECO routes. The violation will just be
created again. But you will find lots of things that you can fix without your
work being undone.
Start LVS as soon as you possibly can.
LVS on blocks is usually easy
(and should be done along with DRC as soon as a block is timing closed and
"on the shelf"), but top-level LVS is always tricky. IOs, power
domains, analog vs digital, etc. usually mean some detective work with the
physical and/or spice netlist. Starting a full-chip LVS three or four weeks
before tapeout is not too soon.
Start power analysis as soon as possible.
All you need is for the
top-level to have clock trees, routes, and a spef file. You'd be surprised how
much can be uncovered during early power analysis. Once you have all the
command files set up, it will be easy to rerun when your top-level data has
Don't wait until the last minute to run LEC.
If you haven't run LEC
during the whole project, and you find at the very end that your final netlist
doesn't match the golden one, that could mean big problems. We try to run LEC
every time we save the database, to make sure that we haven't inadvertently
mangled the netlist. If you get an ECO during the project, make sure to update
the golden netlist too.
Conduct peer reviews.
It never hurts to check each other's work. Have
block designers swap designs and check everything you can think of. Have a
couple of people browse the top-level or full chip for any issues. It may help
to prepare a checklist of items that you know are important.
See if your foundry is willing to do a dry-run.
The data you send
would not need to be totally DRC clean, but can be used to flush out the flow
of GDS delivery, making sure the data looks how the foundry expects and to get
any DRC waivers in place.
Once you have taped out several chips, you kind of get a feel for what tasks
you should start early and what can really wait until the last minute. I'm
curious what other people find to be the bottlenecks during tapeout. Is it
timing closure? ECOs? SI? Power analysis? Physical verification? Something else
entirely? Let me know via the comments!