LEC Verification Guide

Product Version 12.1

July 31, 2013

This guide reviews the key steps in the synthesis verification flow. This guide has
recommendations on RTL Design / Synthesis for ease of verification, running LEC effectively,
resolving abort, debugging non-equivalence and updating LEC dofile, etc that will help
streamline the verification process.
 LEC Verification Guide

Copyright Statement

© 2008-2013 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the
Cadence logo are registered trademarks of Cadence Design Systems, Inc. All others are the
property of their respective holders.
 LEC Verification Guide

Contents
Purpose ....................................................................................................................... 5
RTL Design for Ease of Verification ............................................................................. 5
RTL Coding Guidelines for Ease of Verification ....................................................... 5
Removing Don’t Care Conditions in RTL ................................................................. 6
Removing Don't Care Conditions in RTL.................................................................. 6
Removing Don't Care Conditions in RTL (index out-of-range reading) .................... 6
Removing Don't Care Conditions in RTL (unique case) ........................................... 7
Removing Don't Care Conditions in RTL (X assignment)......................................... 7
Removing Don't Care Conditions in RTL (range constraint)..................................... 8
Structural Implementation in RTL ............................................................................. 8
Design Partitioning in RTL ....................................................................................... 8
Design Report .......................................................................................................... 9
Design Partitioning in RTL (add module hierarchy) .................................................. 9
Design Partitioning in RTL (add module hierarchy) .................................................. 9
Understand Design Verification Complexity ........................................................... 10
Run LEC RTL Rule Checker .................................................................................. 10
Checklist for RTL Designs ...................................................................................... 11
Synthesis for Ease of Verification .............................................................................. 11
Multi-Stage Synthesis ............................................................................................ 12
Embed Verification Requirements in Synthesis...................................................... 12
Module Based Datapath (MDP) Analysis ............................................................... 12
Synthesis Script to Enable MDP Analysis .............................................................. 12
Synthesis Script to Enable MDP Analysis (continued) ........................................... 13
Collecting Synthesis Data ...................................................................................... 13
Qualifying Your Synthesis Environments ............................................................... 13
Checklist for Synthesis ........................................................................................... 14
Running LEC Effectively ............................................................................................ 14
Verification Flow ..................................................................................................... 14
Checklist for Running LEC ..................................................................................... 14
What is an Abort ........................................................................................................ 15
What Causes an Abort? ......................................................................................... 15
LEC Methods to Resolve Abort .............................................................................. 15
Advanced LEC Techniques .................................................................................... 15
User can Help to Resolve Abort ............................................................................. 16
Review Synthesis Flow .......................................................................................... 16
Review LEC Dofile/Logfile ...................................................................................... 16
Make LEC Hierarchical Compare Successful ........................................................ 16
 LEC Verification Guide

Abort Diagnosis ...................................................................................................... 17

Abort Diagnosis (Isolation for Datapath Module) .................................................... 17
Abort Diagnosis (Isolation for Datapath Module) .................................................... 18
Unresolved Aborts.................................................................................................. 18
Checklist for Resolving Aborts ............................................................................... 18
Set Up LEC Correctly for NEQs ................................................................................. 19
Debugging NEQs ....................................................................................................... 19
Ensure High Quality Mapping ................................................................................ 19
Validate the RTL Elaboration Results .................................................................... 20
Incomplete Modeling .............................................................................................. 20
Using Higher Effort for Modeling and Setup ........................................................... 20
Re-synthesis for Resolving NEQ ............................................................................ 20
Loops and Cuts ...................................................................................................... 20
Checklist for Debugging NEQs............................................................................... 21
Getting Help ............................................................................................................... 21
Checklist for Preparing Testcase ........................................................................... 21
Use LEC New Features in the Dofile ......................................................................... 22
Conformal LEC Drop-In Beta Program................................................................... 22
Recommended Directory Layout ............................................................................ 22
Appendix: Example Dofile for RTL-to-Gate Verification ......................................... 22
Appendix: Example Dofile for Gate-to-Gate Verification ........................................ 23
 LEC Verification Guide

Purpose
This guide reviews the key steps in the synthesis verification flow. Following are the
recommendations in this guide will help streamline the verification process.

This guide covers the following topics:

• RTL design for ease of verification

