Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *


Comments(9)Filed under: Digital Implementation, DRC, ECO, LVS, LEC, tapeout, power analysis


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!



By eminemshow on November 20, 2008
Kari, Really Great Experience Sharing.

By PramodSabnis on November 24, 2008
Hello Kari, I am working on a Mixed Signal Physicl Design. Half the die is digital and half of it is Analog/RF. It has been decided early in the flow that Digital will be done separately and we will pins on one complete side of the digital so that the RF can Hook up to it on the top. Problem is carrying out the signoff DRC/LVS at chip level on half the GDS. i.e. When I run "verifyConnectivity -type regular" it is clean but when I run it with "-type all" I get a huge number of violation on IO ring. This is possibly due to incomplete IO power ring that the power nets are open. How can I handle this? Or is this expected?

By rodomir on November 24, 2008
Hello Kari and thanks for your post.
The answer for me it is LVS on top level in a mixed signal chips...
To PramodSabnis - maybe need to add some pad fillers?

By Scrivner on November 24, 2008
My biggest bottleneck is not getting a good set of constraints from the RTL coders until the last minute. Our schedules are so short and the designers so busy that it's like pulling teeth to get constraints from them. It's low priority for them because they don't have to have them for what they're doing. So I have to hope and pray that I'm able to swap out my generic constraints with the real ones at the last minute and everything still works.

By Pramod B Sabnis on November 28, 2008
This is to Rodomir: I am following all the physical design practices. That includes adding fillers to the pad ring. What I noticed though, is that, the corner cells LEF just had pins on two of its internal edges instead of the complete ring. Hence, per se, the ring is not complete. Top level LVS with Caliber was clean since it used the GDS of the corner cell.

By maven7783 on December 2, 2008
Thanks Kari,

By Kari on December 2, 2008
Thanks for the comments, everyone!
Scrivner - I totally hear you on the constraint issue. This bites us a lot.
Pramod - pin/blockage issues can make a top-level verifyConnectivity kind of muddy - it does the best it can with the LEF models it has. Of course your Calibre run with the GDS is the signoff - another good reason to run early DRC. I should have specifically mentioned running DRC on the IO Ring as early as you can, that is another thing that we try to do.

By Dipak Chaphle on January 13, 2009
Hi Kari, Its a good post by you. I am preparing a checklist for a full chip analog & mixed signal IC layout, so that it will be helpfull to me & my teammates. I have included many things in my checklist, but i want to be very through to this ckecklist. Can you please tell me the different steps, all the reliability and critical checks to be done on Full chip right from top level floorplaning to final GDS tape varification.

By Kari on February 11, 2009
Hi Dipak, unfortunately I would not be able to come up with a good checklist for your specific design, since I am not familiar with it. The best people to come up with the checklist is the team that worked on all phases of the design. As you go through, keep a list of all those little things that nag at you, giving you the feeling "we had better make sure..." or "we need to double check this at the end...". The minimum checks will be covered by timing and SI analysis, power analysis, DRC, and LVS, but every design has specific things that the designers want to look at one final time before taping out. I'm sure you've got a good list going already. Get input from the rest of your team and maybe some other teams, just to cover things you may have forgotten. Then you may want to put the checklist in a spreadsheet so you can reuse it for different designs. Sorry I can't give you anything specific, but I hope these ideas help a little.

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.