Conformal Verification Guide 8.1

I N VE N TI V E CONFIDENTIAL
Formal Verification Guide
Prototype | Implement | Verify

Agenda
• Equivalence Checking Refresh

• Verification Guide
– RTL Design
– Verifiable Synthesis Flow
– Abort Resolution
• ECO Automation
• Best Practice Recommendation
2 August 6, 2009 Cadence Confidential

Encounter Conformal Product Family
Verifies 100% of design Equivalence Digital Custom Verification
functionality without including Memories, Data
requiring test vectors Checking
Paths, and IO
Provides independent Orders of magnitude faster
verification for lowest risk RTL RTL than simulation
silicon or or
Gate Gate
Validates CPF Low Power Functional Finds bugs earlier in
LP Equivalence
Verification Checks the design cycle
Checking Verifies proper CDC
Verifies Low synchronization to
Power design v1 v2 avoid clock related
implementation re-spins
ISO
A B Creates safer EC
Performs
environment
structural and
functional checks
Constraint ECO
Design Implementation Provides automated
Validation, generation
RTL2GDS ECO solution
and analysis of
constraints o1 Identifies and generates
fix to implement ECO
Uses industry proven
formal engines Interfaces with physical
o2 implementation tool flow
Shorter design cycle
with improved timing
constraints

Encounter Conformal & FED Product Family
Equivalence Constraint Low Power
Checking Design
Verification
RTL RTL
or or Functional
Gate Gate Checks v v2
1 ISO
A B
100% Independent vector-less Validation, generation & analysis Structural and functional LP checks
verification of implementation of constraints
LP design implementation
RTL Gate Transistor Shorter design cycles with Verification
improved timing constraints
CDC & Ext Checks LP Equivalence Checking
New Products
ECO RC-Physical Chip Planning

Implementation Synthesis Systems
o
1
o
2
Automated RTL2GDS ECO solution Physical Correlation & Architectural & Economic Forecasting
Identifies and generates ECO fix Predictability with final Lower IC Cost & Expedite TTM
backend
Congestion Analysis & Opto
(Congestion Relief)
Crash Course on
Equivalency Checking

Equivalence Checking Flow
Golden Standard Revised
Design Library Design
Specify Constraints
and Design Modeling Setup Mode
Specify Compare LEC Mode

Parameters
Compare Designs
yes
Miscompare? Diagnose
no
Equivalence Checking
Complete
Mapping! What is that?
Pairing corresponding golden and revised key points:

G R
PI PI
PO PO
DFF DFF
DLAT DLAT
BBOX BBOX
CUT CUT
Z Z Golden Revised
E E
Key points E Extra Points
Combinatorial logic
U Unreachable Points
Unmapped Points

Comparison
– Only mapped points can be compared.
– Comparison is an iterative process.
• Conformal remembers points already compared.
• Comparison can be interrupted with Control-c.
• Enter compare to continue comparing.
set log file logfile.$LEC_VERSION -replace

add notranslate module *sram* -library -both
read design cpu_rtl.v -verilog -golden
read design -file verilog.vc -verilog -revised
add pin
// Command: constraint 0 scan_en -revised
compare
================================================================================
set flatten model -latch_fold
Compared points PO DFF DLAT BBOX Total
add renaming rule rule0 "abc" "xyz" -map -revised
--------------------------------------------------------------------------------
add renaming
Equivalent 2 rule146rule1 2 "xyz"1 "C" -map
151 -golden
--------------------------------------------------------------------------------
set system mode lec
Non-equivalent 0 2 0 0 2
add compare points -all
================================================================================
compare
...

Using the Mapping Manager to Debug NEQs
Main window
Unmapped
points
Mapped
points
Compared
points

Categories of Comparison Results
Equivalent: Key points proven to be equivalent (green-filled
circle)
Inverted-Equivalent: Key points proven to be

complementary (divided green-filled circle)
Nonequivalent: Key points proven to be different (red-filled

circle)
Abort: Key points not yet proven equivalent or nonequivalent

due to timeout or other system parameters (yellow-filled circle)
Not-Compared: Key points not yet compared

? LEC> report compare data -class [...]

RTL Design
For Ease of Verification
RTL Design For Ease of Verification
• To highlight the impact of RTL design on verification

– Useful for RTL designers to understand their impact of coding
styles on verification
– Useful guidelines for machine/script generated RTL codes
• Factors in RTL designs that can affect the ease of
verifications are
– Don’t care conditions in RTL description
– Structuring of logics
– Partitioning of designs

Don’t-Cares Conditions in RTL
• Don’t-care conditions are created in RTL by

– X assignments
– Incomplete case
– Out-of-range indexing
– Range constraint (VHDL)
• A don’t-care condition can be synthesized to
– a constant (zero or one)
– or any Boolean function
• Designs with extensive don’t-care conditions can be difficult to verify
• Use LEC “report design data” to report don’t cares
• Use LEC “report rule checks” to report out-of-range indexing

LEC Feature
RTL Rule Checkers
• LEC’s RTL rule checker provides an fast and easy way

to detect RTL coding styles that can impact verification
• For example, index out of range is reported as

– // Warning: (RTL7.3) Array index in RHS might
be out of range (occurrence:1)
• Running LEC RTL rule checker early in the RTL design

process can reduce many potential synthesis and
verification issues later on

LEC Feature
RTL Rule Checkers
SETUP> read design –golden rtl.v
SETUP> read design –revised rtl.v
SETUP> set system mode lec
SETUP> report rule check –golden –design –verbose > lint.rpt
SETUP> report message –golden –model –verbose > model.rpt
• Consider Synthesis and EC ramifications of design

– Multiply-driven and floating nets
– Combinational cycles
– Assignment size mismatch
– Ambiguities leading to simulation mismatches
– Etc

Don’t-Cares Due to Index Out of Range
• Don’t care is created when index is out of range

– When the index can address more locations than
what an array can hold
• For example
reg [4:0] q; // q has 5 locations
Reg [2:0] A; // A can index 8 locations
BAD - q[A];
// (1) out-of-range condition
GOOD - q[(A > 4) ? 0: A)];
// (2) No out-of-range

Logic Structuring
• Structural Similarity
– How closely does RTL structure match the netlist
• Designs with higher structural similarity between RTL
and netlist are easier to verify
• Synthesis can restructure code. For examples:
– Resource sharing
– Map unsigned operators to signed operators
• Minimize structural differences between RTL and netlist
by:
– Using Verilog 2K to code signed arithmetics
– Using explicit grouping (such as in additions) with parenthesis
– Manually code resource sharing

Design Partitioning
• Partitioning a complex block breaks it into smaller pieces

for ease of verification
• Guidelines
– Keep high complexity design modules small in size
– Avoid excessive logic cone depth
– Separate datapath block (especially those requiring retiming)
from control block
– Partitioning may impact QOR so the tradeoffs should be
explored early in the design cycle
• Smaller blocks are easier to verify. Well partitioned
designs can also make use of more techniques to ease
verifications

Verifiable Synthesis Flow

Module Data Path
Architecture & Advanced Synthesis
Optimizations Create Verification Challenges
Datapath Resource
Architecture Sharing
LE C
Boundary Phase
Optimization Inversion
• A synthesis flow with verification considerations can significantly

reduce verification challenges
– Enable the identification of synthesis bugs more easily
– Allow use of more LEC features (e.g., module-based datapath analysis,
hierarchical comparisons) to streamline the verification process

Synthesis For Ease of Verification
Synthesis Optimization on Datapath Modules
ungroup/
boundary
optimization
RTL th
ap a
t
Da ign
Des
• Synthesis tools like RC and DC can group several datapath operators into a
single datapath unit which called datapath module. These modules can be
synthetic or they can be instantiated components such as DW modules
• For Design Compiler, these modules are reported in the resource report
with string DP_OP as naming convention
• These modules boundary are not preserved if ungrouping and boundary

optimization are applied, making them difficult to prove
Synthesis Flow Needs To Be Verification-Friendly

Multi-Stage Synthesis
• The basic principle of ensuring ease of verification is to

break difficult to verify synthesis optimizations into
stages in the synthesis flow
• Recommend synthesis stages
– RTL to first mapped netlist
• Enable: datapath synthesis
• Disable: ungrouping, boundary optimizations, phase inversions
– Mapped netlist to optimized mapped
• Enable: Ungrouping, Incremental optimizations, boundary
optimizations

Embed Verification Requirements in Synthesis
• To deploy an easy to verify synthesis flow, embed the verifications

into the synthesis scripts
– Instead of resynthesizing after running into verification challenges
• Control synthesis options that impact verification, e.g.,
– Range constraint
– Datapath synthesis, resource sharing
– Ungrouping, boundary optimizations
• Allow for a range of verification requirements to allow for trade-offs
in verifiability
• This is default behavior for Encounter RTL Compiler (RC)

LEC Feature
Module Based Datapath (MDP) Analysis (DC Synthesis)
• Datapath synthesis may cause aborts because of

operator optimization.
• This is handled in RTL Compiler with Netlist Verification
(more later). DC netlists require MDP.
• Module-Based Datapath (MDP) Analysis performs
datapath abstraction at a module level
• This analysis is performed in addition to and prior to the
regular operator level analysis
• The result goal is to improve the quality of the operator-
level analysis
• Requires the preservation of synthetic datapath modules
during synthesis

(MDP) Analysis (DC Synthesis)
DC Final
RTL
RTL DC Script Gate
Script
Original Flow
LEC
DC + MDP Final •Include MDP Script

RTL
Script Gate
•Output Intermediate &
Final Netlist
New Flow
•Perform RTL2Gate
C
LEC
Intermediate
Gate
LE •Perform Gate2Gate
Improve Synthesis Script to Ensure Verification Success

DC Synthesis Script to Enable MDP Analysis
• To enable the successful verification of datapath design using

Design Compiler synthesis, LEC provides a script to ensure that
LEC’s Module-Based Datapath (MDP) Analysis can be effectively
applied
• The script can be embedded into the overall synthesis script as
follows
source <lec_release_path>/share/cfm/lec/scripts/mdp.tcl
…
compile_ultra_mdp <level> <design_module>
compile_ultra …
…
<continue original DC synthesis script commands>
…
• compile_ultra_mdp command is placed before the first
compile_ultra command in the DC script
• Design module is the name of the top module that is synthesized

DC Synthesis Script for Datapath Verification
• MDP level can be 1, 2, 3, or 4, and affects the

synthesis as follows
MDP Preserve Hierarchy of Sequential

Boundary
Output
Level DP/DW Design Optimization
Inversion
1 YES NO ALLOW ALLOW
2 YES NO DISABLE ALLOW
3 YES NO DISABLE DISABLE
4 YES YES DISABLE DISABLE

Collecting DC Synthesis Data
• During the synthesis process, the following information

should be collected for verification
– Datapath Resource File: This is required to ensure that datapath
intensive design can be easily verified
– Change Name File: This is required to ensure name-based
mapping for ease of verification
– VSDC File: This file contains information that can help to guide
the setup of the verification
– Synthesis log file: This can contain information to help guide the
setup of the verification

LEC Feature
Qualifying Your DC Synthesis Environments
• New versions of synthesis tools may introduce new verification

requirements
– New optimization techniques (e.g., sequential constant groups)
– New datapath structures (e.g., new multiplier architectures)
– New technology mapping techniques (e.g., using multi-bit library cells)
– Changes in naming conventions (e.g., in generate statements)
– Changes in default synthesis option settings (e.g., having sequential
merge optimizations ON by default)
• LEC ships with IP-free designs that can be used as testcases in a
new synthesis environment or tool
– Enable users to provide early feedbacks to the Conformal team to
ensure success of verifications in the latest synthesis environment
– At $conformal_dir/share/cfm/lec/demo/*

How to Determine QoR Impact
DC Final
RTL
RTL DC Script Gate
Script
Original Flow
LEC QoR Impact
DC + MDP Final
RTL
RTL DC Script Gate
Script
New Flow
EC Intermediate
LEC
L Gate

RC Netlist Verification Flow
• RC verification flow
– Only one intermediate netlist between RTL code and the final
netlist
– Two LEC comparisons: RTL-to-Intermediate & Intermediate-to-
Final
– Better support of advanced (datapath) optimizations
– LEC-friendly netlist by 'write_hdl –lec’
• additional datapath info (as comments) about architecture changes

RC Netlist Verification Flow
•Synthesize with no
write_hdl -lec Final ungrouping
New Flow RTL Gate
•Output Intermediate &
Final Netlist
•Perform RTL2Gate
LEC Intermediate
Gate
LEC
•Perform Gate2Gate
Intermediate netlist to Ensure Verification Success

RC Netlist Verification Flow for Datapath
read_hdl
elaborate First netlist generated
read_sdc with “-lec” option
synthesize -to_mapped
write_hdl -lec > intermediate.v
write_do_lec -revised intermediate.v > rtl2map.do
Do not ungroup before
[ungroup in any way] first netlist
<no more datapath architecture change>
synthesize -incr as many times as wished without “-lec” option;

write_hdl > final.v
write_do_lec -golden intermediate.v -revised final.v >
map2final.do
exit Every “write_hdl” followed

by “write_do_lec”

RC Netlist Verification Flow for Datapath
• First LEC run (RTL-gate):

read design <RTL_code> -golden
read design intermediate.v -revised
compare
– write_do_lec generates a hierarchical dofile script (rtl2map.do)
– Conformal dofile script will contain the following commands:
analyze datapath –module –verbose
analyze datapath -verbose
• Second LEC run (gate-gate):

read design intermediate.v -golden
read design final.v -revised
compare
– write_do_lec generates a flat dofile script (map2final.do)

Summary
• When a design is complex and contains many

datapath operators, with today’s advance synthesis
optimizations, the datapath become structurally
different between RTL and netlist, creating challenge
to all verification tools
• To effectively help Conformal datapath analysis
quality and improve verification result, an integrated
synthesis & verification flow is needed
• DC MDP Analysis and the recommended synthesis
script will help close the gap between datapath
synthesis and verification
• RC Netlist Verification flow reduces the chance of
aborts for a more complete verification

Abort Resolution
Resolving Aborts
• Abort is reported when formal (exhaustive) analysis

cannot provide a complete proof of equivalence within a
resource limit
– The design has been partially verified since no input vector
resulting in non-equivalence has been found either
• Resource limit is adjusted by compare effort
– SET COMPARE EFFORT <LOW|MED|HIGH|COMPLETE>
• This section describes
– Techniques to resolve aborts
– Methods to isolate abort to better understand the aborted region
and options for further verifications

Resolving Aborts
Review Synthesis Flow
• Abort can be avoided by following the guidelines given

earlier
• For datapath intensive design
– Check that MDP level 4 has been used for DC synthesis
– Use Netlist Verification Flow for RC synthesis
• RTL design for ease of verification
– Check for excessive don’t care conditions with LEC’s rule
checker and design report
• Partition the design well and use LEC’s hierarchical
comparison
– Check that all complex modules can be hierarchically compared

Resolving Aborts
Review LEC Dofiles
• Hierarchical Comparison
– Check that hierarchical comparison is used
– For module containing abort, check that it has no submodules
that can be further hierarchically compared
• For datapath intensive design
– Check that MDP has been used (Analyze datapath –module)
– Check that datapath analysis are successful
• Abort Analysis
– Check that LEC’s abort analysis has been used (analyze abort)
• Multithreading
– Check that multithreading is used for abort analysis

Resolving Aborts
Advanced LEC Techniques
• Several advanced techniques are available to resolve

aborts
• Advanced options for ‘analyze datapath’
– -wordlevel
– -share
– -effort high
– -addertree
• Advanced commands and techniques
– run partition_compare (help run partition_compare –verbose)
– add partition points
– read design –norangeconstraint –vhdl

Resolving Aborts
Re-synthesis and RTL Recoding
• Re-synthesis of problem blocks

– Adjust effort level
– Disable range constraints
– Preserve key signals and boundaries
• Pros
– Makes verification easy for all future runs
• Cons
– Requires additional efforts, may impact quality

Resolving Aborts
Abort Isolation
• When aborts cannot be completely resolved, it is

useful to identify the region where aborts occurred
– Allow for a more targeted re-synthesis
– Allow for a better understanding on the netlist that leads to abort
– Allow for additional verification to these smaller regions
• Techniques to isolate abort
– Ensure that the modules are hierarchically compared
• Easier if RTL is partitioned well
– In MDP analysis flow, abstracted datapath cluster can be
automatically isolated

LEC Feature
Abort 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
– That is, if the remaining netlist is equivalent and the datapath
module is also equivalent, then the entire netlist is equivalent
• Provides more visibility into the region of abort
– Instead of reporting all fanout keypoints from the datapath
module as abort, only the datapath module is reported as abort
(See next slide)
• The is invoked as
– ANALYZE DATAPATH –isolate_abort_module …

LEC Feature
Abort Isolation for Datapath Module
• Results with abort:

==============================================================
Compared points PO Total
--------------------------------------------------------------
Abort 67 67
==============================================================
• Results with abort isolation:

==============================================================
Compared points PO Total
--------------------------------------------------------------
Equivalent 67 67
==============================================================
Compared results of isolated instances in Revised design (top)
==============================================================
Status Instance (Module)
--------------------------------------------------------------
Abort i5/add_123_S1_DP_OP_123_456
(NV_GR_PE_STRI_core_add_123_S1_DP_OP_123_456)
==============================================================

Resolving Aborts
Multi-Threading
• For machines with multi-core CPUs

– No need to set up the parallel processing environment
– Takes advantage of multi-core, multi-CPU machines
• Parallel Comparison
LEC> compare –threads #
• Best for large gate-to-gate comparisons, where the comparison can
be distributed to multiple comparison threads
LEC> analyze abort –compare –threads #

• Best for RTL-to-gate comparison aborts, where a few keypoints can
consume a large portion of the runtime
*Obsoletes the previous method of parallel comparisons using the command Run Parallel Compare

Resolving Aborts
Datapath Analysis
• Support two new multiplier architectures
• Improve divider architecture analysis
• Support higher effort analysis for better datapath learning quality.
Results from sample testcases
Radix-8
Unsigned Divider
High Effort
Analysis

ECO Automation

ECO Challenges
Nomenclature
• Engineering Change Order (ECO) is the process of making local

changes to the design netlist without re-running the entire synthesis
and P&R flow
• ECO Types
– Functional ECO
• Changes the functionality of the design
– Non-functional ECO
• Fix timing, cross talk, DRV, routing violations with minimal effort
• ECO Stages
– Pre-Mask ( Pre tape-out) ECO
• Uses normal logic gates to implement change
– Post-Mask (Metal-only ECO)
• Uses spare gates only to implement change

ECO Challenges
Manual Task
• Current ECO flows are manual

– Process is very time and resource consuming
– Error Prone
– Limited by ECO size
• Very difficult to identify location of needed fix

– Easy to modify RTL, yet difficult to transfer fix to gate netlist
• Manual ECO changes do not easily incorporate use of

– Spare gates, location, timing, routing access
– Freed cells (used originally but not used in ECO patch)
• Hard to manually optimize the eco patch

ECO Challenges
Manual Flow Targeting Post Mask ECO
Old RTL
Use limited Will this ECO
(R1) meet timing, is it
Metal
Layers! DRC clean?
Synthesis
Back-end ECO
Test Insertion
P&R
P&R Delete/add connections
Map to spare gates
Which logic
cones are affected?
New RTL Old Netlist
EC Old DEF ECO Route/DRV/SI
(R2) (G1) OR
Difficult to
identify
How can I get Create
where to fix!
Manual the smallest ECO
Editing Final Netlist
possible Cmd
(New DEF)
change?
What type/many
EC New Netlist spare cells are
Front-end ECO
(G2) available and how

Repeat can I optimally map
process for new gates to them?
each ECO

Cadence ECO Solution
Complete Capability
– Only flow that provides RTL2GDS ECO flow
Old Gate/DEF New RTL w/ ECO Predictable Closure
– Single-pass integrated flow ensures functionality
and timing requirements are met
Encounter ECO – Power domain awareness allows ECO for low
power designs that use multiple power domains
Front-end Functional Fast time-to-market
ECO – Automated flow with minimal manual
intervention
Back-end Physical
ECO implementation – Post-mask ECO flow helps manufacturing to
start while providing ECO flexibility at a late
stage
Reduced Cost
– Improved designer productivity
GDSII
– Flexibility to do ECO with frozen metal layers
reduces manufacturing cost

Cadence ECO Solution Flow
New RTL Old RTL

(R2) (R1)
Synthesis SDC Synthesis
Back-end ECO
Test Insertion
SOCE
P&R
Pre-mask ECO
ECO placement & routing
Post-mask ECO
New Netlist Old Netlist DEF GA/SG mapping & eco
(G2) (G1) (G1) routing
Functional Tech Map

ECO & ECO Netlist Final Netlist
Patch
Patch
Analysis Patch Optimize (G3) (G4)
Conformal ECO Designer Front-end ECO

Conformal ECO Designer
Objectives
• Provides automation to implement functional ECO’s

– Uses proven formal engines
• Generates the minimal change in the design netlist

– Preserves the rest
• Leverages Cadence logic and physical synthesis technology to map and

optimize ECO logic
– Support pre-mask and post-mask flow
• Provides faster turnaround time

– Minimizes manual intervention
– Generates early estimate on ECO feasibility
– Provides high value in the design cycle when schedule delays are highly visible
• Reduces Costs
– Improves designer productivity
– Offers flexibility to do ECO with metal-only layers thus reducing manufacturing
cost

Functional ECO Flow: Step 1
Create gate netlist from New RTL and identify changes
• Compare old RTL (R1) to post- New RTL Old RTL

layout old netlist (G1) (R2) (R1)
– Should be equivalent (avoids

common mode errors) Synthesis
Equivalence
Check
• Synthesize the new netlist (G2)

– Provides a structurally similar netlist
New Netlist Old Netlist
• Compare new RTL (R2) to new (G2) (G1)
netlist (G2)
– Should be equivalent
• Compare old netlist (G1) to new
netlist (G2) Conformal
ECO
– Identify non-equivalent modules
– Identify non-equivalent logic cones
Non-Equiv
to prepare for patch generation Report

Functional ECO
Patch Generation
Old P&R Netlist (G1)
o1
o2
Conformal ECO
o3 o1
o2’
o3
O1
ECO
O2 New Netlist (G3)
O3 • Compare Designs
• Extract ECO
New Synthesis Netlist (G2) • Generate minimal patch
Analyze ECO
ANAlyze Eco
<patch_filename>
[-REPlace]
[-EFFort <HIGH | LOW | MEDIUM | SUPER | ULTRA>]
[-PRESERVE_clock]
(LEC Mode)
// Command: compare
================================================================
Compared points PO DFF Total
--------------------------------------------------------------------------------
Equivalent 38 100 138
--------------------------------------------------------------------------------
Non-equivalent 0 2 2
================================================================
// Warning: There are extra POs in Golden
// Command: analyze eco patch.v -rep
// Grouping
// Note: 1 group(s) added
// Note: 0 library cell(s) is in the patch
// Note: 17 primitive(s) are in the patch

Apply Patch
APPly PAtch
<module_under_ECO_name>
<patch_module_name>
[-KEEPHierarchy]
[-NETnaming <format_string>]
[-INStancenaming <format_string>]
[-SEQuantialnaming <format_string>]
[-KEEPFreed | -TIEFREED0 | -TIEFREED1 ]
[-AUTO]
[-Golden | -Revised]
(Setup Mode)
// Command: apply patch test_1 test_1_eco -keephierarchy

// Note: 0 library cell(s) is in the patch
// Note: 480 primitive(s) are in the patch
// Warning: 24 module instance(s) are in the patch
// Note: 106 library cell(s) are freed
// Note: 0 library cell(s) is recycled

Patch Optimization for Pre-mask ECO New Netlist
(G2)
Old Netlist
(G1)
• Generate the ECO Patch file Analyze

ECO
– Minimize delta circuit between old gate
and new gate Design+ Patch
Patch
Patch(es)
– Preserve scan chain
– Handle clock gating Tech. Map
Run Optimize SDC
• Maps the generated patch to the target Script
technology library Optimized

patch(es)
– Optimizes logic
• Applies technology mapped patch file to Integrate
ECO
the old gate netlist (G1)
– Write out ECO netlist (G3) ECO Netlist
(G3)
• Compares new netlist (G2) to ECO netlist

Equivalence
(G3) Check

Spare Gate mapping for Post-mask ECO
• Conformal ECO generates patch New Netlist Old Netlist
(G2) (G1)
• DEF is read in to derive standard cell spare
gate physical information
Conformal ECO
SDC
– Spare cell types and instance quantities Analyze
ECO
– Spare physical location
• SDC, LEF, Cap tables read in Patch
Patch LEF
• Maps the generated patch to the target std.

cell technology library using restricted set Physically
Aware DEF
representing spare logic + freed up cells Spare Gate
Tech.
– Considers spare gate location and timing mapping
(G1)
– Reports inadequate spare cell resources
• Applies spare gate mapped patch file to the New Netlist SG Map
File
old gate netlist (G1) (G3)
– Writes out ECO netlist (G3) and SG map file Equivalence

SOCE
Check Post-mask
• Compares new netlist to ECO netlist P&R

Optimize Patch
OPTimize PAtch
-WORKdir <working_directory>
-LIBrary <library_file_list>
[-SDC <sdc_filename>]
[-KEEPHierarchy]
[-AVOID <cell_name>*]
[-USE <cell_name>*]
[-POSTLIBscript <script_name>]Check: The Command Reference Manual
[-POSTSYNscript <script_name>]
[-PRESYNscript <script_name>]
For More Details…
[-NETnaming <format_string>]
[-INStancenaming <format_string>]
[-SEQuentialnaming <format_string>]
[-CAPtable <filename>]
[-USESPARE]
[-DEF <filename>] [-LEF <filename> …]
[-SPEF <spef_filename>]
[-MAPscript <filename>]
…
(Setup Mode)
DESCRIPTION
Writes out an RTL Compiler script (cfm_eco_rc.tcl) in the working directory
that will optimize the patches and execute the script.

Example Log Output:
Optimize Patch
• // Command: apply patch abc abc_eco -gold -keephierarchy

• // Note: 42 library cell(s) are in the patch
• // Note: 37 primitive(s) are in the patch
• // Note: 76 library cell(s) are freed
• // Note: 0 library cell(s) is recycled
• // Command: optimize patch -work OPT_PAT -lib ../std_cell.lib
• // Note: Wrote VERILOG design successfully
• // Parsing file OPT_PAT/abc_eco.gv ...
• // Note: Read VERILOG design successfully
• // Note: Flatten patch abc -instance abc_eco

Report Eco Changes
REPort ECo Changes
[-MODule <module_name>]
[-SUMmary]
[-SCRipt]
(SETUP Mode)
// Command: report eco changes –script > change_script.tcl
Example change_script.tcl NOTE:

• # ===============================================
• # MODULE chip
Example
• # =============================================== is
• set_root_module chip
Truncated
• # DISCONNECT PINS : 230
• disconnect_pin {icd_core/mc_top/u5/p4379A/A2} ;# net:icd_core/mc_top/u5/state[59] ,
dir:in
• # DEL INSTANCES : 212
• delete_instance {icd_core/dbg_top/p29680A} ;# OAI22D0
• # ADD INSTANCE :1
• add_instance {chip_eco} {chip_eco}
• # ADD NET : 27
• add_net {icd_core/mc_top/u5/state[59]_1}

Sample ECO Dofile (flat run)
setlog
set logfile
filelogfile.$LEC_VERSION
logfile.$LEC_VERSION–replace
–replace
readdesign
read design–file
–fileG1.v
G1.v-verilog
-verilog–golden
–golden
readdesign
read design-file
-fileG2.v
G2.v-verilog
-verilog–revised
–revised
flatten-nolibrary
flatten -nolibrary-revised
-revised
addpin
add pinconstraint
constraint00scan_en
scan_en–gold
–gold ////Scan
Scanchain
chaincontrol
control
setflatten
set flattenmodel
model–gated_clock
–gated_clock ////Gated
Gatedclock
clockcontrol
control
setsystem
set systemmode modelec lec
addcompare
add comparepoint point–all
–all
compare
compare
Analyzeeco
Analyze ecopatch.v
patch.v–rep
–rep
Setsystem
Set systemmode
modesetup
setup
readdesign
read designpatch.vpatch.v–append
–append
applypatch
apply patch-auto -auto
optimizepatch
optimize patch-workdir
-workdirWORK
WORK-library
-library.slow.lib
.slow.lib-sdc
-sdctop.sdc
top.sdc\ \
-INStancenaming"ECOinst_%d"
-INStancenaming "ECOinst_%d"-NETnaming
-NETnaming
"ECOnet_%d"-SEQuentialnaming
"ECOnet_%d" -SEQuentialnaming"ECOreg_%s"
"ECOreg_%s"
writedesign
write designG3.v G3.v
reporteco
report ecochanges
changes–script
–script>>changes_script.tcl
changes_script.tcl
Summary
Conformal ECO Designer == Faster TTM!

• Only solution for front-end functional ECO
• Supports Pre and Post Mask ECO
• Leverages proven and trusted Conformal technologies
• Helps bring predictability to ECO process
• Reduced costs due to the improved designer
productivity and lower manufacturing costs
RTL-GDS
RTL Metal

Best Practices /
Recommendations

Best Practices
Verification Flow
• Standardize on a verification Flow

– Use Hierarchical comparison for verifying RTL to mapped netlist
• Use resource file for Design Compiler synthesis
• Use Module-based datapath analysis for datapath design
– Mapped to optimized mapped
• Can be flattened comparison
• Deploy advanced LEC capabilities
– Capture these in the standardized dofile
– Multi-threading for abort analysis and comparison
– Datapath analysis
– Analyze abort
• Review dofiles regularly

Best Practices
Example of Standard Dofile Script
read design -golden ...

read design -revised ...
report design data
report black box
uniquify -all -nolibrary
<constraints>
write hier dofile <hier.do> -replace -usage -constraint -noexact -run_hier \
-prepend_string "report design data; analyze setup -verbose; usage; analyze
datapath -module -resourcefile <file> -verbose; usage; analyze datapath -
verbose; usage"
usage
set parallel option -threads 4
run hier <hier.do> -analyze_abort
usage

Encounter Conformal Virtual Reference Series
• Three online
tutorials
– EC Jumpstart
– Debug Techniques
– Custom EC
• Each 2 hour
tutorial includes:
– slides with audio
– videos
– quizzes
Enroll through http://trainingondemand.cadence.com

Encounter Conformal Forum on
http://www.cadence.com/community/
• User-driven
• Post questions,
tips, answers
• CoreComp group
has been posting
a ‘tip of the
month’
– Easy to sign up
for automated
notification

Best Practices
Customer Support
• Create a Service Request by:
– http://sourcelink.cadence.com
– mailto:support@cadence.com
– Toll Free 877-CDS-4911 (877-237-4911)
• A SR number will be generated automatically
– A CS engineer will be assigned
– Your issue will be tracked
– It allows us to detect trends and enhance the tool and the
documentation
• No SR number is generated if an AE is contacted
directly and Customer Support is not involved
• You should still cc your AE on the SR for critical issues

Best Practices
Customer Support
• Search Solutions on SourceLink
– Includes a large number of articles on Conformal
– Search function has been improved
• Local Technical Resources:

– Sean Lee – surlung@cadence.com
– Noel St. John – noel@cadence.com
– Shankar Vellanthurai – shankarv@cadence.com

Best Practices
Preparing a Testcase
• Complete
– All required design files are included
– All synthesis log and report files are included
– Hard coded paths are removed/recoded
– Validate environmental settings (e.g., TCL, or env)
• Small
– Isolate to the problem module or region
– Remove any files that are not needed for the testcase
– A clean dofile to execute the testcase
• Validate
– Double check with the latest production release and include the
log file results

Best Practices
Conformal Tool Usage
• Use the latest version
– Contains CCR fixes, check RELEASE notes for the list
– New enhancements
• Make use of the all the features available to you. For

Conformal XL for example:
set analyze option –auto
set datapath option –auto –verbose
run hier_compare

Best Practices
Applications
• RTL conversion check

– Verilog 2001 to System Verilog comparison, and vice-versa
– Schematic to RTL conversion
• Library conversion and consistency
• Design version consistency
• Early adoption of less-mature implementation tools
[Reference: Padnos, Steve; Atheros Comm. 2008]

LEC Feature
Conformal LEC Drop-In Beta Program
Slides to detail all new features

Includes AEwares (scripts to extend the functionalities of LEC)
Standard dofiles that you can use as reference to deploy the latest
features
Example testcases are provided
• Available before each major releases!

– Best way to learn of upcoming features in LEC
– Help you deploy the latest features of LEC
• To make use of the Beta Program

– Contact your local AE
– Read the details (are they clear?)
– Run the provided testcases (do they illustrate the features well?)
– Apply to your own environments (Are they effective?)

The Most Important Recommendation

Debugging Tips
Debugging Nonequivalent Key Points (NEQ)
– After sorting the cone size using the Mapping Manager,

diagnose the smaller cone first.
– Concentrate on one logic cone at a time.
– Use the following diagnosis managers to debug nonequivalent
key points:
• Mapping Manager
• Diagnosis Manager
• Schematic Viewer
• Source Code Manager
• Hierarchical Browser
• Gate Manager

Main
window
Mapping
Manager
Unmapped
Points
Mapped
Points
Compared
Points

(continued)
• To display only
nonequivalent
results:
• 1. Choose Class
—Disable All
• 2. Choose Class
— Non-
Equivalent

Sorting Key Points by Supporting Size
• Diagnose smaller logical

cones first.
• Smaller logical cones are
on top of the list.
• To sort key points by
size:
1. Left-click a compared
point.
2. Right-click the point and
choose Sort by
Support Size.

Displaying the Diagnosis Manager
• To display the
Diagnosis Manager:
1. Click left to select a
nonequivalent point
(red-filled circle).
2. Click right and
select Diagnose.
•

Diagnosis Manager
Compared Point
Diagnosis Point (Active)
Diagnosis Points (inputs)
Corresponding Support
Noncorresponding Support
Noncorresponding,
and not mapped (red)
M Noncorresponding but
mapped (yellow with M)
Error Candidates
Diagnosis Manager (continued)
– Color-coded support
points
– Cross-highlighting of
support key point
and error pattern
Red: Nonequivalent points

Green: Equivalent points
Black: Points will not be or
are not yet compared
Brown: Abort points

Diagnosis Information
seq1
A 1 1
1 1
1 D
GOLDEN seq0 DFF
1
D QQ 1
DFF
CP
Corresponding Diagnosis Compare Points

Support points Input
1 1 seq1
A 1 0 0 D
0 Q
seq0 DFF
D Q 1
REVISED Q CP
DFF
Path to Error Candidate
CP (highlighted)
1 1 0
Noncorresponding B
support points
Error Candidate
Schematic Viewer
Diagnosis Manager
Double-click any gate to
display the Source
Code Manager.
Golden Revised

Source Code Manager
– Golden and Revised gates are highlighted.
– Signal can be traced across modules.

Gate Manager
Gate Manager
Browse Design Connectivity

Mapping Manager

Analyze Commands (XL License Required)
• The following analyze commands help with diagnosing

errors in your setup or in your design:
– Analyze Nonequivalent
– Analyze Setup
– Analyze Abort

Analyze Nonequivalent Command
• The analyze nonequivalent command helps identify the

possible causes of nonequivalent compared points. This
command must be used in the LEC mode.
• Syntax
ANAlyze Nonequivalent [ <gate_id> |
<instance_pathname*> [-Golden | -Revised] ]
[-Summary | -Verbose]
• Example
analyze nonequivalent -summary

Debugging with Analyze Nonequivalent
The -summary and -verbose options of the analyze nonequivalent command
report the following nonequivalence issues:
– Sequential constants – DFF to DLAT zero

– Clock gating – DLAT transparency
– Sequential redundancy – DFF Set/Reset/Data interaction
– Sequential merge – Redundant DLAT
– Z gate mapping – Unbalanced blackbox
– Phase mapping – User-added cut points
– Direct feedback – User-added partition points
– DLAT folding – Output Z gate (true error)
Example
LEC> analyze noneq -verbose
Analyzing nonequivalent compared points:
(G) +5 DFF /u2
(R) +5 DFF /u2
The clock of DFF in Golden is not gated.
The clock of DFF in Revised is gated.

Debugging with Analyze Nonequivalent (continued)
• Example of Gated Clocks
• Performing scan synthesis on a design can cause gated
clocks.
LEC> analyze noneq 213
// Command: analyze noneq 213 Problem
Analyzing non-equivalent compared points:
(G) + 213 DFF /wbs/hvlen_reg[28]
(R) + 6277 DFF /wbs/hvlen_reg[28]/U$1
The clock of DFF in Golden is not gated.
The clock of DFF in Revised is gated.
Analysis of non-equivalent compared points: Solution:
Gated clock of DFF or DLAT. (Occurrence: 1) LEC> remodel -gated_clock
Unknown reason. (Occurrence: 1) SETUP> set flatten model -gated_clock
CK CK
D
DFF
EN
MUX DFF
D DFF
EN
Golden Revised
Debugging with Analyze Nonequivalent (continued)
• Example of Sequential Constants
• Design constraints on a data port can cause a
sequential constant.
LEC> analyze noneq 170 –revised
// Command: analyze noneq 170 –revised
Analyzing non-equivalent compared points:
(G) + 167 PO /wbm_sel_o[0] Problem
(R) + 170 PO /wbm_sel_o[0]
Following constraints may be necessary:
Constant 1: (g) 1026 DFF /wbm/sel_o_reg[0]
Analysis of non-equivalent compared points: Solution:
Sequential constant. (Occurrence: 1) LEC> remodel -seq_constant
SETUP> set flatten model -seq_constant
Unknown reason. (Occurrence: 1)
1’b1 1’b1
PO PO
DFF
CLK
in1 in1
Golden Revised
Analyze Setup
• The analyze setup command automatically resolves the

setup-related issues so that nonequivalency due to
incorrect setup can be prevented or resolved.
• Syntax
ANAlyze Setup [-VERBose]
• The following problems are analyzed using this

command:
– Clock gating
– Sequential constants
– Sequential redundancy
– Redundant DLAT
– Transparent DLAT

Analyze Datapath Command
• The analyze datapath command analyzes datapath modules and based
on the results of the analysis, Conformal can automatically resolve
multipliers, operator merging, and resource sharing problems.This
• Syntax
• ANAlyze DAtapath
• [-MODULE [-RESOURCEFILE <filename>]]
• [-MERGE | -NOMERGE]
• [-NOSHARE | -SHARE]
• [-EFFort <MEDium | HIgh>]
• [-NOADDERTREE | -ADDERTREE]
• [-Verbose]
• Performs arithmetic analysis automatically. Defined in Setup mode
• SET DAtapath Option -auto -verbose

Analyze Abort Command
• The analyze abort command analyzes the abort points and recommends
actions to help solve them. This command also provides useful information
for further investigation in case the abort point cannot be diagnosed. This
• Syntax
ANAlyze Abort [-All | <<gate_id | instance_pathname |
pin_pathname> [-Golden | -Revised]> | -Number
<number>] [-Summary | -Verbose | -Compare –Threads ]
[-CLass <Abort | Notcompared>]
• The following commands run abort analysis after the initial comparison and
resolve the aborts:
compare
analyze abort –compare –threads 4

Debugging with Analyze Abort
• The -summary and -verbose options of the analyze abort command

report the following:
– Design and cone characteristics
• Cone size and support size
• Number of don’t care gates
• Number of datapath gates and modules
• Number of potential correspondence gates
– Design recommendations
• Redefine definitions for multipliers such as DW02_mult.
• Recode RTL to remove don’t cares.
• Use general constraint encoding.
• Use higher effort of the analyze datapath command.
• Use analyze datapath -share for resource sharing.
• Use add partition point.
• Use key point partitioning.
• Use analyze abort -compare to resolve aborts.

Conformal Verification Guide 8.1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Conformal Verification Guide 8.1

Încărcat de

Drepturi de autor:

Formate disponibile

I N VE N TI V E CONFIDENTIAL

Formal Verification Guide

Prototype | Implement | Verify

• Equivalence Checking Refresh

2 August 6, 2009 Cadence Confidential

3 August 6, 2009 Cadence Confidential

ECO RC-Physical Chip Planning

Prototype | Implement | Verify

Specify Compare LEC Mode

Pairing corresponding golden and revised key points:

7 August 6, 2009 Cadence Confidential

set log file logfile.$LEC_VERSION -replace

8 August 6, 2009 Cadence Confidential

9 August 6, 2009 Cadence Confidential

Inverted-Equivalent: Key points proven to be

Nonequivalent: Key points proven to be different (red-filled

Abort: Key points not yet proven equivalent or nonequivalent

Not-Compared: Key points not yet compared

10 August 6, 2009 Cadence Confidential

• To highlight the impact of RTL design on verification

12 August 6, 2009 Cadence Confidential

• Don’t-care conditions are created in RTL by

13 August 6, 2009 Cadence Confidential

• LEC’s RTL rule checker provides an fast and easy way

• For example, index out of range is reported as

• Running LEC RTL rule checker early in the RTL design

14 August 6, 2009 Cadence Confidential

• Consider Synthesis and EC ramifications of design

15 August 6, 2009 Cadence Confidential

• Don’t care is created when index is out of range

16 August 6, 2009 Cadence Confidential

17 August 6, 2009 Cadence Confidential

• Partitioning a complex block breaks it into smaller pieces

18 August 6, 2009 Cadence Confidential

Verifiable Synthesis Flow

• A synthesis flow with verification considerations can significantly

20 August 6, 2009 Cadence Confidential

• These modules boundary are not preserved if ungrouping and boundary

Synthesis Flow Needs To Be Verification-Friendly

• The basic principle of ensuring ease of verification is to

22 August 6, 2009 Cadence Confidential

• To deploy an easy to verify synthesis flow, embed the verifications

• This is default behavior for Encounter RTL Compiler (RC)

23 August 6, 2009 Cadence Confidential

• Datapath synthesis may cause aborts because of

24 August 6, 2009 Cadence Confidential

DC + MDP Final •Include MDP Script

Improve Synthesis Script to Ensure Verification Success

• To enable the successful verification of datapath design using

26 August 6, 2009 Cadence Confidential

• MDP level can be 1, 2, 3, or 4, and affects the

MDP Preserve Hierarchy of Sequential

1 YES NO ALLOW ALLOW

2 YES NO DISABLE ALLOW

3 YES NO DISABLE DISABLE

4 YES YES DISABLE DISABLE

27 August 6, 2009 Cadence Confidential

• During the synthesis process, the following information

28 August 6, 2009 Cadence Confidential

• New versions of synthesis tools may introduce new verification

29 August 6, 2009 Cadence Confidential

LEC QoR Impact

30 August 6, 2009 Cadence Confidential

31 August 6, 2009 Cadence Confidential