GT FV Training

GT/Display FV TRAINING
Modified: (4/1/2015)
GT FV WG
INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

AGENDA
• Formal Verification Basics
• What is FEV
• How it works
• Pros/cons
• GT FV Flow
• SD FV flowchart
• SD FV build process
• Types of FV
• FV env/tools
• Conformal LEC
• key/compare points
• Conformal flow
• Conformal commands
• Conformal mapping
• Equicheck Environment
• Introduction
• FV Unit Dir Structure
• Verify.do file
• Equicheck inputs
• Equicheck outputs
• Equicheck command options
• Launch_RT2Gate_FV
• Command options
• Datapath FV
• Gate2Gate FV
• Xbuf FV
VPG FV Training
2 INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY
AGENDA
• Debugging with Conformal
• How to open Interactive mode
• Mapping Manager
• Diagnose Manager
• Hierarchical View
• Aborting Resolution Techniques
• Non-FV’ble Units
• FV Model Basics
• Setting FV Area
• Dir Structure
• FV model dir structure
• FV collaterals dir structure
• FV run area dir structure
• Setting up par FV label
• Misc. Commands/Scripts
• Responsibilities
• Lab Session
• Q&A
VPG FV Training
Formal Verification Basics

What is Formal Verification (FV) ?
• Formal Verification (aka FV/ FEV/ EC) is a verification process that proves the functional
equivalence between two different representations of the same design without using test
vectors
• It ensures the netlist is functionally equivalent to the RTL as the design moves through the
successive design steps or transformations
• The main steps involved in Formal Verification process are:
❑ Translate both designs to a mathematical format in boolean domain

❑ Establish correspondence between the two designs
❑ Prove equivalence or non-equivalence
VPG FV Training
How Formal Verification Works?
• Design and library information are read in along with other environment related
information for both designs being compared
• Design are broken up in logic cones whose end points (aka key-point) are either registers or
primary outputs ( more will be covered in Next topic)
• Logic cones are paired between two designs using name, functional and topological mapping
• The mathematical functions of cones are compared to see if they are equivalent
R1 r1
Y ≡ Y
X X ≡ X
X
R1 ≡ r1
R2 ≡ r2
R2 ?= r2
Y ?= Y
VPG FV Training
Formal Verification –Pros and Cons
PROS
• Provides fastest functional coverage for the changes made in a design
• Checks the functional equivalence without using simulation test vectors and hence its cost
effective and saves time
• Enables comparison of different views/abstraction levels
• Helps to identify potential Synthesis or ICC issues way ahead of GLS and thus shortens the
design cycle
CONS
• FV does not perform timing checks to ensure that the design will work on the operating
frequency
• As the design complexity increases, design translation and mapping becomes difficult. This
requires time consuming manual mapping
• Most of the FV models assumes that the circuit is purely digital, whereas the modern SOCs
contain many analog components which will not be verified by FV
VPG FV Training
GT FV FLOW

GT FV FLOW GT Core FV
RTL
Unit FV Synthesis FC FV
PTD
4 Unit FV Runs/Tnet FC FV
Placement
5 FCFV Runs/Tnet
CTS
postCTS psynopt
FC FV
Unit FV
Route Opt
Freeze
Unit FV FC FV
ECOs
TO
VPG FV Training
SD FV Flow
The following steps are followed in SD team to perform Formal Verification
1. Collaterals i.e., netlist pointers is released in the form of release.info file or by Vault. If
released in release.info file, pointers should have the standard build path
/p/<proj>/build/models/<model name>/build/<par name>/[<version>]/ios/<label name>/<par>.syn.vg*
2. Build FV model based on the syn/cts/eco release model

3. Build FV collaterals (hier files, cts and const files) corresponding to the build label
deposited in the release.info file
4. Extract unit netlists from partition level netlists
5. Set up FV run area with soft links to the rtl, netlists and FV collaterals
6. Launches FV according to the options specified
7. Debug begins for failing units
8. Once issues are identified, they are communicated to the responsible persons/team
VPG FV Training
Types of FV
• PostSyn Unit FV - RTL against postsyn DC netlist at unit level

• PostCTS Unit FV - RTL against postcts ICC netlist at unit level
• Full Chip FV/LPFV - RTL against postsyn/postcts netlist at Full chip level with blackboxed
units
• XBUF Unit FV - RTL against postsyn/postcts netlist at unit level
• PTD FV - PostSyn against place-prep netlist at Full chip/macro level
• Partition FV - RTL against post-syn/cts netlist at partition level
• STDCell FV - Standard cell RTL lib view against SD lib view
• CTECH FV - Ctech cell RTL lib view against SD lib view
• Datapath FV - .bvrl or .sdpv against retimed netlist at fub level
• Scan FV - Pre ECO netlist against Post ECO netlist at unit level
• RTL2RTL FV - Compare 2 versions of RTL
VPG FV Training
FV execution in GT
Launch_RTL2Gate_FV
• Developed and owned by GT FV team Most Automated
• Wrapper around DA environment to allow FV Labels organize constraints/
collaterals accordingly
• Provides a single platform to PEO/SFVO/UOs for running RTL2Gate FV
Equicheck
• DA environment
• Invoked by Launch_RTL2Gate_FV
• Can be launched directly Least Automated
Cadence Conformal LEC
• FV tool invoked by Equicheck
VPG FV Training
Conformal LEC

Conformal Basics : Key-Points
▪ Conformal divides both designs into combinational logic cones.

▪ The breaking up of the design into logic cones is “accomplished” by finding all components that define
the boundary of combination logic cones
▪ These components are called “key-points”
▪ Types of Key Points
❑ Primary inputs Logic cones
❑ Primary outputs
❑ FFs
❑ Latches
❑ Black-boxes
❑ Z gates
❑ Cut points
Key points
Key points
Combinatorial logic
VPG FV Training
Conformal Basics : compare Points
▪ Compare Point : Each logic cone is driven by multiple drivers but can have only one load. Load of a logic
cone is called compare point.
▪ Not all keys points can be compare points as some key points are not driven by logic cones
❑ PI
❑X
❑Z
▪ Key-points that are driven by logic cones are compare point
❑ PO
❑ DFF
❑ DLAT
❑ BBOX
❑ CUT
VPG FV Training
Conformal Flow
Golden Standard Revised
Design Library Design
Setup
Mode Specify constraints
Fix
& design modeling
Map key points Analyze
All No
Mapp
ed
Yes
Specify compare
LEC
parameters
Mode
Compare Designs
Yes
Misco
mpare Diagnose
No
Equivalence
Checking Complete
VPG FV Training
Conformal Flow
Running EC in Conformal
■ Reading in designs and libraries

