Tapeout!

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.
We usually 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 done.
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 non-volatile errors.
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 been updated.

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!