feature article
Subscribe Now

Out, Damned Spot!

How to Detect Devices Drawing the Life Blood Out of Your Design

Lurking unseen in CMOS designs, unintended devices may be drawing current. As multiple power domains become common, it’s more likely that unintentional forward-biased diodes are introduced in the design. Forward-biased diodes also can be introduced by circuit design errors or layout design errors in complex circuitry such as digital circuits that contain pass gates and analog circuits.

Forward-biased diodes may draw enough current to cause outright device failure. However, even more worrisome are the ones that don’t draw enough current to cause outright failure, but increase power consumption unnecessarily. These devices need to be detected and addressed so that IC designers can be assured that they are creating high-quality products. A comprehensive verification system will detect these unintended devices that may be drawing the life blood out of your design.

Whether a design is intended for use in power-saving mobile devices or high-performance server applications, power consumption is a critical design limitation. In high-performance devices, heat dissipation limits clock speed—heat dissipated is proportional to power consumed. Every serious PC gamer knows that the clock speed of the processor can be set higher than the manufacturer’s specification if the supply voltage is set a little high and better cooling is applied.

One of the ways power consumption is controlled is by using multiple power domains in a design. Examples of power-saving techniques that rely on multiple power domains include temporarily or permanently reducing the supply voltage to parts of a device or turning off some circuitry.

Here, I illustrate a verification system, using programmable electrical rule checking, to detect forward-biased diodes efficiently [1]. This type of complex problem cannot be dealt with traditional individual point tools. The ability to verify the presence of these unintended devices requires the circuit extraction capability of a traditional LVS tool, the geometric checks of a DRC tool, selective parasitic extraction, and analysis tools.

Diodes that we want versus diodes that we don’t

In this example (Figure 1), there are diodes that are end up being part of the design. For example, there are diodes from the p-substrate to the n+ of the NMOS transistor’s source and drain. There are also diodes from the PMOS transistor’s source and drain to the n-well. These diodes from the NMOS base p+ to the p-substrate and from the PMOS base n+ to the n-well are the ones we are interested in.


Figure 1: Example of intentional diodes in NMOS and PMOS transistors.


To verify these parasitic diodes, we need to address the following.

First, we must ensure that the voltage applied to A is less than or equal to the voltage applied to C (Figure 2).


Figure 2: Voltage check for an intentional diode device.

Second, for the PMOS device, we must ensure that the voltages applied to the source and drain are less than or equal to the voltage applied to the bulk (Figure 3).


Figure 3: Voltage check for PMOS diodes.

Finally, for the NMOS device, we must ensure that the voltages applied to the base is less than or equal to the voltage applied to the source and drain (Figure 4).


Figure 4: Voltage check for NMOS diodes.

Normally the bulk pin of a MOS transistor is tied to the same voltage as the source. So the primary culprits which may be draining power that we don’t intend will be cases where the bulk pin is tied to something else. This is more common than you might expect, especially in multi-voltage domain parts and in analog circuitry. Simply reporting all devices with unusual bulk pin connections isn’t useful because the majority of these will be working as needed in the actual operation of the circuit.

For example, while the bulk pin of mn2 can be at the Vdd level in Figure 5, it isn’t logically possible for this to occur at the same time that mn2’s source pin is connected to ground because both mp1 and mn1 can’t be on at the same time. On the other hand, in figure 6, that same diode can clearly be forward-biased.


Figure 5: Example of circuit layout with mn2 not forward-biased.



Figure 6: Example of circuit layout with mn2 forward-biased.

Determining if forward bias can actually occur in real circuits is very hard. Several voltage levels can be propagated to the same device terminal, and determining which scenarios can actually occur is extremely difficult (logic pruning is equivalent to the Boolean ability-to-satisfy problem, which is NP complete).

Figure 7 is an example of forward-biased diodes in an actual circuit.  


Figure 7: Example of actual circuit with forward-biased diodes.           

For the NMOS devices mM8 and mM9, the bulk pin voltages can be less than voltages on d0b and d1b, respectively. For the PMOS devices mM7 and mM10, the bulk pin voltages can be greater than the voltages on d0b and d1b,respectively.

How to spot those troublesome forward-biased diodes

To address the issue of parasitic devices, one can implement a checker that detects forward-biased diodes in reasonable time with minimal “false violations.”

Checks for the forward-biased diodes checks can be performed on schematic data to verify design intent or on layout to verify design implementation. Layout verification tools can use the electrical rule checker’s circuit extraction capability. Devices are recognized in the layout, and a netlist is assembled from the chip’s drawn interconnect.

The idea is to use the tool’s TCL API to implement a verification scheme called “multi-stage filtering.” This strategy applies multiple filters in sequence. Each filter identifies devices that can never be in a forward-biased state. Each filter is more effective at eliminating devices but is also more time-consuming to execute.

To start, you can define the possible voltage levels for each external connection of the design. These voltages are propagated through resistors and transistors to the internal nets to define the worst case potential voltage set for each net.

The first filter simply checks these propagated voltage sets at each device. As an example, if the propagated set of voltages for the net attached to PMOS bulk pin is {2.5 volts and 3 volts} and the drain and source pins both have a propagated voltage set of {0 and 2.5 volts}, the device could never be forward-biased.

However, consider a device that is part of a subcircuit that can be powered down. Then the bulk pin voltage set might be {0 and 2.5 volts}. With source and drain voltages of {0 and 2.5 volts}, it’s possible for the device to fail this simple check.

Subsequent filtering steps consider progressively more complicated logical elimination of impossible states.

A customer used just this approach with Mentor’s Calibre PERC product and achieved a run time of just over two hours on a device with just approximately 49 million devices. The checker reported a few hundred potential violations that the designer then had to verify. The checker found real forward-biased diodes in designs — some of them caused excessive power draw and, in one case, caused a hard part failure. Using this method, the designer was assured that these unintended devices were caught before the IC went into manufacture.


  1. Grinshpon, A.S. Schubert, Z. Lu, “Using Calibre PERC for Full-Chip Detection of Unintentional Forward-Biased Diodes,” Design Automation Conference 2010.

About the Author

Gregory Hackney manages the PERC, LFD, and LVS engineering groups at Mentor Graphics Corporation. He has more than 30 years of experience in the EDA and semiconductor industries, with responsibilities ranging from managing diverse engineering teams and quality programs to multisite and international program management. Throughout his career, Hackney has held management and executive positions with Applied Micro Circuits Corporation (AMCC), UNISYS Corporation, COMPASS Design Automation, and Silicon Access. Before his current position at Mentor he was Vice President of Engineering for Sycon Design, Inc. He holds a degree in computer science and biology from University of California/San Diego (UCSD).

Leave a Reply

featured blogs
Aug 3, 2021
I just discovered that Norland Nannies -- who can command a salary of $170,000 on a bad day -- are trained in self-defense and defensive driving....
Aug 3, 2021
Picking up from where we left off in the previous post , let's look at some more new and interesting changes made in Hotfix 019. As you might already know, Allegro ® System Capture is available... [[ Click on the title to access the full blog on the Cadence Community si...
Jul 30, 2021
You can't attack what you can't see, and cloaking technology for devices on Ethernet LANs is merely one of many protection layers implemented in Q-Net Security's Q-Box to protect networked devices and transaction between these devices from cyberattacks. Other security technol...
Jul 29, 2021
Learn why SoC emulation is the next frontier for power system optimization, helping chip designers shift power verification left in the SoC design flow. The post Why Wait Days for Results? The Next Frontier for Power Verification appeared first on From Silicon To Software....

featured video

Accelerate Intelligent SLAM with DesignWare ARC EV Processor IP

Sponsored by Synopsys

Simultaneous localization and mapping (SLAM) algorithms build a map and determine location in the map at the same time. But how can you speed up the results? This demo shows how ARC EV processor IP with CNN engine accelerates KudanSLAM algorithms.

Click here for more information about DesignWare ARC EV Processors for Embedded Vision

featured paper

How AoP technology expands radar sensor placement for automotive applications

Sponsored by Texas Instruments

Car manufacturers are moving toward making several non-ADAS features autonomous, such as automated car doors and trunk opening. These features require a high-resolution sensor that can detect different types of objects and avoid collisions.

Click to read more

featured chalk talk

Using the Graphical PMSM FOC Component in Harmony3

Sponsored by Mouser Electronics and Microchip

Developing embedded software, and particularly configuring your embedded system can be a major pain for development engineers. Getting all the drivers, middleware, and libraries you need set up and in the right place and working is a constant source of frustration. In this episode of Chak Talk, Amelia Dalton chats with Brett Novak of Microchip about Microchip’s MPLAB Harmony 3, with the MPLAB Harmony Configurator - an embedded development framework with a drag-and-drop GUI that makes configuration a snap.

Click here for more information about Microchip Technology MPLAB® X Integrated Development Environment (IDE)