• Synthesis for ease of verification
• Running LEC effectively
• Resolving abort
• Debugging non-equivalence
• Getting help
• Updating LEC dofile

RTL Design for Ease of Verification

This describes the following:

• The impact of RTL design on verification

• Factors of RTL designs that can affect the ease of verification:
 Don’t care conditions in RTL
 Structural implementation
 Partitioning of designs
• Coding RTL with the previously-mentioned factors in mind to help avoid aborts in
verification

Coding guidelines are provided in the following slides.

RTL Coding Guidelines for Ease of Verification

• Adopt RTL coding guidelines for verification and include them into the designer's coding
style guide.
• Being aware of verification during the design stage can streamline all the downstream
synthesis and verification processing.
• Run LEC in the early stages of design.
o Check that the coding guidelines are fulfilled
o Understand verification complexity for your design style and avoid recoding RTL
at the last minute to resolve aborts
 LEC Verification Guide

Removing Don’t Care Conditions in RTL

Removing don't care conditions in RTL is good for

• Resolving aborts
• Diagnosis
• Performing ECO
• Simulation

Don’t care conditions are created in RTL by

• Array index out-of-range reads

• Parallel/Full case statements
• X assignments
• Range constraints (VHDL)

A don’t care condition in RTL can be synthesized to any Boolean function.

Removing Don't Care Conditions in RTL

LEC can report the RTL source of don't care conditions:
report message -rule F34 -verbose
// Converted 'type of don't care' at 'gate_name' be don't care
source_code_file_name:line_number
(LEC mode)
Example:
// 1: Converted 'index out of range' at 'n1' be don't care
design.sv:321
// 2: Converted 'parallel_case' at 'n2' be don't care
design.sv:322
// 3: Converted 'full_case' at 'n3' be don't care
design.sv:323
// 4: Converted 'X assignment' at 'n4' be don't care
design.sv:324

General rules for removing don't care conditions:

• Preserve the function under the care condition

• Implement a deterministic function under the don't care condition

Removing Don't Care Conditions in RTL (index out-of-range reading)

Interpret the index as a constant 0 when it is out of range:
 LEC Verification Guide

// RTL
wire A, B[6:0], C[2:0];
// Since the index of B only allows from 0 to 6,
// don't care conditions are introduced when C[2:0] > 6.
A = B[ C[2:0] ];
// RTL without don't care conditions
A = B[ (C[2:0] > 6) ? 0 : C[2:0] ];

Removing Don't Care Conditions in RTL (unique case)

Use and/or logic to implement selection function:

In general, the implementation using this coding style is more compact and thus it can yield
optimal synthesis QoR performance.

