LVS Debug: The Good, The Bad, and The Future

By Srinivas Velivala, Mentor Graphics

The Bad News: Layout vs. schematic (LVS) comparison is often a tedious and time-consuming process,

requiring many debugging iterations and cross-functional interactions before a designer team converges

to a LVS-clean design.

The Good News: EDA vendors are responding with new LVS technology to help designers more quickly

and efficiently converge to a LVS-clean design.

The Future: What’s emerging are comprehensive LVS debug solutions that can help designers quickly

identify and resolve LVS errors. The ideal debug solution would address the two critical issues currently

impacting the LVS process of advanced node design verification:

• Isolation of connectivity errors found in extraction. By quickly correcting these errors and

rerunning LVS, designers can focus most of their time on debugging true comparison errors

between the layout netlist and schematic netlist.

• A debugging environment that actively helps designers debug LVS discrepancies, and allows

cross-probing of LVS discrepancies into design environments.

Let’s take a closer look at why those issues exist, and then we’ll examine some of the new LVS

technology helping to resolve them.

The Layout vs. Schematic Process

LVS is a two-step process, consisting of device extraction and comparison. The extraction process

extracts the devices and their connectivity from the physical layout, and then generates a netlist

interpretation of the layout to be used in the comparison step. As transistor sizes continue to decrease

while design intricacy increases, the complexity and number of parameters that are required for

extraction have significantly increased. At 45 nm and below, foundries also require the extraction of

custom parameters that are important to their unique process, which further intensifies extraction

complexity and lengthens runtimes.

The comparison process compares the extracted netlist to the schematic netlist, and reports all

discrepancies, which must then be debugged and resolved. Without a clean extraction, the subsequent

compare results may be invalid, because many of the errors reported in the LVS results will turn out to

be extraction errors, rather than true comparison errors. Resolving these errors accounts for a

significant amount of the time required for LVS operations. However, without any means to distinguish

between extraction errors and true discrepancy errors, designers must assume all errors are comparison

errors, and debug them accordingly. Extraction errors can manifest themselves in unusual ways, causing

designers to experience a lot of pain and waste a lot of time trying to identify and fix them. Common

types of extraction errors include top-level power-ground shorts, bad devices, soft connections, etc. In

this article, we will focus our attention on debugging top-level power-ground shorts. Designers

frequently encounter top-level power-ground shorts errors. There are multiple power and ground net

paths that run throughout the chip, making it very hard for designers to debug the location of the short.

If multiple shorts are present between power-ground nets, designers typically fix one short at a time,

and then re-run the LVS process to get to the next short in the design. Running the complete LVS job

multiple times significantly adds to the total turnaround time.

Even if the extraction errors are removed, debugging and resolving the true LVS discrepancies at

advanced technology nodes can be difficult, and can have a major impact on the total turnaround time

of a project. Designers often need significant time to comprehend complex LVS issues and determine

the most appropriate way to fix LVS discrepancies without compromising the performance quality of

their design, even while they are under pressure to meet the ever-tightening tapeout deadlines of

today’s IC market.

To explain how new LVS tools and techniques are helping designers resolve these two major issues, we’ll

walk through some typical LVS error conditions, and demonstrate how, using tools that implement

advanced debugging technology, designers can now minimize time spent debugging LVS errors. In our

examples, we’ll be using a combination of Calibre® nmLVS™, Calibre RVE™, and Calibre DESIGNrev™ as

our debugging technology.

Extraction Errors

Texted Shorts

Shorts found in the extraction process are often just text conflicts that occur due to different text -

names being present on the same net. With traditional LVS technology, when shorts are identified after

an LVS run, the errors must be corrected and the extraction process run after each error correction,

each time lengthening the total time required for the LVS process to achieve an LVS-clean result.

By distinguishing between extraction errors and true comparison errors, advanced LVS debugging

techniques enable designers to identify and correct these errors before moving on to the debugging of

the true comparison errors. In our example, once Calibre nmLVS has run the LVS process and generated

a shorts database, the results are displayed in Calibre RVE, a results viewing tool. The first thing you

notice is that extraction errors are now separated from the comparison errors (Figure 1). This separation

enables designers to analyze and correct errors created in the extraction netlist, such as shorts created

by text conflicts.

Figure 1: Calibre RVE interface with extraction and comparison results displayed separately.

Using a Calibre RVE feature called Interactive Short Isolation (ISI), designers can now fix multiple top-

level power-ground shorts without having to run the extraction process after each error correction. With

ISI, designers identify the polygons constituting a short. They then highlight the shorted path in Calibre

DesignRev (a layout viewing tool), step through the polygons, and assign net name text (VDD or VSS) to

each of the polygons, based on their knowledge of the design layout (Figure 2). In this way, they can

quickly and progressively get to the location of a texted short.

Figure 2: Identification of polygons constituting a shorted path between Power & Ground Nets in pllclk cell. The

shorted path is then highlighted in the design viewing environment, enabling designers to assign net names to

the polygons constituting the shorted path.

Once designers locate the shorted polygon, they can virtually remove this polygon from the shorts

database and run ISI to see if the short is corrected. During ISI, Calibre nmLVS does not launch the

