A Guide on LVS in the Nanometer Era


Layout versus schematic (LVS) is a method to validate that the layout of an integrated circuit is functionally identical to the original schematic of the design. LVS debug of today’s nanometer era designs isn’t only challenging, but also time-consuming. Therefore, reducing the LVS debug time while continuously delivering reliable, high-performance design is a requirement for chip designers who want to meet their tight tapeout deadlines and go beyond client expectations.

To ensure the correctness of the implemented design, bigger layout databases need to be checked during the physical verification stage in the same ambitious project time frames as before.

The LVS report describes the comparison between the layout and schematic with respect to ports, nets, and instances. If the schematic and the layout don’t match, the discrepancies are mentioned, separated by broken lines. The “overall comparison results” gives the numerical details of the ports, nets, and instances appearing in the layout and schematic (also referred to as source).

The report gives detailed information on the sources of error either in the layout or schematic by displaying the comparison results. All of the errors can be tracked by understanding the LVS report, thus avoiding any design failure that could lead to expensive mask changes and delays in getting the system-on-chip (SoC) to market.

LVS, which is a part of physical verification, checks whether the design layout is equivalent to its schematic and checks the layout against process manufacturing guidelines provided by the semiconductor fabrication labs to ensure it can be manufactured correctly. LVS verifies the design correctness with intended functionality, and formal verification matches the design’s pre-layout netlist to post-layout netlist.

These “sanity checks” should be done before running LVS:

  • The design doesn’t have any signal or power short/open.
  • The design doesn’t contain any overlapping of cells.
  • The design db. and Open Artwork System Interchange Standard (OASIS) should have syn.
  • The design doesn’t have a base layer DRC.

LVS Flow

An electronic-design-automation (EDA) tool performs LVS via a set of instructional code input, commonly known as an LVS rule deck, which is a guide for the verification tool to provide the instructions and identify files that are needed for LVS.

Design inputs needed for running LVS are:

  • OASIS or Graphical Database System (GDS) layout database of the design
  • Schematic netlist of the design (Spice netlist)
  • LVS rule deck file (SVRF/TVF)
  • LVS options file provided by foundry
  • LVS IP filter file provided by foundry
  • Source layout netlist ($design.netlist.layout)—the LVS tool creates a layout netlist by extracting the geometries

LVS is a two-step process:

  • Extraction: The 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.
  • Comparison: The process compares the extracted netlist to the schematic netlist, and reports all discrepancies, which must then be debugged and resolved.

If extraction isn’t clean, 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. Even if the extraction errors are removed, debugging and resolving the true LVS discrepancies at advanced technology nodes can be difficult and may seriously impact the total turnaround time of a project. 

1. General flow of LVS during physical verification for all PV tools.

The steps in the LVS flow include (Fig. 1):                                          

  • GDS/OASIS: The tool takes the GDS (or OASIS) file as input and breaks it down into basic design devices like transistors, diodes, capacitors, resistors, etc.; it recognizes the devices in the form of layers and shapes that make up the circuit. It also extracts the connectivity information between these devices from the GDS file.
  • Layout netlist: Device information along with their connectivity is written into a layout netlist file. It also contains physical cells, generally called layout extracted netlist. This process is known as extraction.
  • Schematic netlist: This netlist is a textual description of a circuit that contains components like gates. It also has a connection with the resistors, capacitors, and transistors.
  • Comparison: This tool compares the electrical circuits from the schematic netlist and the layout extracted netlist and reports all discrepancies, which must then be debugged and resolved. The netlist comparison process also uses the LVS rule deck.
  • LVS report & result: If the two netlists differ, discrepancies are reported in the form of an LVS result database that can be used to debug LVS issues. The result database would contain the list of incorrect elements and the reason for mismatch, such as incorrect nets, incorrect ports, and incorrect instances.

LVS Issues and Debug

The LVS report describes the comparison between the layout and schematic with respect to ports, nets, and instances. If the schematic and layout don’t match, the discrepancies are mentioned, separated by broken lines. The “overall comparison results” gives the numerical details of the ports, nets, and instances appearing in the layout and schematic (also referred to as source).

LVS Overall comparison result shows discrepancies (incorrect matching) in the following points:

  • Number of nets
  • Number of ports
  • Connectivity issues
  • Ambiguity points in the design
  • Cell comparison