// RTL
wire sel[1:0];
wire in0, in1, in2;
reg out;
always @(*) // one-hot case selection
unique case (1'b1)
sel[0] : out = in0; // sel = 01
sel[1] : out = in1; // sel = 10
endcase // sel = 00, 11 : don't care
// RTL without don't care conditions
// (branch-1-condition & branch-1-data) |
// ... |
// (branch-n-condition & branch-n-data)
out = (sel[0] & in0) |
(sel[1] & in1);

Removing Don't Care Conditions in RTL (X assignment)

Implement the X assignment as a constant:

// RTL
wire sel[1:0];
wire in0, in1, in2;
reg out;
always @(*)
case (sel)
2'b01 : out = in0;
2'b10 : out = in1;
default : out = 1'bx;
endcase
// RTL without don't care conditions
always @(*)
case (sel)
2'b01 : out = in0;
2'b10 : out = in1;
default : out = 1'b0;
endcase
 LEC Verification Guide

Removing Don't Care Conditions in RTL (range constraint)

Extend the range to the full range of the bit vector:

// RTL (VHDL)
entity mult is
# Since the range is not the full range of the bit vector [1:0],
# don't care conditions are introduced.
port (a, b : IN integer range -1 to 1;
prod : OUT integer);
end mult;
architecture rtl of mult is
begin
prod <= a * b;
end rtl;
// RTL without don't care conditions
entity mult is
# Extend to the full range of the bit vector [1:0]
port (a, b : IN integer range -2 to 1;
prod : OUT integer);
end mult;
architecture rtl of mult is
begin
prod <= a * b;
end rtl;

Structural Implementation in RTL

• As the structural similarity between RTL and the synthesis netlist increases, the ease-of-
verification increases.
• Use detailed structural descriptions in RTL so that structural changes in synthesis are easier
to control.
o For complex arithmetic expressions, introduce intermediate signals and additional
assignments
o Implement datapath word-level structures in an explicit way

Design Partitioning in RTL

• Partitioning design breaks into smaller pieces for ease of verification

• Separate logic into different blocks. Specifically, separate datapath blocks from control
blocks.
• Keep datapath intensive modules to a reasonable size. Modules that have less than 50k
primitives and 50 datapath operators are generally easier to verify.
• Add additional module hierarchies to prevent critical signals from being optimized away for
ease of verification.
 LEC Verification Guide

Design Report
LEC can report the module size in design hierarchies to help you partition the design into
reasonable sizes.
Example:
============================================
Summary Golden Revised
============================================
Design-modules 31 5
--------------------------------------------
AND * 3323 3821
....
XOR * 2106 0
------ word-level --------------------------
ADD * 40 0
MULT * 2 0
SUBTRACT * 34 0
--------------------------------------------
Total 7927 10158

Design Partitioning in RTL (add module hierarchy)

Make critical intermediate signals in RTL as module boundaries and preserve them during
synthesis.

// RTL
module top (input [31:0] a, b, c, d, e, f, output [31:0] out);
wire [31:0] t;
assign t = a + b + c + d + e;
assign out = t * f;
endmodule
// Recoded RTL
module top (input [31:0] a, b, c, d, e, f, output [31:0] out);
wire [31:0] t;
// add module for preserving intermediate RTL signals
new_mod i0 (a, b, c, d, e, t);
assign out = t * f;
endmodule
// add additional module hierarchy
module new_mod (input [31:0] a, b, c, d, e, output [31:0] t);
assign t = a + b + c + d + e;
endmodule

Design Partitioning in RTL (add module hierarchy)

Convert critical functions in RTL to modules and preserve the module boundaries during
synthesis.
 LEC Verification Guide

// RTL
module top (input [31:0] a, b, c, d, e, f, output [31:0] out);
wire [31:0] t;
function [31:0] func_add;
input [31:0] a, b, c, d, e;
begin func_add = a + b + c + d + e; end
endfunction
assign t = func_add(a, b, c, d, e);
assign out = t * f;
endmodule
// Recoded RTL
module top (input [31:0] a, b, c, d, e, f, output [31:0] out);
wire [31:0] t;
// Convert the function into module
new_mod i0 (a, b, c, d, e, t);
assign out = t * f;
endmodule
// add additional module hierarchy
module new_mod (input [31:0] a, b, c, d, e, output [31:0] t);
assign t = a + b + c + d + e;
endmodule

Understand Design Verification Complexity

• Run LEC in an early design stage to understand the verification complexity of the design
style.
• If the design has aborts, LEC can analyze the abort point.
• Example:
• -----------------------------------------------
• Compared result is abort.
• (G) + 38 PO /O1
• (R) + 38 PO /O1
• -----------------------------------------------
• Don't care condition
• 1) (G) X-assignment
• rtl.v:line 17, column 319
• -----------------------------------------------
• Similarity degree of the abort point fanin cone
• 20% fanin cone of gate O1
• -----------------------------------------------
• Datapath resources which cause abort:
• 1) (G) Datapath_module instance
• rtl.v:line 5, column 346

-----------------------------------------------

Run LEC RTL Rule Checker

The LEC RTL rule checker can help reduce many potential synthesis and verification issues.
 LEC Verification Guide

• Check the rules that highlight potential ambiguities in verification, such as simulation
mismatches.
• Ensure that there are no error/warning messages reported by RTL rule checks. To specify
rule severity:

report rule check

Example:

RTL5.1: Overlapped case items are in parallel case statement

Type: Golden Severity: Warning Occurrence: 1

RTL5.4: Partial case items are in full case statement

Type: Golden Severity: Note Occurrence: 1

HRC3.10a: An input port is declared, but it is not completely

used in the module

Type: Golden Severity: Warning Occurrence: 1

Checklist for RTL Designs

Checklist Items
Remove don't care conditions in the RTL
Use structural descriptions instead of behavioral descriptions in RTL
Partition the design into a reasonable size
No error/warning messages reported by the RTL rule checker
No simulation mismatches reported by RTL rule checker

Synthesis for Ease of Verification

