You are on page 1of 10

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: Whats 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.

Lets take a closer look at why those issues exist, and then well 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
todays IC market.
To explain how new LVS tools and techniques are helping designers resolve these two major issues, well
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, well 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 toplevel 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 powerground 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 todays 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 .

You might also like