A few weeks ago, we talked about template text labels for design-specific information. There, we were focused on labels that are specific to the design as a whole: revision information, dates, authors, etc. Today, we’re looking at a different kind of label, but one no less crucial to a correct design – labels used by your formal verification and LVS flows.

Labels for Formal LVS 

For those of you who haven’t used a formal check like Cadence’s own Pegasus / PVS tools, these tools take a netlist from your front-end schematic and compare it to the geometry data from the layout. The geometry most commonly comes in GDSII format. Why is this important? Stream is a 'dumb' format. It has no netlist! How, then, do you match up your schematic elements, which have no physical data, with the physical GDSII that has no logic?

This is where text labels come in. GDSII, while it may not include constructs for arcs, for holes/voids, or even a cross-section layer order, does have text elements. The LVS tools use text on specific layers and data-type combinations, which overlaps with geometry elements, to effectively assign labels for nets, pin names, etc. Reconstructing things this way enables mapping and comparison to the golden schematic. It’s a very handy technique!

However, it does mean that the labels absolutely MUST be correct in the physical design. If any are wrong, out of date, or missing, then the LVS won’t be able to make the needed associations or verify that all connections are present with no bonus shorts.

CDL and Its Text Requirements

CDL is a netlist format that can be used to feed into the formal verification tools. The format itself is simple and elegant. It will list the elements that are connected in the same net, with the possibility to include pseudo-resistor elements on pins or vias where the connectivity bridges from one net to another.

You’ll find the Allegro Package Designer Plus GUI for defining and generating this file below:

We’ve talked about this command in the past because it’s critical to anyone who is using the formal LVS checkers. By the way, if you look in the forums, you’ll find methods for generating this file from many of the Cadence IC Layout tools as well. 

The most important part of this form (well, honestly, they’re all important; this is the netlist for comparison to the golden!) is the format for the labels. Configure the label strings here. They’ll be used in the next session.

Generating Labels and Maintaining Them

Knowing the labels that are needed for your design, the easiest way to generate them the first time is with the Manufacture – Documentation – Display Pin Text command. You’ve probably heard me talk about this in the past, but the command is critical for this flow.

Above, you can see the selection of text labels you can create. I bet you can guess which ones we are interested in, today: the final three! The LVS descriptor, port, and resistor. When selected, these will query the CDL setup information to determine the value assigned to each object. Because the two commands are tied in this way, the potential for a text object to not match the entry in the CDL netlist is nil.

They can, however, get out of date. You really don’t need the labels until it is time to do LVS, but even if it is the final thing you do in the design flow,  ECO will inevitably come your way. That’s why the refresh and update options are here in the command (note: there’s also a batch command, dpn_update, which you can put into a script, function key alias, or a SKILL command that will scan and refresh any out-of-date labels).

A hint: If you ever are unsure whether a specific text object is registered for an intelligent update – perhaps you did a refresh from the library on the symbol and replaced all the text, for instance – then a quick show element will tell you all you need to know. Check for whether the text is part of a DPN labeling group. If it is, you’re all set; it will be updated by the refresh tool.

Also, keep in mind that text labels for these purposes are typically needed at the top level of the GDSII. This means that they shouldn’t be embedded into hierarchical cells (like those attached to the pins) since there can be multiple instances of the component. Each instance would have different labels. The choice to place the text at the top (design) level is a simple checkbox in the Display Pin Text GUI:

How Do You Label? 

Do you use these tools today? If not, how do you create and ensure the up-to-date status of design element labels? You might implement your own specific tools, and that’s fantastic! Could some of that custom code be replaced with the tool-provided interfaces to save you the cost and effort of maintaining a custom solution? Is there something you need to access from SKILL to efficiently update the labels to align with your golden netlist? Whatever it is, if Cadence can help you save time and energy, please work with us to make that happen!