Setting up a synthesis flow with verification considerations can significantly reduce verification
challenges:

• Synthesis bugs are more easily identified

• Enables the use of more LEC features (such as module-based datapath analysis and
hierarchical comparisons) to streamline the verification process
 LEC Verification Guide

Multi-Stage Synthesis

The basic guideline for ensuring ease of verification is to break down the difficulty in order to
verify synthesis optimizations in stages.

Recommended synthesis stages:

• RTL to first mapped netlist

o Enable: datapath synthesis
o Disable: ungrouping, boundary optimizations, clock gating, phase inversions,
and name changes
• Mapped netlist to optimized mapped
o Enable: ungrouping, incremental optimizations, boundary optimizations, and
clock gating

Embed Verification Requirements in Synthesis

• To deploy a synthesis flow that is easy to verify, embed the verifications into the
synthesis scripts instead of re-synthesizing after running into verification challenges.
• Control synthesis options that impact verification, such as:
o Range constraint optimization
o Datapath synthesis, resource sharing
o Ungrouping, boundary optimizations, and clock gating
• Allow for a range of verification requirements to allow for trade-offs in verifiability

Module Based Datapath (MDP) Analysis

Module-based datapath (MDP) analysis performs datapath abstraction at the module level, and
is performed prior to the regular operator-level analysis.

MDP analysis requires that synthetic datapath modules be preserved during synthesis. MDP
analysis is performed in order to improve the quality of the operator-level analysis.

Synthesis Script to Enable MDP Analysis

LEC provides a synthesis script that ensures that the MDP analysis can be effectively applied for
ease of verification. The script can be embedded into the overall synthesis script as follows:

## generate the first mapped netlist

source <lec_release_path>/share/cfm/lec/scripts/mdp.tcl
compile_ultra_mdp <level> <design_module>
## generate the final mapped netlist
(with incremental optimization)
compile -incremental
 LEC Verification Guide

• compile_ultra_mdp procedure is invoked before the first compile command in the DC script
• design_module argument in the procedure is the name of the top module that is
synthesized

Synthesis Script to Enable MDP Analysis (continued)

The level argument in the procedure can be 1, 2, 3, or 4 and affects the synthesis as follows:

Preserve Hierarchy of
MDP Level Boundary Optimization Sequential Output Inversion
DP/DW Design
1 YES NO ALLOW ALLOW
2 YES NO DISABLE ALLOW
3 YES NO DISABLE DISABLE
4 YES YES DISABLE DISABLE

Collecting Synthesis Data

During the synthesis process, the following information should be collected for verification:

• Datapath resource file: Required to ensure that datapath intensive design can be easily
verified
• Change name file: Required to ensure name-based mapping for ease of verification
• Synthesis log file: Can contain information to help guide the setup of the verification

Qualifying Your Synthesis Environments

• New versions of synthesis tools can introduce new verification requirements

o New optimization techniques (such as, sequential constant groups)
o New datapath structures (such as, new multiplier architectures)
o New technology mapping techniques (such as, using multi-bit library cells)
o Changes in naming conventions (such as, in generate statements)
o Changes in default synthesis option settings (such as, having sequential merge
optimizations ON by default)
• LEC is shipped with IP-free designs that can be used as testcases in a new synthesis
environment or tool
o Enable users to provide early feedback to the Conformal team to ensure success of
verifications in the latest synthesis environment
 LEC Verification Guide

Checklist for Synthesis

Check Items
Use 2-step synthesis (RTL to first mapped, first mapped to final netlist)
Use MDP synthesis flow
Only incremental optimization is used for gate-to-gate compare
Collect datapath resource file and synthesis logfile

Running LEC Effectively

To ensure the best results of verification:

• Standardize on a dofile
• Deploy advanced features
• Review dofiles regularly

Verification Flow

• Standardize a verification flow (see example dofile in Appendix)

o Use hierarchical comparisons when verifying RTL to mapped netlist
o Use module-based analysis for datapath designs
o Mapped to optimized mapped (can be flattened comparison)
• Deploy advanced LEC capabilities
o Capture these in the standardized dofiles
o Multi-threading for abort analysis and comparison
o Datapath analysis
o Analyze abort
• Review dofiles regularly

Checklist for Running LEC