How to Open LVS db. in Calibre

First you have to check latest OASIS file of your current db. Then from below command you can invoke caliberDrv (Fig. 2):

calibredrv -64 $design.oasis_file{Oasis file of design}

2. The Calibre gui window show all types of layers.2. The Calibre gui window show all types of layers.

How to open LVS marker:

  • Verification -> Start RVE (Fig. 3). Then give the option to be lvs and subsequently give the pointer to calibre/lvs/svdb.
  • Then check for discrepancies (Fig. 4).
  • Debug layout missing connections and plot error with them.

3. This Calibre RVE window is where we have to check all violations after loading it.3. This Calibre RVE window is where we have to check all violations after loading it.

4. The discrepancies window shows all violations with the schematic.4. The discrepancies window shows all violations with the schematic.

Case 1: Short

Shorts between different nets are the most common problem during the final tapeout. Fixing those shorts is one of the toughest challenges for the designers.

When two different nets’ layers touch each other, it will result in a short in your design. Shorts can also occur when in a specific layer of GDS, two polygons having different layout text overlap and have no intersection. In the example in Figure 5, two signal nets are creating a short between each other in db.

5. In this case, one signal is a short, with the other in a metal layer.5. In this case, one signal is a short, with the other in a metal layer.

In general practice, in the place-and-route tool we need to fix shorts before running LVS, one short present in PNR tool is showing in the above figure.

Possible of shorts include:

  • Short between full chip-level net and block level.
  • Short between P/G inside block level or between full chip and block nets.
  • Signal/PG short during merging hierarchical design.
  • Short between DM and signal/PG nets.

Once Calibre LVS has run the LVS process and generated a shorts database, the results are displayed in Calibre RVE, a result viewing tool (Fig. 6).

6. Comparison results are given after this violation in Calibre.6. Comparison results are given after this violation in Calibre.

In the LVS report, the number of nets in the source is greater than that in the layout (Fig. 7). If a short is present in a design, then the connectivity extractor will only extract the shorted nets as a single net in the layout and will not be able to identify them as two different nets (Fig. 8).     

7. More can be dug up about violators in this detailed report.7. More can be dug up about violators in this detailed report.

8. At the end of the report, “incorrect” will appear.8. At the end of the report, “incorrect” will appear.
If a short is present in LVS, it will generate one separate report for detailed information of the short (Fig. 9).

9. This report provides information on all shorts present in the design.9. This report provides information on all shorts present in the design.

Case 2: Power Short

Power shorts are actual connectivity issues that have been analyzed and found to be a short by the comparison process (Fig. 10). Designers can begin debugging these comparison errors, and load 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. 

10. Power short in VDD and VSS.10. Power short in VDD and VSS.

If your design has power short, then you must clean it in place-and-route before moving in signoff—otherwise, you might face a number of issues in LVS. It’s tough to debug power short in lvs. In Figure 11, the overall comparison of design is showing an error and an alternate instance is showing incorrect because of the power short.

11. This overall comparison results report contains details on the power short.11. This overall comparison results report contains details on the power short.

Further in the report, it shows a missing net of VSS because the tool under the VDD and VSS nets appears as one net due to a short (Fig. 12). The tool will generate a short.rpt report for the short as well (Fig. 13).

12. Incorrect nets will appear due to a power mismatch.12. Incorrect nets will appear due to a power mismatch.

13. In this cell comparison layout, the difference in source nets will appear.13. In this cell comparison layout, the difference in source nets will appear.

When the layout net count is greater than source netlist in the net section, then shorts exist in the design. If it’s a valid short, the tool will dump the report. Shorts file into the Calibre results directory (Fig. 14).

14. The short report reveals if any short is present in the design.14. The short report reveals if any short is present in the design.

Case 3: Power Open

An open in a design occurs when polygons having the same layout text aren’t connected to each other, or when two nets having same net names aren’t connected to each other.

Note: It’s suggested that the open/Short script always run in the place-and-route tool before running LVS to detect the open/short in the early phase of the design cycle.

Even LVS will not show power open. Instead, it will show CORRECT because ERC verifies the correctness of power and ground connections, so this will not reflect in LVS.

15. In this case, power (VDD/VSS) is open for a layer.15. In this case, power (VDD/VSS) is open for a layer.

In Figure 15, LVS shows that the example VDD and VSS nets got open.