Setup ■ Specifying black boxes
■ Specifying design constraints
Mode ■ Specifying modeling directives
■ Switching to LEC mode
■ Mapping process
❑ Analyzing unmapped key points
LEC ■ Compare process
Mode ❑ Analyzing non-equivalent key points
■ Report run statistics
Golden (reference) designs vs. Revised (Target/ Implementation) designs

• Golden or ref design is the reference design
• Revised or target or impl design is the post-processed design under test
VPG FV Training
Conformal Commands - Specifying Constraints
What are design constraints?

– User’s inputs to control part of a design’s logic
– Can be either global to handle modeling styles of synthesis tools or unit specific
Purpose of constraints
– To disable test logic present only in the netlist (i.e. scan)
– To specify relationships between pins
– To constrain un-driven signals
– Mapping info for clock tree ports, duplicated instances(e.g. clocks, resets)
Example of constraints
– Pin/output equivalence
– Pin constraints
– Ignore input/output
– Instance equivalence
– Renaming rule
– Map points
– Prove command
VPG FV Training
Conformal Commands – Pin constraints/ Pin equivalence
Pin constraint: Constrains pins to a logic value. You can use this command on primary input pins, or compare two different
designs under certain input constraints. Example, scan constraints
Syntax: ADD PIn Constraints <0 | 1> <primary_pin* ...> [-module <module_name>] [-golden | -revised | -both]
Golden Revised
U1
U1 0
D Q
D Q scan_in 1 s DFF
DFF
CLK scan_en (0)
CLK
addpin
add pinconstraint
constraint00scan_en
scan_en-revised
-revised
Pin Equivalence : Specifies if two boundary module pins are equal or not. Example, cts ports punched at unit level in postcts
Syntax: ADD PIn Equivalences <primary_pin> <secondary_pin> [-module <module_name>][-INPUT_OUTPUT] [-gol | -rev | -both]
U1 U2 U1 U2
D Q D Q D Q D Q
DFF DFF DFF DFF
CLK CLK
CLK_0
addpin
add pinequivalence
equivalenceCLK
CLKCLK_0
CLK_0-revised
-revised
Output equivalence : Specifies if two boundary module pins are equal or not.
Syntax: ADD OUtput Equivalences <primary_pin> <secondary_pin> [-module <module_name>][-INPUT_OUTPUT] [-gol |rev | both]
VPG FV Training
Conformal Commands – Ignore input/output, Instance equivalence
Ignore Input: Specifies to ignore any bbox input pins. You can use this command on primary input pins, or compare two
different designs under certain input constraints. Example, scan constraints
Syntax: ADD Ignore Input <primary_pin* ...> [-module <module_name>] [-golden | -revised | -both]
Golden module Revised module
Bbox module Bbox module
port z port z
addignore
add ignoreininport
port–module
–module<bbox
<bboxmodule>
module>-both
-both
Ignore Output: Specifies to ignore boundary ouput pins. Example, dangling output port of a unit
Syntax: ADD IGnore Output <output port> [-module <module_name>] [-gol | -rev | -both]
Golden Parent module Revised

Parent module
module module
DFF
z port z port
addignore
add ignoreout
outport
port–module
–module<module>
<module>-both
-both
Instance equivalence : Defines D-latches and D flip-flops as equivalent or inverted equivalences. For eg, used for dops of same
clock domain.
Syntax: ADD INstance Equivalences <instance path > <instance path> [-module <module_name>] [-gol |rev | both]
VPG FV Training
Conformal Commands – rename rule, add map points, prove
Conformal does name based mapping. If the RTL and netlist names are different, we can create exceptions
for this by using either of the below 2 conformal commands
RTL DFF name : ramdtofixpar1unit1/ramdto_dftin[20]

Netlist DFF name : ramdtofixpar1unit1/ramdto_dftin_20
Rename Rule: Specifies renaming rules for key points, modules and blackbox pins. For example:
Syntax: ADD REname Rule <rule name> <pattern> <substitution> -<map|pin> [-golden | -revised | -both]
ADD REname Rule test ramdto_dftin_%d ramdto_dftin\[@1\] –map –rev
Map points: Manually specify the key points to be mapped

Syntax: ADD MApped Points <instance/pin path> <instance/pin path> [-Output_pin <golden pin> <revised
pin>] [-Input_pin <golden pin> <revised pin>] -[invert/noinvert]
ADD Mapped Points ramdtofixpar1unit1 ramdtofixpar1unit1 –Input_pin ramdto_dftin[20]
ramdto_dftin_20 –noinvert
Prove: Prove if the specified key point is zero/one. For example, used in the case of constant propagation.
Syntax: PROve <0|1> <key point> -<gol/rev>
Non-conformal prove: tcl_prove_dont_drive

Usually used along with “add ignore in/out” to prove that the ignored ports does not drive anything. It works
in tclmode
Syntax: tcl_prove_dont_drive “<instance path | pin path>” -<gol/rev>
VPG FV Training
Conformal Flow - LEC mode & Mapping Process
LEC Mode:
• Switching to LEC mode is done by using “set system mode lec” command
• Flattens golden and revised design
• Perform circuit modeling based on modeling directive used in SETUP mode
• By default automatically maps key points by name-first mapping method
Mapping Process:
Mapping Options Execute Mapping Method Followed by Use
-name first (default) name-based Function-based Regular flow
-name only name-based Debugging mapping issues
-name guide function-based name-based NOT USED
-noname function-based Debugging mapping issues
If these mapping methods are not satisfactory, you can improve them by “add renaming rules “command or
by custom mapping
VPG FV Training
Equicheck

What is Equicheck?
DA environment that acts as a Wrapper to Conformal.

– Creates work area
– Creates all scripts required to
– read libs
– read designs
– set constraints & other design assumptions
– verify design
– Invokes conformal and executes dofiles through it
– Generates verification reports
– Parses logs/reports and determine design status
VPG FV Training
FV Run Area Directory Structure
Unit
equic dofil repo