Check Items
Use a standard LEC dofile to verify the designs
Use hierarchical comparison to compare RTL with the first mapped netlist
Do datapath analysis: analyze datapath -module; analyze datapath
Use "analyze abort -compare" to solve aborts
Use multi-threading for compare and abort analysis: set parallel option -threads 4
 LEC Verification Guide

What is an Abort
• All formal verification tools have a worst-case scenario where it takes an exponential
amount of time to complete
• To avoid the unrealistically long execution and to give a timely response, LEC aborts the
comparison
• Abort is a notion that LEC finds it not likely to prove or disprove the equivalence
relationship within a reasonable amount of time
• Abort also means that LEC will need much more effort and time on the proof, after which it
still may not resolve them

What Causes an Abort?

• Design size
o The larger the size of the design, the more difficult it can be to compare
o Ungrouping design modules or boundary optimization increases the design size
• Design similarity
o Less design similarity makes compare more difficult
o Advanced synthesis optimization usually decreases the design similarity
• Design function
o More complex function such as don't care conditions or datapath makes compare
more difficult
o Synthesis has more chance to optimize the design with datapath or don't care
conditions

LEC Methods to Resolve Abort

• LEC integrates many techniques to resolve abort

o Compare engine
o Datapath analysis
o Hierarchical compare
o Structural partition
o Functional partition
o Multi-threading
• Following LEC recommended usage to execute the tool can utilize the advanced techniques

Advanced LEC Techniques

• LEC commands are available to resolve aborts

o analyze abort -compare
o analyze datapath -wordlevel
o analyze partition
o add partition points
 read design –norangeconstraint –vhdl
 LEC Verification Guide

User can Help to Resolve Abort

• Use LEC recommended synthesis flow

o DC-MDP
o RC-LEC
o Incremental synthesis (gate-to-gate compare)
• Resolving abort through re-synthesis
o Adjust synthesis optimizations
o Keep design hierarchies and preserve critical signals
• Resolving abort through recoding RTL
o Remove don't care condition

Review Synthesis Flow

• Check if non-standard synthesis flow is used:

o Advanced optimizations are turned on during synthesis
o Boundary optimization or ungrouping is applied on the complex modules, which
causes hierarchical compare not efficient

Review LEC Dofile/Logfile

• Hierarchical comparison
o For abort modules, check that no sub-modules (primitive size larger than 5k) are not
blackboxed
• For datapath-intensive designs
o Check that MDP has been used (analyze datapath –module)
o Check that datapath analysis is successful
• Abort Analysis
o Check that LEC abort analysis has been used (analyze abort)
• Multithreading
o Check that multithreading is used for abort analysis

Make LEC Hierarchical Compare Successful

• Sub-modules with high compare complexity must use hierarchical compare to resolve abort
• For hierarchical compare to be successful, it needs to keep the module boundary and
disable all the optimizations across boundary
o Preserve module boundary
o Disable clock gating
o Disable boundary optimizations
• LEC can report the reason that hierarchical compare cannot be applied on the module
 LEC Verification Guide

• LEC generated hier.do

•
• // Module Pair: mod (G) and mod (R)
• // Cause for mismatched ports is hierarchical clock-gating
• // IN (R) port_name (REP)
• // (Extra clock pin due to hierarchical clock-gating)
• ...

• It can guide the user to adjust the synthesis flow to generate the netlist in which the sub-
module can run hierarchical compare

Abort Diagnosis

• When aborts cannot be completely resolved, identifying the region where aborts occurred:
o Allows for more targeted re-synthesis
o Allows for better understanding on the netlist that leads to abort
o Allows for additional verification to these smaller regions
• Techniques for isolating aborts:
o Ensure that the modules are hierarchically compared
 Easier if RTL is partitioned well
o In MDP analysis flow, abstracted datapath cluster can be automatically isolated

Abort Diagnosis (Isolation for Datapath Module)

When using MDP analysis, LEC can isolate the datapath module that causes the abort so that
the remaining non-aborting netlist can be verified:

• Narrow down the abort region. Instead of reporting all fanout keypoints from the datapath
module as abort, only the datapath module is reported as abort (See next slide)
• Invoke abort isolation using the following command:

• analyze datapath –isolate_abort_module -module \

[-resourcefile <filename>]

• Automatically generate a testcase for the abort datapath module using the following
command:

• set project name <project_name>

• ...
• analyze datapath -module [-resourcefile <filename>]
 LEC Verification Guide

