Matthew Hogan's BlogMatthew Hogan's Blog RSS
Designers are discovering a new class of design errors that is difficult to check using more traditional methods, and can potentially affect a wide range of IC designs, especially where high reliability is a must. There errors require electrical rule checking to complement the tradition layout checks.
Electrical rules are relatively complex, non-standard, and growing in number and type, creating a need for a highly flexible, user-configurable tool. ERCs are important, but particularly challenging in designs with multiple voltage domains and mixed analog/digital circuits, such as low-power devices targeting mobile and other battery-powered applications.
Designs that incorporate multiple power domain checks are particularly susceptible to subtle design errors that are difficult to identify in the simulation space or with traditional PV techniques. Often these subtle errors don’t result in immediate part failure, but performance degradation over time. For example, Negative Bias Temperature Instability (NBTI) leads to the threshold voltage of PMOS transistors increasing over time, resulting in reduced switching speeds for logic gates. Another effect is Hot Carrier Injection (HCI), which alters the threshold voltage of NMOS devices over time. Soft breakdown (SBD) also contributes as a time-dependent failure mechanism, contributing to the degradation effects of gate oxide breakdown.
Some electrical rule checks are based on the netlist and include looking for floating devices, nets, or pins, detecting thin gates connected to excessive voltages, checking for violations of the maximum allowed number of series pass gates, and finding issues related to level shifter designs. Other checks are performed using geometric layout information, such as net area ratios for antenna rules, floating wells, and minimum “hot” NWELL width.
An important application of ERC is verifying that electrostatic discharge (ESD) protection circuits are in place wherever the device is vulnerable, whether those circuits are included in the schematic and netlist or not. To ensure a robust design, the ERC tool must go beyond simple schematic or netlist-to-layout verification and recognize where ESD protection elements are needed, based on combined information from the netlist and the layout topology.
In multiple power domains, other precautions have to be considered. For example, IP reuse may require more robust rules to avoid device burnout at the system integration stage. This is particularly the case where an IP block is being re-targeted to a different process node or power domain. The introduction of lower voltage power domains is also an area where IP reuse and the contribution to the overall reliability of the chip must be considered. Often, to attain lower voltage thresholds for lower power circuits, the oxide layer of a transistor is made thinner. While this has significant voltage and power benefits, there are potential problems when thin-oxide gates have paths to specific voltage rails. To avoid long term damage to the gate over a period of time, which results in performance degradation, the voltage rail must be carefully chosen. A previous implementation may have the gate tied at a voltage that is too high for the current use.
Successful integration of physical IP blocks requires knowledge of the design hierarchy as well as the structure of voltage domains and cell voltage constraints. Design hierarchy also comes into play when one set of rules is applied to upper layer interconnects and pad frames, while different rules are applied between blocks crossing multiple power domains.
As ERC becomes more critical to producing a reliable product, designers and engineers are constantly discovering new checks that they would like to make during verification. These checks are based on their accumulated knowledge and best practices of design groups; thus, there is no “standard” set of checks. Consequently, it is crucial that an ERC tool be easily programmable, allowing users to adapt it quickly to new checks as they become needed.
There is more information available on this topic as well as Calibre PERC, an ERC tool specifically developed to address advanced circuit verification issues, at http://www.mentor.com/products/ic_nanometer_design/techpubs/addressing-reliability-and-circuit-verification-challenges-with-calibre-perc-42217 and http://www.mentor.com/products/ic_nanometer_design/multimedia/circuit-verification-design-reliability.
Mentor will also be presenting on this topic at the free Tech Design Forum on March 10 in Santa Clara (http://www.edatechforum.com/events/santa-clara/event.cfm). Look for the session “Successful Analog Mixed Signal Design at Advanced Nodes.”
Verification of ESD structures and other protection circuits is often a time consuming and tedious task. How do you do it? Complex DRC rules? An assortment of specialized rule decks? Home-brew tools?
Recently a colleague and I published a paper which used one of the Mentor tools (Calibre® PERC) to help with this ESD checking.
If you’re interested, the paper is available on-line here:
New Flow for Automating Verification of ESD Design Rules
Also of interest is the ESDA Symposium in the Los Angeles area (Anaheim to be precise) over the coming week. I’d encourage you to pop in if you can. Last year’s event was our first at the ESDA Symposium, and it was very good. Lots of great papers, interesting views and opinions on ESD, as well as a healthy turnout, all of which led to a successful event. We’re hoping this year will be just as good, if not better. If you do happen to attend, pop in to our booth and say “Hi”. You can also let us know how you liked the Symposium and your thoughts.
Come see us at:
Disneyland Hotel in Anaheim, CA
We are in Booth #: 503
Mon, August 31 6:00pm – 9:00pm
Tues, September 1 9:00am – 5:00pm
Wed, September 2 9:00am – 12:00pm
If you don’t get to make it ot this event in person to chat about all things ESD, let us know here. What are your concerns? What causes you the most grief? What keeps you up at night?
Until next time,
There are many way to skin a cat, so the saying goes… (well, at least in English… I’m sure each nationality / language has something similar). So when your debugging and verifying your IC design with LVS, what information do you use? Are you a text report kind of engineer, pouring over the text files that Calibre LVS generates? Are you an RVE wiz, preferring to do things in a GUI? Or do you use a bit of both, or something else? I’m sure there are also a number of custom GUIs that have been internally developed.
With the 2009.2 version of Calibre, we launched a new version of RVE, our GUI based results viewing environment for Calibre. This is an exciting new release with a number of significant enhancements tuned specifically for LVS. Some of these include schematics generated from the source and extracted netlists (great if you have a no schematic, like Verilog only), improvements to short isolation and a new report option, LVS REPORT OPTION FX. If you haven’t seen RVE for a while, now might be a good time to give it another look.
While final verification needs to happen in the Calibre version specified by your foundry, getting to LVS Clean does not have to. Why don’t you give 2009.2 or later a try and see how the New RVE and new FX report option goes for you…
Have you already tried it? Let me know what you think… Anything you’d like to see in there? Well, let me know that too…
Hopefully you’ll find the current and future content posted here interesting enough that you’ll come back and share own opinions, thoughts and ideas. Please let me know if there are specific topics you’re interested in. Maybe we can look at these in the future…
Today, I’d like to explore the task of creating a trusted source netlist that is used as the template for comparison to prove that your layout is good. The actual proof of comparing two dis-similar, yet equivalent SPICE netlists is handled pretty well by layout versus schematic (LVS) tools. Over the years a nice solid methodology for this comparison has been developed and the mechanics of LVS are well understood by many. But getting to the point where you have that trusted source netlist to take to comparison still seems as much experience and art, as it is about the technology. Especially for a complex mixed-signal design. A good dose of faith in your process, trust in your LVS tool, and experience to tie it all together seem to be a common (and winning) strategy that many often use.
So, how do you go about managing the complexities of putting together your trusted source netlist? Single language designs from SPICE or Verilog may seem easy enough, at least conceptually, while mixed-signal designs require a bit more fiddling – So how do you know your done? In Calibre land, there are some utilities to aide with the transformation. Do they suffice? Or are you using something internal, or looking for more?
Let me know your thoughts and opinions…
About Matthew Hogan's Blog
Physical and Circuit verification of today's multi-billion gate designs is hard. Heck, even verification of what's considered a "small" design today is hard. The complex work we do day-to-day to make silicon function is akin to magic for most of the population on this planet. What do you do to make things simpler, easier and more efficient? What are the trends you're seeing? Best Practices? Got ideas to make things simpler, more robust and more efficient? Come join in, and share...
- Gate Oxide Breakdown Failures Highlight Industry Need for New Electrical Rule Checking Tools
- ESD Design Rule Checking
- How do you debug LVS?
- Source Netlist Creation for LVS