unit. map ref tar log cmd
heck,.l e rts env.
hier
og csh
unit.c
unit.v md
.build. .con .std.
erify.d
rev.do f.log log
o .build. .read.
gol.do do
.ren .comp
.ma .inst
ame
.unmap
are.rp …
p.do .lec. .do .pro ped.rpt
.do t
map. ve.d
do o
Once equicheck creates all the above files and directories, it invokes Conformal LEC tool and executes the
master dofile file “<design>.verify.do” to run FV.
Note: For debug purposes, please do no edit the dofiles/map files/ref /tar directories in the official area.
Please make a copy of the original area for debug
VPG FV Training
<design>.verify.do File
//-- Pre-Read Section
set log file log/gacvunit.conf.log -replace
set flatten model -nodff_to_dlat_zero
set flatten model -nodff_to_dlat_feedback
set flatten model -nomap
set flatten model -gated_clock
//Appending User Provided Conformal Global Proc

dofile /p/bdwgfx/gt3/sd/fv/models/B0_ECO1_v120906_b0_fso1/COLL/PROC/cts/global.conf.rtl2gate.preread.append
dofile dofiles/gacvunit.no_translate.do Equicheck

dofile dofiles/gacvunit.read.lib.do
dofile dofiles/gacvunit.build.gol.do
Inputs
dofile dofiles/gacvunit.build.rev.do
dofile map/gacvunit.map.do
dofile map/gacvunit.rename.rule.map
dofile map/gacvunit.inst.eq.do
//-- Pre-Map Section

set mapping method -name First -noPhase -NOBBOX_NAme_match
//Appending User Provided Conformal Global Proc
dofile /p/bdwgfx/gt3/sd/fv/models/B0_ECO1_v120906_b0_fso1/COLL/PROC/cts/global.conf.rtl2gate.prelec.append
//-- Lec Map Section

set sys mode lec
dofile map/gacvunit.lec.map.do
map key point
//-- Compare Section

add compare points -all
set compare effort auto
Compare
dofile map/gacvunit.prove.do
VPG FV Training
<design>.verify.do File (contd)
//-- Report Section
WRIte MApped Points map/gacvunit.conf.gen.map -replace
report black box -both
report unmapped points -summary -Gol
report unmapped points -summary -Rev
report compare data -summary
report floating signals -root -undriven -full -both > reports/gacvunit.undriven.rpt
report environment > reports/gacvunit.summary.rpt
report verification >> reports/gacvunit.summary.rpt
report statistics > reports/gacvunit.statistics.rpt
report messages -nosummary > reports/gacvunit.messages.rpt
report black box -nohidden -both > reports/gacvunit.blackbox.rpt Equicheck
report pin constraint -both > reports/gacvunit.const.rpt Outputs
report pin equivalence > reports/gacvunit.pin.equiv.rpt
report compare data -summary > reports/gacvunit.compare.data.rpt
report compare data -noneq >> reports/gacvunit.compare.data.rpt
report compare data -abort >> reports/gacvunit.compare.data.rpt
report compare data -cut >> reports/gacvunit.compare.data.rpt
report compare data -notcompared >> reports/gacvunit.compare.data.rpt
report unmapped points -Golden > reports/gacvunit.unmapped.rpt
report unmapped points -Revised >> reports/gacvunit.unmapped.rpt
report unmapped points -type pi >> reports/gacvunit.unmapped.rpt
report unmapped points -type po >> reports/gacvunit.unmapped.rpt
report unmapped points -notmapped >> reports/gacvunit.unmapped.rpt
VPG FV Training
Equicheck Inputs – Setup mode
1. dofiles/<design>.notranslate.do
• This file blackboxes any sub-modules in the design
• Populated when @ec/@bb is used for a fub in the hier file of that design
2. dofiles/<design>.read.lib.do
• Reads the default rtl and sd libs (std/ebb/fake libs) used when FV model was built.
readlibrary
read library$PATH/lib/*.lib
$PATH/lib/*.lib-verilog–golden
-verilog–golden
3. dofiles/<design>.build.gol.do
• Reads shared libs (which is common to all units of a FV model) as specified by
/p/<proj>/fv/lib/<fv model name>/<default rtl model>/equate.rtl_lib.file
• Reads all rtl files listed under this design in hier file from rtl pointed by “ref/<design>” link
readdesign
read design$PATH/verilog/*.v
$PATH/verilog/*.v-verilog
-verilog–golden
–golden
4. dofiles/<design>.build.rev.do
• Reads the netlist as pointed by “tar/<design>.vg” link
readdesign
read design$PATH/verilog/*.vg
$PATH/verilog/*.vg-verilog
-verilog–revised
–revised
VPG FV Training
Equicheck Inputs – Setup mode
5. dofiles/<design>.map.do
• Contains all the port equivalences and pin constraints
• Populated by cts file and const file and user proc (map.append or map.replace)
addpin
add pinequivalence
equivalence<primary
<primaryininport>
port><secondary
<secondaryininport>
port>-<gol|rev|both>
-<gol|rev|both>
addout
add outequivalence
equivalence<primary
<primaryout
outport>
port><secondary
<secondaryout
outport>
-<gol|rev|both>
addpin
add pinconstraints
constraints<input
<inputport>
-<gol|rev|both>
addignore
add ignoreout
out<output
<outputport>
-<gol|rev|both>
addignore
add ignoreout
out<output
<outputport>
-<gol|rev|both>
6. dofiles/<design>.inst.eq.do
• Contains instance equivalences for flops and latches
• Populated by cts file and user proc (inst.equiv.append or inst.equiv.replace)
addinstance
add instanceequivalence
equivalence<primary
<primarylat/dff
lat/dffhier
hierpath>
path><secondary
<secondarylat/dff
lat/dffhier
hier
path>-<gol|rev|both>
path> -<gol|rev|both>
7. dofiles/<design>.rename.rule.do
• If compare points have different names in both designs they can renamed to match and
hence enabling name based mapping by tool
• Populated by user proc (renam.rule.map.append/replace)
addrename
add renamerule
rule<rule
<rulename>
name><pattern>
<pattern><substitution>
<substitution>-<map|pin>
-<map|pin>-<gol|rev>
-<gol|rev>
VPG FV Training
Equicheck Inputs – lec mode
8. dofiles/<design>.lec.map.do
• Contains mapping information for all the key points that should be additionally applied on
top of default name based mapping by the tool
• Populated by cts file and user proc
addmap
add mappoints
points<<gol
golkey
keypoint
pointhier
hierpath>
path><rev
<revkey
keypoint
pointhier
hierpath>
path>-<invert|
-<invert|
noinvert>
noinvert>
9. dofiles/<design>.prove.do
• Populated by cts file and user proc
VPG FV Training
Equicheck Inputs – User PROC
Custom Mapping (aka User PROC) : Any mapping manually provided to the tool by the user
This is achieved by the tool_usr_proc utility in equicheck
The custom mapping is passed to the tool through a user proc that sits in
/p/<proj>/fv/<models>/COLL/PROC/<flow>/<unit>
• The PROC format is <unit>.conf.<rtl2gate|gat2gate|rtl2rtl>.cts.<state>.<action>
User Proc is picked based upon:
• Unit/design name
• State e.g. preread, compare, etc…
Equicheck User Proc states for Conformal:
– preread
– ref.read
– tar.read
– read.lib
– map
– inst.equiv
– rename
– prelec
– lec
– lec.map
– precompare
– compare
– prove
– report
– preexit
Equicheck User Proc actions:
– append
– replace
VPG FV Training
Equicheck Inputs - Hierarchy file
Mapping and/or compare strategy can be specified with attributes in the design’s hierarchy file. Most
common hierarchy file attributes
• @ec verify at this level
• @bb (strictly not used for unit level FV) black box this design
• @gate_design=<uniquified module name> All the unit collaterals are based on gate_design name
Sample hierarchy file
0 gacunit1 (gacunit) @ec @gate_design=gtvidpar6_gacunit_0
1 noa_muxing @bb
When is it useful?
• When the design is too complex causing the tool to choke and abort
• During ECO’s the UO may request for a fub level FV support
How it works?
Fub level FV is run by adding the @ec attribute on the fub in interest in the hier file before running FV. When
Hier FV is run, equicheck creates another level of directory structure under the work area. The structure
underneath these directories is similar to the regular FV flow
2 FV runs are launched in parallel Unit
• One at the unit level with the fub blackboxed
• One at the fub level unblackboxed Unit fub
VPG FV Training
Equicheck Inputs – CONST file
− Const file pointer:
/p/<proj>/fv/models/<modelname>/COLL/<parname>/<fv_label>/<par>.const
− It is picked up during SYN FV collaterals build from syn reports area.

− This contains the constraint values for the scan paths to disable them. Also for some unused cts
ports
− Each line will be converted into will be converted to “add pin constraints” for input ports and “add
ignore out” for output ports in map.do
− If that particular fub is bboxed at top level FV, input ports will be converted to “add ignore in” in
map.do
− Syntax:
<fub> {<dir>} <0|1> <port> <ref|tar> <rtl2gate|gate2gate>
gacvarb {constin} cu2xclk 0 tar rtl2gate

gacvarb {constin} cu2xclk 0 tar gate2gate
gacvarb {constin} dt_scanshiften_b 1 tar rtl2gate
gacvarb {constin} dt_scanshiften_b 1 tar gate2gate
VPG FV Training
Equicheck Inputs – CTS file
− Cts file pointer: /p/<proj>/fv/models/<modelname>/COLL/<parname>/<fv_label>/<par>.cts
− It is created during CTS FV collaterals build by picking up reports from place_prep, clock,
clock_misc stages
− The first line of a particular rtl port will be converted into mapping command in lec.map.do
− The next consecutive lines will be converted into equivalences in map.do
− Syntax:
<fub> {<dir>} <rtl port> <netlist port>
gacvarb {} in cdevrst_b cdevrst_b_cts_1 -> add map points gacvarb1 gacvarb1 -Input pin cdevrst_b cdevrst_b_cts_1
gacvarb {} in cdevrst_b cdevrst_b_cts_5 -> add pin equivalence cdevrst_b_cts_1 cdevrst_b_cts_5 –module gacvarb -rev
gacvarb {} in cdevrst_b cdevrst_b_cts_6 -> add pin equivalence cdevrst_b_cts_1 cdevrst_b_cts_6 –module gacvarb -rev
VPG FV Training
Equicheck Inputs – bound opt file
− bo_file pointer: /p/<proj>/fv/models/<modelname>/COLL/PROC/<flow>/<par>/par.bo
− It can be created by the user manually to account for DC/ICC boundary optimization
− If a unit input port is unused in RTL, it gets optimized in netlist as shown in diagram
Syntax:
module_name {rtldangin} rtl_pin(netlist pin) both (netlist pin required only if pin names are different)
(Equicheck will automatically add below)
At unit level: tcl_prove_dont_drive <pin_name> -gol
At higher level when module is bboxed: add ignored inputs <pin_name> –module <name> -both
module_name {rtldangout} rtl_pin(netlist pin) both (netlist pin required only if names are different)
(Equicheck will automatically add below)
At unit level: add ignored outputs <pin_name> -gol
At higher level when module is bboxed: tcl_prove_dont_drive <inst/pin_name> -both
VPG FV Training
Equicheck Outputs
Reports created by Equicheck
− <design>.unmapped.rpt : Check for any unmapped ports or flops here. For example:
Unmapped point (extra):
(R) 971 PI /dt_scanshiften_b_cts_2_21
− <design>.compare.data.rpt: Check for the mismatched logic cones here. For example:
Compared points are: Non-equivalent
(G) + 5238 DFF /gafsrdreqblk1/sf_fifoinpkt_ff_reg[90]
(R) + 28497 DFF /gafsrdreqblk1/sf_fifoinpkt_ff_reg_b84_b85_b89_b90_qreg/U$4
Due to these Non-equivalent points:
[CLOCK]
(G) + 1 PI /crclk
(R) + 817105 AND /gafsrdreqblk1/pwc_clk_gate_3_presplit1/U$1
− <design>.blackbox.rpt
− <design>.const.rpt
− <design>.messages.rpt
− <design>.pin.equiv.rpt
− <design>.statistics.rpt
− <design>.undriven.rpt
VPG FV Training
Equicheck Vs Conformal
Equicheck takes a set of input files to generate the required tool scripts in the FV run area for the tool to kick
off.
Equicheck Input files Conformal scripts generated from
equicheck input files
Mapping Information map

■CTS file ■.map.do
■CONST file ■.lec.map.do
■User PROC ■.inst.do
■Bound opt file ■.rename.do
■Renaming rules ■.prove.do
Design Information dofile

■Ref design ■.build.gol.do
■Tar desgin ■.build.rev.do
■Lib ■.read.lib.do
■HIER file ■.no_translate.do
■User PROC
The following table lists the input files required to generate each of the tool script for mapping information.
Conformal Tool script Equicehck input files used for

generation
.map.do CTS, CONST, bound opt and User
PROC files
.lec.map.do CTS and User PROC files
.inst.do CTS and User PROC files
.prove.do CTS, bound opt and User PROC
.rename.do Renaming rules
VPG FV Training
Equicheck Command-line Options
Equicheck
-ref <path to reference netlist directory/files>
-tar <path to target netlist directory/files>
-unit <unit name> top level unit or fub name that needs to be verified
-dir <dir name> output directory to be created
-hier Enables hierarchical verification. Default is flat verification
-hier_file <hier file path> Creates a new hier file by default
-cts_file <cts map file path> Overrides default map file
-const_file <const file path> Overrides default const file
-bo_file <bound opt file> Picks boundary optimization file
-recurse_equicheck_search_path recursive searches for RTL files in search path directories
-higher_level_retiming accounts for module name changes in retimed designs
-debug Prints debug information in equate.log file
-stop Sets up equate environment but does not run verification
-restart Launches conformal with for existing dofiles and updates only job result
-help Shows equate help
VPG FV Training
Unit List file
List file contains information about all the units including the instance names and the syn/cts build labels.
A list files looks like….
designtype:(unit|par);
extra_equate: (-ultra on);
fc_bvr: (bbox|unbbox); Full chip behavior whether is bboxed or not
fcfv_bbox_fubs:; specifies the fubs to the blackboxed in FC FV. Eg: fubs in euunit
gate_design:mbcunit; The name of the unit as in the netlist
global_instance:/bdwgtt1/gtgti1/gtsqidi1/mbcunit1;
hier_fv_design:; fubs on which hier FV is run
hier_fv_instance:;
instance:/mbcunit1;
mem:; Memory used
new_hier_node:; Any extra fubs that are to be added in the hier file
par:;
pool: slow; The pool to be used (slow,fast)
report: (0|1); Whether this unit has to be reported in the summary report
rtl_design:mbcunit; rtl design name
runfv:(0|1);
sec:;
status:;
tpt:;
waive_bbox:0;
The attributes in blue are under SFVO’s control while the one in red are under PO’s control
VPG FV Training
Launch_RTL2Gate_FV
GT Wrapper around Equicheck

Launch_RTL2Gate_FV
Launch_RTLGate_FV is a wrapper around equicheck. It invokes the equicheck command to run FV.
Usage:
Required
• units|unit Separated by colon ":” If not specified would run all units in partition
• cts|syn Run CTS or Syn FV on unit(s)
Optional
• runmode
– norun - don't run just print out commands for running equicheck
– stop - builds FV directory without invoking FV tool
– batch - run on netbatch
• netlist If not specified script will look for IMPL link
– If netlist/IMPL link is netlist, it will pick this netlist for all unit FV
– If netlist/IMPL link is directory it will pick <unit>.vg in this directory
• rtl_dir|unit_rtl_dir If not specified, script picks the unit from default RTL label
– If rtl_dir is specified, it picks <rtl_dir>/<unit> as RTL directory
– If unit_rtl_dir is specified, it picks <unit_rtl_dir> as RTL directory. Only valid for
single unit run
• rtl_label Specify if an rtl label other than default rtl label (library etc...) needs to be picked
• dir FV directory name. Only valid if FV is to be run for single unit
• xbuf Run XBUF FV
• par_label Specify if FV should be run on par label other than default label
• fc_label Pick Par label that is default to specified FC label
VPG FV Training
Launch_RTL2Gate_FV (Cntd)
These are some examples on how to invoke the script:

From official run area
Launch_RTL2Gate_FV –syn|cts –runmode <>
From any directory
Launch_RTL2Gate_FV –syn|cts –rtl_dir|unit_rtl_dir <> -netlist <> -par_label <> -runmode <>
When no option specified, script launches FV job on the local machine. Default option
VPG FV Training
Other Types of GT SD FV
Datapath FV
XBUF FV
Gate2Gate FV

Datapath FV Flow
GT/Display have pipelined datapath fubs within units which are synthesized bottom-up and
retimed. Datapath FV for these fubs is run between RTL and post-retimed syn netlist with
Equicheck Formality flow using a 2-pass and Syn (DC) generated SVF files to simplify verification
• Pass1: RTL Source to Pre-retimed netlist (s2p)
• Pass2: Pre-retimed netlist to Post-retimed netlist (p2r)
The goldenized post-retimed netlists are plugged into RTL during unit FV to simplify verification
The following steps are followed in SD team to perform Datapath FV
(-syn|-cts options specify the collateral in the FV model which is picked up for DPFV. Use –syn in early TNETs
when only syn partition collateral is available in FV model. Use –cts once cts partition collateral is available in
FV model and for signoff.)
1. Setup DP FV Runarea (Use –syn in early TNET when only partition syn collateral is available.
Setup_DP_FV –chip –dir <release1_DP> -syn|-cts
2. For each partition, launch DP FV for all the retimed datapath fubs
Launch_DP_FV –runmode batch –par <par> -syn|-cts &

3. Generate summary report
GenDPFVSummary.pl –chip –syn|-cts (when FV model only has syn collateral)
VPG FV Training
Xbuf FV
GT RTL instantiates “xbuf” parameterized modules (modules with pass through wires) as a mechanism to
specify timing exceptions. GT PV flow uses the xbuf instances in the SD database to automate generation of
timing exception constraints.
XBUF FV is not a functional FV check. It is a flow which uses FV engine to check that the RTL timing
exception intent remains intact throughout RLS build flow to prevent incorrect PV exception constraint
generation.
It’s a RTL2Gate FV. Its run during ECO’s and sometimes at the end of FSO
Xbuf FV is run to verify:
• Xbuf buffer timing path matches between RTL and Netlist
• Xbuf parameters matches between RTL and Netlist
• All the xbufs are bboxed in xbuf FV
Commands to run Xbuf FV:

Using Xbuf Wrapper:
• Launch_RTL2Gate_FV –runmode batch –xbuf -syn|-cts
Using standalone script:
• Launch_RTL2Gate_FV –runmode norun –xbuf –units unit1:unit2 –syn|-cts
The Xbuf script to run FV is: xbuf_check
VPG FV Training
Gate2Gate FV
Gate2gate FV is a netlist vs netlist FV and it’s a flat FV (no hierarchy underneath)
Its used to verify if
• The correct netlist has been released to FC roll-up
• Netlist released to ECO model for UO’s is same as the FV clean netlist of the prev model
• The DB released by the LPEO is functionally same as the ICC DB
Commands to run gate2gate FV: Can be used for all unit/par/sec FV

• setenv DESIGN <par/unit/sec name>
• echo “0 ${DESIGN}1 ($DESIGN)” > $DESIGN.gh ; equicheck -ref <Partition level post-CTS netlist> -tar
<Partition level pre-ECO1 netlist> -hier_file $DESIGN.gh -tool_usr_proc -dir gate_fv/$DESIGN -unit $DESIGN
Note: DESIGN can be unit or partition name but ref and tar netlist should be partition level netlist
To run FV on multiple units, loop through the units
• foreach unit (<unit1> <unit2>)
• setenv DESIGN $unit
• echo “0 ${DESIGN}1 ($DESIGN)” > $DESIGN.gh ; equicheck -ref <Partition level post-CTS netlist> -tar
<Partition level pre-ECO1 netlist> -hier_file $DESIGN.gh -tool_usr_proc -dir gate_fv/$DESIGN -unit $DESIGN
• End
For PEO DB vs LPEO DB FV:
-ref : netlist from PEO DB
-tar : netlist from LPEO DB
VPG FV Training
Debugging Basics

Debugging Basics
Once the FV run is launched and completed, check the <unit>/equicheck.log for the result which can be
UNKNOWN : Mostly due to RTL or FV setup issue. Check in log/<design>.conf.log for debug
DESIGNS EQUAL : You got lucky ☺
DESIGNS NOT EQUAL : due to real failures like non-equivalent points, extra input/output ports or
not-mapped points as discussed below
Types of real failures in Conformal
▪ Non Equivalent Points
▪ Unmapped points
❑ Unreachables: Often ignored, but sometimes they cause unmapped points on the other design
❑ Extras: Equicheck doesn’t allow any extra ports in the design
❑ Not-mapped points: There are 2 kinds of not-mapped points
– Not-mapped flops: flop in one design that’s driving logic but missing corresponding flop in the other
design
– Z: Any dangling undriven net is a Z
More information on failing points can be obtained from the below reports
▪ log/<design>.conf.log
▪ reports/<design>.unmapped.rpt
▪ reports/<design>.compare.data.rpt
Note: Unmapped points are different from not-mapped points though they sound similar
VPG FV Training
Debugging Basics (cntd)
For Further debug, open conformal in interactive mode by following the below steps:
❑ `cd` to run directory
❑ GenerateDebugFVDo
❑ Run ‘cmd/<unit>.cmd.debug`
❑ LEC> set gui
The following components of Conformal GUI can be used in debug

❑ Mapping Manager
❑ Diagnosis Manager
❑ Schematics Viewer
❑ Gate Manager
❑ Source Code Manager
VPG FV Training
Debugging Basics – Mapping Manager
Mapping Manager
LEC
window
Unmapped
Points
Mapping
Mapped Manager
Points Window
Compared
Points
VPG FV Training
Debugging Basics – Mapping Manager (Cntd)
What each points means?
Extra: Key point that exists only in the Golden design or only in the
Revised design, but does not effect the circuit functionality. Example:
scan_in, scan_out
Unreachable: Key point that is not propagated to any observable point.

Example: spare flops
Not-mapped: Key point that has no correspondence on the other side.

May be resolved with renaming rules(Red filled circle)
VPG FV Training
Comparison results category
Equivalent: Key points proven to be equivalent (green-filled circle)
Inverted-Equivalent: Key points proven to be

complementary to the other key point (divided green-filled circle)
Non-Equivalent: Key points proven to be different (red-filled circle)
Abort: Key points not yet proven equivalent or non-equivalent due to timeout
or other system parameters (yellow-filled circle)
Not-Compared: Key points not yet compared
VPG FV Training
Comparison results?
• Filtering comparison results
VPG FV Training
Debugging Basics – Diagnosis Manager (Cntd)
Diagnosis manager can be invoked from Mapping Manager

• Select a non-equivalent point(red-filled circle)
• Right-click, choose "Diagnose"
VPG FV Training
Debugging Basics – Diagnosis Manager (Cntd)
Compared Point
Diagnosis Point (Active)
Diagnosis Points
Corresponding Support
Non-corresponding
and not mapped (red)
M Non-corresponding but
mapped (yellow with M) Error Patterns Error Candidates
VPG FV Training
Debugging Basics – Diagnosis Information
Compare Points: Non-equivalent compared point

Diagnosis Point (Active): Point at which diagnosis failed
Diagnosis Point (Inputs): List all the fan-in diagnosis points for the compare point. Different corresponding
and non-corresponding points, error patterns, and error candidates are displayed according to selected
diagnosis input
Support
▪ Key-Points driving logic cones in golden and revised.
▪ Corresponding Support
❑ Drives in both
▪ Non Corresponding
❑ Non Corresponding
– Drives current logic cone in one design and doesn’t come with corresponding key-point in other
design at all
❑ Non Corresponding
– Drives current logic cone in one design and doesn’t drive corresponding logic cone in other design,
however it does exist in the other design.
Error Pattern: Test vector proving the diagnosis point to be non-equivalent. Simulation value shown in
parenthesis ( ) for every diagnosis, corresponding and no corresponding support points.
Error Candidate: Gates in the Revised with highest probability of causing non-equivalence
VPG FV Training
Debugging Basics – Diagnosis Information (Cntd)
VPG FV Training
Debugging Basics - Schematics
Invoked from Diagnosis Manager

• Click on select data port as active diagnosis point
• Click on “Schematic 🡪 Open”
Can invoke source code manager by double clicking on any gate
VPG FV Training
Debugging Basics – Source Code Manager
VPG FV Training
Abort Resolution Techniques
The steps for resolution depend on the cause of the abort and other factors with the design. This section
describes some advanced techniques on how to resolve aborts.
1. Hierarchical Compare: Achieved by using @ec on the aborting fub in hier file. This helps to breakdown the
aborting logic cones to two hierarchical compares. Very effective way to handles aborts, but introduces
boundary optimization failures
2. Analyze abort: This is used after comparison to automatically recommend steps to resolve the abort points
in your design. This command can also perform the recommendations and re-compare the design, which
might automatically solve the aborts without any further input. Syntax: analyze abort –compare
3. Multi threading: To reduce the time spent on RTL-to-gate comparisons, where aborts on a few key points
can consume a large portion of the time, the parallel analyze abort feature might be more effective. Syntax:
compare –threads 6
4. Partitioning: breaks down large logic cones in the aborting input cone to resolve them. Syntax: add partition
points –abort_cones –all
5. Isolating abort modules: automatically identifies any datapath fubs and applies merging of operators used
to resolve aborts. Syntax:
analyze datapath -verbose -module -resourcefile <resources.syn.rpt> (this analyzes netlist)

or/and
analyze datapath –verbose ( with any combo of –wordlevel, -share, -merge, -addertree will analyze
RTL)
VPG FV Training
FV Model Basics
Before running SD FV, a FV model must first be built by the FV execution owner.
The FV model provides an infrastructure to manage multiple RTL models, multiple partition
RLS Build collaterals, FV global and unit/fub constraints, specific FV abort resolution procs
and facilitate the launch and tracking of Datapath FV, Unit FV and Fullchip FV in a single area
The following slides pertains to FV model and collateral build

FV MODEL Directory Structure

Directory Structure
/p/<proj>/fv
setu mod wor

lib doc etc bin
p els k
Checklist equa scrip
s te ts
Equate. COL
setup syn scan cts dop ptd HDL
L
defa
tnet COR OTH
ult
0 E ERS
tnet EBB
DW fak
1 PRO
e.li lists AUX cts syn conf
1.0.0 C
b
DW01_mux
equate. _any
lib.file gths summ
gtfix gtl3
c ary
gtms gths
mod gtvid
c m
el1
ctec
noa …
h
aub_w
RETIMED clock layo
are RTL syn scan cts eco
NETLIST misc ut
equate.rt <pro
l_lib.file mod mod j>
el1 el2 Chip
label
gtmscp gtmscp …
ar1 ar2
label label
1 2
VPG FV Training
FV COLL Directory Structure
COL
L
AUX conf syn cts RTL lists
Renamin
g.rules
gtmscpa gtmscpa … gtmscpa gtmscpa …

r1 r2 r1 r2
label label label label

1 2 1 2
HIE HIE
gtmscpar
R R Gtmscpa Gtmscpa
1.const
BUILD BUILD r1.scan. r1.scan
REPORTS REPORTS Gtmscpa Gtmscpa
Tdb.h Rtl_model_p
r1.cts r1.const
ier st_prcs RELEASE_FIL
ES
Rtl_lib_
def_file Releas gtmscp gtmscp
e.info ar1 ar2
label label
1 2
Label1.li
st
VPG FV Training
FV Run Area Directory Structure
Run
Area
Section
s
Partitio
ns
All IMP PRO SYNC SYNL CTSC CTSLI summ

REF
units L C OLL IST OLL ST ary
VPG FV Training
Setting up FV Par Label

What is FV Label?
• Constraints for running FV are DC/ICC db specific. DC/ICC db launched with different build
options/labels may require different set of FV constraints
• To allow FV on multiple dbs run in parallel we support FV labels. FV label is of format

<build_model>_<build_version>_<build_label>
• Each partition can have multiple labels, however only one label will be made default one by
the process owner. SFVO’s are allowed to setup new FV labels.
• All FV utilities are run based on default label if a label is not explicitly specified
• ALL the netlist paths should strictly follow the format “/p/<proj>/build/models/
<model>/<par>/build/ios/<label>/<par>.<flow>.vg[.gz]”
VPG FV Training
FV COLLATERALS
Collaterals required for postsyn FV from build area are:
• HIER files
• dt_scanshift report from reports area
• Retimed netlists and svfs for datapath blocks from build ios area
• Resources.syn.rpt files from build reports area
Collaterals required for postcts FV from build area are:

• Netlist -> place_prep, scan and clock_misc
• FV traces files and other cts map files from every flow stage starting from postsyn
• Mdb file of that flow type
• Ascii file for par fv
FV constraints in postsyn & postcts:
Signal Name Info
dt_l2ugt Power clock gate signal. Constrained

to 0.
dt_scanshiften* Scan enable signal. Constrained
according to dt_scanshift report
test_si Scan input signal. Constrained to 0
test_so Scan output signal. ignored
VPG FV Training
Setting up syn FV label
Re-synthesis of any partition will require resetting the postsyn FV collaterals of that partition. This can be
done using the below command
Add_Syn_Par_2_Model
Usage:
Required
− cur_model : current FV model name
− par : partition
− vault
− milestone : Vault milestone name (i.e. TNET2, FSO)
− build_model : build model name (build model checked into FV vault)
− ref_model : reference FV model used to build current FV area (to carry forward changes made in ref
model
Optional
− rep : replaces if the label already exists
− copy : copies the par netlist in the netlist area under the respective partition label
Note: This script will not make the label the default. The Process Owner can only make the label default
VPG FV Training
Setting up CTS FV label
• Re-synthesis of any partition will require resetting the postsyn and postcts FV collaterals of that partition.
• The below script will trace the corresponding syn DB used for the new cts run and builds new syn label
• This script will generate new cts/const files
• It will soft link the syn area HIER file to the cts area hier file
Add_CTS_Par_2_Model command is used to reset them.
Usage:
Required
− cur_model : current FV model name
− par : partition
− vault
− milestone : Vault milestone name
− build_model : Build model checked into FV Vault
− ref_model : reference FV model used to build current FV area (to carry forward changes made in ref
model)
Optional
− rep : replaces if the label already exists
− syn_rep : replaces the postsyn label if it already exists
− copy : copies the par netlist in the netlist area under the respective partition label
Note: This script will not make the label the default. The Process Owner can only make the label default
VPG FV Training
FV Area Setup (for private DB)
Setup_RTL2Gate_FV
Usage:
Required:
-par <par> Setup FV area for partition
-chip Setup FV area for chip (par, sec and chip are mutually exclusive)
-syn|cts Setup FV area for chip
Optional :
-par_label <label> Only applicable for par setup. Picks par label other than default label
-dir <dir name> Uses this as the new directory name to set up FV area
Example:
Once the syn/cts collaterals for the label (DB) of interest are generated, the following commands will build
the FV run area:
• cd/p/<proj>/fv/models/<model>/[syn|cts]/work/
• Setup_RTL2Gate_FV –syn|cts –par <par> -[netlist] –dir <name of the directory> -par_label <par label>
Once the area is setup, FV can be launched on all units using the script. (Details of the script usage are given
in the following slides)
• Launch_RTL2Gate_FV –cts|syn –runmode batch –par_label <par label>
VPG FV Training
Useful FV Utilities
Extract_Netlist_FV.pl
• To extract the partition/unit level netlists from FC or sec level netlists
• Usage: Extract_Netlist_FV.pl –[par <par name>|-design <design1>:<design2>] –netlist <FC/sec/par/unit
netlsit> -dir <output dir>
GenFVSummary.pl
• This script is run in the section /partition fv run area.
• Generates FV summary Table
• Usage: GenFVSummary.pl –[par|sec] <name> -[syn|cts]
GenFVSummary.pl –chip –[syn|cts]
FindUnitPar
• To find the partition the unit belongs to
• Usage: FindUnitPar <unitname> [-cts|-syn]
Get_Par_Label
• To get the default FV par label for the partition
• Usage: Get_Par_Label -par <par name> -syn|cts
The FV ENV has to be sourced to use the above scripts
VPG FV Training
Non-FV’ble Units
• Lcpunits: Due to lcp controller fub duplication that happens during place_prep stage, postcts
FV will fail for lcpunits. Until we get RTL updated to match netlist duplication, this will
remain as failing
• During FSO, new rtl with lcp duplication is released
• Cpunits: During the initial tnets’s cpunits are expected to fail due to existence of clock spines.
However these units are unblackboxed at FC postcts FV, so we don't loose any coverage.
• During FSO, workarounds would be developed to make them FV clean
VPG FV Training
Misc Commands/Scripts
To save a conformal session for later use:
checkpoint <checkpoint_filename> [-protect <password>] [-replace]
lec -restart_checkpoint <checkpoint_filename> [-protect <password>]
Hier files should not have any hierarchies underneath “@dcudp “ fubs, because we will be using retimed
netlist for those instead of rtl sdpv. This sometimes causes”Missing files” error. Below is the script that
removes these hierarchies.
/p/<proj>/fv/bin/dcudp_hier_fix.pl <input .hier file> [output .hier file]
VPG FV Training
FV Execution Team Responsibilities
SFVO (Section FV Owner)
• Debug any failures and communicate it to Unit/ Process owners if it is a real issue. (rtl fixes, renaming
rules, DC issues, icc issues etc.)
• Work with Unit/ Flow (Syn/ PS/ CTS PEOs)/ Process owners to understand/ fix Structural Design related
issues
• Make sure ‘all units’ are passing at every stage of the flow
• Make sure if all not-mapped points (that are not getting compared) are understood
• Keep the process owner in the loop on ALL failures/ issues
• RTL , netlists and CONST files shouldn’t be modified
• Official runs should not have hacks in map and dofiles dir
Process Owner
• Setup Model/ rtl/ netlist areas
• Make sure all the libraries have been setup
• Make sure all the CTS mapping information is in place
• Make sure global renaming rules are in place
• Run FC FV
• Debug global FV failures
• Keep track of status of all units in all partitions
• Communicate any FV failures to GLS team
• Work with DA/Vendor on any tool/environment issues
VPG FV Training
Q&A
Backups
Thank You

GT FV Training

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

GT FV Training

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GT FV Training

Uploaded by

Copyright:

Available Formats

GT/Display FV TRAINING

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

❑ Translate both designs to a mathematical format in boolean domain

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

2. Build FV model based on the syn/cts/eco release model

• PostSyn Unit FV - RTL against postsyn DC netlist at unit level

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

▪ Conformal divides both designs into combinational logic cones.

Map key points Analyze

■ Reading in designs and libraries

Golden (reference) designs vs. Revised (Target/ Implementation) designs

What are design constraints?

Golden Parent module Revised

RTL DFF name : ramdtofixpar1unit1/ramdto_dftin[20]

Map points: Manually specify the key points to be mapped

Non-conformal prove: tcl_prove_dont_drive

• Perform circuit modeling based on modeling directive used in SETUP mode

• By default automatically maps key points by name-first mapping method

Mapping Options Execute Mapping Method Followed by Use

-name first (default) name-based Function-based Regular flow

-name only name-based Debugging mapping issues

-name guide function-based name-based NOT USED

-noname function-based Debugging mapping issues

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

DA environment that acts as a Wrapper to Conformal.

equic dofil repo

//Appending User Provided Conformal Global Proc

dofile dofiles/gacvunit.no_translate.do Equicheck

//-- Pre-Map Section

//-- Lec Map Section

//-- Compare Section

− It is picked up during SYN FV collaterals build from syn reports area.

gacvarb {constin} cu2xclk 0 tar rtl2gate

Mapping Information map

Design Information dofile

Conformal Tool script Equicehck input files used for

GT Wrapper around Equicheck

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

These are some examples on how to invoke the script:

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

Launch_DP_FV –runmode batch –par <par> -syn|-cts &

Commands to run Xbuf FV:

The Xbuf script to run FV is: xbuf_check

Commands to run gate2gate FV: Can be used for all unit/par/sec FV

INTEL CONFIDENTIAL, FOR INTERNAL USE ONLY VPG FV Training

The following components of Conformal GUI can be used in debug

What each points means?

Unreachable: Key point that is not propagated to any observable point.

Not-mapped: Key point that has no correspondence on the other side.

Comparison results category

Equivalent: Key points proven to be equivalent (green-filled circle)

Inverted-Equivalent: Key points proven to be

Non-Equivalent: Key points proven to be different (red-filled circle)

Not-Compared: Key points not yet compared

Diagnosis manager can be invoked from Mapping Manager

Diagnosis Point (Active)

Compare Points: Non-equivalent compared point