Abort Diagnosis (Isolation for Datapath Module)

• Results with abort:

• ===========================================
• Compared points PO Total
• --------------------------------------------
• Abort 256 256
• ============================================

Results with abort isolation:

• ============================================
• compared points PO Total
• -------------------------------------------
• Equivalent 256 256
• ============================================================
• Compared results of isolated instances in Revised design (top)
• ============================================================
• Status Instance (Module)
• ------------------------------------------------------------
• Abort i0/add_1_S1_DP_OP_1_1
• (block_add_1_S1_DP_OP_1_1)
• ============================================================

Unresolved Aborts
When an abort cannot be resolved, running the following methods on the abort points can
increase the chance to detect non-equivalence if it exists in the designs:

• Simulation
• Functional partition
• Set LEC compare effort as complete

Checklist for Resolving Aborts

Check Items
All the sub-modules (primitive size > 5k) in the aborted module have been blackboxed in
hierarchical compare
Use the LEC command to isolate aborted MDP datapath module and extract the testcase
Use "analyze datapath -wordlevel" for the aborted module
Recode RTL to remove don't care conditions for the aborted module
 LEC Verification Guide

Set Up LEC Correctly for NEQs

• Turn on necessary options that are off by default
o Options in set flatten model, such as clock gating
o Mapping method options, such as phase mapping
o Retiming
• Take advantage of synthesis generated files
o Generate mapping files via change name when name correspondence is destroyed
o Sequential merge information
o Retiming state point information
• Properly constrain the design
o Instance equivalence
o Pin constraints

Debugging NEQs
• Remove sequential elements that are not in loops from circuits by using remodel -seq2buf
-all -both to see if the NEQs exist in the combinational logic
• When high numbers of NEQs are reported, make sure verification environment is properly
setup
o Missing top-level constraints (test mode vs. function mode)
o Missing design files, library files
• Large number of unbalanced DFF and DLAT in golden and revised
o set flatten mode –latch_fold is turned on?
• RTL elaboration differences
• LEC incomplete modeling

Ensure High Quality Mapping

• Avoid duplicate names for key points

• If percentage of name-based mapping is low, use:
o Renaming rules to map key points with particular patterns
o change name report from synthesis if available to assist mapping
o SETUP> CHAnge NAme file_name
o [-Summary | -Verbose]
 [-Golden | -Revised | -Both]
 This should be read in after reading the designs/libraries.
o for mapping involving multibit library cells without the
set multibit option
default multibit naming convention
• Turn on phase mapping if necessary
• If unreachable key points need to be compared, first map the reachable
keypoints, then turn on the -unreach option for set mapping method

• Confirm mapping result

o report map point –method –summary
 LEC Verification Guide

o report unmap point -summary

Validate the RTL Elaboration Results

• When NEQs occur during RTL-netlist comparison

o Generate a synthesis elaborated netlist so that multiple comparisons can be done
o RTL vs. elaborated netlist
• Confirm or rule out RTL interpretation differences
• Elaborated netlist vs. netlist
o Very likely, name-based mapping is ideal

Incomplete Modeling

• Check modeling messages to see if modeling options are correctly enabled or disabled with
report message -modeling
• When majority of the design is properly setup, invoke analyze noneq -verbose to see
possible causes
• Correlate synthesis log with LEC modeling messages:
o Use read setup information file_name -type RCLOG | DCLOG
o Check missing sequential constants and constant values
o Check missing and/or incorrect sequential merges
• Clock gating issues
• Check wire-resolution behavior
• Check for same number of cut points created to break feedback paths between golden and
revised

Using Higher Effort for Modeling and Setup

• Using set analyze option -auto -effort high for high effort automatic analyze setup
• Invoke analyze setup -verbose twice
• Invoke analyze setup –effort high after compare
• Use the -repeat option for the remodel command

Re-synthesis for Resolving NEQ

• Re-synthesize module without advanced optimizations

• Iteratively turn on each synthesis optimization
• Isolate the step which introduces NEQs

Loops and Cuts

• Avoid combinational loops in the design, especially oscillating ones

• If combinational loops are due to IO pads, black-box the IO pads if they are instantiated
in RTL and gates
 LEC Verification Guide