extraction process. Instead, it utilizes the extraction information present in the shorts database, which

allows ISI runs to generate results very quickly. This speed allows designers to conduct a what-if analysis

on their designs to rapidly deduce the optimum solution to fix the shorts. Designers can quickly make a

few changes in the design to fix the short, run ISI, and see the results of those changes. At any stage of

the analysis, designers can revert back to the original shorts database generated from the Calibre nmLVS

run.

If the change made to the shorts database fixes the short, then Calibre RVE displays the next shorted

path between the two nets (Figure 3) and the process is repeated until no additional shorts are found

(Figure 4).

Figure 3: The next shorted path between power-ground nets in pllclk cell is shown in Calibre RVE and highlighted

in Calibre DesignRev.

Figure 4: Results of Interactive Short Isolation when no other short is present between the power–ground nets

in cell pllclk.

Of course, at this point, the changes made to fix the shorts are virtual changes to the shorts database,

not actual changes made in the design. To actually fix the shorts, the designer must make permanent

changes in the design environment to remove the shorted polygons.

Comparison Errors

Non-Texted Shorts

In addition to the texted shorts that are caught as part of the extraction process, there are non-texted

shorts generated during the comparison process. Non-texted shorts are actual connectivity issues that

have been analyzed and found to be a short by the comparison process. Once all of the texted shorts

have been corrected, designers can begin debugging these comparison errors, which can sometimes be

tricky to correct.

To help them fix non-texted shorts, designers can use Calibre RVE to see a visual representation of the

layout and source netlists used in the LVS run, and debug LVS discrepancies by comparing the source

and layout schematics side-by-side. These schematics are especially valuable to designers when

schematics are not otherwise available for debug (e.g., Verilog).

To debug a non-texted short present in the layout, designers work from the source netlist information,

which is considered the “golden” data. They can separately highlight the instances on the source nets

corresponding to the shorted layout net, using different colors to trace the good segments to find the

bad one. Color consistency of highlighted layers between the external design environment and Calibre

RVE schematics ensures users can easily identify the nets and devices highlighted when cross-probing.

In our example, the shorted layout net 13 is made up of two nets, n3 and n1, in the source (Figure 5).

The instances on the two source nets (n3, n1) are separately highlighted.

Figure 5: Non-texted layout shorted net 13 is shown highlighted in the Calibre DesignRev environment. The

corresponding two source nets, n1 and n3, are highlighted in the Calibre RVE source netlist schematic.

By highlighting the known devices in the source netlist, designers can visually prune the non-shorted

portion of the net to reduce the problem to the remaining portion on the net (Figure 6).

Figure 6: The devices corresponding to source nets n1 and n3 are highlighted separately in the Calibre RVE

source schematic, and the corresponding layout net is shown. Users can visually inspect the shorted layout net

and the corresponding source nets to deduce the location of the short.

Cross-Connect Errors

A cross-connect error is a common LVS discrepancy that is caused by swapped signal nets in the layout.

Our example contains a typical case of swapped signals, as the counts of Nets and Instances for the

design cell matches in both layout and source netlists, but the count for the Ports is different, indicating

that this is a connection problem (Figure 7). To help reduce debugging time, Calibre RVE provides users

with a “fix suggestion” that contains a simple English language description of the problem. In our

example, this description tells us that there is a cross-connect error between layout nets 10 and 5 due to

a faulty wiring connection, and that swapping the connections for the two nets will fix the problem.

Figure 7: A simple English language description of the LVS cross-connect error. Count of the Nets, Instances and

Ports for the design cell in both Layout and Source netlist cells is displayed. The mismatch in the count of Ports

indicates a connection problem.

To debug this problem, designers can use the fix suggestion to highlight the two nets and instances that

have a cross-connect error in the layout environment (Figure 8). From the highlights, it is easy for the

designers to see that there are swapped signal connections between the two nets. To fix this problem,

the designers just need to swap the via connections between the two nets (Figure 9).

Figure 8: Highlights of Nets 10 and 5 cross-connected to instances M7 and X27/M0 respectively

Figure 9: Swapping the via-connections between the two nets fixes the cross-connect error.

Conclusion

LVS debug of today’s complex designs is challenging and time-consuming, but reducing LVS debug time

while continuing to provide reliable, high-performance designs is a requirement for chip designers who

want to meet their tight tapeout deadlines and satisfy customers. As the chip industry moves towards

advanced technology nodes, design automation technology must ensure that it provides the speed and

quality of results necessary to ensure the continued success of its customers. EDA vendors are providing

new techniques and tools that work together to automated and enhance LVS debugging capabilities,

ensuring that their customers can meet market deadlines while maintaining product quality, even for

the most advanced designs.

Author:

Srinivas Velivala is a Technical Marketing Engineer with the Design to

Silicon Division of Mentor Graphics, focusing on developing Calibre

integration and interface technologies. Before joining Mentor, he was

an IC designer, designing high density SRAM compilers. Srinivas

received a B.tech. in Electronics from Jawaharlal Nehru Technological

University in Hyderabad, India, and pursued additional studies at

Southern Illinois University in Carbondale, Illinois. He can be reached at

srinivas_velivala@mentor.com .