Case 4: Power Short with Signal

Shorts are formed if two or more wires that should not be connected together become connected. Figure 16 shows a case where power VDD is getting shorted by one of the signal nets. Figure 17 reveals the LVS detailed errors.

16. Here, power (VDD/VSS) is shorting with the regular signal net.16. Here, power (VDD/VSS) is shorting with the regular signal net.

17. The overall comparison report shows “incorrect” due to a short.17. The overall comparison report shows “incorrect” due to a short.

When the source net count is greater than the layout netlist in the net section, then shorts exist in the design (Fig. 18).

18. Report of layout and source mismatch.18. Report of layout and source mismatch.

Case 5: Signal Open

Opens are formed if the wires or components that should be connected together are left floating or are partially connected. An open in a design may result in floating gates, which leads to short-circuit power dissipation and may even lead to chip failure.

In the example in Figure 19, two signal nets got open. The LVS report details these errors (Fig. 20).

19. In this case, two regular signals became open.19. In this case, two regular signals became open.

20. The overall report results will show all violations.20. The overall report results will show all violations.

When there’s a lesser net count at the source side compared to the layout side (Fig. 21), then an open exists in the design.

21. Report of layout and source mismatch.21. Report of layout and source mismatch.

Case 6: Particular Instance is Deleted

This issue arises when a designer is in a manual fixing cycle and accidentally deletes the particular instance, and subsequently moved ahead. This is because the LVS algorithm only works on whatever netlist received by the user. If your source netlist doesn’t contain x instance, it will not create a layout for that particular instance and hence the comparison process will not detect the issue.

In this case, lvs will not detect this issue and it will show CORRECT. This is because it will work on the netlist that’s dumped from your latest database—if an instance is deleted an instance from the latest database, it will not reflect in the layout netlist.

Case 7: Missing Well Tap

Figure 22 illustrates a missing well tap. Tap cells are used to provide a substrate connection; they connect an n-well to VDD and p-sub to VSS. These cells are inserted in the layout at regular intervals based on tap rules (tap-to-gate distance) defined in the technology rule deck file.

22. A well tap cell is missing in this design.22. A well tap cell is missing in this design.

If we missed these cells, n-well continuity will stop and due to that, the instance of a row (that’s not continuous) will not get power (VDD) (Fig. 23).  The report in Figure 24 shows that particular instance as incorrect.

23. All red-colored instances belong solely to the missing well tap row.23. All red-colored instances belong solely to the missing well tap row.

24. In this report, all cells have become “incorrect.”24. In this report, all cells have become “incorrect.”

As shown in the report in Figure 25, again there’s a lesser net count at the source side compared to the layout side. In addition, an open of VDD exists in the design, highlighted by the incorrect instances in the LVS report.

25. The detailed report shows the mismatch between layout and source netlist.25. The detailed report shows the mismatch between layout and source netlist.

Case 8: Overlapping Filler Cells in db.

This situation arises when a designer is in a manual fixing cycle and placement filler cells became overlapped with each other. Thus, we have to run LVS with the same db. But LVS will not detect this issue and give you clean results.

Case 9: Missing Filler Cells in db.

If you forgot to add filler into your design and gone through LVS, then it will be hard to detect this issue in an LVS report because every alternative cell is showing incorrect due to N-well discontinuity. It will fail ERC (electrical rule check) and give floating n-well violations (Fig. 26).

26. The electrical rule check uncovered floating n-well violations.26. The electrical rule check uncovered floating n-well violations.

Basically, filler cells will provide power/ground and n-well continuity. There will be power/ground opens between the standard cells (empty space), creating incorrect cells in the report (Fig. 27). As a result, not every cell will have power/ground connectivity, making it an incorrect cell.

27. The ERC report indicates floating n-well violations due to missing filler in the design.27. The ERC report indicates floating n-well violations due to missing filler in the design.

Conclusion

The article covered some of the general debugs that are used when you need to analyze LVS results. If we debug LVS step by step, it will help us understand the error in depth, and the GUI mode will help to understand depth of the mismatch. Using this corner case can be helpful in physical-verification iterations for debugging the LVS.

Chetna Jaiswal is Senior Engineer, Sandeep Jain is Technical Lead, and  Mrunal Mirani is Physical Design Engineer at eInfochips.



Source link