• Use set flatten model -loop_as_dlat if the NEQ key points involving unbalanced
number of DLATs and CUTs
• Use analyze setup -cut to fix the cut point positions
• Use abstract logic to abstract away state-holding loops

Checklist for Debugging NEQs

Check Items
Use phase mapping when the mapping is successful and compare is NEQ
Use renaming rules for verifying the synthesis flows that involve name changes
Use analyze setup to automatically correct setup issues
Use analyze noneq to determine the causes of the NEQs
Use diagnose to debug specific compare points
Make sure retiming modules are verified separately from the rest of the designs

Getting Help
• Providing a testcase is the best way to help Conformal improve the capability and help you
resolve the verification issues
• Saved sessions are limited in usefulness for debugging
o Cannot view RTL files, resource files, netlist information, etc.
o Cannot provide RTL recoding
• Review LEC Web Interface documents to see if any latest features can be applied
• Running LEC early and often and reporting LEC issues to Cadence early will provide us time
to investigate and resolve them in a timely manner

Checklist for Preparing Testcase

Check Items
All the necessary design files to reproduce the problem
LEC dofile and logfile
LEC project directory
Synthesis logfile, resourcefile and other report files
 LEC Verification Guide

Use LEC New Features in the Dofile

• usage -auto
Automatically displays usage at the end of every command
• set project name
Automatically stores running information and extracts testcase
• set analyze option -analyze_renaming_rule
Report mapping renaming rule analysis during the flattening process
• write hier_compare dofile -balanced_extractions
Enable more modules to be compared in hierarchical compare

Conformal LEC Drop-In Beta Program

• Best way to learn of upcoming features in LEC

• Help you deploy the latest features of LEC
• Contains standard dofiles that you can use as reference to exploit the latest features in LEC

Recommended Directory Layout

design1/
libs/
rtl/
scripts/
sdc/
syn1/
fv/
outputs/
reports/
scripts/
wlec_rtl2g1_dofile wlec_g1tog2_dofile ... syn2/ ...

• Each synthesis directory should contain:

o The RTL Compiler generated verification directory fv/
o The intermediate and final netlists in outputs/
o LEC dofiles generated by write_do_lec

Appendix: Example Dofile for RTL-to-Gate Verification

// Set up log file, get misc info about the run
set log file <logfile> -replace
usage -auto
// Read in design and library
read library -liberty -replace -both \
<lib_file1.lib > \
<lib_file2.lib >
read design -verilog -replace -golden -noelaborate \
<design_file1> \
<design_file2>
elaborate design -golden
read design -verilog -replace -revised -noelaborate \
<design_netlist>
elaborate design -revised
 LEC Verification Guide

report design data

report black box
// Setup design and LEC run
uniquify -all -nolibrary

// Specifying user renaming rules if needed to help mapping

add renaming rules <rulename> <string> <string> \
[-golden|-revised|-Both]
// Specify user constraints for test/dft/etc
add pin constraint 0 scan_en -golden/revised
add ignore output scan_out -golden/revised
// Specifying the modeling directives for constant optimization,
// clockgating
set flatten model -seq_constant
set flatten model -gated_clock
// Enable multi-threading
set parallel options -threads 4
set analyze option -auto
// Write hierarchical compare dofile
write hier dofile <hier.do> -replace -usage -constraint -noexact \
-balanced_extractions -input_output_pin_equivalence \
-function_pin_mapping \
-prepend_string "report design data; \
analyze datapath -module -resourcefile <file> -verbose; \
analyze datapath -verbose;"
// Run hierarchical compare
run hier <hier.do>

Appendix: Example Dofile for Gate-to-Gate Verification

// Set up log file, get misc info about the run

set log file <logfile> -replace
usage -auto
// Read in design and library
read design -verilog -replace -golden -noelaborate \
<design_file1.v> \
<design_file2.v>
elaborate design -golden
read design -verilog -replace -revised -noelaborate \
<design_file1.v> \
<design_file2.v>
elaborate design -revised
// Setup design and LEC run
// Specifying user renaming rules if needed to help mapping
add renaming rules <rulename> <string> <string> \
[-golden|-revised|-Both]
//Specify user constraints for test/dft/etc
add pin constraint 0 scan_en -golden/revised
add ignore output scan_out -golden/revised
// Enable multi-threading
set parallel options -threads 4
set analyze option -auto
set system mode lec
// Compare
add compare point -all
compare