TIP OF THE MONTH: Verifying Final Netlist

Many users with access to Conformal-XL (ultra) and GXL (custom) don't realize they have the capability to equivalence check the final netlist, post-place and route, at the transistor level. This is what's called "LVR" and I'll describe what it does, why it's important, and how to run it.

What is LVR? Well, in an ASIC flow, the design goes through a series of changes from RTL to various stages of gate netlists (typically Verilog), then finally the SPICE and GDSII netlist. From RTL to the final gate netlist, Conformal ensures logical equivalency of the new gate netlists to the RTL. Then, the SPICE and GDSII netlists are also verified by running LVS, but keep in mind that LVS does physical verification (connectivity and the layout). Therefore, neither of the SPICE nor GDSII data is logically verified against the RTL/gate netlist! The LVR capability ties this missing logic equivalency link between LVS SPICE netlist and RTL.

Why is LVR important? Let me describe two classes of issues that we've encountered at customers. Often seen is the case with wrong library versions, usually because of Unix symbolic link to wrong/previous versions. At a particular customer site, the library group created a new updated library because the previous version had bad spice/layout view, then library data was validated clean with updated library.  Now, the RTL-2-gate equivalency check was clean (library sim view was functionally correct across various versions), and LVS passed (bad spice/bad layout matched connectivity-wise), but the design was implemented with the old library data!  This would have caused a silicon failure.  Once the customer ran LVR, they were able to find that there was a logical mismatch between the SPICE and Verilog libraries used by the design.

Another customer had a LVS error.  Debugging process involved finding out which netlist is correct, then the designer implemented the fix on the GDSII, assuming SPICE is golden.  However, it turned out that layout was the correct one - Verilog to SPICE translation treated two signals  (bus[0] and \bus[0]) as same net and shorted them together, while in logical netlist \bus[0] is a buffered version of the bus[0] net. Again, if LVR wasn't run, this would have been a bug in the silicon.

So how does LVR work? This is done in two steps.

First, all the library cells in the SPICE netlist are verified against the reference library for logical correctness. Conformal XL has a transistor logic abstraction engine, which understands the channel connected transistor groups and abstract them into Verilog primitive gates (digital logic only).

Here's a sample script for running the first step:

  Setup> add notranslate module embedded_macro_blocks -both  // memory elements, analog, etc

  Setup> read design lib.v -golden -verilog // or use .lib

  Setup> read design netlist.sp -revised -spice // could be cdl/hspice format

  Setup> validate circuit -revised -bboxscript libcell_bbox.do

-bboxscript option creates a dofile that adds black box to all of the verified library cells. This allows more accurate structural verification in the next step. I will illustrate more on this at the end.

Once the library data is clean, library is validated to have same logic functionality. Now the user can run final gate netlist vs SPICE netlist verification - here's a sample script for running the second step:

  Setup> read library lib.v -golden -verilog

  Setup> read design netlist.v -golden -replace

  Setup> // Define design constraints and modeling options

  Setup> dofile libcell_bbox.do

  Setup> set system mode lec

  Lec> add compare point -all

  Lec> compare

 
If both steps are clean, you just verified that your LVS SPICE netlist is logically/structurally equivalent to the final gate netlist.

LVR provides two modes, one is a black box approach, and another is white box approach.  Black boxing the library cells during the LVR flow (after library validation) will verify that all the connectivity from cell to cell is consistent between two netlists.  This has added benefit that all function is correct, and connectivity is correct as well.  Therefore, user should always use this flow for gate netlist versus SPICE netlist LVR.  However, if user wanted to run RTL versus SPICE netlist LVR, then the library cells cannot be black boxed (since RTL do not have them normally), so white box approach should be used.  Be warned that this flow will not catch the example of bus[0] and \bus[0] problem, because white box approach will check logical equivalency only (bus[0] and \bus[0] are logically same nets).

Also, by running LVR in two steps (1st library validation, then 2nd design verification), library problems will not stop user from verifying the top design and vice versa.

A few words of caution - transistor abstraction is capacity-limited in Conformal XL, basically for LVR purposes only.  Also, Conformal XL does not provide a debugging environment for the SPICE library comparison - this has to be debugged by the library team with Conformal GXL.  If you have large custom digital sections, such as embedded memories or custom datapath logic, you will also need to use Conformal GXL.