Professional Documents
Culture Documents
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.
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 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: