Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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 and \bus) as same net and shorted them together, while in logical netlist \bus is a buffered version of the bus 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
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 and \bus problem, because white box approach will check logical equivalency only (bus and \bus 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.