EDA DesignLine Blog
Tell us What You Think
We want to know what you thought about this Discussion. Let us know by adding a comment.
LVS Debug: The Good, The Bad, and The Future
Srinivas Velivala, Mentor Graphics
9/25/2012 1:31 PM EDT
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:
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.
Next: Extraction errors
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.
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.
Next: Extraction errors
|
|
|
|
|
Navigate to related information