Voltage drop analysis and verification - physical data requirements
| Summary: The power distribution system delivers power and ground from outside the chip to each MOS device. This article describes the power and ground networks data that is required for voltage drop (and to some extent current density or electromigration) analysis, how you can get it, and how it will be used. |
In the first article in this series about voltage drop verification and analysis we discussed the components of the power distribution system, and briefly described the problem. The remaining articles in this series will describe solutions, targetted at each stage of the design process. We’ll start, in this article, with necessary physical data.
In working with power nets over the last decade or so, I’ve often been frustrated by the lack of any standard data format to enable power net parasitics data export from extraction tools to analysis tools. If you remain within the complete flow provided by a broadline supplier then you don’t need to worry about moving data , but if you want to introduce new, innovative analysis tools, you have to feed them the data they need. For this reason, many of the simpler power net analysis tools include their own power net extractors. These extractors are straightforward.
Power net extraction
Power net conductors are typically Manhattan shapes, except in analog/RF designs where non-orthogonal structures may be used. The metal shapes are fractured into ‘more manageable’ sizes, naming the intermediate sub-nodes.
Capacitance extraction precision depends to a large extent on determining the environment in which the metal element is placed. Only the simplest structures, like the parallel plate capacitor, have an analytical formula with good accuracy; for the vast majority of geometries, fringing and lateral capacitance dominate parallel or area capacitance. For power nets, though, the geometries are usually large in size and so the significance of fringing and lateral is reduced. Usually, then, a simple pattern matching algorithm gives acceptable accuracy for capacitance (to ground) of power net conductors.
Resistance extraction for simple geometries is simply the sheet resistivity multiplied by the geometry length and divided by the cross-sectional area. This is usually simplified to “square counting” - multiplying the resistance per square by the number of squares (geometry length / width). Some adjustment may be made at orthogonal abutments to account for current crowding. Vias are complex 3D geometries, but for power net extraction they can usually be merged into one ’super-via’ without too much degradation in accuracy. Those with a need for the utmost level of accuracy may employ 3D solvers on the via arrays, but this probably overkill for the majority of designs.
Finally, the RC data is written back to the physical database, from where it can be fed into the analysis tools, natively or though file I/O, when needed.
Parasitic data exchange formats
There are two commonly used file formats to exchange extracted parasitic data, the Standard Parasitic Exchange Format (SPEF) and the Detailed Standard Parasitic Format (DSPF). SPEF is the newer of the two, is an IEEE standard (part of IEEE 1481), and has explicitly-defined support for coupling capacitors. It’s also a much denser format than DSPF, thanks to its table-like indexing structure, but it suffers from having no standard method of describing resistor geometrical information.
DSPF, on the other hand, is verbose. DSPF files can easily be many times larger than SPEF files for the same design, and 5-10GB is not unusual. Coupling capacitors are not explicitly supported (since there’s no standard, each vendor extends DSPF in their own unique way, eliminating any chance of easy interoperability, and in one case actually double-counting coupling capacitors - so take care if you’re using this flow.) For our purpose here, though, DSPF has one advantage - with some setting of switches and controls in extraction and netlisting, a DSPF netlist can include resistor geometry and location information. While this isn’t absolutely vital for voltage drop analysis, it assists both visualization of results (maybe back-annotating to a GDS viewer or DRC analysis tool, e.g. Mentor’s Calibre RVE) and enables electromigration - more correctly current density - analysis (which tends to go hand-in-hand with voltage drop analysis).
Sadly, again, there’s no standard for annotating the DSPF file with resistor geometry information. Generally, though, there are two formats.
The first we shall call “element geometry format”, since it attaches relevant geometrical information to each resistor element contained in the DSPF. Each resistor declaration, without geometry, appears:
/* resistor declarations */ R<identifier> <node1> <node2> <Rvalue>
The geometry information is contained in a comment appended to the resistor declaration line, and typically includes the X, Y locations of node1 and node2, as well as the width, length and layer number of the resistor. If it’s a modeled resistor (to include temperature-dependent or voltage-dependent effects, for example, there may be a model identifier called out here too).
The second format we shall call “coordinate geometry format”, since it attaches less data to the resistor declaration line and relies upon additional content in the DSPF file.
/* sub-node declarations */ S<node1> <node1.x> <node1.y> S<node2> <node2.x> <node2.y> /* resistor declarations */ R<identifier> S<node1> S<node2> <Rvalue>
For the coordinate geometry format, width and layer are written into the comment field, while the length may or may not. If not, it can be calculated. Since these are Manhattan geometries, S<node1> and S<node2> will have identical X or Y coordinates. The absolute difference between the other, non-identical coordinates, gives the resistor length. Even if the length was given in the resistor declaration line, it’s a good idea to check the given and the calculated are the same. I’ve known them to be different.
Other physical data
Signal net parasitic data may needed, and back-annotated to the analysis netlist. If the currents are going to be computed, or stored during some transient simulation, signal net RC data is vital. After all, current comes from the switching MOS or logic gate charging a load capacitance. Also, this data is needed for ‘regular’ post-layout performance verification, even without voltage drop analysis, so it has to be available somewhere.
The VDD and GND voltage sources, their values and their locations must also be available.
The models for power and signal pad and pin electronics are, if present at all, usually contained in the analysis netlist.
So that’s it for the physical data requirements. We’re going to move on to modeling and deriving the current, starting in the next article with static or pseudo static approaches, and how these can be used for rudimentary voltage drop (and current density) analysis. Stay tuned.
Example extraction tools (not an exhaustive list)








No Comments »
No comments yet.
RSS feed for comments on this post.
Leave a comment
If you want to leave a feedback to this post or to some other user´s comment, simply fill out the form below.