Conformal User PDF
Conformal User PDF
Conformal User PDF
Guide
Conformal L, Conformal XL, and Conformal GXL
Contents
About This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
How This Manual Is Organized . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Syntax Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
GUI Convention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Additional Learning Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1
Introduction to the Conformal Equivalence Checker . . . . . . . . . 25
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Conformal Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Supported File Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conformal Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Preparing the Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Mapping and Comparing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Diagnosing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Conformal Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
System Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Transition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Diagnosis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Overview of Conformal Tcl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Specifying the Command Entry Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Using Native Conformal Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Duplicate Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Tcl Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2
Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Product and Installation Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Start-Up Command Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Initial Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Dofile Command Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Saving and Restoring a Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Save and Restore Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Checkpoint and Restart Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Transcript Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Setting Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Font & Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Hierarchical Browser On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Hierarchical Browser Sync. up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Icon Bar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Show Static Infobox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Simplified Schematic Viewing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Accessing Online Help and Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Launching Cadence Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Getting Help for Cadence Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Getting Help on Commands to Run Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Getting Help on Commands and Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Searching the Help Database for Specified Strings . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Using the Help Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Platform Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Dofile Generation from First Encounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Dofile Generation from RC Synthesis Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Using Conformal With Virtuoso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3
Using the Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Main Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Selecting Multiple Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4
Command Line Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Command Line Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Command Line Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Using Command Line Completion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Repeating Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5
Managing Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
HDL Rule Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
HDL Rule Manager Fields and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Severity Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Enabling and Disabling Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Running Incremental Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Reporting Messages for Rule Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Viewing a Specific Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Viewing Source Code for an Occurrence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Modeling Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6
Using the Setup Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Setting Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Changing the Root Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Adding Search Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Adding Notranslate Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Setting Global Options For Mapping and Comparison . . . . . . . . . . . . . . . . . . . . . . . 100
Reading in Libraries and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Reading in Library Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Reading in Design Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Using Verilog Command Filelists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Comparing Design Hierarchies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Comparing Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Design Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Blackboxes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Net Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Pin Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Pin Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Primary Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Primary Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Tied Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Instance Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Instance Equivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Cut Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Flattening Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Specifying Key Point Mapping Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Retaining Gate Pin Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Converting DLATs to DFFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Converting DLATs to Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Converting DFF or DLAT to Zero or One Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Gated-Clock Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Converting DFFs to DLATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Flatten Model Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Mapping Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
7
Using the LEC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Moving to LEC Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Mapping Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Altering Key Point Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Adding Mapped Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Inverting Mapping Phase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Saving Mapping Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Compare Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Adding Compared Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Setting the Compare Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Setting a CPU Limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Reporting Compare Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reporting Compare Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reporting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Reporting CPU Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Report Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Running Additional Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Black Boxes Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Cut Points Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Design Data Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Environment Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Floating Signals Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Instance Constraints Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Instance Equivalences Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Messages Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Modules Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Notranslate Modules Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Pin Constraints Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Pin Equivalences Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Primary Inputs Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8
Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Diagnosing Non-Equivalent Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Proving Equivalence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Adding Dynamic Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Displaying Error Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Reporting Design Similarities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Gate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Gate Manager Fields and Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Refreshing the Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Opening Schematics from the Gate Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Using the Preferences Drop-Down Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Filtering the Gate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Finding Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Reporting Gate Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Customizing the Gate List Section with Specified Gates . . . . . . . . . . . . . . . . . . . . . 182
Proving Equivalency for Two Specified Gates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Removing Gates from the Prove List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Locating an Equivalent Gate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Adding and Deleting Dynamic Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Locating a Gate in the Design Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Highlighting a Point in the Hierarchical Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Viewing a Gate’s Location in the Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Highlighting a Point in the Source Code Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Viewing a Schematic Representation of One Gate . . . . . . . . . . . . . . . . . . . . . . . . . 185
9
Resolving Aborts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Avoiding Aborts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
RTL Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
MDP Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
RTL Compiler Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Resolving Aborts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Hierarchical Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Analyzing Abort Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Isolating Abort Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Dofile Template Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
10
Running Hierarchical Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Comparing Designs at the Module Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Running Dynamic Hierarchical Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Interrupting a Hierarchical Comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Hierarchical Comparison Command Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Read the Libraries and Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Generate a Hierarchical Compare Dofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
No Blackboxing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Constraint Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Renaming Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Hierarchical Compare Dofile Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
Hierarchical Comparison for Abort Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Hierarchical Module Comparison Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Hierarchical Module Comparison Fields and Options . . . . . . . . . . . . . . . . . . . . . . . 245
Setting General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Reporting CPU Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Working with Hierarchical Compare Dofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Finding Module Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Deselecting the Dual Scroll Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Viewing a Module’s Compare Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Specifying Blackbox Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Deleting Previously Added Blackbox Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Ignoring Modules during Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Deleting No-Blackbox Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Running a Hierarchical Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Comparing Lower-Level Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
Highlighting Non-Equivalent Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Deleting and Resetting Hierarchical Compare Results . . . . . . . . . . . . . . . . . . . . . . 249
Specifying the Root Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
11
Advanced Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Supported Datapath Structures and Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Multipliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
Operator Merging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Resource Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Sequential Merge Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
Module-Based Datapath Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Datapath Module Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Datapath Module Abstraction Reporting and Diagnosis . . . . . . . . . . . . . . . . . . . . . . 258
Handling Aborts in Datapath Module Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Datapath Operator Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
DC Synthesis Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Sample DC Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
DC Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
MDP Effort Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Dofile Example for Intermediate Netlists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Dofile Example for Intermediate to Final Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Extracting Testcases for Datapath Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Recreating Testcases for Datapath Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Isolating Aborted Datapath Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Word-Level Datapath Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Datapath Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Reporting and Diagnosis of Datapath Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Sequential Merge Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Sequential Merge Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Synthesis Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
Sequential Merge Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Setting the Effort Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Diagnosing Instance/Sequential Merge Nonequivalence . . . . . . . . . . . . . . . . . . . . . 274
Retiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Basic Pipeline Retiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Advanced Pipeline Retiming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Pipeline Retiming on a List of Specified Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 278
12
Layout Versus Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
LVR Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Starting Conformal GXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
LVR Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Circuit Library Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Design Logic Function Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
13
Conformal Custom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Custom Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Abstraction Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Starting Conformal GXL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Conformal GXL Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Reading a Transistor Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Defining Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Running Logic Transistor Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Reporting MOS Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
Continuing the Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Specifying Conditions for Abstracting Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
Analyzing Switch and Primitive Drive Strength . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
Custom Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
General Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Tie Off Cell Pins to 0 or 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Set Equivalent or Inverted Cell Input Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Group Single Pins into Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Flatten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
Ungroup Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Group Instances into New Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Custom Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
SPICE Netlist Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
MOS Devices Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Pre-charge Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
Module Pin Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333
Circuit to Logic Transformation Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
MOS Direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Define Power and Ground Supply . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Data Entry Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Pattern Match . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
Cell Remodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Application Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Logic Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
Test View Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Power View Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Library Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
RAM Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
RAM Primitive - Standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
RAM Primitive - Specialty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
RAM Primitive - SRAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
ROM Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
14
Conformal ECO Designer Functionality and Methodology . 359
15
FPGA Capabilities and Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . 361
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
FPGA Front-End Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Requirements and Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Front-End Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Current Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
FPGA Back-End Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Generating a Post-PAR Gate Netlist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Comparing the Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Continuing the Conformal Verification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Tips for the FPGA Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Xilinx Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Synplify Pro Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
General FPGA Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Using the Verilog Always Statement with Mixed Register Types . . . . . . . . . . . . . . . 377
A
VHDL Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Supported and Unsupported IEEE Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Vital Package Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387
Read Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Library Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Global Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 390
Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Component Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Nested Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Initial Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Shared Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Sliced Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Predefined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396
User-Defined Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Function Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
Sequential Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Wait Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 401
Signal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403
Procedure Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
For Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
While Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Concurrent Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Signal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
B
Verilog Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Verilog Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Supported Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Synthesizable UDPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
C
SystemVerilog Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
SystemVerilog Support Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Literals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Data Declarations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Operators & Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
Procedural Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 429
Randomization & Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Scheduling Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Clocking Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Program Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Modules and Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Configuration Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
System Tasks and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
VCD Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Macros and Compiler Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445
Configuring the Contents of a Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Non-std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
System Verilog Assertions (SVA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448
Supported SVA System Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Default Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449
Property Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Property Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Supported SVA Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Clocked Boolean Expression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 450
Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
D
Supported Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455
Supported Vendors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Supported Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456
Conformal Directive Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Enabling Directives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Enabling One Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Disabling All Directives for One Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Disabling Specified Directives for One Vendor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Enabling a List of Directives from an RTL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
E
Conformal Sample Test Case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 461
Starting Conformal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Reading the Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Read the Designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
Changing to the LEC System Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Viewing Unmapped and Mapped Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464
Running a Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Diagnosing a Non-Equivalent Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
Non-Corresponding Support Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Error Pattern Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
F
Top-level IO Port Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
G
Conformal Primitive Gate Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477
The Encounter® Conformal® logical equivalence checking tools verify RTL, gate, or
transistor-level designs. As part of the functional verification platform, Conformal gives you
complete equivalence checking (EC) solution available for verifying complex system-on-a-
chip (SoC) designs from RTL to layout.
Audience
This manual is written for experienced designers of digital integrated circuits who must be
familiar with RTL, synthesis, and design verification; as well as having a solid understanding
of UNIX and Tcl/Tk programming.
Each chapter focuses on the concepts and tasks related to the particular design phase or
topic being discussed.
In addition, the following sections provide prerequisite information for using the Conformal
software:
■ Chapter 1, “Introduction to the Conformal Equivalence Checker”
Describes the process flow and the major components of the Conformal operation.
■ Chapter 2, “Getting Started”
Describes how to install, set up, and run the Conformal Equivalence Checker software,
and use the online Help system.
Conventions
Syntax Structure
Convention Definition
Bold Case Indicates the command name.
UPPERCASE Indicates the required minimum character entry.
< > Indicates required arguments. Do not type the angle brackets.
[ ] Indicates optional arguments. Do not type the square brackets.
| Indicates a choice among alternatives. Do not type the vertical
bar.
\ The backslash character (\) at the end of a line shows that the
command you are typing continues on the next line.
… Indicates multiple entries of an argument.
* Indicates that Conformal lets the wildcard (*) represent any zero
or more characters.
GUI Convention
Convention Definition
Menu – Command Indicates command sequences under a menu. For example:
Choose File – Read Design.
Left-click Click the left mouse button on the specified item.
Right-click Click the right mouse button on the specified item.
Click Click the left mouse button unless otherwise specified.
Double-Click Click twice on the left mouse button.
Drag Press and hold the left mouse button, and then move the pointer
to the destination and release the button.
1
Introduction to the Conformal
Equivalence Checker
■ Overview on page 26
■ Conformal Features on page 27
■ Supported File Formats on page 28
■ Conformal Methodology on page 29
❑ Preparing the Designs on page 30
❑ Mapping and Comparing on page 30
❑ Diagnosing on page 30
■ Conformal Operation on page 30
❑ System Modes on page 31
❑ Transition on page 31
❑ Mapping on page 32
❑ Comparison on page 32
❑ Diagnosis on page 33
■ Overview of Conformal Tcl on page 34
❑ Conventions on page 34
❑ Specifying the Command Entry Mode on page 35
❑ Using Native Conformal Commands on page 36
❑ Duplicate Commands on page 36
Overview
The Conformal Equivalence Checking solutions are logical equivalence checking tools that
verify RTL, gate, or transistor-level designs. As part of the Encounter® Conformal® functional
verification platform, Conformal gives you the only complete equivalence checking (EC)
solution available for verifying complex system-on-a-chip (SoC) designs from RTL to layout.
It verifies the widest variety of circuits, including complex arithmetic logic, datapath,
memories, and custom logic. Conformal has high-performance, high-capacity, and excellent
debugging capabilities. These features are combined in an integrated environment.
Conformal supports standard library and design interface formats and integrates readily into
existing design environments. The flexibility of these tools lets you efficiently impose
constraints and apply guidance. Conformal is self-contained and is not tied to any particular
synthesis environment. Thus, it gives you a higher degree of confidence than equivalence
checkers integrated with a particular logic synthesis tool.
Conformal employs proprietary key point mapping and formal functional comparison
algorithms that incorporate many innovative techniques for solving a wide range of problems.
The comparison engine has superior performance and successfully completes verification of
designs with differences.
Conformal Features
Conformal incorporates many features that streamline and authenticate the design process,
while giving you flexibility.
■ Supports Full-Chip Verification
Conformal has excellent processing speed that significantly reduces verification time for
high-capacity, high-complexity, full-chip designs.
■ Supports Multiple Design Formats
Conformal supports Verilog®, VHDL, SPICE, EDIF, and NDL design formats.
■ Supports Standard Library Formats
Conformal supports Verilog simulation libraries and the Synopsys® LibertyTM Format
Libraries.
■ Employs Verilog/VHDL-RTL and Transistor Function Abstraction
Conformal has a built-in Verilog/VHDL-RTL and transistor function abstraction engine
that lets you verify Verilog/VHDL-RTL, gate, or transistor level designs.
■ Employs Advanced, Automatic Mapping
Conformal contains advanced and proprietary sequential element mapping algorithms
that identify corresponding sequential elements automatically with minimal user
resources. This feature relieves you of the tedious job of specifying corresponding
flip-flops and latches.
■ Employs an Efficient and Effective Comparison Engine
Conformal has a superior formal comparison engine to ensure successful verification of
non-similar designs with different hierarchical structures. Conformal contains a unique
correlation learning technology that effectively explores both structural and functional
relationships of the logic in two designs and dramatically reduces the verification run
time. This technology does not require high memory use and is very effective for both
similar and dissimilar designs.
■ Includes Automatic Diagnosis
When a logic mismatch is found, designers find that it is absolutely essential to be able
to quickly locate the source of functional differences. Conformal automatically diagnoses
functional differences, narrowing them to a small number of possible locations in the
design. This feature helps you identify and effectively correct problems and reduce
debugging time.
Conformal Methodology
The following flowchart illustrates the Conformal process flow.
Specify Constraints
and Design Modeling
Setup Mode
LEC Mode
Specify Compare
Parameters
Compare
Designs
Yes
Miscompare? Diagnose
No
Equivalence
Checking Complete
After reading in designs and libraries, you can tailor the session to your particular needs by
specifying constraints and parameters. When all of these Setup mode tasks are complete,
you can change to LEC mode and the next session phase.
Diagnosing
During the final phase of the Conformal process flow, you can employ a combination of the
integrated diagnosis tools to examine differences. These tools include the Schematic Viewer
and Source Code Manager. After you have remedied the differences, a new verification
session begins.
Conformal Operation
This section details the Conformal integrated debugging environment, describing each of the
major components of the Conformal operation.
System Modes
Conformal operates in two system modes: Setup and LEC. In the Setup mode, Conformal
reads two designs. You designate the design types, which are Golden and Revised.
(Generally, the Revised design is a modified or post-processed design that Conformal
compares to the Golden design.) Additionally, you apply constraints and design settings in the
Setup mode. Finally, you can specify Conformal compare options and mapping methods.
When you have set all design conditions, you can move to the LEC system mode.
Transition
The following two sections relate to events that occur as Conformal transitions from the Setup
to the LEC mode.
Rule Checking
Conformal checks various rules during parsing. You can specify how Conformal will respond
to rule violations before you read in the designs and libraries. Additionally, you can choose to
view a report displaying all of the library and design rule violations that occurred during
parsing.
For additional information about rule checking, see the Conformal HDL Rule Check
Reference.
Key Points
In the transition from the Setup to the LEC system mode, Conformal flattens and models the
Golden and Revised designs and automatically maps the key points. Key points are defined
as:
■ Primary Inputs
■ Primary Outputs
■ D Flip-Flops
■ D Latches
■ TIE-E Gates (error gate, created when x-assignment exists in Revised design)
■ TIE-Z Gates (high impedance or floating signals)
■ Blackboxes
Mapping
Conformal employs three name-based methods to map key points and one no-name method.
Name-based mapping is useful for gate-to-gate comparisons when small changes have been
made to the logic. Conversely, the no-name-mapping method is useful when Conformal must
map designs with completely different names. By default, Conformal automatically maps key
points with the name-first mapping method when it exits the Setup mode. Any key points that
Conformal does not map are classified as unmapped points.
Unmapped Points
After Conformal maps key points, the remaining unmapped points are classified into one of
three categories: extra, unreachable, or not-mapped.
■ Extra unmapped points are key points that are present in only one of the designs,
Golden or Revised.
■ Unreachable unmapped points are key points that do not have an observable point,
such as a primary output.
■ Not-mapped unmapped key points are key points that are reachable but do not have a
corresponding point in the logic fan-in cone of the corresponding design.
Comparison
After Conformal maps the key points, the next step of the verification is comparison.
Compare Points
You can designate mapped points for comparison. Comparison examines these compare
points to determine if they are equivalent or non-equivalent.
■ Inverted-equivalent
■ Aborted
In the case of aborted compare points, you can change the compare effort to a higher setting.
Thus, Conformal can continue the comparison on only the aborted compare points.
Conformal can also display the complete run time and total memory use for the comparison.
Reports
When Conformal completes the comparison, you can get summary reports showing which
key points are equivalent and which are non-equivalent. Then, you can diagnose
non-equivalent points to determine the cause of the difference.
Diagnosis
Diagnosis is the process of examining non-equivalent points and identifying the most likely
error candidates. In this phase of verification, examine non-equivalent points using the
integrated tools as described below.
The Conformal diagnosis feature precisely locates the cause of a non-equivalent point.
During this process, Conformal displays the error patterns that caused the difference and lists
the possible candidates. Included in this list is the percent of probability, which is shown in
decimal form. The most likely candidate is 1.00.
Gate Reporting
With the above diagnosis information gathered, you are ready to employ gate reporting to
trace the fan-in or fan-out cone of the non equivalent point. Additionally, you can view a
schematic representation of the non-equivalent point.
Schematic Viewing
When you view the schematic representation of the non-equivalent point, the viewer displays
the fan-in cone with the corresponding and non-corresponding supporting key points and
their simulation values. The non-equivalent compared point, diagnosis input point, supporting
key points, and error candidates are all color-coded for visual accessibility. The schematic
viewer displays the Golden and Revised schematic representations side-by-side in separate
windows, for quick comparison.
To further diagnose non-equivalent points, you can access the Source Code Browser. This
tool lets you specify a gate in the Revised or Golden design and view its relative location in
the source code.
For a complete description of the Tcl design access commands and the Tcl Utility commands,
see the Tcl Command Entry Mode Support chapter of the Conformal Equivalence
Checking Reference Manual. Each section includes the syntax for individual commands,
definitions for the applicable arguments, command examples, and what Conformal returns.
The focus of the chapter is Conformal Tcl commands. Therefore, if you want to learn more
about native Tcl commands, refer to the public Tcl manual widely available online. To see a
list of supported Tcl commands, enter a question mark (?) at the Tcl prompt.
Note: This has no effect when Conformal is in the default command entry mode.
As you work with the Tcl commands, you will find that some of the commands invalidate the
object handles you saved in Tcl variables. For example, when you change the design with set
root module, every object handle is invalidated. When an object handle is invalidated, yet
still referred to by a Tcl variable, the memory is not free until you reassign the Tcl variable to
another value.
By its very nature, the Tcl command interface is not as efficient as internal C functions.
Therefore, you will encounter some performance penalties when you access large amounts
of information using Tcl commands. For example, most of the get commands return a TCL
LIST, thus costing memory and speed.
Conventions
Conventions used in the Conformal Tcl command documentation differ somewhat from those
used in the remainder of the manual. For example, Conformal Tcl commands are case-
sensitive (you must type them in lowercase). Therefore, as a reminder, they appear in
lowercase.
■ commands
Tcl commands appear in the text and in examples in lowercase with a Courier font. And
since Conformal Tcl commands are case-sensitive, you must type them in lowercase.
(However, options are not case-sensitive.) Default options are noted.
■ Hierarchical context (/)
If a name begins with a slash (/), Conformal considers the name in a hierarchical context.
For example: /U02/U199
■ Module context
Module context operations always work on the current module. For example, find -net
zero refers to a net named zero that is in the current module.
■ Pin object_type
Pin object_types appear in the format instance_name/pin_name. For example:
❑ Pin object_type in module context:
A pin named data on instance U01 of the current module is specified as U01/data.
❑ Pin object_type in hierarchical context:
In hierarchical context, the string is preceded by a slash. Thus, the pin is specified
as /U01/data.
■ Wildcards: (*) and (?)
Conformal supports the wildcard * or ? in an object_name, but only at the bottom
hierarchical level:
To return to the default Conformal command entry mode, run the following command:
vpxmode
■ Example two: Use an underscore for spaces in commands. With this feature, type the
entire command; Conformal does not permit partial entry matching for native Conformal
commands in Tcl command entry mode unless you preface the command with the vpx
keyword (as shown in Example one, above).
read_design counter.v
If you type a native Conformal command incorrectly using the underscore method in Example
two (above), Conformal echos commands with common prefixes. For example, type:
add_in
Conformal returns:
ambiguous command name “add_in”: add_instance_attribute add_instance_constraints
add_instance_equivalences
Duplicate Commands
The following native Tcl commands are also defined as native Conformal commands:
break
continue
exit
Important
The behaviors of these commands are not the same in Tcl command entry mode as
they are in Conformal command entry mode. Use these commands with caution.
Tcl Version
To determine the current version of Tcl used by Conformal:
SETUP> tclmode
TCL_SETUP> puts $tcl_version
8.5
or
TCL_SETUP> info tclversion
8.5
To know from where the tcl script is being used from, one can do:
TCL_SETUP> info library
<cadence lec installation>/share/cfm/lec/tcl8.5
2
Getting Started
Without the -xl or -gxl option, the Conformal software starts with the default L license.
Once you start your session, you can use the LICENSE command to display the current
license status in the transcript output.
The lec command has the following additional options. This list is also available using the
lec -help command before you start your session.
If the CONFORMAL_RC variable is not set, the software continues the search as follows:
1. The installation directory
2. The home directory
3. The current working directory
Note: The software does not include conformal_lec.rc in the release.
If one or more of these files exist, the software runs them in the order noted above. This
search order gives you flexibility in using the initial command file. You can set up initial
command files for any or all of the following purposes:
■ Global initial command file for all users
■ Global initial command file for an individual user
■ Initial command file for a test case
The file contents vary according to your needs; for example, they can include commands,
aliases, and dofiles. You can use this file for any purpose at the system, user, and local levels.
Important
Do not use an initialization file to run a complete batch file. Use dofiles, as explained
in the following section, for this purpose.
Execute dofiles during startup or with the DOFILE command. When you create a dofile, follow
these guidelines:
■ Each new command must begin on a new line.
■ Two or three slashes (// or ///) precede comments.
For more information, see Comments in Dofiles on page 46.
■ Dofiles can execute additional dofiles.
You can use the DOFILE command (or the -dofile command option at startup) to read in
and execute a command file that includes any set of commands.
In GUI mode, the -dofile option is useful for running a set of commands that set up your
environment and advance to a specific point in the verification session. The following example
command substitutes your dofile name for my_dofile:
UNIX% lec -dofile my_dofile
In non-GUI mode, you can use the -dofile option for running batched sets of commands.
The following example command substitutes your dofile name for my_dofile:
UNIX% lec -nogui -dofile my_dofile
Saving a Dofile
To save the commands entered during a current session that you can use later as a batch file
to repeat the session, use the SAVE DOFILE command, or the Save Dofile form in GUI mode
(File – Do Dofile).
When running a session from a dofile, this command does not save individual commands that
might have been included in a separate dofile (that is, it saves the manually entered
commands, which might include a dofile <filename> command).
Use the Save Dofile form to save commands to a dofile to be used later as a batch file to
repeat the Conformal Equivalence Checker session.
Filename Specifies the name of the dofile. You can enter the path
of the dofile or click Browse and select a location from
the Save Dofile browser window.
Open Mode Overwrites or appends to the dofile. Replace overwrites
the contents of an existing dofile, and Append appends
to the contents of an existing dofile.
At any time during a session, execute commands in a batch mode using the DOFILE
command or the Do Dofile form in GUI mode (File – Do Dofile). By default, the dofile aborts
at any command that generates an error message.
Use the Do Dofile form to execute a batch file of commands, or run a set of commands from
a previous session.
Interrupting a Dofile
Within a dofile, use the BREAK command to interrupt a dofile and return to the current system
mode.
When a dofile executes the BREAK command, the Conformal software issues a warning and
prompts you to use the CONTINUE command to resume running the dofile:
//Warning: Break dofile ‘my_dofile’ at line 32. Use ‘continue’ command to continue.
Use the SET DOFILE ABORT command in a dofile to specify how the Conformal software
responds to errors it encounters:
■ set dofile abort on
Aborts the dofile and generate a message.
■ set dofile abort off
Continues with the dofile and generate a message.
■ set dofile abort exit
Exits the session.
Comments in Dofiles
In this example, the read library command is run for lib01.lib through lib_03.lib,
commenting out lib04.lib through lib_06.lib, and not specifying the -liberty
and -both options:
read library ../library/lib_01.lib ../library/lib_02.lib \
../library/lib_03.lib // ../library/lib_04.lib \
../library/lib_03.lib
../library/lib_05.lib ../library/lib_06.lib \
-liberty -both
2. Three slashes (///) comments out the rest of the line. /// must have a space before it
if you add it to the middle of the text.
In this example, the first line only runs the read library command, commenting out
lib_01.lib and lib_02.lib, and including lib03.lib through lib_06.lib, and
specifying the -liberty and -both options:
read library ///../library/lib_01.lib ../library/lib_02.lib \
../library/lib_03.lib ../library/lib_04.lib \
../library/lib_05.lib ../library/lib_06.lib \
-liberty -both
Use the RESTORE SESSION command, or the Restore Session form (File – Restore
Session), to restore a session you previously initiated and saved. Before using this
procedure, Conformal must be in its initial state. Therefore, you must either reset the system
to the initial state with the RESET command or Reset Design menu option (File – Reset
Design), or exit and restart the Conformal software.
Limitation: When you use the Restore Session menu option, you must restore the session
on the same platform and with the same Conformal version.
Applicable CHECKPOINT
commands INFO CHECKPOINT
<start_up_command> -restart_checkpoint <checkpoint_file_name>
[-protect <password>]
Data preserved When you save your session as a checkpoint, the tool preserves the:
■ Hierarchical and flattened databases
■ Environment settings
■ Constraints
■ Verification results
■ User-defined variables
■ User-defined procedures
Supported Linux
Platform
Limitations:
This feature has the following limitations:
■ If you are creating a checkpoint file that you plan to restart using a different license
server, add the restart license server to the LM_LICENSE_FILE variable before invoking
Conformal and before creating the checkpoint file; otherwise, you will not be able to
restart the checkpoint file with the new server. For example:
setenv LM_LICENSE_FILE "$LM_LICENSE_FILE":5280@mylic01
■ Do not enter the GUI mode if you plan to create a checkpoint file that you will want to run
later in the GUI mode. If a checkpoint file is created after having entered GUI mode, when
the checkpoint file is restarted, it will restart and run in non-GUI mode and the GUI mode
is disabled. If a checkpoint file is created before entering the GUI mode, the checkpoint
file can enter the GUI mode when it is restarted.
■ Checkpoint and restarts works on only the following Linux platforms:
32/64-bit Linux kernel versions 2.6.9-34, 2.6.9-42, 2.6.9-67, 2.6.9-78, 2.6.9-89, 2.6.10,
2.6.14, 2.6.16, 2.6.18, 2.6.25, 2.6.26 and 2.6.27
■ You cannot specify the stack limit in a restarted tool process. You can, however, specify
the stack limit when you save the checkpoint:
CHECKPOINT -stack <multiplier>
Default multiplier is 1 (in other words, 64MB).
Transcript Messages
In both the GUI and non-GUI modes, you can choose to turn the transcript output on or off.
This is especially useful for batch processing in the non-GUI mode. With the transcript output
turned off, none of the regular transcript output is displayed to the screen. Rather, the
Conformal Equivalence Checker retains the transcript in a file. To save the transcript output
in a log file, see Recording Transcript Log Files on page 50.
To turn the transcript output on or off, use the SET SCREEN DISPLAY command.
To create or append to an existing transcript file, use the Log File form in GUI mode (Setup
– Log File).
Tip
Recording in this file begins after you click OK; therefore, you might want to create
a log file at the beginning of your session. However, if you begin a session and
decide to save the transcript at a later point, see Saving a Transcript File on page 50
to capture a transcript of the beginning of the session.
You can save a transcript to a file at any point during a session, use the Save Transcript form
in GUI mode (File – Save Transcript). It contains all of the information from the beginning
of the session up to the point when you save the file.
You can start or stop a transcript log file at any time during a session using the SET LOG
FILE command. Furthermore, you can save multiple log files during a session. However, only
one log file is active at a time. If you create a new log file without stopping a previous log file,
Conformal ends the previous log file and starts recording in the new file.
The SET LOG FILE command options allow you to overwrite (replace) or append existing
files. There is no default; therefore, if you enter an existing filename without specifying the
replace or append option, the Conformal software responds with an error message.
Aliases
To reduce typing, you can use an alias (single word) in a session. For example, if you
frequently use the REPORT ENVIRONMENT command in a session, define an alias for that
command with the ADD ALIAS command, or use the Alias form in GUI mode (Setup – Alias).
In the following example, the ADD ALIAS command adds renv as the alias for the REPORT
ENVIRONMENT command:
Example command:
add alias env report environment
If you re-use an existing alias name, the Conformal software accepts (overwrites) the former
alias.
Alias Form
You can use the the Alias form in GUI mode (Setup – Alias) to add, delete, or view alias
names.
Important
If you type a command name incorrectly, the Conformal software accepts your entry,
but returns an “Unknown command” error message when you attempt to use the
alias. In this case, delete or overwrite the faulty alias with the correct command.
Setting Preferences
You can use the Preferences pull-down menu from the main window.
The Font & Size form has five tabs (pages) for the following:
To change the font style, click the Font down-arrow to display a list of font styles, select the
font style, and click Apply.
To change the font size, click the Size down-arrow to display a list of font sizes, select the font
size, and click Apply.
Hierarchical Browser On
Displays or hides the Module Browser in the main window.
The Conformal software will open a paired HRC sync-up schematic when selecting
Schematics from the the following areas:
■ Selecting Schematics from the Hierarchical Browser popup menu.
■ Selecting Show Hierarchical View from the Flattened Schematic window.
■ Selecting Show Hierarchical HLite View from the Flattened Schematic window.
Icon Bar
Displays or hides the Icon Bar in the main window.
Without simplified viewing, the tool determines the number of netlists to display. Very large
schematic displays can take a long time to load, and it can be difficult to pinpoint/trace logic.
With simplified viewing, you can drag/drop any module/instance you want to view and then
trace corresponding loads/drivers.
Simplified schematic viewing is enabled by default. To disable simplified schematics, use the
Preferences - Simplified Schematics Viewing Options menu item from the main
Conformal window.
From the main GUI, click on the Help menu item and navigate to the HTML version of the
document that you wish to view. This will bring up Cadence Help.
Some GUI windows also have a Help button that will launch Cadence Help.
Example:
% ccd -help
■ -verbose—To view expanded information about a specific command, enter the MAN
command, followed by the command name, and the -verbose option. For example:
man read design -verbose
■ message_name—To view help for a particular rule check message, enter the MAN
command followed by the message name. For example:
man f10
■ -message—To view a list of all the rule check messages, use the MAN command with
the -message option. For example:
man -message
For more information on the MAN command, use the following command from within the tool:
%man man
A Help button is available in many command windows. Unlike the Help button on the main
window, when you left-click the Help button in command windows, the Conformal software
automatically executes Help – Commands and displays the information for the related
command in the Command Help window.
Use the following procedure to view the user guides and reference manuals.
1. Click the Help pull-down menu located at the far right end of the menu bar.
2. Click <Book Name> (pdf) or <Book Name> (html).
The PDF reader launches and displays the PDF version of the book. Or, Cadence Help
launches the HTML version. If you choose the HTML version, you will have access to all
the other books in the documentation set through Cadence Help.
Note: You must have a PDF reader to access the documentation. To download the
current version of Adobe Acrobat Reader, visit the following web page:
http://www.adobe.com/support/downloads/main.html
Use the following procedure to display the Cadence company logo, the product version
number and date, mailing address, phone and fax numbers, and web page and E-mail
addresses.
1. Click the Help drop-down menu located at the far right end of the menu bar.
2. Click About.
From the Help drop-down menu in the main window, click License to view information
regarding all the installed Conformal software licenses. The report appears in the Transcript
window and includes information such as the current user, feature, and expiration date.
You can also use the LICENSE command to review the current license status. The current
status of the license appears in the transcript output.
Platform Integration
Preferences
In the Encounter main window, select Design – Preferences to open the Preferences form,
and click on the Design tab.
Click Write Conformal/LEC dofile When Design is Saved to specify that when saving a
netlist, this automatically saves a dofile for the Conformal Equivalence Checking capabilities.
In the Encounter main window, select Tools – Conformal – Verify Design Equivalence to
open the Conformal Equivalence Checker form.
Click Dofile to specify the dofile creation. You can enter the name of the dofile, use the
dofile.lec default, or click Browser icon select a dofile from the Open Dofile browser
window.
There are two ways Conformal LEC performs the comparison between the Golden design
and the revised design: a hierarchical comparison and a flattened comparison. A flattened
comparison is sufficient when comparing two gate-level designs.
However, when at least one of the two designs is a complex RTL design, a hierarchical
Conformal LEC comparison might be necessary. By default write_do_lec always
prescribes a hierarchical comparison if the Golden design is at the RTL level.
write_do_lec assumes:
■ The design loaded into RTL Compiler is an RTL design
■ The design specified with the -Golden_design option is a gate-level netlist. A flat
compare will be performed with this option.
■ The design specified by the -revised_design option is a gate-level netlist
If the -Golden_design switch is not specified, and a single-shot do file was created, the
RTL design loaded with the read_hdl command will be considered the Golden design and
a hierarchical comparison will ensue. If the -Golden_design switch is not specified and an
incremental comparison was performed, then the Golden netlist is described in the last
checkpoint file, and a flat comparison will ensue.
RTL Compiler and Conformal LEC handle the combination of Liberty files in the same way.
Both can combine multiple Liberty files that are syntactically incomplete into a single Liberty
file. For example, in the following RTL Compiler example, file1.lib and file3.lib
Liberty files are complete, and file2.lib and file4.lib Liberty files are missing the
library keyword and the corresponding opening and closing braces (“{}”):
set_attribute library { { file1.lib file2.lib } { file3.lib file4.lib } }
The file1.lib and file2.lib libraries will nonetheless be combined and treated as a
single Liberty file. The file3.lib and file4.lib files will also be combined and treated
as a single Liberty file.
If all the Liberty files were syntactically correct, in this case with their library keywords and
braces, then the above example will look like this in Conformal LEC:
SETUP> read library -liberty file1.lib file2.lib file3.lib file4.lib
■ If an incomplete Liberty file only contains elements that Conformal LEC does not need,
like wire-load models, simply remove them from the dofile.
■ If an incomplete Liberty file contains elements that Conformal LEC needs, like extra cells,
you must manually combine the main library and the partial library and then load the new
single library in Conformal LEC. To do this:
a. Take the main library and delete the final “}” (brace) character
c. Add the previously deleted “}” character at the end of the main library.
All library files are loaded into Conformal LEC through a single read library command that
is specified in the generated dofile. The command will always be specified with its -both
option. The following example loads all the Liberty libraries:
rc:/> read library -both -liberty $lib_files
An alternative to using the Liberty libraries is to use simulation libraries with the
write_do_lec command.
Currently, the simulation libraries are only supported in Verilog-1995 format. Multiple
simulation libraries can be specified as a Tcl list.
Every read library Conformal LEC command in the RTL Compiler generated dofiles is
always accompanied by the -statetable option.
RTL Code
■ Each read_hdl -verilog RTL Compiler command translates to a
read design -verilog Conformal LEC command.
■ All the read_hdl -vhdl commands (if there are more than one) are combined into one
read design -vhdl command.
■ The read design -vhdl command will be placed after the last
read design -verilog commands.
Each parameter that was explicitly specified with the elaborate -parameters RTL
Compiler command will become an argument to the -parameter option of the
read design command in the generated dofile. For example:
rc:/> elaborate -parameters {{p1 16} {p2 10}}
Blackboxes
The write_do_lec command will always insert the following Conformal LEC command in
the dofiles:
set undefined cell -noascend black_box -both
Undriven Signals
In Conformal LEC, the default undriven setting is Z. In RTL Compiler, the default undriven
setting is none for all three scenarios.
■ The 0 setting in RTL Compiler is the same as the 0 setting in Conformal LEC.
■ The 1setting in RTL Compiler is the same as the 1 setting in Conformal LEC
■ The X setting in RTL Compiler is the same as the X setting in Conformal LEC.
■ The none setting in RTL Compiler is the same as the Z setting in Conformal LEC.
Conformal LEC uses one undriven setting to control all three undriven scenarios. RTL
Compiler has one undriven setting for each scenario. To translate from RTL Compiler
undriven settings to Conformal LEC undriven setting, the following two RTL Compiler
attributes are ignored:
hdl_undriven_output_port_value
hdl_unconnected_input_port_value
Translating the undriven setting is only needed for RTL designs. Therefore, translation of the
undriven attributes is done only for the Golden design when it is the RTL loaded into RTL
Compiler. In this case, the following actions are taken:
■ If get_attribute hdl_undriven_signal_value / returns 0, then the dofile has
set undriven signal 0 -Golden
Only RTL designs require the translation of undriven settings. Therefore, undriven attributes
only need to be translated when the Golden design is the RTL that is loaded into RTL
Compiler.
Tip
Adding an instance constraint on a DFF removes it from the compare list. As a
result, it becomes unreachable because it is no longer needed. However, if you still
want to compare it, use the SET MAPPING METHOD -unreach command.
Among the Low Power transformations and optimizations performed by RTL Compiler,
write_do_lec supports MSV and clock-gating insertion.
It ignores the Conformal LEC impact (if any) of the SRPG and operand isolation Low Power
features
write_do_lec supports the ff and none styles of clock-gating insertion, and ignores the
Conformal LEC impact (if any) of the latch style.
Conformal LEC performs functional verification of the core logic of a design and not the scan-
insertion logic. Therefore, the RTL Compiler generated dofile may carry the following types of
design constraints:
■ For every scan-data-out port added by RTL Compiler, there is a Conformal LEC
add ignored outputs command to exclude it from the Conformal LEC comparison.
■ For every test signal that is declared by the RTL Compiler define_dft command, there
is a Conformal LEC add pin constraints command to tie it to the inactive state.
■ For every primary input port serving as a test control signal of an IEEE 1500 core
wrapper, there is a Conformal LEC add pin constraints command to tie it to the
inactive Conformal state.
For LSSD designs, provide Conformal LEC with a simulation model for every LSSD cell used
in the design.
If the RTL code instantiates a ChipWare or DesignWare model, the generated dofile loads its
simulation model using the read design command. However, currently this process will not
work for the pipelined models (like CW_mult_2_stage), or non-bit-accurate models (like
CW_multp).
By default, the last line in a generated dofile is an exit command, telling Conformal LEC to
quit its session after finishing the dofile.
You can suppress the exit command in the generated dofile by specifying the -no_exit
switch of the write_do_lec command. Doing so will not terminate the Conformal LEC
session after the last command is executed.
3
Using the Graphical User Interface
Main Window
This section describes some of the basic features of the main window.
Menu Bar
Icon Bar
Hierarchical
Browser
Transcript
Window
Command
Entry
Status Bar
■ Hold down the Shift key and click on two items; this selects every item on the list
between the two.
■ Hold down the Control key and click on items that you want to select. With the
Control key depressed, you can jump around the item list.
Menu Bar
The menu bar represents categories of commands. Each of the headings supports a
pull-down menu of related commands. Click a menu bar category to display the group of
represented commands. The menu names are enabled or disabled (grayed) according to the
current operating mode (Setup or LEC). With the drop-down menu visible, click on an enabled
command to run it.
The drop-down menus support meta-key invocation for menu commands using mnemonics.
The mnemonic for each command name is shown with an underscore. For example, run the
File – Read Design command by typing meta-f, then d. The meta key is usually the
diamond key on Sun keyboards, or the Alt key on other keyboards.
Window Menu
Note: The following information also applies to the Manager windows.
The Window drop-down menu is a dynamic menu that changes as you open and close
windows. All active windows are listed in the Window drop-down menu. Clicking on a window
name brings it to the front of your screen.
Use the Window – Cascade menu command to refresh your desktop and display the main
window on top with all other open windows in a cascading view to the left of the main window.
Icon Bar
The Icon Bar, which is located in the main window, contains icon buttons that run specific
commands. Click an icon to run the related command or access the related tool. If an icon is
not highlighted, it is not available in your current system mode. For example, when the system
is in Setup mode, the Mapping Manager and Diagnosis Manager icons are not
highlighted, since they are available in the LEC operating mode only. The following tables
defines the icons.
To display or hide the Icon Bar in the main window, choose the Preferences – Icon Bar
check box.
The following lists the fields and options for the Find Hierarchical Modules form.
Hierarchical Browser
The Hierarchical Browser, located in the main window, displays the hierarchical modules of
the Golden and Revised designs. The root module is displayed along with its hierarchical
contents. Clicking the + and - icons expand and compress the hierarchical display. Click the
Refresh icon, located on the icon bar near the top of the main window, compresses all
hierarchical modules back to the root module. The module name is displayed first, and
instance names are enclosed in parentheses ( ).
To display or hide the Hierarchical Browser in the main window, choose the Preferences –
Hierarchical Browser On check box.
Run certain commands when you select a module or instance in the hierarchical display. You
cannot run commands on library cells.
1. Click a module or instance in the Golden or Revised design to select it.
2. Right-click to display the pop-up menu.
3. Drag the cursor to choose a command.
Run certain commands when you select a module or instance in the hierarchical display. You
cannot run commands on library cells.
1. Click a module or instance in the Golden or Revised design to select it.
2. Right-click and drag the cursor to choose a command from the pop-up menu.
In the Setup system mode, you can run certain commands from within the Hierarchical
Browser window. The following commands relate to the root module.
Run the following commands from within the Hierarchical Browser window for a hierarchical
module or instance that is not a root module.
Transcript Window
The Transcript window is located in the main Conformal Equivalence Checker window. It
displays information regarding the current session, including warnings and error messages.
Additionally, when you enter a report command, the report information is displayed in the
Transcript window. The text is color-coded for greater visual accessibility. For example, error
messages appear in red text.
Right-click in the Transcript window to open the pop-up menu and choose Clear.
Commands you execute using the menus or icons are transcribed to the Command Entry
window. If you use the Save Dofile feature, Conformal writes all of the commands that are
listed in the Command Entry window to the file.
Right-click in the Command Entry window to open the pop-up menu, and choose Clear.
Status Bar
The Status Bar is located at the bottom of the main window. It shows the status of certain
processing commands. The progress meter at the right end of the status bar changes
incrementally and a corresponding percentage number shows the level of completeness.
To switch GUI mode to the non-GUI command line mode, choose File – Exit GUI from the
main window.
To exit completely, use the EXIT command, or choose File - Exit from the main window.
Note: All design and diagnosis information is lost when you terminate the session.
Choosing File - Exit opens a confirmation window. By default, the Conformal software does
not automatically save GUI settings for future sessions. To save your preferred settings, click
the Save GUI settings check box. Included in the list of supported settings are:
■ Window size and location (excluding schematics and source code windows)
■ Fonts
■ Schematic colors
■ Mapping Manager sorting option
■ Mapping Manager display object class selection (for example, show only non-equivalent
points)
■ Mapping Manager region display option
If you exit from the Exit window and save preferences, you can later reverse this choice and
use default settings in future sessions. Remove the .conformal_gui.rc file from your
home directory or reset the default settings with the -resetrc options when you begin a
session:
rm ~/.conformal_gui.rc
conformal -resetrc
If you have done some debugging, the Conformal software returns a status code. The exit
status code consists of flags that represent different conditions.
For more information, including a table that lists of flags, their descriptions, and examples, see
Exit Status Codes on page 218.
File Menu
The following menu options are accessible from the File menu:
■ Read Library—Specify library filenames you will include with a design.
See Read Library Form on page 105.
■ Read Design—Specify the design filenames the Conformal software reads in as the
Golden and Revised designs.
See Read Design Form on page 109.
■ Save Dofile—Save commands to a dofile to be used later as a batch file to repeat the
Conformal Equivalence Checker session.
See Saving a Dofile on page 43.
■ Do Dofile—Execute a batch file of commands, or a Dofile set of commands from a
previous session.
See Executing Commands in a File on page 44.
■ Save Transcript—Save a transcript to a file at any point during a session. It contains all
of the information from the beginning of the session up to the point when you save the
file.
See Saving a Transcript File on page 50.
■ Reset Design—Reset the system to its initial state. This deletes all existing designs and
libraries and cancels all previously issued commands.
■ Save Session—Saves your session up to a current point and outputs the session file in
a binary format. You can then restore the session later using the Restore Session
command. You can use this command if priorities demand that another session preempt
your session.
■ Restore Session—Restores a session you previously initiated and saved using the
Save Session command. When invoked, Conformal will go back to its initial state then
restores the state from the saved session.
See Saving and Restoring a Session on page 47.
■ Exit GUI—Switch Conformal from the GUI mode to the non-GUI command line mode.
■ Exit—Exit the Conformal software completely.
See Exiting the GUI and Software on page 73.
Setup Menu
The following menu options are accessible from the Setup menu:
■ Log File—Create or append to an existing transcript file.
See Creating a Transcript File on page 49.
■ Alias—Add, delete, or view alias names in a session.
See Alias Form on page 51.
■ Search Path—Create, modify, or delete directory search paths.
See Adding Search Paths on page 97.
■ Environment—Set global options for the Golden and Revised designs and for mapping
and comparison operations.
See Setting Global Options For Mapping and Comparison on page 100.
■ Pin Constraints—Add and delete pin constraints to primary input pins.
See Pin Constraints on page 119.
■ Pin Equivalences—Add and delete pin equivalences.
See Pin Equivalences on page 122.
■ Primary Input—Add and delete primary inputs.
See Primary Inputs on page 124.
■ Primary Output—Add and delete primary outputs.
See Primary Outputs on page 127.
■ Cut Point—Add and delete cut points.
See Cut Points on page 134.
■ Tied Signals—Add and delete tied signals to floating nets and pins.
See Tied Signals on page 130.
■ Root Module—Change the Conformal automatic root module assignment and to
specify the name of the new root module in the Golden and Revised designs.
See Changing the Root Module on page 96.
■ Renaming Rule—Add or delete renaming rules to guide mapping, help map modules
for hierarchical comparisons, or rename pin names of blackboxes.
See Renaming Rules on page 147.
■ Notranslate Modules—Add and delete design or library modules that will not be
translated. These modules will be treated as blackboxes.
See Adding Notranslate Modules on page 98.
■ Flatten Model—Set global options for flattening and modeling, which occur when
exiting Setup system mode.
See Flatten Model Form on page 144.
Report Menu
Use the Report form to display extensive design information in the Transcript window of the
main window. For information on saving the reports to a file, see Transcript Messages on
page 49.
Reporting contains the following categories. You can either select these from the Report
menu, or from the form’s Report Type pull-down menu.
■ Black Box—Displays black boxes from the Golden and Revised designs.
■ Cut Points—Displays cut points from the Golden and Revised designs.
■ Design Data—Displays the number of design modules, library cells, inputs, outputs,
primitives, and one-to-one mapped state points on the Golden and Revised designs.
■ Environment—Displays global settings for the Golden and Revised designs and system
settings.
■ Floating Signals—Displays all floating signals in the Golden and Revised designs or in
specified modules of a design.
■ Instance Constraints—Displays the constraints placed on instances in the Golden and
Revised designs.
■ Instance Equivalences—Displays the equivalences placed on instances in the Golden
and Revised designs.
■ Messages—Displays either a summary or complete list of the warning messages that
come from the modeling, mapping, or comparison process.
■ Modules—Displays module information for the Golden and Revised designs.
■ Notranslate Modules—Displays all of the library and design modules that Conformal
will not compile when reading in libraries and designs.
■ Pin Constraints—Displays the constraints placed on primary input pins in the Golden
and Revised designs.
■ Pin Equivalences—Displays a list of added pin equivalences and inverted pin
equivalences.
■ Primary Inputs—Displays primary input pins from the Golden and Revised designs.
■ Primary Outputs—Displays primary output pins from the Golden and Revised designs.
■ Renaming Rule—Displays all of the library and design modules that Conformal will not
compile when reading in libraries and designs.
■ Search Path—Displays the paths Conformal searches to locate filenames included in
the Conformal software.
■ Tied Signals—Displays the list of renaming rules for mapping, module, and pin
renaming.
The following options are for the Mapping Manager window. For more information about these
features and related functionality, see Mapping Manager on page 188.
■ Mapped Points—Opens the Mapping Manager and displays the mapped points that
were automatically identified or added with the Conformal software. Each mapped point
from the Golden and Revised design is displayed along with a summary of all Golden
and Revised mapped points.
■ Unmapped Points—Opens the Mapping Manager and displays a list of unmapped
points, along with a summary of all of the unmapped points in the Golden and Revised
designs.
■ Compared Points—Opens the Mapping Manager and displays the compared points
that were added with the Conformal software.
■ Compare Data—Opens the Mapping Manager and displays a list of all or specified
compared points.
■ Statistics—Displays the mapping and comparison statistics for the Golden and Revised
designs.
When Conformal completes the comparison, it displays a summary table of the number of
equivalent and non-equivalent compared points in the Transcript window.
Tip
You can also run the COMPARE command in the Mapping Manager to compare
specified points or all points (see Comparing Key Points on page 197).
➤ Choose Run – Compare.
Stop After # Mismatch Specifies the number of non-equivalent points where the
comparison stops.
Stop After # Abort Specifies the number of abort points where the
comparison stops.
Display Non-equivalent Points
Displays the non-equivalent points as they are found
during the comparison.
Add All Compare Points Automatically adds all compare points (the default).
Tools Menu
The following options are accessible from the Tools menu:
■ HDL Rule Manager—Display all of the library and design rule checks the Conformal
software runs during parsing.
See HDL Rule Manager on page 86.
For more information on the HDL Rule Checks that Conformal performs, see the
Conformal HDL Rule Check Reference.
■ Gate Manager—Helps diagnose and debug your designs.
See Gate Manager on page 176
■ Mapping Manager—Serves as a gateway to the integrated debugging environment.
See Mapping Manager on page 188
■ Diagnosis Manager—Display the error patterns and error candidates for
non-equivalent points.
See Diagnosis Manager on page 205
■ Hierarchical Compare—Run a module-by-module, bottom-up, hierarchical
comparison on two hierarchical designs.
See Hierarchical Module Comparison Window on page 244
■ LowPower Manager—Display unmapped and checked points, check key points, and
report the status of each checked point.
See Low Power Manager in the Conformal Low Power User Guide for more
information.
4
Command Line Features
In the following table, ^F indicates pressing the Ctrl key and the F key simultaneously.
Function keys have their names enclosed in angle brackets, for example, <ESC> is the
Escape key.
The key sequences for basic editing functions are summarized in the following table.
Keys Function
^F or <right-arrow> Move the cursor one character to the right
^B or <left-arrow> Move the cursor one character to the left
^A Move the cursor to the beginning of the line
^E Move the cursor to the end of the line
^U Delete the entire line
^K Delete all characters from the cursor position to the
end of the line
<ESC>f Move the cursor forward by one word
<ESC>b Move the cursor backward by one word
^D Delete the character under the cursor
Every command that is successfully entered is saved in a history list. You can recall
commands in the history list to avoid repeated typing. The history list has a size limit of 256k
bytes and the oldest commands in the list will be discarded when this limit is exceeded.
Key Function
^P or <up-arrow> Recall the previous history line
^N or <down-arrow> Recall the next history line
<ESC>p History search backward
<ESC>n history search forward
^Xh List the history
<ESC>< Recall the first history line
<ESC>> Recall the last history line
^D List all possible completions when
cursor is at end of line
The history search capability looks into the history list for one that matches the beginning of
the current line. If the search string contains wildcards (*, ?), then the entire pattern is
matched. This is useful for searching patterns in the middle of a line.
For example:
SETUP> usage
SETUP> echo hello
SETUP> echo bye
SETUP> us<ESC>p
SETUP> usage
SETUP> *hello*<ESC>p
SETUP> echo hello
The command line history can also be saved into a file using the command SAVE DOFILE.
Partial command completions are listed with the postfix "..."; complete command
completions are listed with the postfix "*". In the example above, the remodel command is
complete, commands like "read" are not. To narrow the choices, type more characters. For
example, press <TAB> after typing "read" will show the commands that begin with "read":
SETUP> read<TAB>
read cpf* read lef... read memory... read rule... read design* read library* read
pattern* read testcase* read fsm... read mapped... read rom...
When there is only one choice, the command is completed automatically. For example,
pressing <TAB> after typing "read li" will complete the command "read library". Typing
^D (when the cursor is at the end of a line) lists the possible completions without making any
completions. Beware that using ^D on an empty line will terminate the tool.
Command completion understands the VPX and MAN commands, and will complete the
commands that come after. For example,
SETUP> man write l<TAB> SETUP> man write library
After the command is completed, pressing <TAB> will activate filename completion.
Repeating Actions
The effect of pressing a key can be repeated automatically by giving it a repeat count using
the key sequence <ESC>numberX where number is the count in one or more digits, and X
is the key to be repeated. For example, the following example repeats the single character
deletion using the <Backspace> key 20 times.
SETUP> abcdef01234567890123456789<ESC>20<Backspace>
SETUP> abcdef
Notes
■ Command completion completes one word at a time. For example, the partial input
"write ru" needs two completions, one for "rule", and one for "check" to result in
the completed "write rule check" command. However, since there are no other
commands that begin with "write ru", only one completion should be necessary.
■ Options are not completed.
5
Managing Rule Checks
You can view all the HDL rule check messages and their details in the Reference Guide, or
type ‘help <rule>’ at the command line.
You can use the HDL Rule Manager to manipulate the HDL Rule Checks that are done when
reading in libraries and designs. There are two ways to open the HDL Rule Manager from the
Main window:
➤ Choose Tools – HDL Rule.
➤ Click the HDL Rule Manager toolbar widget.
For the HDL Rule Manager, see the following for more information:
■ Changing the Severity of Rule Checks on page 89
■ Enabling and Disabling Rule Checks on page 89
■ Running Incremental Rule Checks on page 89
■ Reporting Messages for Rule Checks on page 90
■ Viewing a Specific Message on page 90
■ Viewing Source Code for an Occurrence on page 90
The HDL Rule Manager includes the following tabs, corresponding to the rule checking
categories, and a display area.
■ RTL—For designs that are written in the register transfer level of abstraction.
■ Verilog—For designs that are written in Verilog.
■ UDP—For designs that contain user-defined primitives.
■ Directive—For designs that include directives or pragmas.
■ Ignored—For designs that include unsupported or redundant constructs, which are
ignored by the checker.
■ Hierarchy—For designs that contain hierarchical components.
■ Spice—For designs that contain SPICE netlists.
Options Click the View pull-down menu and choose Rule with
messages only (the default), or All to display a
complete list of rules and the messages (violations) for
each page.
Click the Page Size option to open the Page Size form
to specify the page limits to control the number of rules
that are displayed.
Summary For each page, this displays the total number of rules for
the specified category, and the total number of rule
violation occurrences (messages).
Severity Levels
The severity levels are listed below from the most serious to the least serious:
■ Error—The Conformal software might not allow you to begin verification until you resolve
the error.
■ Warning—The Conformal software allows you to begin verification; however, it warns you
of potential errors in the design.
■ Note—The Conformal software allows you to begin verification; however, it flags potential
errors in the design.
■ Ignore—The Conformal software does not report this severity by default.
You can change the level of severity for rule violations with the SET RULE HANDLING
command. You must use this command during Setup before reading in library or design files.
Alternatively, you can use the HDL Rule Manager to change the severity (see Changing the
Severity of Rule Checks on page 89.)
For example, to show the initial default severity level for HRC7, you would run the following
command (in Setup mode):
report rule check hrc7 -help
The output shows the rule name, default severity, and description:
HRC7 WARN Module specified by ‘add notranslate modules’ command cannot be found
To show the current severity of HRC7, which in this example has not been changed from its
default severity level, you would run the following command:
report rule check hrc7 -setting
===============================================================================
= RTL Rules =
===============================================================================
HRC7: Module specified by ‘add notranslate modules’ command cannot be found
Type: Golden Severity: Warning
Type: Revised Severity: Warning
Type: Golden library Severity: Warning
Type: Revised library Severity: Warning
To change the default severity level to an error, you would run the following command (in
Setup mode):
set rule handling HRC7 -error
To show the new severity level for HRC7, you would run the following command:
report rule check HRC7 -setting
===============================================================================
= RTL Rules =
===============================================================================
HRC7: Module specified by ‘add notranslate modules’ command cannot be found
Type: Golden Severity: Error
Type: Revised Severity: Error
Type: Golden library Severity: Error
Type: Revised library Severity: Error
Note: However, if after changing HRC7 rule’s severity to an error, you run the report rule
check HRC7 -help command, you will still get the (default) severity of Warning.
To change the severity of the rule handling in the HDL Rule Manager, use the following
procedure in Setup mode and before you read in the library, designs, and SDC files, do the
following:
1. Click to select a rule check number.
2. Right-click and choose Severity and select Warning, Error, Note, or Ignore from the
pop-up menu:
Note: Conformal does not report rules with a severity of Ignore as violations.
Use the SET RULE HANDLING command to exclude specified entities (for example, a
specified module) from rule checking.
Use the SET RULE FILTER command to filter out rules that occur in modules outside the
root hierarchy.
Use the ADD IGNORE RTLCHECK command to ignore HDL (RTL) rule checking for all or
specified modules. By default, rule checking is enabled. Thus, you will only use the DELETE
IGNORE RTLCHECK command to reverse the effects of the ADD IGNORE RTLCHECK
command.
read rule check -exclude <filename> command to exclude the violations already
flagged.
Alternatively, you can use the HDL Rule Manager to report individual rules and violations. To
view a report for a particular rule check message, use the following procedure:
1. Click to select a rule check number.
2. Right-click and choose Report and one of the following from the pop-up menu:
❑ Summary—Displays total number of occurrences for the selected rule check.
❑ Verbose—Displays the rule check message, the total number of occurrences, and
the severity level for the selected rule check.
Some messages can be further expanded to show where they are located in the library or
design.
Modeling Messages
Modeling messages indicate any modeling warnings encountered during the analysis and
modeling of the design. Each modeling message is prefixed by F* because they require a
flattened design.
You can view a summary or expanded report of all rule violations with one of the following
commands:
■ report messages -modeling -verbose
■ report messages -modeling -summary
To view information for a specific message, use the HELP command followed by the message
name.
HELp [message_name]
For example:
help F1
To view all rule check messages, use the HELP command with the -message option:
help -message
You can view all the modeling rule check messages and their details in the Reference
Guide, or type ‘help <rule>’ at the command line.
6
Using the Setup Mode
■ Overview on page 94
■ Setting Options on page 94
■ Reading in Libraries and Designs on page 103
■ Design Constraints on page 115
■ Flattening Options on page 137
Overview
The Conformal software has two operating modes, Setup and LEC. After startup, the
Conformal software begins operation in the Setup mode, as indicated by the SETUP> prompt
in the command entry window. In the Setup mode, you can read in the library and design,
apply constraints, and set up options for verification.
Setting Options
The following sections describe the settings you can apply before reading in the library and
design files.
■ Change the Severity of Rule Checks
See Chapter 5, “Managing Rule Checks” for more information.
■ Specify Case Sensitivity
Use the SET CASE SENSITIVITY command to specify whether any names you use are
case-sensitive. The system default is no case sensitivity.
■ Specify Directives Handling
Use the SET DIRECTIVE command to specify whether to enable or disable the effects
of all or specified vendor directives when reading in Verilog or VHDL files.
To see a list of the supported vendor names and directives, and information on enabling
and disabling these directives, see the SET DIRECTIVE command in the Conformal
Equivalence Checking Reference Manual, or type help set directive
-verbose in the command line.
■ Specify Text Handling Rules
Use the SET NAMING RULE command to specify special text handling rules, such as
hierarchical separators, tristate naming rules, register naming rules, array delimiters,
instance names, or variable names. This command has no effect unless you use it
before reading in Verilog and VHDL design files.
■ Set Undefined Cells
All referenced modules must be either defined or blackboxed. When Conformal finds an
undefined cell, it reports an error. To prevent an error, choose to blackbox undefined cells
using the SET UNDEFINED CELL command.
Note: For information on replacing blackboxed modules with synthesized modules, see
the WRITE BLACKBOX WRAPPER or SUBSTITUTE BLACKBOX WRAPPER commands.
Alternatively, you can open this form from the main window (Setup – Root Module).
The current root module is displayed in the Golden Module and Revised Module fields.
To manually specify a new root module, double-click a module name in the Golden Module
or Revised Module list to add the root module in the field above the list and click OK.
To alphabetically sort the Golden Module and Revised Module list boxes, right-click in the
appropriate column and choose Sort from the pop-up menu.
To add a design search path, click the Design tab. To add a library search path, click the
Library tab.
Pathname Specifies the search path. You can type the directory path
or click Browse to locate the path.
Add Adds the directory path to the list in the Pathname list
box. Use the pull-down window to select Both, Golden,
or Revised design type.
The ADD NOTRANSLATE MODULES command is applied during initial parsing, so name
matching applies only to original module names. For parameterized or VHDL generic
modules whose names are determined and applied by Conformal after parsing and
preprocessing, you must use the ADD BLACK BOX command.
Alternatively, you can use the Notranslate Module form (Setup – Notranslate Module)
before reading designs or libraries to add and delete design or library modules that will not
be translated.
To delete one or all notranslate modules from designs and libraries, click a module name in
the list box in the Design or Library page, and right click to open the pop-up menu and
choose Delete Notranslate Module to delete a single notranslate module, and Delete All
Notranslate Module to delete all notranslate modules.
Undefined Cell Specifies handling for any undefined cell the Conformal
software encounters when reading designs and libraries.
Click the pull-down menu to choose either Error or Black
Box. Based on your selection, Conformal automatically
reports undefined cells as errors, or it blackboxes them.
Undriven Signal Specifies handling for any undriven signal the Conformal
software might encounter when reading designs and
libraries. Click the pull-down menu to choose 0, 1, X, or Z.
Undefined Port Specifies handling for any undefined port the Conformal
software might encounter when reading designs and
libraries. Click the pull-down menu to choose either Error
or Ignore.
Wire Resolution Specifies how the Conformal software treats the output
behavior of multi-driven nets. Click the pull-down menu to
choose either And or Or.
Array Delimiter Specifies the array delimiter rule for reading in a Verilog
RTL or hierarchical design.
Tristate Specifies the tristate rule for reading in a Verilog RTL or
hierarchical design.
Register Specifies the register rule for reading in a Verilog RTL or
hierarchical design.
Hierarchical Separator Specifies the hierarchical separator rule for reading in a
Verilog RTL or hierarchical design.
Cpu Limit Specifies CPU time limit for the Conformal equivalence
checking compare effort. Type a positive integer to
change the CPU time, and click on the pull-down menu to
choose Minutes, Hours, or Days.
Compare Effort Specifies the amount of effort equivalency checking
applies for a particular gate. Click the pull-down menu to
choose Low, Medium, or High.
Mapping Method (name) Specifies the mapping method for names. Choose one of
the following (to a certain degree, the mapping method
operates under the following modes.)
■ Name First—Conformal first maps the key points
with the paths of the gates, then uses the mapping
algorithm to map the rest of the key points.
■ Name Only—only maps the key points based on the
paths of the gates.
■ Name Guide—Conformal first maps key points with
a mapping algorithm, then maps the rest of the key
points based on paths of the gates.
■ Name None— will not map key points based on the
paths of the gates. If the mapping algorithm cannot
map a key point, it remains unmapped.
Mapping Method (phase) In the On position, Conformal maps key points with an
inverted phase. Inverted-phase compared points can
either be Inverted-equivalent or Non-equivalent.
Mapping Method (sensitive) In the On position, Conformal maps key points with
case-sensitive key point names.
Case Sensitive On specifies that names you use are case-sensitive.
Directive On enables the effects of Synopsys and Conformal
synthesis directives when reading in a Verilog or VHDL
file.
Dofile Abort Specifies how Conformal responds when executing a
dofile that generates an error message. Choose one of
the following:
■ On—The dofile terminates when an error message
occurs.
■ Off—The dofile continues even if an error message
occurs.
■ Exit—Conformal exits the session and returns to the
system prompt if an error message occurs.
Latch Folding In the On position, Conformal converts two latches in a
simple LSSD format into a single DFF gate.
Sequential Merging In the On position, Conformal merges common groups of
sequential elements into one sequential element in the
clock cone of a DFF or D-latch.
Pin Keep In the On position, Conformal retains all of the gate pin
information for gate reporting. Use this option when
reporting gate information at the design level. It increases
the memory use.
Automatic Mapping In the On position, Conformal automatically maps key
points when you change the system mode from Setup to
LEC.
If there are duplicate modules, Conformal uses the first module found and ignores all others.
However, you can use READ LIBRARY -lastmod to specify that Conformal use the last
module and ignore the earlier ones. The library can also be in the Synopsys Liberty format.
Note: For RTL to gate formal equivalence checking, use simulation libraries instead of
synthesis libraries because design verification sign-off happens for simulation libraries—not
for synthesis libraries.
Cadence recommends that you use one of the following methods to read in multiple library
files.
Method 1:
List all of the library files after the READ LIBRARY command explicitly or using wildcards, as
shown in the following syntax. Use the backslash character (\) at the end of a line to show that
the command you are typing continues on the next line.
read library file1.v file2.v file3.v... \
-verilog -Golden
Or
read library lib/*.v -verilog -Golden
Method 2:
1. Create a file containing all of the necessary library files. For example, a file called
verilog_all.v might contain the following:
`include "file1.v"
`include "file2.v"
`include "file3.v"
2. Append the name of this newly created file to the READ LIBRARY command:
read library verilog_all.v -verilog -Golden
Method 3:
Writing Libraries
After you read in a library, Conformal can write it out in Verilog format. This command is useful
for learning how Conformal parses User-Defined Primitive (UDP) library models. To write out
the library, use the WRITE LIBRARY command.
Use the Read Library form to specify library filenames you will include with a design.
➤ Choose File – Read Library.
File List Lists the library files that the Conformal Equivalence
Checker reads in for this session. As you build the list of
files, the Conformal Equivalence Checker adds them to
this display.
You can also delete files from this list by right-clicking
and choosing Delete from the pop-up menu to delete
the selected files. Or, right-click and choose Delete All
to remove all the files from the File list.
File Selection Specifies one or more library files. Double-click file
folders in the Directories display to specify the location
of the library files.
From the Files list box, select the files you want to read
and click Add Selected to add the selected files, or click
Add All to add all the files in the Files list box
List Files of Type Filters the file type display.
Format Specifies the format of the library you intend to read. You
can use the pull-down menu to choose a format.
Type Specifies the library type. You can choose Golden,
Revised, or Both.
Verbose Displays the verbose messages for parsing and
translating each library module.
Case Sensitive Specifies that the Conformal Equivalence Checker
should handle the library as case sensitive.
Note: This option is not available for VHDL.
Extraction Specifies that the Conformal Equivalence Checker is to
abstract transistor models into gate models.
State Table Specifies that the library contains Synopsys Liberty state
tables. Conformal can handle state tables that have
single asynchronous inputs and no overlapping rule
outputs. This option is only available when selecting
Liberty from the Format pull-down menu.
Define Specifies the text macro name you want to define. For
Verilog formats, enter your Verilog `ifdef macro in this
field.
The supported design formats are Verilog, Verilog2K, SystemVerilog, VHDL, SPICE, EDIF
and NDL (LSI Logic’s netlist format). When you must replace a design, use READ DESIGN
-replace. If Conformal finds multiple modules with the same name, it uses the first module
and ignores later modules with that name. You can use READ DESIGN -lastmod to specify
that Conformal use the last module and ignore the earlier ones.
If your design contains mixed languages, use READ DESIGN -noelaborate, as shown in
the following example:
read design sub1.vhdl -vhdl -mapfile lib1 lib/pkg1.vhd -Golden -noelaborate
read design sub2.vhdl -vhdl -mapfile lib2 lib/pkg2.vhd -Golden -noelaborate
read design top.v -verilog -Golden
Please refer to “VHDL Support” on page 381 and proper library mapping setup for the READ
DESIGN command. Library in this context refers to the technology library, such as ASIC cell
and memory definitions. See READ DESIGN for information on reading VHDL libraries and
packages
Cadence recommends that you use one of the following methods to read multiple design files
of the same language.
Method 1:
Explicitly list all of the design files after the READ DESIGN command or use wildcards, as
shown in the following syntax. Use the backslash character (\) at the end of a line to show that
the command you are typing continues on the next line.
read design file1.v file2.v file3.v... \
-verilog -Golden
Or
read design src/*.v -verilog
Method 2:
1. Create a file that contains all of the necessary design files. For example, a file called
Golden.v might contain the following:
`include "file1.v"
`include "file2.v"
`include "file3.v"
2. Append the name of this newly created file to the READ DESIGN command as shown
below.
read design Golden.v -verilog
Writing Designs
Use the WRITE DESIGN command after you read in a design to write it out in Verilog format.
This feature is useful for learning how Conformal parses RTL or transistor-based designs.
Use the Read Design form to specify the design filenames the Conformal software reads in
as the Golden and Revised designs.
➤ Choose File – Read Design.
File List Lists the design files that the Conformal Equivalence
Checker reads in for this session. As you build the list of
files, the Conformal Equivalence Checker adds them to
this display.
You can also delete files from this list by right-clicking
and choosing Delete from the pop-up menu to delete
the selected files. Or, right-click and choose Delete All
to remove all the files from the File list.
File Selection Specifies one or more design files. Double-click file
folders in the Directories display to specify the location
of the library files.
From the Files list box, select the files you want to read
and click Add Selected to add the selected files, or click
Add All to add all the files in the Files list box
List Files of Type Filters the file type display.
Format Specifies the format of the library you intend to read. You
can use the pull-down menu to choose a format.
When selecting VHDL, the bottom portion of the form
expands. See Specifying Design Options for VHDL
Designs on page 111 for more information.
When selecting EDIF, the bottom portion of the form
expands. See Specifying Design Options for EDIF
Designs on page 112 for more information.
Type Specifies the design type. You can choose Golden,
Revised, or Both.
Root Module Designates a root module other than the top module.
Click the check box and type the name of the intended
top root module in the field.
Note: If a single top-level module exists, by default,
Conformal uses it. However, if multiple top-level modules
exist, Conformal specifies one. Use this option to change
that specification.
Verbose Displays the verbose messages for parsing and
translating each module in the design.
If the design format is VHDL, the bottom portion of the form expands.
Add Map Entry Opens the Add Vhdl Library Mapping window where you
can select the library name and path of the specific
VHDL libraries.
Add Map File Entry Opens the Add Vhdl Library Mapfile window where you
can specify exactly which files belong to a given library.
f the design format is EDIF, the bottom portion of the form expands.
EDIF Net Name Type EDIF Net Names in the Supply 1 and Supply 0
fields to assign a value of 1 or 0 to specified variables.
And in the current working directory, there is a Golden and Revised directory with a gate
netlist in each:
$CWD/Golden/Golden.v
$CWD/revised/revised.v
Golden.vc:
-y /user/library/verilog
Golden/Golden.v
revised.vc:
-y /user/library/verilog
revised/revised.v
2. Run the READ DESIGN command with the -file option to read in the designs and
libraries without using the READ LIBRARY command. (See the following examples.)
read design -file Golden.vc -verilog -Golden
read design -file revised.vc -verilog -revised
Conformal uses the specified library directory to locate the modules needed in the
design.
See Chapter 10, “Hierarchical Module Comparison Window” for additional information.
Comparing Libraries
In addition to comparing design hierarchies, the WRITE HIER_COMPARE DOFILE command
compares two libraries, such as Liberty and Verilog libraries. The sample dofile below does
the following:
■ Reads in a synthesis library and simulation library
■ Writes out all of the library models
■ Compares the libraries
read design syn.lib -liberty -Golden
read design simulation.v -verilog -revised
Design Constraints
After Conformal successfully reads the designs and libraries, you can place constraints on
the designs to exclude sections of a design from verification, specify behavior and
relationships, and constrain internal nets, instances, and feedback.
The following sections show procedures that are commonly used to set constraints.
Blackboxes
When running the Conformal software, there are several ways to blackbox a module in
Conformal:
Note: Although the internal logic within a blackbox is not compared, the connections feeding
in and out of the blackbox is still verified.
■ Use the ADD NOTRANSLATE MODULE command
This command is run before running the READ DESIGN and READ LIBRARY commands.
It instructs Conformal to blackbox the specified module(s).
With this command, the actual code of the module is not parsed; only the directions for
the input and output ports are parsed and used for the blackbox. As a result, it requires
less memory in Conformal to process blackboxes. Typically, RAMs and ROMs are
blackboxed this way because it would require too much memory in Conformal to process
them for comparison. Analog blocks are also blackboxed this way because the code is
not synthesizable.
For more information on this method of adding blackboxes, see Adding Notranslate
Modules on page 98.
■ Use the ADD BLACK BOX command
This command is used to blackbox a module after the module has already been read in,
and is often used in hierarchical comparison.
For more information on adding blackboxes with this command, see Adding a Blackbox
Instance or Module on page 117.
■ Use the SET UNDEFINED CELL -black_box command
With both ADD NOTRANSLATE MODULE and ADD BLACK BOX, the code for the modules,
or a dummy module with port declarations, are required for the commands to work. If a
module does not exist, you can use SET UNDEFINED CELL -black_box to instruct
Conformal to treat any missing references as blackboxes. Like ADD NOTRANSLATE
MODULE, this command must be run before running the READ DESIGN and READ
Regardless of how blackboxes are created, the number of the blackboxes must match
between the Golden and Revised designs for Conformal to perform the comparison correctly.
Running the REPORT BLACK BOX command shows whether the blackboxes are paired up
properly. The following shows an example of a set of balanced blackboxes:
SETUP> report black box
SYSTEM: (G R) ram8x1024
SYSTEM: (G R) rom8x256
If the blackboxes are not balanced, you might see the following:
SETUP> report black box
SYSTEM: (G R) ram8x1024
SYSTEM: (G) rom_wrapper
SYSTEM: (R) rom8x256
In this case, you can check to see how the blackboxes are constructed by running the REPORT
BLACK BOX command with the -detail option.
in addition to the blackbox modules matching up, the blackbox input and output pins must also
match up for the comparison to work properly. You can run the REPORT MAPPED POINTS
command to check if the blackbox pin names got changed. For example:
report mapped points bbox_u1 -input -output
By default, blackboxes are mapped by their module names. To map by instance names
instead, use the SET MAPPING METHOD -nobbox_name_match command.
If blackbox pins are not paired up correctly because pin names got changed, you can use the
ADD RENAMING RULE command to rename those pins. For example:
add renaming rule ... -pin -bbox ...
To treat any module or instance as a blackbox, use the ADD BLACK BOX command.
Module U1
Module U2 Module U3
Instance Instance
I2 I1
Module U4
Alternatively, you can use the Hierarchical Browser in the main window.
The Black Box menu option adds or deletes instances or modules as blackboxes in the
Hierarchical Browser window display. The Black Box icon appears or disappears,
accordingly.
Use the DELETE BLACK BOX command, or use the following procedure in the Hierarchical
Browser window:
1. Click a blackbox instance or module to select it.
2. Right-click and choose Delete Black Box and Instance or Module from the pop-up
menu.
The blackbox icon will disappear.
Net Constraints
To add one-hot or one-cold constraints to specified net paths, use the ADD NET
CONSTRAINTS command. You can delete either the Golden or Revised design net constraints
that are added with this command using the DELETE NET CONSTRAINTS command.
Use the REPORT NET CONSTRAINTS command to display a list of all added net constraints
Pin Constraints
To add a constraint, such as Logic-0 or Logic-1, to the primary inputs, use the ADD PIN
CONSTRAINTS command.
Module TOP
IN2
SCAN_EN 0 0
To delete pin constraints to primary input pins, use the DELETE PIN CONSTRAINTS
Command.
Alternatively, you can use the Pin Constraints form from the main window to add and delete
pin constraints to primary input pins.
➤ Choose Setup – Pin Constraints.
The Pin Constraints window includes two tabs: Golden and Revised. Click on the Golden or
Revised tab to switch between the two lists.
For each list there are four columns with the headings: Pin, 0, 1, and
GROUPING_CONSTRAINT. The primary input list is shown in the Pin column. Each
primary input is either a system class primary input (S: name) or a user-defined class primary
input (U: name).
In the following procedures, you are asked to select primary inputs. Use any of the following
procedures to select primary inputs:
■ Click a primary input to select it.
■ Click and drag the mouse over a group of adjacent primary inputs to select them.
■ Click the first primary input in a group, press and hold the Shift key, and click the final
primary input in a group to select the entire group.
■ Press the Ctrl-key and click a primary input to add it to the selected group.
The following procedures explain how to add and delete pin constraints.
Use the following procedure to add a constraint to a single primary input using the Pin
Constraints form:
1. In the Pin column, click a primary input to select it.
2. Right-click and choose the Constraint 0 or Constraint 1 constraint from the pop-up
menu.
The selected primary input appears in the appropriate column.
Use the following procedure to add a constraint to a group of primary inputs using the Pin
Constraints form:
1. In the Pin column, select multiple pins with one of the methods described in “Selecting
Primary Inputs” on page 120.
2. Right-click to open the pop-up menu and choose a constraint.
Use the following procedure to delete one or all constraints using the Pin Constraints form:
1. Click a primary input in the 0, 1, or GROUPING_CONSTRAINT column to select it.
2. Right-click and choose one of the following from the pop-up menu:
To delete a constraint from the selected pin, choose Delete Pin Constraint. Conformal
removes the pin constraint. And in the case of GROUPING_CONSTRAINT, Conformal
deletes the entire group.
To delete all constraints, choose Delete All Pin Constraints. Conformal deletes all
constraints from all columns.
Pin Equivalences
To create equivalences or inverted equivalences among primary inputs, use the ADD PIN
EQUIVALENCES command.
Note: If you use the -both option, every primary input pin you list must exist in both designs
(Golden and Revised). If they do not, Conformal returns an error message.
Golden Re
Module U1 Module DFF
U1
CLK CLK
U2 DFF
U2
CLK1
To delete the added pin equivalences from the specified primary input pin that were placed
on primary input pins, use the DELETE PIN EQUIVALENCES command.
Alternatively, you can use the Pin Equivalences form from the main window to add and delete
pin equivalences.
The primary input lists for each of the Golden and the Revised designs are displayed in their
respective columns. Conformal displays added pin equivalences below the target primary
input with a connecting line. Inverted pin equivalences are denoted with (-) following the
primary input name.
To alphabetically sort the primary input lists by column, right-click in the column you want to
sort and choose Sort from the pop-up menu.
Primary Inputs
To add additional primary inputs to corresponding nets, use the ADD PRIMARY INPUT
command.
Module
net1
net
IN1
DFF DFF
IN2
IN3
To delete specified primary inputs that were originally added, use the DELETE PRIMARY
INPUTS command. After you delete the primary input pins from either the Golden or Revised
design, the associated nets become floating nets, unless there are other net drivers.
Alternatively, you can use the Primary Input menu from the main window to add and delete
primary inputs.
Choosing Primary Input – Add opens a dialog box instructing you to use the Hierarchical
Browser window to add primary inputs. You must use the Hierarchical Browser window
because primary inputs are added to hierarchical net names and, for a hierarchical design, it
is not possible to list all hierarchical net names from the root module.
To open the Add Primary Input form to add primary inputs to net names from the Hierarchical
Browser window, do the following:
1. Click an object to select it.
2. Right-click to open the pop-up menu and choose Add Primary Input.
3. Click on the Net or Pin tab to view a list of all of the net or pin names in the design.
4. Double-click a net (or pin) name to show the name in the Net (or Pin) field.
5. Click the Cut check box to specify if the other drivers of the net are to be disconnected
so that the new added primary input is the only driver of the net.
The default is Cut.
6. Click Add.
Conformal adds the primary input to the net and appends (added cut) to the name in
the Add Primary Input window. This notation means a primary input that is the only driver
to the net. Otherwise, Conformal appends (added nocut) to the name to mean a
primary input has been added.
To alphabetically sort a Net or Pin list, right-click in the list display area to open the pop-up
menu and choose Sort.
Use the Delete Primary Input form to delete user-defined primary inputs.
➤ Choose Setup – Primary Input – Delete.
Conformal displays the primary input list for each of the Golden and Revised designs in the
left and right columns. Each primary input is either a system class primary input (S: name) or
a user-defined class primary input (U: name).
Important
The class cyclic field adjacent to the Net field automatically displays whether the
selected primary input is a system or user-defined primary input. You can only delete
user-defined primary inputs
To delete a single user-defined primary input, double-click a user-defined (U) primary input
and click Delete.
To delete all user-defined primary inputs, right-click in one of the columns to open the pop-up
menu and choose Delete All – User.
To alphabetically sort the primary input lists, right-click in either column and choose Sort from
the pop-up menu.
Primary Outputs
To add additional primary outputs to corresponding nets, use the ADD PRIMARY OUTPUT
command.
Modul
net
net
2
DFF DFF
PO
PO
To delete specified primary outputs that were originally added, use the DELETE PRIMARY
OUTPUTS command. When you delete the primary output pins from the Golden or Revised
design, the nets become floating nets, unless there are other net drivers.
Alternatively, you can use the Primary Output menu from the main window to add and delete
primary outputs.
Choosing Primary Output – Add opens a dialog box instructing you to use the Hierarchical
Browser window to add primary outputs. You must use the Hierarchical Browser window
because outputs are added to hierarchical net names and, for a hierarchical design, it is not
possible to list all hierarchical net names from the root module.
To open the Add Primary Output form to add primary inputs to net names from the
Hierarchical Browser window, do the following:
1. Click an object to select it.
2. Right-click to open the pop-up menu and choose Add Primary Output.
3. Click on the Net or Pin tab to view a list of all of the net or pin names in the design.
4. Double-click a net (or pin) name to show the name in the Net (or Pin) field.
5. Click the Add button.
(added) appears following the name.
To alphabetically sort a Net or Pin list, right-click in the list display area to open the pop-up
menu and choose Sort.
Use the Delete Primary Output form to delete user-defined (U) primary outputs.
Conformal displays the primary output list for the Golden and Revised designs in the
respective columns. Each primary output is either a system class primary output (S: name)
or a user-defined class primary output (U: name).
Important
The class button adjacent to the Net field automatically displays whether the
primary output is a system or user-defined primary output. You can only delete a
user-defined primary output.
To delete a single user-defined primary output, double-click a user-defined (U) primary input
and click Delete.
To delete all user-defined primary outputs, right-click in one of the columns to open the pop-
up menu and choose Delete All – User.
To alphabetically sort the primary output lists, right-click in either column and choose Sort
from the pop-up menu.
Use the REPORT PRIMARY OUTPUTS command, or use the Primary Outputs Report form
(Report – Primary Outputs) to display primary output pins from the Golden and Revised
designs. You can open this form in two ways from the main window.
Tied Signals
To tie any floating nets or pins to Logic-0 or Logic-1, use the ADD TIED SIGNALS command.
Module
0 PO
vd
IN 1
1
0
To delete specified tied signals from the Golden or Revised design, use the DELETE TIED
SIGNALS command.
Alternatively, you can use the Tied Signals form from the main window to add and delete tied
signals to floating nets and pins.
Click the Golden or Revised tab to switch between the two lists. For each list there is a
Module Name, Net or Pin, 0, and 1 column.
The names of all of the design’s modules are displayed in the Module Name list box. Click
the Net or Pin tab to display all of the selected module’s floating nets or pins.
Use the following procedure to delete a tied signal from a net or pin.
1. Double-click a module name.
2. Click on the Net or Pin tab.
3. Click the net or pin name in the 0 or 1 column.
4. Right-click to open the pop-up menu and choose Delete Tied Signal.
Use the following procedure to delete all System or User tied signals from nets or pins.
1. Click on the Golden or Revised tab.
2. Right-click in the 0 or 1 column to open the pop-up menu and choose Delete All – User
or Delete All – System.
To alphabetically sort the lists in all columns of this window, right-click in any column and
choose Sort from the pop-up menu.
Instance Constraints
To constrain any internal DFF or DLAT output to Logic-0 or Logic-1, use the ADD INSTANCE
CONSTRAINTS command.
Module TOP
U3
U4
U1
U2
0
Use the DELETE INSTANCE CONSTRAINTS command to delete instance constraints that
were added. Use the REPORT INSTANCE CONSTRAINTS command to display a list of all
added instance constraints.
Instance Equivalences
The ADD INSTANCE EQUIVALENCES command to specify internal equivalence or inverted
equivalence between DFFs or D-Latches.
Note: This command affects comparisons when you use add compared points -all.
In that situation, Conformal merges the instances specified with the ADD INSTANCE
EQUIVALENCES command, and then it verifies them at the end of the comparison.
Golden R
U1
U1
PO
PO
U2
Use the DELETE INSTANCE EQUIVALENCES command to delete instance equivalences that
were added. Use the REPORT INSTANCE EQUIVALENCES command to display a list of all
added instance equivalences.
Cut Points
To specify the cut points for breaking combinational feedback loops, use the ADD CUT POINT
command. If you do not use this command and combinational feedback loops exist,
Conformal automatically cuts the loops when you exit the Setup mode.
Module
net1
Use the DELETE CUT POINT command to delete cut points that were added.
Alternatively, you can use the Cut Point menu from the main window to add and delete cut
points. Cut Point has the following submenus:
■ Adding Cut Points on page 134
■ Deleting Cut Points on page 136
Primary Output is a menu item on the Setup drop-down men. This section explains the
submenu choices for Primary Output.
Choosing Cut Point – Add opens a dialog box instructing you to use the Hierarchical
Browser window to add cut points. You must use the Hierarchical Browser window because
cut points are added to hierarchical net names and, for a hierarchical design, it is not possible
to list all hierarchical net names from the root module.
To open the Add Cut Point form to add user-defined cut points to net and pin names to break
combinational feedback paths, do the following:
3. Click on the Net or Pin tab to view a list of all of the net or pin names in the modules you
selected from the Hierarchical Browser.
4. Double-click a net or pin name.
The name appears in the Net or Pin field.
5. Click Add.
Conformal affixes added to the net or pin name to show that a cut gate will be added to
break the combinational feedback path.
You can alphabetically sort a net or pin list by doing the following:
1. Click the Net or Pin tab.
2. Right-click in the list display area and choose Sort from the pop-up menu.
Use the Delete Cut Point form to delete user-defined cut points that were established to cut
combinational feedback paths.
➤ Choose Setup – Cut Point – Delete.
To delete a cut point, double-click a user-defined (U) primary input and click Delete.
To delete all cut points, right-click in one of the columns to open the pop-up menu and choose
Delete All.
To alphabetically sort net names, right-click in either column and choose Sort from the pop-
up menu.
Flattening Options
The SET FLATTEN MODEL command allows you to specify certain conditions for flattening
the circuit. This section includes flattening information to help you tailor the command for your
designs.
Alternatively, you can use the Flatten Model form to set some of the options described here.
For a description of the form, see Flatten Model Form on page 144.
U1
U1 D
D DLAT U2
CLK
DFF
CLK DLAT
Golden Revised
U0 U1
U1
DFF DLAT DFF
1’b1
SETUP> set flatten model -latch_transparent
To convert a DFF or DLAT to a ZERO/ONE gate if the data port is set to 0/1, use the SET
FLATTEN MODEL command with the -seq_constant option.
Golden Revised
U1 1’b1
1’b1 out1
out1
DFF
CLK
in1
in1
To remodels registers that also have feedback to constants, use the SET FLATTEN MODEL
command with the -seq_constant_feedback option. This is also enabled by default when
you select the -seq_constant option. Once the flop is set at ZERO it will remain ZERO.
in0
in1
Res
To optimize a flop to a constant value (either zero or one) when the flop is always in a don’t
care (X) state, use the SET FLATTEN MODEL command with the -seq_constant_x_to
option.
Note: Use this in conjunction with the -seq_constant option.
Tip
The -seq_constant_x_to switch can trigger the following modeling messages:
F18: Converted DFF/DLAT(s) to ZERO/ONE
F34: Convert X assignment(s) as don’t care(s)
For example, the following figure illustrates a Golden and Revised version of a circuit when
using this switch. The Golden circuit has a flop where its output Q is feedback to its input D
and its asynchronous set and reset are disabled.
out1
D
CLK
Gated-Clock Learning
When clock gating styles are causing problems during a comparison, you can use gated-
clock learning to remodel the gated-clock logic during flattening.
You can use the -gated_clock and -gated_clock_latch_free options of the SET
FLATTEN MODEL to remodel these types of gating during flattening.
During flattening, Conformal will model the latch-based clock gating structure into a MUX-
DFF feedback type circuit.
For example:
After enabling gated-clock learning, the latch-based gated clock is remodeled as follows:
To remodel latch-free clock gating, you must specify that the enable signals for the clock
gating circuits are stable with respect to the clocks. This can be done automatically using the
-gated_clock_latch_free option of the SET FLATTEN MODEL command, or manually
using the ADD CLOCK command.
Note: For the latch-free clock gating modeling to be valid, the enable signals must be stable.
You can verify this using external circuits that are outside of the design, but that are also
subject to LEC verification.
To transform latch-free clock gating into a MUX-DFF-feedback type circuit, use the SET
FLATTEN MODEL’s -gated_clock_latch_free and -gated_clock options (they
must be used together).
You can also transform latch-free clock gating into a MUX-DFF-feedback type circuit by
explicitly specifying the clocks. For example:
SETUP> add clock 0 clk -revised
SETUP> set flatten model -gated_clock
By doing this, the tool assumes that the enable signal is stable with respect to the clock
specified in the ADD CLOCK command.
In this example, the clk value holds the clock signal (low/high) when inactive and allows for
a gated clock transformation into a MUX-feedback type circuit.
Golden Revised
U1 U1
D
D DFF
DFF
enable clk
enable
clk
Golden Revised
U U
D
D DLA
DFF 1’b0
1’b0
To convert a DFF to a DLAT when there is a direct feedback loop from the Q port of the DFF
to its D port, use the SET FLATTEN MODEL command with the -DFF_TO_DLAT_FEEDBACK
option.
Golden Revised
U1 U1
DFF DLA
clk 1’b0
To use a DLAT to model a combinational loop, you can use the SET FLATTEN MODEL
command with the -loop_as_dlat option.
Mapping Settings
When you move from the Setup system mode to the LEC system mode, Conformal
automatically maps the key points with the name-first default mapping method. Before you
exit the Setup mode, you can use the SET MAPPING METHOD command to change the
default settings and specify the following:
■ Mapping Method—If the Golden and Revised designs have the same names, change the
mapping method to name-only. This option makes mapping more efficient and less time
consuming.
■ Mapping Phase—You can specify inverted phase mapping.
Note: When using the SET MAPPING METHOD -phase command, the Conformal
software compares the set logic of the Golden design to the reset logic of the Revised
design (and vice-versa) for inverted-equivalence.
■ Case Sensitivity—The default is no case sensitivity. Conformal considers key point
names case-sensitive, if you prefer.
■ Unreachable Points—If you want Conformal to map unreachable points, use the
-unreach option. If you do not want to report unreachable points, use the
-noreport_unreach option.
■ Name Effort—You can specify the amount of effort you want Conformal to apply to key
point mapping. The system default level is hi, which eliminates the need for simple
renaming rules.
Note: This option applies to DFFs and DLATs.
■ Blackboxes—You can specify mapping for blackboxes based on instance name matches
(by default, Conformal maps blackboxes if both the module names and instance names
match).
Mapping Methods
Conformal employs three name-based methods to map key points and one no-name method.
If most of the key point names in the Golden and Revised designs are the same, choose a
name-based mapping method. This method is useful for gate-to-gate comparisons when
small changes have been made to the logic. Conversely, the no-name-mapping method is
useful when Conformal must map designs with completely different names. By default,
Conformal automatically maps key points with the name-first mapping method when it exits
the Setup mode.
In addition to the name-first method, Conformal includes two other name-based methods:
name-guide and name-only. Use the name-only and name-first methods when the Golden
and Revised designs have the same names. (This approach speeds up mapping.) And create
naming rules to help Conformal during mapping when corresponding key points have
different names. (See “Renaming Rules” on page 147.) Any key points that Conformal does
not map are classified as unmapped points.
Name-First Mapping
For the name-first mapping method, which is the default, the Conformal software maps key
points in two steps.
1. When the names are the same in the Golden and Revised designs.
Any key points that remain unmapped after the second step are identified as unmapped
points.
Name-Guide Mapping
For the name-guide mapping method, the Conformal software also maps key points in two
steps.
1. Maps key points with a mapping algorithm.
2. Attempts to map remaining key points by matching names in the Golden and Revised
designs.
Any key points that remain unmapped after the second step are identified as unmapped
points.
Name-Only Mapping
When using the name-only mapping method, Conformal maps key points only if the names
are the same in the Golden and Revised designs. Any key points that do not have the same
name are identified as unmapped points.
No-Name Mapping
When using the no-name-mapping method, Conformal relies solely on the mapping algorithm
to map key points. Any remaining key points are identified as unmapped points.
Renaming Rules
When the naming conventions in the Golden and Revised designs are not the same, augment
the name-based mapping methods described above by introducing naming rules. These
rules are a way to translate key point names. When you use the ADD RENAMING RULE
command, you identify string patterns and define temporary substitute string patterns, thus
enabling Conformal to automatically map additional key points when names are not the same.
The ADD RENAMING RULE command lets you include or exclude particular types of key
points for renaming. Additionally, you can apply renaming rules to module names when you
use the ADD RENAMING RULE command. Use this command before you use the READ
LIBRARY and READ DESIGN commands.
Alternatively, you can use the Renaming Rule form (Setup – Renaming Rule), to add or
delete renaming rules to guide mapping, help map modules for hierarchical comparisons, or
rename pin names of blackboxes.
You can also use the TEST RENAMING RULE command (see Testing Renaming Rules on
page 151) or the Renaming Rule form to test renaming rules for mapping performance based
on name mapping.
The Renaming Rule window includes a Renaming Rule and Test Renaming Rule sections
and three pages:
■ Map for renaming rules that apply to key point mapping.
■ Module for renaming rules that apply to module renaming when the library and design
are read in
■ Pin for renaming rules that apply to pin names of blackboxes.
Most of the fields and options are the same for the Map, Module, and Pin pages, except
where noted in the following descriptions:
Tip
You can also right-click on a rule to open the
pop-up menu where you can delete the selected
or all renaming rules.
■ Both (the default) - Applies the renaming rule to both
the Golden and Revised designs. You can use this
pull-down menu to select Golden to apply the
renaming rule to the Golden designs, or Revised to
apply the renaming rule to the Revised designs.
Black Box (for the Pin page) Applies a renaming rule to a specified blackbox module.
Rule Name Specifies a unique rule name.
From Specifies the renaming pattern.
To Specifies the substitution pattern.
After adding renaming rules, you can use bottom part of the form to check their effectiveness.
See the ADD RENAMING RULE command for the following information:
■ The structure of renaming rules
■ Keywords that require escape characters
■ Sample expression pattern matching and substitution strings
You can specify a set of naming rules of each read design or read library session. For
example, if you ran the following command for VHDL as rule 1:
set naming rule "%L.%s" "%L[%d].%s" "%s" -variable
read design -vhdl <all the vhdl design> -noelab
When running the commands, rule 1 can apply to the VHDL designs and rule 2 can apply to
the Verilog designs.
Use the REPORT RENAMING RULE command or the Renaming Rule Report form (Report –
Renaming Rule) to display the list of renaming rules for mapping, module, and pin renaming.
The list displays a rule number along with a renaming rule. If you do not enter options, the
Conformal software displays all renaming rules.
Use the TEST RENAMING RULE command to test specific or all renaming rules before you
add them. Other uses for this command follow:
■ Use this command to apply a new or existing rule without committing to it.
■ Apply a renaming rule to a sample or the entire design to see how Conformal matches
the key points.
■ Get a summary or complete listing of the design’s key point pairs, groups, and singles.
This feature is effective only when balanced modeling is enabled, for example, with the setting
SET FLATTEN MODEL -SEQ_CONST.
During the flattening process, LEC reports the renaming rule analysis. For example:
// Command: set system mode lec
// Renaming Rule Analysis (DFF/DLATs)
============================================================
Rule Matches(G) Matches(R) Mapped %
------------------------------------------------------------
0 0
r1 20 0 20 80
============================================================
// Balanced modeling (auto) mapped 21 out of 25 DFF/DLATs
You can use the REPORT RENAMING RULE command to view the added rules.
7
Using the LEC Mode
To switch system modes, use the SET SYSTEM MODE command. When you exit the Setup
system mode, Conformal automatically flattens the designs and maps key points between the
Golden and Revised designs. However, when you use the -nomap option, you prevent
Conformal from automatically mapping key points on entering the LEC mode.
In the LEC mode, you can view warning messages and compare and debug a design. This
chapter describes the commands that allow you to choose verification options and run the
verification.
Mapping Modifications
On entering the LEC system mode, you might find you need to make modifications to improve
mapping results. If the results are not satisfactory (that is, Conformal did not map a high
percentage of key points) you can change the mapping method (see Mapping Settings on
page 145) and introduce renaming rules (see Renaming Rules on page 147). The following
information guides you as you remap key points, manually add mapped points, and save
mapping results for future sessions.
IN1 IN1
IN1 PO1
CLK CLK
DFF PO1 PO1
CLK Unmapped Points
Revised
SCAN_IN1 Extra
SCAN_EN Extra
Revised
IN1
DFF PO1
MUX
SCAN_IN1
SCAN_OUT1
SCAN_EN
CLK
or
...
set flatten model -nomap
set system mode lec
read map point <map_file>
...
Compare Options
Conformal can compare all mapped points or a sub-set of mapped points. The comparison
tells whether key points are equivalent or non-equivalent. Compared points are:
■ Primary Outputs
■ D Flip-Flops (DFFs)
■ D-Latches (DLATs)
■ RAMs
■ Blackboxes
■ Cut Gates that were identified as mapped points
You must enable this feature before starting a comparison; otherwise, Conformal does not
record any information. For example:
command> compare
command> report compare time -enable
command> compare
command> report compare time
In this example, Conformal records the CPU time for the second comparison only.
Note: Conformal does not record compare time for trivial cones.
Comparison
To start the comparison, use the COMPARE command.
Reporting Statistics
The REPORT STATISTICS command summarizes the mapping and compare statistics.
Report Verification
Conformal can report a table of all violated checklist items for the following categories:
1. Non-standard modeling options used
2. Incomplete verification
3. Design modifications
4. Conformal recommended extended checks
5. Design ambiguity
Use the REPORT VERIFICATION command to run the report. You can prints out each
category and the count of violations, or print out all items for each category where the violated
items are marked with an asterisk (*).
The Report menu and Report form contains the following categories:
■ Black Boxes Report on page 160
■ Cut Points Report on page 160
■ Design Data Report on page 161
■ Environment Report on page 161
■ Floating Signals Report on page 161
■ Instance Constraints Report on page 162
■ Instance Equivalences Report on page 162
■ Messages Report on page 162
■ Modules Report on page 163
■ Notranslate Modules Report on page 164
■ Pin Constraints Report on page 164
■ Pin Equivalences Report on page 165
■ Primary Inputs Report on page 165
■ Primary Outputs Report on page 165
■ Renaming Rules Report on page 166
■ Search Paths Report on page 166
■ Tied Signals Report on page 166
■ Mapped Points Report on page 167
■ Unmapped Points Report on page 167
■ Compared Points Report on page 167
■ Compare Data Report on page 167
Golden Module Name Specifies the module name for the Golden design.
Revised Module Name Specifies the module name for the Revised design.
Extra Reports the extra input, output, or I/O pins for pair-able
modules between the Golden and Revised designs.
Choose Input for input pins, Output for output pins, or
Inout for inout pins.
Key Point Reports the total one-to-one mapped state points.
Note: If you use this with Verbose, Conformal reports all
one-to-one mapped state points.
Summary Summarizes the design data.
Verbose Verbose reports a detailed list of the design data.
Environment Report
Use the REPORT ENVIRONMENT command or the Environment Report form (Report –
Environment) to display global settings for the designs and system settings.
There are no customized options for the Environment Report form. Click Apply to view the
report in the Transcript window.
There are no customized options for the Instance Constraints Report form. Click Apply to
view the report in the Transcript window.
There are no customized options for the Instance Equivalences Report form. Click Apply to
view the report in the Transcript window.
Messages Report
When you exit Setup system mode, there can be summary warning messages related to
modeling the Golden or Revised designs, mapping key points, or comparing. Use the REPORT
MESSAGES command or the Messages Report form (Report – Messages) to report a
detailed, or verbose, listing of the warning messages.
Conformal inserts CUT gates to break combinational feedback paths. Then, it displays a
summary warning message during flattening and modeling to tell how many CUT gates were
inserted. Display the feedback paths of all CUT gates using the REPORT PATH command with
the -feedback option. Also use this command to display the path between two key points.
Modules Report
Use the REPORT MODULES command or the Modules Report form (Report – Modules) to
display the module hierarchy for the design.
Golden Module Name Specifies the module name for the Golden design.
Revised Module Name Specifies the module name for the Revised design.
Source Displays the source-code information identifying where
the module is located.
Library Displays all of the library cells that are in the module
hierarchy.
There are no customized options for the Modules Report form. Click Apply to view the report
in the Transcript window.
Golden Module Name Specifies the module name for the Golden design.
Revised Module Name Specifies the module name for the Revised design.
Design Specifies the design to display the pin constraints.
Choose Revised, Golden, or Both (the default).
All Displays pin constraints in all modules (within the given
defaults).
Root Displays the pin constraints from the root module.
Inverted pin equivalences are distinguished by a “-” next to the primary input pin name.
Golden Module Name Specifies the module name for the Golden design.
Revised Module Name Specifies the module name for the Revised design.
Design Specifies the design to display the pin equivalences.
Choose Revised, Golden, or Both (the default).
All Displays pin equivalences in all modules (within the
given defaults).
Root Displays the pin equivalences from the root module.
There are no customized options for the Primary Inputs Report form. Click Apply to view the
report in the Transcript window.
There are no customized options for the Primary Outputs Report form. Click Apply to view
the report in the Transcript window.
There are no customized options for the Search Path Report. Click Apply to view the report
in the Transcript window.
Signal Net displays net names that have tied signals assigned
to them, Pin pin names that have tied signals assigned
to them, and All displays net and instance names that
have tied signals assigned to them (within the given
defaults).
Class Full (the default) displays tied signals from both the User
and System classes. System displays tied signals from
the original design. User displays tied signals added
with the Conformal software.
Design Specifies the design to display the tied signals. Choose
Revised, Golden, or Both (the default).
Statistics Report
Use the REPORT STATISTICS command or the Statistics Report form (Report – Statistics)
to display the mapping and comparison statistics for the Golden and Revised designs.
There are no customized options for the Statistics Report. Click Apply to display the Statistics
Report in the Transcript window.
8
Debugging
Use the command with the -summary option to display a diagnosis summary table listing all
of the non-equivalent points. The summary table helps you determine which non-equivalent
point has the smallest cone size. You can then use this information to diagnose the non-
equivalent point that has the smallest cone size first and work through non-equivalent points
by degrees of complexity.
Note: Conformal automatically assigns ID numbers. They can differ from one version to
another. Always use the full path in dofiles and when you rerun a design with a different
Conformal version.
In many cases, multiple non-equivalences are due to the same error. For example, an error
in a clock gating circuit can cause all DFFs driven by the same clock gating circuit to be non-
equivalent. As another example, a wrong keypoint mapping can cause multiple frontier
keypoints of the same wrong mapping to be non-equivalent. In these cases, diagnosing the
entire group of non-equivalences simultaneously can better reveal the single root cause of
the non-equivalences.
Use the -group option of the DIAGNOSE command to group non-equivalences that are likely
caused by the same error. For example:
diagnose -noneq -group
analyzes all the non-equivalences and reports groups with more than one non-equivalence.
Since the non-equivalences in the same group are caused by the same error, you can focus
on the one with the smallest logic cone to diagnose. The following sample report groups the
key points by non-equivalences, common supports, and common test vectors:
The non-equivalences are sorted by support size, in increasing order. By default, non-
equivalences are grouped together if they share a common support or test vector. You can
specify more stricter conditions for grouping. For example, you can require that the non-
equivalences in one group have at least 5 common supports:
diagnose -noneq -group -common_support 5
The common test vectors are ordered according to the number of non-equivalences they
cause, where the vector that causes the most non-equivalences is shown first.
You can also use -group option on specific keypoint. For example, the following reports the
group that contains the compare point 14:
diagnose 14 -group
In multipoint diagnosis, test vectors are ordered so that you can identify patterns that can help
diagnose the causing issue. The following are examples of the test vector patterns for non-
equivalences.
Test vectors contain only patterns of a, b non- equivalence. The output values are also
inverted when a, b change from 01 to 10.
■ Sequential constant
The following illustrates the test vector ordering for a non-equivalence caused by a
sequential constant issue. Specifically, the Golden key points have non-corresponding
DFF supports, and some pattern of these non-corresponding supports is missing in all
test vectors.
0: 11101110 01 Dddd0
1: 11011110 01 Ddd0d
2: 11101110 11 Dddd0
3: 11011110 11 Ddd0d
4: 11101110 10 0ddd0
5: 11011110 10 0dd0d
6: 11001110 01 Ddd00
7: 11001110 11 Ddd00
8: 11001110 10 0dd00
^^ (non corresponding supports that can be sequential
constant 00)
For the above example, pattern 00 is missing, which is the value that these DFFs become
after sequential constant propagation.
■ Sequential merge
The following illustrates the test vector ordering for a non-equivalence caused by a
sequential merge issue. Specifically, both Golden and Revised key points have non-
corresponding DFF supports. The all 0 or all 1 patterns of the non-corresponding DFF
supports are missing from the test vectors.
0: 10000000000000000000000000000000 1 dddddddddddd1ddddddddddddddddddd
1: 01000000000000000000000000000000 1 dddddddddddddddddddddddddddd1ddd
2: 11000000000000000000000000000000 1 dddddddddddd1ddddddddddddddd1ddd
3: 11100000000000000000000000000000 0 0000000000D0D000000000000000D000
4: 11010000000000000000000000000000 0 000000000000D0000000D0000000D000
5: 11001000000000000000000000000000 0 000000000000D000000000000000D0D0
......
In the above example, Golden has 32 DFFs that should be merged, which are shown as
the first 32 supports. These DFFs directly feed to POs, which are proven non-equivalent.
The last support shown is the Revised non-corresponding support. The error happens
when Golden DFFs are taken at different values from the Revised support.
Proving Equivalence
Another command that is useful for debugging is the PROVE command. This command
checks for equivalence and shows whether the specified gates from the Golden or Revised
designs are equivalent or non-equivalent. Use the ADD DYNAMIC CONSTRAINTS command
to specify constraints you want to use during the proof.
Use the following command to check equivalency for one of the following pairs:
■ One gate in each of the Golden and Revised designs
Tip
If you intend to use the schematic viewer to aid diagnosis, you must start it while
Conformal is in GUI mode. If the current session is in non-GUI mode, use the SET
GUI command.
The Conformal software can help increase design similarity with features such as datapath
analysis and functional partitioning. Designers can also increase design similarity with RTL
recoding techniques, such as parenthesizing adder trees or avoiding coding with don't cares.
You can also increase design similarity by re-synthesizing the netlist.
Use the REPORT DESIGN SIMILARITY command to report the degree of similarity between
two designs. Design similarity reflects the complexity of comparison and it can be used to
measure the effectiveness of methods used to increase design similarity. The value of
similarity ranges from 0% to 100%, and is obtained by measuring the number of
corresponding points in the two designs.
For example, if aborts occur when comparing two designs, RTL1 and GATE1, you can run the
REPORT DESIGN SIMILARITY command to get a report that shows that the GATE1 netlist
has a structure that is possibly very different from RTL1, which could possibly cause aborts.
=============================================================
Similarity Region (Golden)
30% (root module)
=============================================================
Then you can run several commands, such as ANALYZE DATAPATH or the automatic abort
resolution ANALYZE ABORT command.
Run the REPORT DESIGN SIMILARITY command again after these commands to see if the
design similarity has been increased. If the aborts remain, you could consider recoding the
RTL or resynthesize the netlist to increase the similarity between the designs. The design
similarity can be reported any time to track the progress.
Gate Manager
Use the Gate Manager (Tools – Gate Manager) to help you diagnose and debug your
designs. You can also access this form from the Mapping Manager, Diagnosis Manager, and
Schematic Viewer. See the sections on the related integrated debugging tools for more
information.
The Gate Manager includes two columns in each of the major sections. The left column
contains Golden design information and the right column contains Revised design
information.
For the Gate Manager, see the following for more information:
■ Gate Manager Fields and Options on page 178
■ Refreshing the Window on page 179
■ Opening Schematics from the Gate Manager on page 179
■ Using the Preferences Drop-Down Menu on page 179
■ Filtering the Gate List on page 180
■ Finding Gates on page 181
■ Reporting Gate Information on page 182
■ Customizing the Gate List Section with Specified Gates on page 182
■ Proving Equivalency for Two Specified Gates on page 182
■ Removing Gates from the Prove List on page 183
■ Locating an Equivalent Gate on page 183
■ Adding and Deleting Dynamic Constraints on page 183
■ Locating a Gate in the Design Hierarchy on page 184
■ Highlighting a Point in the Hierarchical Browser on page 184
■ Viewing a Gate’s Location in the Source Code on page 185
■ Highlighting a Point in the Source Code Manager on page 185
■ Viewing a Schematic Representation of One Gate on page 185
■ Gate Reporting on page 186
Equivalent Point After you have run the COMPARE command, Conformal
can display the corresponding equivalent gate of a
specified gate in this section.
Dynamic Constraint When you add a dynamic constraint to any gate in the
Fanins or Fanouts sections of the Gate Manager,
Conformal lists the gates in this section.
This procedure lets you display specified sections of the Gate Manager.
1. Click the Preferences button located on the menu bar.
2. Click the check boxes to display only the sections you specify.
By default, Conformal displays all inverters and buffers in fan-in and fan-out cones at the
primitive level. Use the following steps to change the preferences to exclude inverters and
buffers from the display and change the number of displayed levels in fan-in and fan-out
cones.
1. Click the Preferences button located on the menu bar.
2. Click Options.
The Gate Manager Display Option window appears.
3. Click the Collapse Internal Buffers check box according to your preferences.
4. Click the Collapse Internal Inverters check box according to your preferences.
5. Click in the Fanin/Fanout Expand Level field and type a number, or click the adjacent
up- or down-arrow to specify the number of levels Conformal automatically displays in the
fan-in and fan-out cones.
You can also manually expand and collapse the levels by clicking on the + and - markers.
6. Click Apply.
7. Click Close.
Use the following procedure to filter the display of gate IDs that match a specified
string.
Note: Conformal supports wildcards. For example, type *35* to display all points
that include 35 in their name or gate ID.
The section-specific filter window opens, for example, Filter: Gate List (Golden).
Finding Gates
Use the following procedure to locate gate IDs based on a search string.
1. Click the Find icon button located in the upper right corner of the appropriate section, or
press Ctrl-f. The section-specific Find window opens, for example, Find: Gate List
(Golden).
2. Type any string or partial string of a key point name in the Find field.
3. Click the Find Forward or Find Backward check box to specify the direction of the
search.
4. Click the Case Sensitive check box, if applicable.
5. Click the Find button to search for the name.
6. Repeat step 5 to find the next point that fulfills the search criteria.
Use the following procedure to filter out categories of gates from the Gate List
section of the Gate Manager, and then report on gates from the shortened list.
1. Click the Class icon located at the top right corner of the Gate List section of the
window.
2. From the drop-down menu, choose the types of gates you want to view.
For example, All, PI, 0, 1, X, Z, and so forth.
1. Click a gate in the Golden column in Fanins, Fanouts, or Gate List to select it:
2. Right-click and choose Add Prove List from the pop-up menu.
Conformal adds the gate to the Prove List section in the appropriate column.
3. Repeat steps 1 and 2 for a second gate in the Revised column.
4. Click the Prove button located in the upper right corner of the Prove List section.
Conformal runs the PROVE command for the specified gates and prints the proof result
in the status field at the top of the Prove List section and in the Transcript window of the
main window.
Do the following to remove all gates from the Prove List section.
➤ Click the X icon located in the upper right corner of the Prove List section.
Tip
Begin this procedure with the main window open on the desktop and the Gate
Manager active.
1. Click to select a point in Gate List, Fanins, or Fanouts:
2. Using the middle mouse button, click and drag the selected point from the Gate Manager
to the main window.
When you click with the middle button, the Gate Manager displays the name of the point
you clicked in an ivory text box. As you move the box to the new window, the background
of the text box changes if the object is in a window where you can drop items.
3. Release the middle button, and the Hierarchical Browser window scrolls to and highlights
the applicable line of code.
Tip
Begin this procedure with the Source Code Manager open and the Gate Manager
active.
1. Click a point in the Gate List, Fanins, or Fanouts section.
2. Using the middle mouse button, click and drag the selected point from the Gate Manager
to the Source Code Manager.
When you click with the middle button, the Gate Manager displays the name of the point
you clicked in an ivory text box. As you move the box to the new window, the background
of the text box changes if the object is in a window where you can drop items.
3. Release the middle button, and the Source Code Manager scrolls to and highlights the
applicable line of code.
Gate Reporting
Use the REPORT GATE command report the gate ID, type, name, and its fanins and fan-outs
at the primitive level. For information the structure of the gate report information at the
primitive level, see Gate Report Structure on page 186.
Use the REPORT ENVIRONMENT command to display the gate report level settings.
Gate Tracing
The BACKWARD and FORWARD commands allow you to back trace and forward trace a gate.
These commands show the fan-in and fan-out cones of a gate’s inputs and outputs. The
integer further specifies the trace; for example, backward 1 denotes the first fan-in.
The structure of the gate report information at the design level is as follows:
Mapping Manager
Use the Mapping Manager as a gateway to the integrated debugging environment. The
Mapping Manager serves several functions:
■ Displays the unmapped, mapped, sequential merge, and compared points
■ Adds and deletes mapped and compared points accordingly
■ Compares key points
The Mapping Manager includes two columns in each of the major sections. The left column
contains Golden design information and the right column contains Revised design
information.
For the Mapping Manager, see the following for more information:
■ Mapping Manager Fields and Options on page 191
■ Setting Preferences on page 193
■ Copying Information from the Mapping Manager on page 193
■ Selecting Points on page 193
■ Adding Unmapped Points as Mapped Points on page 194
■ Reporting Information on an Unreachable Gate on page 194
■ Reporting Renaming Rules on page 195
■ Re-Mapping Key Points on page 195
■ Adding All Compared Points on page 195
■ Deleting One or More Mapped Points on page 195
■ Adding One or More Compared Points on page 196
■ Changing the Mapping Phase of a Mapped Point on page 196
■ Highlighting a Mapped Point in the Compared Points Section on page 196
■ Comparing Key Points on page 197
■ Deleting One or More Compared Points on page 197
■ Diagnosing a Non-Equivalent Point in the Compared Points Section on page 197
■ Sorting Compared Points by Support Size on page 198
■ Sorting Compared Points by Non-Corresponding Support Cones on page 198
■ Changing the Mapping Phase of a Compared Point on page 198
■ Highlighting a Compared Point in the Mapped Points Section on page 198
■ Displaying the Information Box on page 199
■ Filtering the Display on page 199
■ Finding Key Points on page 200
■ Displaying Specified Classes of Points on page 200
■ Deleting Mapped or Compared Points on page 201
■ Displaying Diagnosis Data on page 201
Extra
Unreachable
Not-mapped
■ Mapped Points—Lists all of the mapped points in the Golden and Revised designs.
When you select a mapped point in one of the columns, Conformal highlights its
corresponding mapped point in the adjacent column.
■ Compared Points—Lists all of the compared points from the Golden and Revised
designs. Additionally, when you click a point, Conformal displays the status and support
size in the text fields at the top of the Compared Points section. The status of the
compared points is one of the following:
Equivalent
Inverted-Equivalent
Different
Abort
Not-Compared
Split status indicators are for top-level sequential merge instances. The left side shows the
design-level compare result. The right side shows any sequential merge results:
Note: A compared point can have an S to indicate that it is a sequential merge—in that
registers merge to it.
Tip
Conformal displays a red circle or a green circle to show whether points are
equivalent or different.
Setting Preferences
Click the Preferences pull-down menu on the menu bar to specify the following viewing
preferences:
Selecting Points
In the following text, when you are directed to select one or more points, you can do any of
the following:
■ Click a point to select it.
■ Click the first point in a group, depress and hold the Shift key, and click the final point in
a group to select the entire group.
■ Depress the Ctrl-key and click a point to add it to the selected group.
To manually map points in the Unmapped Points section, click a point to select it and press
one of the following keys:
Key Function
t Sets the selected Golden or Revised point as the target mapping point.
n Makes a corresponding mapped point in the adjacent column a non-inverted
mapping point.
i Makes a corresponding mapped point in the adjacent column an inverted
mapping point.
2. Right-click and choose Report Unreachable Info from the pop-up menu.
➤ Click the Re-map icon located in the upper right corner of the Mapped
Points section to run the MAP KEY POINTS command.
When you add compared points, they appear in the Compared Points section.
A question mark (?) next to these points means that Conformal has not
compared them.
➤ Click the Add icon located in the upper right corner of the Mapped Points section.
Use the following shortcut procedure to invert the mapping phase of a specified point.
1. Click a point to select it.
2. Press c on the keyboard.
When you click with the middle button, the selected point is displayed in an ivory text box.
As you move the point to the Compared Points section, the background of the text box
changes if the object is in a window where you can drop items.
3. Release the middle button.
Conformal scrolls the Compared Points section to and highlights the selected point.
➤ Click the Compare icon located in the upper right corner of the
Compared Points section.
When the comparison is complete, the equivalent compared points are marked with
a green circle or a green check, according to your specifications. (See “Pass/Fail
Icon Style” on page 239.) The non-equivalent compared points are marked with a
red circle or red X.
Tip
See Diagnosis Manager on page 205 for additional information about using this
integrated tool.
Use the following procedure in the Unmapped Points, Mapped Points, and
Compared Points sections to display points that match a specified string.
Conformal bases the filter on instance names, gate type, and gate IDs.
Note: Conformal supports wildcards. For example, type *17* to display all points
that include 17 in either their name or gate ID.
Tip
To find a single point, refer to Finding Key Points on page 200“.
Note: If you click the Refresh button on the menu bar of the Mapping Manager, the original
unfiltered display returns.
1. Click the Find icon button located in the upper right corner of the appropriate section, or
press Ctrl-f. The section-specific Find window opens (for example, Find: mapped
points).
2. Type any string or partial string of a key point name in the Find field.
3. Click the Find Forward or Find Backward check box to specify the direction of the
search.
4. Click the Case Sensitive check box, if applicable.
5. Click the Find button to search for the name.
6. Repeat step 5 to find the next point that fulfills the search criteria.
1. Click the Class icon located in the upper right corner of the Unmapped Points or
Compared Points section.
2. Choose one or more classes for the Unmapped Points or Compared Points section.
Do the following to clear the Mapped Points or Compared Points display. When
you clear the Compared Points section, Conformal removes the points. However,
when you clear the Mapped Points section, Conformal moves points to the
Unmapped Points section.
➤ Click the X icon located in the upper right corner of the Mapped Points section or the
Compared Points section.
Tip
Begin the following procedure with the Gate Manager open and the Mapping
Manager active.
1. Click a point in the Unmapped Points, Mapped Points, or Compared Points section
of the Mapping Manager:
2. Using the middle mouse button, click and drag the point from the Mapping Manager to
the Gate Manager (Fanins or Fanouts section).
When you click with the middle button, the name of the point you clicked is displayed in
an ivory text box. As you move the point to the new window, the background of the text
box changes if the object is in a window where you can drop items.
3. Release the middle button, and the Gate Manager refreshes the Fanins and Fanouts
sections accordingly.
Tip
From the Source Code Manager, you can open an editor.
Use the following procedure to find a mapped or compared point in the Source Code
Manager.
Tip
Begin this procedure with the Source Code Manager open and the Mapping
Manager active.
Use the following procedure in the Unmapped Points, Mapped Points, or Compared
Points section of the Mapping Manager to locate and highlight a specified point in the
schematic. This feature also works in the reverse drag-and-drop order (drag from the
Flattened Schematics window to a section in the Mapping Manager).
Tip
Begin this procedure with the schematic viewer open and the Mapping Manager
active.
1. In the Mapping Manager, click and hold the middle mouse button over a point in the
Unmapped Points, Mapped Points, or Compared Points section.
2. Drag the point from the Mapping Manager to the Flattened Schematic window.
When you click with the middle button, the Mapping Manager displays the name of the
point you clicked in an ivory text box. As you move the point to the new window, the
background of the text box changes to black if the object is in a window where you can
drop items.
3. Release the middle mouse button, and the point is highlighted in the Flattened
Schematic window.
Diagnosis Manager
Use the Diagnosis Manager to display the error patterns and error candidates for non-
equivalent points. Additionally, it lists the corresponding and non-corresponding support
points in the logic fan-in cone for both the Golden and Revised designs. Error patterns can
be written as a testbench for simulation on another tester.
To access the Diagnosis Manager for a non-equivalent point, right click on the non-equivalent
point from the Compared Points section of the Mapping Manager and click on Diagnose. Or,
Choose Tools – Diagnosis Manager. See Diagnosing a Non-Equivalent Point in the
Compared Points Section on page 197 for additional details about how to get to the Diagnosis
Manager.
The Diagnosis Manager includes two columns in each section. The left column contains
Golden design information and the right column contains Revised design information.
You can obtain a quick summary about a compared point by hovering over it.
For the Diagnosis Manager, see the following for more information:
■ Diagnosis Manager Fields and Options on page 207
■ Setting Preferences on page 210
■ Copying Information from the Diagnosis Manager on page 212
■ Refreshing the Window on page 212
■ Displaying the Information Box on page 212
■ Selecting a New Active Diagnosis Point on page 212
■ Changing the Simulation Value on page 212
■ Saving Modified Values as an Error Pattern on page 213
■ Viewing a Schematic on page 213
■ Changing the Mapping Phase of a Mapped Point on page 214
■ Deleting Mapped Points on page 214
■ Reporting Renaming Rules on page 215
■ Adding Unmapped Points as Mapped Points on page 215
■ Viewing a Schematic Representation of Diagnosis Points on page 215
Compare Point Displays the non-equivalent point that was selected for
diagnosis for both the Golden and Revised designs. You
will have selected this point from the Compared Points
section of the Mapping Manager.
Diagnosis Point (active) Displays the point at which the equivalency check failed.
It displays the compare point for both the Golden and
Revised designs. A simulation value is shown in
parentheses ( ). If there is no simulation value,
Conformal displays a (-).
For inverted-mapped points, (+/-) indicates the mapping
phase.
For DLATs where there is feedback interaction between
the Q outputs and input cone, (X/Y) indicates the current
state and the next state. The first value (X) represents
the current state of the DLAT, the second value (Y)
represents the next state of the DLAT. For example, (0/1)
indicates that the DLAT currently has a value of 0 at its Q
output. After feeding in all of the test vectors from its
support points, the DLAT will have a value of 1 at its Q
output for the next state.
Diagnosis Points (inputs) Lists all of the fan-in diagnosis points for the compare
point.
For inverted-mapped points, (+/-) indicates the mapping
phase.
In cases where there is more than one diagnosis point,
double click on a point to make it the active diagnosis
point.
Corresponding Support Displays the simulation values with all of the mapped
Non-corresponding Support points that are in the fan-in cone of the diagnosis point.
Both the Golden and Revised designs are represented.
To change the simulation value, right-click on the
mapped point and use the pop-up menu.
By default, support points are color coded as. See
Support Points on page 209.
For inverted-mapped points, (+/-) indicates the mapping
phase
For more information on corresponding and non-
corresponding support points, see Figure 8-2 on
page 210.
Error Pattern Displays all of the test vectors that prove the diagnosis
point to be non-equivalent. If the bit is 0 in all error
patterns, the point is highlighted in green. If the bit is 1 in
all error patterns, it is highlighted in red. When you select
a support point, Conformal applies a pink highlight to the
associated column in the test vector set.
You can also select the following options to filter the
column display.
■ All 0s – displays the bit(s) that are 0 in all error
patterns.
Use the p keyboard stroke to move the highlight to
the next column of 0 in all error patterns; or the n key
to move to the previous column of all 0.
■ All 1s – displays the bit(s) that are 1 in all error
patterns.
Use the p keyboard stroke to move the highlight to
the next column of 1 in all error patterns; or the n key
to move to the previous column of all 1.
Error Candidate Lists the gates in the Revised design with the highest
probability of causing non-equivalence. The list is
ordered from greatest to least probability, and displays a
weighted percentage number displayed in decimal form.
Thus, (1.00) signifies that the gate in the Revised design
has the highest probability of causing non-equivalence.
For a graphic description of corresponding and non-
corresponding support, see Figure 8-2 on page 210.
(Brown) Abort
(Black) The support point either has not been compared yet or cannot be
compared (for example, PI).
(Yellow with an R) The support point is redundant logic associated with a don’t
care gate.
(Yellow with an M) The support point is a mapped point. The point exists for this
logic cone but not its corresponding mapped point.
(Red circle) Support point is an unmapped point
Setting Preferences
Use the following procedures to specify viewing preferences.
To turn on and off sections of the Diagnosis Manage, click the Preferences button on the
menu bar and click the check boxes to select specific sections for the display.
To sort gates alphabetically by name or numerically by ID, click the Preferences button on
the menu bar and choose Sort by Name or Sort by ID.
Use the following procedure to set the text color for equivalent, non-equivalent, and abort
points.
1. Click the Preferences button located on the menu bar.
2. Click Set EQ/NEQ/Abort text color to open the Color Selection window.
3. Click to select an Equivalent, Non-equivalent, or Abort point type in the list box.
4. Click a color on the Color Selection wheel.
5. Repeat steps 3 and 4 if necessary.
6. Click Close.
Viewing a Schematic
In the Diagnosis Manager, use the following procedure to open schematics displaying the
specified points.
1. Click a point in the Diagnosis Points (inputs), Corresponding Support,
Non-corresponding Support, or Error Candidate section.
2. Right-click and choose Schematics from the pop-up menu.
Conformal opens the schematic viewer showing the selected point. In the case of pairs
of points, (Golden and Revised), two schematic viewer windows open for side-by-side
viewing.
You can hover over an object to view more information on it. The information box will also
display information on corresponding points, if applicable.
Error pattern values are not displayed when opening the schematics from these sections. To
view error pattern values, click on the Schematic icon located on the menu bar.
The following table shows the color defaults for the flattened schematic viewer when opening
from the Diagnosis Manager:
Color Description
Purple Gates proven to be equivalent between the Golden or Revised designs.
Red Gate or net that is a potential candidate for an error path, or a trace load
object.
Blue Key point (DFF or DLAT) that needs to be compared. This is typically a
flip-flop or latch.
Yellow Non-corresponding support key point (DFF, DLAT, PI, BBOX or cut
gate), or a trace driver object.
Green Key point (DFF or DLAT) that proves to be a constant zero.
Pink Key point (DFF or DLAT) that proves to be a constant one.
Cyan Gate that drives the input of the compare key point (DFF or DLAT)
The mapped point becomes inverted-mapped. Conformal changes the 1 or 0 in the Revised
column.
Conformal opens a pair of schematic windows showing the Golden and Revised
diagnosis points.
Use the following procedure in the Diagnosis Points (inputs), Corresponding Support,
Non-corresponding Support, or Error Candidate section as a convenient way to locate
and highlight a specified point in the schematic. This feature also works in the reverse drag-
and-drop order (drag from the Flattened Schematics window to the Diagnosis Manager).
1. With the Flattened Schematics window open, click and hold the middle mouse button
over a point in the Diagnosis Manager.
2. Drag the point from the Diagnosis Manager to the Flattened Schematic window.
When you click with the middle button, the Diagnosis Manager displays the name of the
point you clicked in an ivory text box. As you move the point to the new window, the
background of the text box changes to black if the object is in a window where you can
drop items.
3. Release the middle mouse button, and the object is highlighted in the Flattened
Schematic window.
With the Gate Manager open and the Diagnosis Manager active, use this drag-and-drop
procedure to display selected gate information.
1. In the Diagnosis Manager, click a gate to select it.
2. Click and hold the middle mouse button over the selected point.
3. Drag the point from the Diagnosis Manager to the Gate Manager (Fanins or Fanouts
section).
When you click with the middle button, the Diagnosis Manager displays the name of the
selected point in an ivory text box. As you move the point to the new window, the
background of the text box changes to black if the point is in a window where you can
drop items.
4. Release the middle mouse button, and the Gate Manager refreshes the Fanins and
Fanouts sections accordingly.
With the Source Code Manager open and the Diagnosis Manager active, use this drag-and-
drop procedure to locate a key point or error pattern in the Source Code Manager.
1. In the Diagnosis Manager, click a key point or error candidate.
2. Click and hold the middle mouse button over the selected item in the Diagnosis Manager.
3. Drag the item from the Diagnosis Manager to the Source Code Manager.
When you click with the middle button, the Diagnosis Manager displays the name of the
item you selected in an ivory text box. As you move the item to the new window, the
background of the text box changes to black if it is in a window where you can drop items.
4. Release the middle mouse button, and the Source Code Manager scrolls to and
highlights the applicable location in the code.
The exit status code consists of flags that represent different conditions. Bit 0 is the least
significant bit. Refer to the table below for a list of flags. This table is followed by three case
examples of nonzero exit status codes.
Tip
To view the status codes without exiting Conformal, use the SET EXIT CODE
command or the Tcl get_exit_code command. (See the Tcl Command Entry
Mode Support chapter of the Conformal Equivalence Checking Reference
Manual for additional information about Conformal Tcl commands.
Bit Condition
0 Internal Error
1 Exit status before comparison
2 Command error
3 Unmapped points or extra POs
4 Non-equivalent points during comparison
5 Abort or uncompared points exist during any comparisons.
6 Abort or uncompared points exist during the last comparison or hierarchical
comparison.
Note: For bits 0, and 2 through 5, once they are set to 1, they will remain at 1.
Note: For bit 1, once it is set to 0, it will remain at 0.
■ Case 1:
Start Conformal and then exit immediately
Status = 2 (00010 in binary). There are no equivalent points since there was no
comparison. Thus, bit 1 is set.
■ Case 2:
Comparison produced a non-equivalent point, an abort point, and an equivalent point.
Status = 48 (110000 in binary). Bits 4 and 5 are set to flag the abort and non-equivalent
points.
■ Case 3:
Comparison produced all non-equivalent points.
Status = 18 (010010 in binary). Bits 1 and 4 are set to show two conditions: During this
session, Conformal found no equivalent points and the comparison produced non-
equivalent points.
9
Resolving Aborts
Overview
Aborts are compare points that have not been conclusively compared. By the time aborts are
reported, the Conformal software has applied multiple algorithms without a deterministic
result. Aborts can have several causes including don’t cares, large cones, and large numbers
of inputs. Cones with these attributes will result in increased runtime. To deal with extremely
long runtimes, developers have limited the amount of time which the tool can use on a specific
compare point. When the Conformal software exceeds this limit, the compare point will be
reported as an abort. By setting a time limit for each compare point, the Conformal software
avoids the appearance that it is locked up when it is still processing the compare point.
Avoiding Aborts
The best method for handling aborts is to avoid them in the first place. This implies the use
of equivalency checker friendly coding practices and modularization of large cones of logic.
This section offers recommendations on how to avoid aborts.
RTL Guidelines
Coding can have a huge impact on the outcome of a comparison. Don’t cares can add extra
inputs to the cone of logic, doubling the number of vectors for verification with every ’don’t
care’. Resource sharing can merge multiple operators and require the comparison of a huge
cone of logic. Using ungroup in synthesis can create larger blocks to work on. The following
sections identify issues in RTL and synthesis that can cause aborts, with recommendations
on how to handle them.
Hierarchy
Hierarchy creates boundaries for the Conformal software to work with. Creating boundaries
around datapath operators can help simplify the verification task. Placing difficult arithmetic
operators in modules isolates difficult comparisons. By simplifying the verification task,
comparisons will take less time and aborts will be reduced. Do not write too large a Verilog
module or VHDL entity. Attempt to separate the structural code from the behavioral.
Synthesis
Synthesis tools can do special optimizations to achieve timing and area goals. Some of these
optimizations cause problems for equivalency checking. These include ungrouping, inversion
pushing, resource sharing, name changes, and other boundary optimizations.
If possible, avoid ungrouping and inversion pushing. These methods complicate the
verification task and most often do not provide much improvement in quality of results (QoR).
If you plan to use advanced optimization methods, set up your flow to utilize the Module-
Based Datapath (MDP) Flow (see MDP Flow on page 225).
Operator Optimization
Designers often cluster groups of mathematical operators into a single line. This is a fast and
easy coding style.; however, this allows the synthesis engine to merge and combine operators
with no distinguishing factors. This results in huge cones of logic and aborts.
Adding parentheses guides the synthesis tool to group the operators so they can be
distinguished. Assign statements also increase the likelihood of equivalency checking
success. For example:
assign pmo = (((x * y) & mask) + offset);
Golden Revised
By breaking the original lengthy assign statement into multiple statements, the logic cones
are shorter and operator grouping is more easily identifiable. For example:
assign p = (x * y);
assign pm = (p & mask);
assign pmo = (pm + offset);
Golden Revised
Avoid using ’X’ or Don’t care in your RTL code. Setting default values to X, or using Synopsys
full_case and parallel_case, create ’X’ sources and decrease the chance of success.
You will need to find the ’X’ sources in the RTL and modify the code to eliminate them.
Before writing the RTL code, review rule checks reported by the Conformal software that
indicates potential ‘X’ sources in the code. The following shows examples of how these rule
check messages are reported:
■ parallel_case
On lines 8 and 9 (in bold) of the following example, case_items 2'b1? and 2'b?1 match
the case_expression sel when sel is equal to 2'b11.
module test ( a, b, sel, out0);
input a, b;
input [1:0] sel;
output out0;
reg out0;
always @(sel or a or b) begin
casez (sel) //synopsys parallel_case
2'b1? : out0 = a;
2'b?1 : out0 = b;
default: out0 = 1'bx;
endcase
end
endmodule
// Warning: (RTL5.1) Overlapped case items are in parallel case statement (occurrence:1)
directory: parallel_case/
■ full_case
The following example uses the Synopsys full_case directive in line 7 (in bold):
module test ( a, e, sel, out0);
input a, e;
input sel;
output out0;
reg out0;
always @(sel or a or e) begin
case(sel) // synopsys full_case
1'b1 : out0 = a;
default: out0 = e;
endcase
end
endmodule
// Warning: (DIR2.1) full_case directive is detected (occurrence:1)
directory: full_case/
■ x_assignment
In the following example, the design assigns a 1'bx value to output o. See line 6 (in
bold).
module test(o,i);
output o;
reg o;
input i;
always
o = 1'bx;
endmodule
■ range_overflow
The following example uses an index where its right hand side might be out of range. See
line 10 (in bold):
module test (clk, idx, in0, out0);
input clk;
input [3:0] idx;
input [3:0] in0;
output out0;
reg out0;
The following example uses an index where its left hand side might be out of range. See
line 10 (in bold):
module test (clk, idx, in0, out0);
input clk;
input [3:0] idx;
input in0;
output [3:0] out0;
reg [3:0] out0;
MDP Flow
Module-Based Datapath (MDP) analysis performs datapath analysis at a module level and
can be used to resolve aborts. MDP analysis is performed in addition to and prior to the
regular operator level analysis. The goal of this analysis is to improve the quality of the
operator-level analysis. For MDP analysis to be successful, the synthetic datapath module
must be preserved in the netlist. Therefore, ungrouping and boundary optimization must be
disabled during synthesis.
MDP analysis generates an intermediate netlist in DC using the mdp.tcl script, included in
the Conformal software. Providing an intermediate netlist reduces the amount of difference
between the compared designs, thus simplifying the effort level for Conformal and handles
most aborts. This automatically creates an intermediate netlist and a resource file for
advanced datapath analysis.
However, the recommended flow in this chapter does not caution against setting the
synthesis effort level to high when running synthesis. In avoiding aborts, Cadence
recommends keeping the effort levels at their default levels. Using high synthesis efforts uses
more aggressive optimizations and architecture selections that might not be supported by
Conformal’s datapath analysis.
The following is the recommended flow modified with this effort level caution:
read_hdl ...
elaborate ...
read_sdc ...
synthesize -to_generic
//Do not set -effort high. Use the default effort level
synthesize -to_mapped
//Do not set -effort high. Use the default effort level
write_hdl -lec > first_mapped.v
write_do_lec -revised first_mapped.v
//ungroup in any way)
//no more datapath architecture change)
synthesize -incremental (as many times as you wish)
write_hdl > final.v
write_do_lec -revised first_mapped.v -logfile rtl2firstmap.log > rtl2firstmap.do
write_do_lec -Golden first_mapped.v -revised final.v \
-logfile first2finalmap.log > first2finalmap.do
exit
Resolving Aborts
Assuming all the precautions were taken as detailed in Avoiding Aborts on page 222, if aborts
are reported, you should resolve them quickly. 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.
Hierarchical Comparison
Running hierarchical comparison provides a convenient method for handling aborts. To run
hierarchical comparison, run the WRITE HIER_COMPARE DOFILE command to write out a
dofile that compares the design module by module. This dofile compares modules separately
or in groups, depending on tool settings. After each module or module group comparison,
results are recorded, the module is blackboxed, and the next module is processed. This
process continues until all modules are processed.
LEC> compare
================================================================================
Compared points PO DFF Total
--------------------------------------------------------------------------------
Equivalent 196 577 773
--------------------------------------------------------------------------------
Abort 0 23 23
================================================================================
Multithreading
Parallel comparison is best suited for large gate-to-gate comparisons, where the comparison
can be distributed to multiple comparison threads. To possibly resolve more abort points and
reduce the time spent on RTL-to-gate comparisons, the parallel analyze abort feature might
be more effective (see Analyzing Abort Points on page 227).
You can only run multithreaded comparison with the COMPARE command’s -abort_stop
option to stop the comparison after finding the specified number of abort points.
Partitioning
Partitioning can be used to help break down large cones of logic that can result in aborts. You
can do this with the ADD PARTITION POINTS command (see Adding Partition Points on
page 286 for more information)
If manually adding partition points is too difficult, the Conformal software can add functional
partition points on the abort points based on the number of key points for a partition. In the
following example, the software selects four common key points from the abort logic cones
as a partition, then performs 16 comparisons for each bit combination (2n4=16):
...
add compare point -all
compare
usage
run partition_compare -number 4 -verbose
usage
Further investigation to resolve the isolated DP_OP module is necessary, but at least the root
cause of the initial aborts are known. If there are additional abort points reported along with
the aborted DP_OP module, this means that those aborts occur outside the DP_OP module
boundary. Usually, continuing with multithreaded abort analysis will resolve these remaining
aborts.
The following shows the results of running ANALYZE DATAPATH without isolating the abort
modules.
// Command: analyze datapath -module -verbose -resourcefile resourcefile.rpt
// Note: add_5822_DP_OP_308_4437_42 : quality evaluated 100% success
// Note: add_5821_DP_OP_306_4437_41 : quality evaluated 100% success
// Note: add_1055_159_DP_OP_311_2879_8 : quality evaluated 99% success
// Note: add_5823_DP_OP_310_4437_43 : quality evaluated 100% success
// Note: add_5820_DP_OP_304_4437_40 : quality evaluated 100% success
// Note: add_9399_S2_DP_OP_314_2331_11 : quality evaluated 38% success
...
// Command: compare
======================================================================
Compared points PO Total
----------------------------------------------------------------
Equivalent 64 64
----------------------------------------------------------------
Abort 3 3
=======================================================================
The following shows the results of running ANALYZE DATAPATH with isolating the abort
modules.
// Command: analyze datapath -module -verbose -resourcefile resourcefile.rpt \
-isolate_abort_module
// Note: add_5822_DP_OP_308_4437_42 : quality evaluated 100% success
// Note: add_5821_DP_OP_306_4437_41 : quality evaluated 100% success
// Note: add_1055_159_DP_OP_311_2879_8 : quality evaluated 99% success
// Note: add_5823_DP_OP_310_4437_43 : quality evaluated 100% success
// Note: add_5820_DP_OP_304_4437_40 : quality evaluated 100% success
// Note: add_9399_S2_DP_OP_314_2331_11 : quality evaluated 38% success
// Warning: add_9399_S2_DP_OP_314_2331_11 is isolated as an aborted instance.
...
// Command: compare
======================================================================
Compared points PO Total
----------------------------------------------------------------
Equivalent 67 67
======================================================================
Compared results of isolated instances in Revised design (top)
======================================================================
Status Instance (Module)
----------------------------------------------------------------
Abort i5/add_9399_S2_DP_OP_314_2331_11
(NV_GR_PE_STRI_core_add_9399_S2_DP_OP_314_2331_0)
======================================================================
10
Running Hierarchical Comparison
The following figure and example demonstrate how a hierarchical comparison proceeds from
the lower-level modules to the top root module. The following figure illustrates the hierarchical
structures of a Golden and Revised design.
TOP TOP
U3 U4 U3 U4
U1 U2 X Y U1 U2 Z
Golden Revised
The following example lists the events that occur when the Conformal software compares the
two designs. Refer to the figure above as you review this example.
1. Compares U1 Module:
b. Compares U1
b. Compares U2
b. Compares U3
Modules X and Y in the Golden design do not have corresponding modules in the Revised
design. Similarly, module Z in the Revised design does not have a corresponding module in
the Golden design.
In this case, the Conformal software finds correspondence one level higher, at module U4.
The submodules of U4 in both the Golden and Revised designs are flattened during the
comparison at the U4 module level.
1. Compares U4 Module:
b. Compares U4
b. Compares TOP
After generating a dofile, you can dynamically run hierarchical comparison. The following are
the major features of dynamic hierarchical comparison:
■ Dynamic Module Comparison
Automatically flattens the selective modules to propagate the design error (if any) to the
top module. The flattened modules are merged to the next level in the hierarchy and
automatically compared at that level. This feature dynamically determines the modules
that must not be blackboxed for successful hierarchical comparisons.
■ Dynamic Module Selection
Gives you the ability to execute multiple hierarchical runs without regenerating the dofile.
You can generate the dofile only once for the top-level module, and the subsequent
hierarchical comparisons for any specific submodules can be carried out using different
flow-control options. In addition, you can specifically target the aborted or retimed
modules without having to modify the hierarchical compare script or dofile.
■ Demand Driven Module Comparison
Gives you the ability to perform demand driven module comparison, such that only the
un-compared modules will be compared in successive hierarchical runs. In addition, you
can interrupt and continue hierarchical comparison any time.
For the purposes of a hierarchical comparison, you can use a dofile to read the library and
designs, and write the hierarchical compare dofile script to a file.
The following sample dofile writes the hierarchical compare dofile script into a file named
hier_compare.do:
read library lib.v -both
read design Golden.v -verilog -Golden
read design revised.v -verilog -revised
write hier_compare dofile hier_compare.do
Tip
You can also use the Hierarchical Module Comparison window. See Writing the
Hierarchical Compare Dofile to a File on page 246.
Using the procedure outlined above, the Conformal software generates a hierarchical dofile
script named hier_compare.do.
Note: In the following script, the hierarchical comparison first pairs corresponding modules
from the two designs, then compares each of these pairs one at a time in a bottom-up fashion.
set system mode setup
//
// Comparing module ‘U1’
//
set root module U1 -Golden
set root module U1 -revised
report black box -NOHidden
set system mode lec
add compare point -all
compare
save hier_compare result
set system mode setup
add black box U1 -module -Golden
add black box U1 -module -revised
//
// Comparing module ‘U2’
//
set root module U2 -Golden
set root module U2 -revised
report black box -NOHidden
set system mode lec
No Blackboxing
For some designs, you might want to skip comparison at a certain module hierarchy level,
even though the Conformal software can successfully pair the corresponding modules. The
following diagram illustrates one such situation. An explanation follows.
U1 U1
U2 U2
A A
In this example, a portion of the logic (labeled “A”) of module U2 in the Golden design (shown
on the left) was optimized to produce the Revised design. This optimization occurred across
hierarchical boundaries. As a result, logic block “A” is a part of module U1 in the Revised
design.
In conditions such as the one described above, use the ADD NOBLACK BOX command.
Note: You must use the ADD NOBLACK BOX command before the WRITE HIER_COMPARE
DOFILE command, but after the Conformal software reads the designs.
This section illustrates a hierarchical comparison on a design that requires the ADD NOBLACK
BOX command. Using the information above, your dofile should appear as shown in the
following example. Note the proper placement of the ADD NOBLACK BOX command.
Additionally, with the -replace option, the Conformal software replaces the original
hier_compare.do file.
read library lib.v -both
read design Golden.v -verilog -Golden
read design revised.v -verilog -revised
add noblack box U2 -both
write hier_compare dofile hier_compare.do -replace
Constraint Propagation
In a flat comparison, the constraint value on scan_en is automatically propagated throughout
the design. As a result, scan circuitry is correctly isolated from comparison regardless of its
placement in the hierarchy.
Unlike a flat comparison, a hierarchical comparison occurs at the submodule level. Therefore,
you must include all information at the module level.
In the following example, the Conformal software does a hierarchical comparison on two
designs, one without scan and one with scan inserted. The following figure shows a design
with scan inserted:
TOP
U1
scan_en_0
scan_en
scan_en_1
Because the scan circuitry only exists in the Revised design, the comparison is only relevant
for the functional portion of the designs. To place the scan design (Revised) in functional
mode, you must constrain the scan_en pin to logic-0.
In a hierarchical comparison you must use the ADD PIN CONSTRAINT command to
propagate this constraint. Thus, the constraint is available at lower module levels. The
information needed in this case is:
scan_en_0 = scan_en_1 = 0;
The Conformal software stores constraint information in the hierarchical compare dofile.
Generate the dofile by including the -constraint option in the WRITE HIER_COMPARE
DOFILE command as follows:
write hier_compare dofile hier_compare.do-constraint -replace
The resulting hierarchical compare dofile is similar to the one that was shown in Example
hier_compare.do Dofile on page 237. However, constraint information has been added:
…
//
// Comparing module ‘U1’
//
set root module U1 -Golden
In this section you found that the hierarchical comparison required a pin constraint. Using the
information above, your modified dofile should appear as follows:
read library lib.v -both
read design Golden.v -verilog -Golden
read design revised.v -verilog -revised
add pin constraint 0 scan_en -revised
write hier_compare dofile hier_compare.do -constraint -replace
Renaming Rules
When running the WRITE HIER_COMPARE DOFILE command, you might encounter warning
messages related to name mismatches between the Golden and Revised designs. When you
encounter this type of warning message, apply module renaming rules to resolve the
mismatches between the Golden and Revised designs.
In the course of generating a hierarchical compare dofile, the Conformal software attempts to
pair modules from the two designs based on the exact spelling of module names. However,
when synthesis and the backend flow alter module names in the Revised design, the
Conformal software is unable to match some module pairs. For example, a module named
cpu in the Golden design is renamed to cpu_0 and cpu_1 in the Revised design (often, this
renaming is a result of the UNIQUIFY command in synthesis).
Dynamic Comparison
When a hierarchical compare dofile is successfully generated, you can perform dynamic
comparison as follows:
run hier_compare hier_compare.do
If all of the situations presented in this chapter are applied, the final version of the dofile is:
read library lib.v -both
read design Golden.v -verilog -Golden
read design revised.v -verilog -revised
add pin constraint 0 scan_en -revised
add renaming rule hier_rule1 "%s_%d$" "@1" -module -revised
write hier_compare dofile hier_compare.do -constraint -replace
run hier_compare hier_compare.do
Static Comparison
When a hierarchical compare dofile is successfully generated, you can perform static
comparison as follows:
dofile hier_compare.do
If all of the situations presented in this chapter are applied, the final version of the dofile is:
read library lib.v -both
read design Golden.v -verilog -Golden
read design revised.v -verilog -revised
add pin constraint 0 scan_en -revised
add renaming rule hier_rule1 "%s_%d$" "@1" -module -revised
write hier_compare dofile hier_compare.do -constraint -replace
dofile hier_compare.do
The following example shows how the UNIQUIFY command works with hierarchical
comparison:
...
uniquify -all
write hier_compare dofile hier.do
run hier_compare hier.do
In the above command example, running the UNIQUIFY -all command makes all the
hierarchical modules unique in the design. Then running the WRITE HIER_COMPARE
DOFILE command creates a hierarchical dofile script named hier.do containing the
compare script for the submodules and the root module. And finally, hierarchical comparison
is executed using the RUN HIER_COMPARE command. Using UNIQUIFY -all allows you
to maximize the number of submodules written out in the hierarchical dofile hier.do.
Before using the Hierarchical Module Comparison window, modules must be paired through
mapping. If modules are not paired, use the ADD RENAMING RULE command with the
-module switch to remedy this situation. See Renaming Rules on page 241 for more
information about renaming. After you have paired all modules, click the Remap button
located on the menu bar in the main window.
✟ Choose Tools – Hierarchical Compare.
The Hierarchical Module Comparison window includes two columns in the Compare Status
Display. The left column is for the Golden design, and the right column is for the Revised
design.
For the Hierarchical Module Comparison window, see the following for more information:
■ Hierarchical Module Comparison Fields and Options on page 245
■ Setting General Options on page 246
■ Reporting CPU Use on page 246
■ Working with Hierarchical Compare Dofiles on page 246
■ Finding Module Names on page 247
■ Deselecting the Dual Scroll Option on page 247
■ Viewing a Module’s Compare Status on page 247
■ Specifying Blackbox Modules on page 247
■ Deleting Previously Added Blackbox Modules on page 247
■ Ignoring Modules during Comparison on page 248
■ Deleting No-Blackbox Status on page 248
■ Running a Hierarchical Comparison on page 248
■ Comparing Lower-Level Modules on page 248
■ Highlighting Non-Equivalent Modules on page 249
■ Deleting and Resetting Hierarchical Compare Results on page 249
■ Specifying the Root Module on page 249
After you have set the general options, fine-tune your comparison options by typing a dofile
name in the Compare command file field and click the Write button.
To open the LEC File Editing window to edit the Hierarchical Compare Dofile, click Edit in the
Compare command file section.
To run a Hierarchical Compare Dofile, click Run in the Compare command file section.
11
Advanced Capabilities
Overview
Many of today's designs for video, graphics, and DSP require complex datapath structures
with high performance. To satisfy those needs, major synthesis companies have developed
tools that aim directly for datapath modules. Using a traditional equivalence checking method
to verify such designs can often lead to abort points and excessive run times.
Multipliers
Both Conformal L and Conformal XL support multipliers with standard architectures.
However, Conformal XL also supports multipliers implemented with dynamic structures.
Standard Architectures
Requirements
The multiplier module boundary must be kept and the product size must equal the combined
size of the inputs, that is:
Product [N+M-1:0] = In1[N-1:0] * In2[M-1:0]
Procedure
While in LEC mode, analyze the multiplier using the ANALYZE MULTIPLIER command. This
command requires the standard Conformal L licenses. Refer to the Conformal Equivalence
Checking Reference Manual for detailed descriptions of the ANALYZE MULTIPLIER
command and other related commands.
Conformal XL supports multipliers that have been implemented with dynamic structures by
datapath synthesis tools from Synopsys Module Compiler and Cadence RTL Compiler.
Requirements
None
Procedure
While in LEC mode, analyze the datapath using the ANALYZE DATAPATH command. You
must have a Conformal XL license to use this command. Refer to the Conformal
Equivalence Checking Reference Manual for detailed descriptions of the ANALYZE
DATAPATH command and other related commands.
Operator Merging
Conformal XL supports datapath structures with operator merging, which is a method to
implement a combination of two or more arithmetic operators. In the following figure, for
example, an arithmetic expression Y = A * B + C is implemented with a multiplier and an
adder using a standard synthesis tool.
However, when the intermediate A*B result is not required, the datapath synthesis tool (such
as the partition_dp or transform_csa command from Design Compiler XL) can
implement one merged operator for the entire arithmetic expression, as show the following
figure:
Procedure
While in LEC mode, use the ANALYZE DATAPATH option. You must have a Conformal XL
license to use this command. Refer to the Conformal Equivalence Checking Reference
Manual for detailed descriptions of the ANALYZE DATAPATH command and other related
commands.
Resource Sharing
The Conformal software can automatically solve long compare times or aborts caused by
resource sharing with the ANALYZE DATAPATH and SET DATAPATH OPTION commands’
-SHARE option, which applies the resource sharing technique on all multipliers with low
datapath analysis quality. Datapath analysis is performed on new resources created after
sharing.
Module-Based Datapath (MDP) Analysis runs datapath analysis at a module level to help
improve the quality of the operator-level analysis in an effort to reduce the number of potential
abort points. This analysis is run in addition to and prior to the regular operator level analysis,
and only on synthetic modules containing datapath operators in the Revised design netlist.
Note: For MDP analysis to be successful, the synthetic datapath module must be preserved
in the netlist. Therefore, ungrouping and boundary optimization must be disabled during
synthesis.
The first command (datapath abstraction on the revised netlist) can help to improve the quality
of second command (Datapath Operator Learning on the Golden netlist).
The second command (without -MODULE option) performs Datapath Operator Learning on
the Golden RTL design to make it structurally similar to the revised netlist. See “Datapath
Operator Learning” on page 260.
Datapath module abstraction on the revised netlist is applied by using the following command
the dofile:
ANALYZE DATAPATH -MODULE [-RESOURCEFILE <file>] -verbose
The first command (with -MODULE option) performs datapath abstraction on the revised
synthesis netlist. During synthesis, synthesis tools usually group several datapath operators
into a module. The first command replaces the module's gate-level netlist with the
corresponding RTL. As a result, the synthesis netlist is abstracted as RTL and it makes it
easier to perform datapath learning on the Golden netlist.
In order for LEC to apply datapath abstraction on the revised netlist, it needs to follow the
recommendations for the synthesis script. The generated netlist keeps the datapath module
boundary for datapath abstraction.
// Synthesis script for RC:
read_hdl
elaborate
synthesize -to_mapped
write_hdl -lec > first_mapped.v
write_do_lec -revised first_mapped.v
synthesize -incremental
write_hdl > final.v
write_do_lec -Golden first_mapped.v -revised final.v
//Synthesis script for DC:
read_hdl
set compile_report_dp true
set compile_ultra_ungroup_dw false
compile_ultra -no_autoungroup -no_boundary_optimization \
-no_seq_output_inversion
report_resource -hierarchy > resource.rpt
write -format verilog -hierarchy -output first_mapped.v
compile -incremental -map_effort high
write -format verilog -hierarchy -output final.v
The following table outlines recommendations for resolving issues during the synthesis and
verification process to ensure datapath abstraction can be applied successfully.
Scenario Recommendation
Abstraction is not used prior to learning Check dofile
Lack of resource file Check synthesis script
Module cannot be found in the netlist Check synthesis script
Module has no RTL definition Check synthesis script
Module cannot be abstracted due to aborts Isolate abort module
This command abstracts the datapath modules from gate-level into RTL by assuming that
these two models are functionally equivalent. This feature has several advantages:
■ Accurately identifies the verification bottlenecks
■ Prevents module abort effects from propagating to the top-level modules. As a result, you
can verify remaining logics without being stuck at the aborted module.
■ Once the remaining logic is verified, you can focus on the isolated abort module at any
time by using more computing resources and algorithms with higher effort.
The following is an example of a report for the datapath abstraction with an abort module
isolated. One datapath module has been isolated during datapath abstraction, and the
comparison reports that the key points of the design are equivalent with the condition that one
module in the revised netlist has been aborted and isolated.
// Command: analyze datapath -module -isolate_abort_module
// Note: i5/add_3200_DP_OP : quality evaluated 38% success
// Warning: i5/add_3200_DP_OP is isolated as an aborted instance.
// Command: compare
====================================================================
Compared points PO Total
--------------------------------------------------------------------
Equivalent 67 67
====================================================================
Compared results of isolated instances in Revised design (top)
====================================================================
Status Instance (Module)
--------------------------------------------------------------------
Abort i5/add_3200_DP_OP
(mod_add_3200_DP_OP_0)
====================================================================
When there are aborts in datapath abstraction, you can also use the following command to
generate the test case and report to LEC supports.
REPORT TESTCASE -DATAPATH_MODULE -QUALITY 70 -file <filename>
Datapath analysis in LEC has been enhanced for advanced adder tree clusters, complex
multiplier architectures (such as product-of-sum multipliers), and XOR trees.
Datapath learning, through the ANALYZE DATAPATH command, makes the Golden datapath
operators structurally similar to the revised netlist so that comparing the two designs is easier.
The -WORDLEVEL option applies additional analysis that handles advanced datapath
optimizations in the following areas:
■ Complex adder tree clustering: Supports clustering multiple adder trees that share
common sub-expressions, and whose input operand has least-significant-bit (LSB)
truncation.
■ Product-of-sum optimizations: Supports optimization of merging the cluster adder with
the multiplier.
■ Associative Law on multipliers: Supports reordering of the cascaded multipliers based
on associative law.
■ XOR tree optimizations: Supports optimization of reordering XOR tree.
■ Constant multipliers and adder trees optimizations: Supports adder tree optimizations
with input constraints.
You can use the -WORDLEVEL option with the SET DATAPATH OPTION and ANALYZE
DATAPATH commands.
The following is an example of the datapath learning report generated by the ANALYZE
DATAPATH -WORDLEVEL command:
// Command: analyze datapath -wordlevel -verbose
// Note: mult_12: quality evaluated 85% success
// Note: mult_18(pos): quality evaluated 90% success
// Note: add_602_2(clustered): quality evaluated 85% success
The command analyzes the Golden design's datapath operators and merges the cluster
adders with the product-of-sum operators.
When the quality of datapath learning is low, you can improve the quality of datapath learning
by using
■ Datapath abstraction on the revised netlist. See “Datapath Module Abstraction” on
page 257.
■ Increased datapath learning effort
■ The -WORDLEVEL option
Note: The datapath operators can only be learned once with the -WORDLEVEL option.
Thus, when you switch to this option, you have to relearn the datapath by changing the
dofile and running it from the beginning.
The following table outlines some recommended methods for resolving datapath aborts,
depending on the given scenario.
Scenario Recommendation
Datapath abstraction is not applied analyze datapath -module
in dofile
Resource sharing is applied in Functional partition
synthesis netlist
Don't care space exists Recode RTL to add CUT points
XOR tree is in RTL analyze datapath -wordlevel
DC Synthesis Flow
In MDP Analysis, there is one intermediate netlist between the RTL code and the final netlist
that divide the flow into two comparisons:
1. RTL to intermediate.
See Dofile Example for Intermediate Netlists on page 265.
2. Intermediate to final
See Dofile Example for Intermediate to Final Netlist on page 266.
This flow is applicable to both Design Compiler (DC) synthesis and RTL Compiler (RC)
synthesis; however, this section is dedicated to the DC synthesis flow.
The RC synthesis flow is more automated than the DC synthesis flow, where the intermediate
netlist and Conformal dofile are generated automatically with the write_hdl -lec and
write_do_lec RC commands. For more information, see the “Interfacing with Conformal
Equivalence Checker” chapter of the Interfacing Between RTL Compiler and Conformal
guide (this document is available within the RTL Compiler document set).
RTL
compile_ultra_mdp
analyze datapath \
LEC -module -resourcefile
Generate Resource Report analyze datapath -verbose
For more information on the DC commands that are included in the mdp.tcl script, see
DC Commands on page 264.
2. Run the compile_ultra_mdp command with the effort level (0, 1, 2, 3, or 4) and the
design module, which is the name of the top module that is synthesized.
compile_ultra_mdp 4 top1
Note: Effort level 0 is a pass-through effort where there are no option changes to the
synthesis script.
For more information on the effort levels, see MDP Effort Levels on page 265.
3. Run the compile_ultra command with the -incremental option to allow
incremental compilation.
compile_ultra -incremental
Sample DC Script
read_vhdl {../src/address.vhd ../src/cfft1024X12.vhd ../src/cfft.vhd \
../src/mulfactor.vhd ../src/p2r_cordic.vh d ../src/sc_corproc.vhd \
../src/blockdram.vhd ../src/cfft4.vhd ../src/div4limit.vhd \
../src/p2r_CordicPipe.vhd . \
./src/rofactor.vhd}
source ../../script/mdp.tcl
compile_ultra_mdp 4 revised1
compile -incremental -map_effort high
write -format verilog -hierarchy -output revised4.2.v
report_qor
quit
DC Commands
This section describes the DC commands that are included in the mdp.tcl script.
■ set compile_ultra_ungroup_dw false
By default, all DesignWare hierarchies are unconditionally ungrouped in the second pass
of the compile. The default is true.
■ compile_ultra
❑ -no_autoungroup
Turns off automatic ungrouping. By default, the compile_ultra command
performs delay-based auto-ungrouping. It ungroups hierarchies along the critical
path and is used essentially for timing optimization.
❑ -no_boundary_optimization
Turns off boundary optimization. By default, the compile_ultra command
optimizes across hierarchical boundaries. Boundary optimization is a strategy that
can improve a hierarchical design by allowing the compile process to modify the port
interface of lower-level designs.
❑ -no_seq_output_inversion
Does not allow sequential elements to have their output phase inverted.
■ -report_resource hierarchy
Displays information about the resource implementation
Options 1 2 3 4*
Preserves DesignWare Hierarchy YES YES YES YES
Boundary Optimization YES NO NO NO
Sequential Output Inversion YES YES NO NO
Preserves Design Module Hierarchy NO NO NO YES
The SET ANALYZE OPTION -auto command invokes both ANALYZE SETUP and ANALYZE
ABORT -compare commands. The first ANALYZE DATAPATH -module command starts
MDP analysis. The second ANALYZE DATAPATH is required to complete the datapath
analysis.
read design <rtl_files> -Golden
read design intermediate_gate.v -revised
report design data
report black box
..
set analyze option -auto
write hier_compare dofile hier.do -replace -usage -constraint -noexact \
-prepend_string “report design data; analyze datapath -module -resourcefile \
resource.rpt -verbose; analyze datapath -verbose”
run hier_compare hier.do
usage
The following shows the output, where the synthetic modules add_* have been analyzed:
LEC> analyze datapath -resourcefile resource.rpt -module -verbose
In this output, each synthetic module contains several individual datapath operators. If this
had high evaluation quality, the operator-level datapath analysis would have higher quality
results, while low evaluation quality has no impact on the operator-level datapath analysis.
MDP analysis results sometimes have low evaluation quality when the datapath module is too
complex. You can automatically extract a testcase with only the information of the failed
modules into a single compact testcase file. The testcase file, in XML format, contains a
netlist of the datapath module, a netlist of the gate-level implementation (from the Revised
design’s netlist), and other attributes associated with the datapath module, such as resource
information. The extracted netlists consist of primitive gates and do not contain direct
information on the library.
2. Specify a number that those datapath modules whose evaluated quality less than or
equal to the specified number will be reported.
For example, the following will report testcase on datapath modules whose evaluated
quality are less than or equal to 38% into the file low_quality.xml under the directory
LEC_testcase.
LEC > report testcase -datapath_module -quality 38 -file low_quality.xml
-dir_name LEC_testcase -replace
// Note: datapath module "add_9399_S2_DP_OP_314_2331_11" reported.
// Note: low_quality.xml generated into directory LEC_testcase.
// Note: Testcase is extracted into directory LEC_testcase.
To enable testcase extraction of datapath modules in the hierarchical flow, you can use
the following command:
write hier_compare dofile -prepend_string
report testcase -datapath_module -quality 38 -file low_quality.xml -dir LEC_testcase -append
Note: Use the REPORT TESTCASE command’s -append option instead of -replace
to avoid overwriting the same file. The -append option will prepend the current root
module name to the low_quality.xml file
The extracted testcase file contains the information of reported datapath modules. You can
reproduce the problem of failed modules in original design. The embedded information in the
testcase file is separated into files under the specified directory, along with one generated
dofile. Running the generated dofile can reproduce the problem of failed modules in original
design.
The Conformal software sometimes has abort points when comparing designs with
complicated datapaths. In such circumstances, you might choose to accept those abort
points as the final result. While you can accept a certain level of risks associated with
datapaths not being formally compared, you should make sure the rest of the designs are fully
compared.
You can isolate the aborted datapath modules and allow the comparison to proceed without
the aborted datapath modules. The aborted datapath module will be reported along with the
final comparison results.
For example, without isolating aborted datapath modules, the report might look like the
following:
// Command: analyze datapath -module -verbose -resourcefile resourcefile.rpt
// Note: add_5822_DP_OP_308_4437_42 : quality evaluated 100% success
// Note: add_5821_DP_OP_306_4437_41 : quality evaluated 100% success
// Note: add_1055_159_DP_OP_311_2879_8 : quality evaluated 99% success
// Note: add_5823_DP_OP_310_4437_43 : quality evaluated 100% success
// Note: add_5820_DP_OP_304_4437_40 : quality evaluated 100% success
// Note: add_9399_S2_DP_OP_314_2331_11 : quality evaluated 38% success
...
===============================================================================
Compared points PO Total
-------------------------------------------------------------------------------
Equivalent 64 64
-------------------------------------------------------------------------------
Abort 3 3
===============================================================================
When isolating the aborted datapath modules, the report looks like the following:
// Command: analyze datapath -module -verbose -resourcefile resourcefile.rpt \
-isolate_abort_module
// Note: add_5822_DP_OP_308_4437_42 : quality evaluated 100% success
// Note: add_5821_DP_OP_306_4437_41 : quality evaluated 100% success
// Note: add_1055_159_DP_OP_311_2879_8 : quality evaluated 99% success
// Note: add_5823_DP_OP_310_4437_43 : quality evaluated 100% success
// Note: add_5820_DP_OP_304_4437_40 : quality evaluated 100% success
// Note: add_9399_S2_DP_OP_314_2331_11 : quality evaluated 38% success
// Warning: add_9399_S2_DP_OP_314_2331_11 is isolated as an aborted instance.
...
===============================================================================
Compared points PO Total
-------------------------------------------------------------------------------
Equivalent 67 67
===============================================================================
Compared results of isolated instances in Revised design (top)
===============================================================================
Note: This feature does not help resolve aborts. It reduces the report to make it easier to
show where the abort points lie. Instead of showing several abort key points, it shows all EQ
key points and shows only the abort DP_OP module. This type of reporting allows you to make
a more informed decision about the risks associated with reported abort modules
You can specify the module to be isolated using either of the following commands:
analyze datapath -module -isolate_abort_module
set datapath option -module -isolate_abort_module
During MDP analysis, the aborted modules are extracted into RTL. The software reports all
isolated modules as part of the final comparison results.
To enable isolation of aborted modules in the hierarchical flow, you can use the following
commands:
write hier_compare dofile -prepend_string \
"analyze datapath -module -isolate_abort_module"
analyze datapath -module -isolate_abort_module
Or set the following option before running the RUN HIER_COMPARE command:
set datapath option -module -isolate_abort_module
During hierarchical comparison, the software automatically isolates the aborted datapath
module for each root in the synthesis netlist. Run the REPORT HIER_COMPARE RESULTS
command to report the isolated module.
Datapath learning, through the ANALYZE DATAPATH command, makes the Golden datapath
operators structurally similar to the revised netlist so that comparing the two designs is easier.
Datapath Learning
The -WORDLEVEL option applies additional analysis that handles advanced datapath
optimizations in the following areas:
■ Complex adder tree clustering: Supports clustering multiple adder trees that share
common sub-expressions, and whose input operand has least-significant-bit (LSB)
truncation.
■ Product-of-sum optimizations: Supports optimization of merging the cluster adder with
the multiplier.
■ Associative Law on multipliers: Supports reordering of the cascaded multipliers based
on associative law.
■ XOR tree optimizations: Supports optimization of reordering XOR tree.
■ Constant multipliers and adder trees optimizations: Supports adder tree optimizations
with input constraints.
You can use the -WORDLEVEL option with the SET DATAPATH OPTION or ANALYZE
DATAPATH commands.
The command analyzes the Golden design's datapath operators and merges the cluster
adders with the product-of-sum operators.
When the quality of datapath learning is low, you can improve the quality of datapath learning
by using
■ Datapath abstraction on the revised netlist.
analyze datapath -module -reseourcefile <filename>
Note: The datapath operators can only be learned once with the -WORDLEVEL option.
Thus, when you switch to this option, you have to relearn the datapath by changing the
dofile and running it from the beginning.
The following table outlines some recommended methods for resolving datapath aborts,
depending on the given scenario.
Scenario Recommendation
Datapath abstraction is not applied For a DC netlist:
in dofile analyze datapath -module -resourcefile \
resource.f
For an RC netlist:
analyze datapath -module
Conformal includes automatic sequential merge analysis and diagnostic capabilities for
sequential merge.
For more information on these commands, refer to the Conformal Equivalence Checking
Reference or use the MAN command.
Synthesis Requirements
DC Synthesis Flow
In the DC synthesis flow, you must turn off inverted sequential merging so that Conformal can
correctly verify the design. Or, you must specify the phase information using the ADD
INSTANCE EQUIVALENCE -INVERT command.
RC Synthesis Flow
In RC synthesis flow, you must use the -lec option when writing out the netlist:
write_hdl -lec
This enables sequential merge annotation, where merges are specified as comments in the
netlist. For example:
// synthesis_merge
// merged rep i1/q1_reg
// merge + i1/q2_reg
// merged rep i2/q1_reg
// merge + i2/q2_reg
Conformal uses this information during sequential merge analysis. For example, when a
netlist with such annotations is set as the revised design, LEC automatically reads in the list
of sequential elements, applies the appropriate sequential merges, and displays the following
modeling message:
// (F21) Merged 123 DFF/DLAT(s) due to added instance equivalences
For example, when a group of four DFFs is merged into a single DFF, this is called a
representative or a merge group, LEC will first perform a single design mergeability proof and
validate whether all four DFFs can be merged together without causing conflict.
When the functions of merged registers contain don't-care (DC) conditions, the mergeability
relationship is no longer transitive. When this happens, LEC will perform a sufficient number
of proofs for the merge group. As a result, the number of reported "Compared points" may
exceed the actual number of merged DFFs. The proof result is reported as follows:
Compare results of instance/output/pin equivalences and/or seq_merge
============================================================
Compared points DFF Total
------------------------------------------------------------
Equivalent 4 4
============================================================
When the merge representative contains a don't-care condition, the sequential merge could
enlarge the permissible functional space, thereby masking any synthesis errors. In this case,
LEC creates additional compare points, one for each merged DFF. These special compare
points, called merged compare points, are compared against the representative's mapped
point in the revised design.
A new comparison result section called "Compare results of merged compare points" for
these merged compare points is reported after a comparison, as follows:
Compare results of merged compare points
====================================================================
Compared points DFF Total
--------------------------------------------------------------------
Equivalent 4 4
====================================================================
Notice that the comparison result of the representative will be reported in the regular
comparison data.
The second and third sections are comparison results for sequential merge and the
ADD INSTANCE and ADD PIN EQUIVALENCE commands.
Note: You can use the -golden and -revised options to specify the design type.
To view the compare points information, use the REPORT COMPARE DATA command.
Retiming
Guidelines
Procedure
To use basic pipeline retiming, use the ADD MODULE ATTRIBUTE -pipeline_retime
command while in Setup mode (as shown in the following transcript):
.
.
.
add module attribute ocd_cs_r4c -pipeline_retime -Golden
.
.
.
// Modeling Golden…
// Pipeline-retimed 50 DFF(s) as 51 DFF(s) in 3 stage
// Modeling Revised…
// Pipeline-retimed 59 DFF(s) as 51 DFF(s) in 3 stage
Unlike basic pipeline retiming, described in Basic Pipeline Retiming on page 276, advanced
pipeline retiming supports:
■ Some forms of set and reset
■ Sequential feedback
■ MUX enable, but not MUX stall
■ Latches that are not retimed
Procedure
To use advanced pipeline retiming in Conformal XL, use the ANALYZE RETIMING command
in LEC mode (as shown in the following transcript):
.
.
.
SETUP> set system mode lec -nomap
// Command: set system mode lec -nomap
LEC> analyze retiming
// Command: analyze retiming
LEC> map key points
// Command: map key points
// Mapping key points ...
================================================================================
Forward and backward pipeline retiming together provide the mechanism and the flexibility to
debug retimed designs by selectively moving only a subset of the registers in the desired
directions. You can run this multiple times with different set of registers and options, thus
allowing the manual refinement of retiming steps.
This can help to reduce unmapped register key points and the resulting false non-
equivalences.
Note: This is on by default when running the ANALYZE RETIMING command.
Retiming Diagnosis
Run the ANALYZE RETIMING -diagnosis <identifier> command to check if the
specified register can be retimed a step forward, or step backward to its fanout or fan-in gates,
respectively. If the retime movement cannot succeed, the reason for the failure is reported.
This option will not change the netlist—it only provides information about the specified
retiming step.
Registers that are outside the retiming modules will not be moved to the part of the design
that has been subject to retiming. You can specify retiming modules by running the ADD
MODULE ATTRIBUTE -pipeline_retime command.
Multithreading Process
Multithreaded comparison is best suited for large gate-to-gate comparisons, where the
comparison can be distributed to multiple comparison threads. To possibly resolve more abort
points and reduce the time spent on RTL-to-gate comparisons, the parallel analyze abort
feature might be more effective.
The easiest method to invoke multithreaded comparisons is to use the COMPARE command’s
-threads option to specify the number of threads. For example, the following command
starts the comparison using four parallel threads:
compare -threads 4
When a comparison is multithreaded, the number of executing threads are updated along
with the comparison results. For example,
// 26% Comparing 4 out of 15 points, 0 Non-equivalent, 4 Threads
Multithreading Model
The multithreading model differs from other models in that the additional threads of
processing are always run on the current machine instead of being launched through a server
farm. This eliminates the complexity of setting up the multithreaded environment and instead
uses multi-core, multi-CPU machines in a computing farm.
During a program’s execution, the elapsed time, or wall-time, is the time measured using a
wall clock (real time), whereas the CPU time is the amount of time that a processor used to
work on the process. The goal of multithreading is to reduce the elapsed time, which does not
necessarily reduce the total CPU time. Therefore, you can collect runtime statistics for
multithreading features using the following command:
usage -elapse
The software spawns additional processes during multithreaded comparison. You can use
the ps or top shell commands to show how many comparisons are running. The Conformal
software also imposes a version match check between main software program and spawned
software processes to maintain consistency.
You can specify the number of threads in three different ways as follows, with decreasing
order of precedence:
Note: You can only specify a maximum of 16 threads.
1. At the command. For example:
compare -threads 4
For example, with either of the following commands, all subsequent COMPARE commands run
with two computing threads:
set parallel option -threads 2
set compare option -threads 2
However, you can override this by running the following command to compare without
multithreading:
compare -threads 0
Or you can compare with more computing threads using the following command:
compare -threads 4
Similarly, if you use the following sequence, all subsequent COMPARE commands will use two
computing threads because the second command setting supersedes the first command
setting:
set parallel option -threads 3
set compare options -threads 2
where MIN() returns the minimum of the number of threads and the number of available
processors, and overhead is a constant factor incurred for each thread, respectively. The
SET PARALLEL OPTION -info command shows you two types of overheads: spawned
process latency and parallel compare overhead. The values displayed are the sum up
overheads for all the threads, so you can roughly use the sum of these two values as ’#-of-
threads x overhead’ as in the previous wall-time equation.
Example:
Because the wall-time speedup is bounded by the number of available processors, Cadence
recommends that the number of threads be the same as the number of available processors
(cores).
Note: Specifying too large an number (-n) could delay or prevent the job from being
executed on the server farm depending on the resources and setup of the server farm.
You can configure the limit of the number of processes for the whole job with option -p. The
default is no limit. Exceeding the limit causes the job to terminate. For example, the following
sets the process limit to be 1:
bsub -p 1 lec
Tip
Make sure this option is not set or the number is set to be greater than the number
of computing threads of parallel comparison.
Licensing Requirements
Each additional computing thread requires one additional license. These additional licenses
are released when the multithreaded comparison is completed.
The multithreaded processing program supports one computing thread with no additional
licensing requirement. If the software starts with a GXL license and comparison is performed
with three threads (compare -threads 3), the licenses used are one GXL when the
software starts and two additional XL when the parallel comparison starts, equaling three
threads.
Note: Make sure to have enough licenses for multithreaded comparison. If you specify three
threads (compare -threads 3), and only one license is available at that time, the software
errors out and falls back to serial mode.
By default, the software attempts to check out additional XL licenses. If this fails, it attempts
to check out the licenses with which the software started. For example, if the software starts
with LP licenses, and comparison is performed with three threads, the software first attempts
to check out two additional XL licenses. If this fails, it attempts to check out two additional LP
licenses. After that, the tool will attempt to check out the license that is next on the default
license list listed in the following table:
The following shows a graphical example of the software flow as it attempts to check out
licenses for multithreaded processing. For this run, the available additional licenses (to the
one startup license) are one XL, one LP and one ECO.
Yes
3 XL? Runs Multithreaded Comparison
Yes
2 LP? Runs Multithreaded Comparison
Yes
1 ECO? Runs Multithreaded Comparison
No
Error Out
In the above example, if there were three XL licenses available, the software would have
checked out the three XL licenses and run multithreaded comparison and disregarded the LP
and ECO licenses.
you can preserve this temporary directory after exiting with the SET PARALLEL OPTION
-keep_dir command. The disk space requirement is approximately the same as the
required amount when writing out the flattened Golden and Revised designs when running
the WRITE DESIGN command.
Tip
Use the /tmp directory if your file system is slow. You can redefine the location of
the temporary directory with the following environmental variable:
setenv RUN_REMOTE_TMPDIR_PREFIX /tmp
There are two ways to set the number of threads for multi-threaded functional partitioning.
Either call the following command:
run partition_compare -threads 2
Either method executes multi-threaded functional partitioning with two active threads.
Note: The first method has higher priority than the second (in other words, if both methods
are used, the number of threads specified in the first method takes priority).
the command will automatically deduce the corresponding partition points in the other design.
Each of the partition pairs are first validated before adding them as physical CUT gates.
The following command example and illustration shows how the partition (CUT) points are
specified for the datapath operators in the Golden design, where the corresponding partition
points (if any) are automatically deduced and added in the revised design:
add partition points -datapath
a b c d e a b c d e a b c d e a b c d e
Cut Points
Golden Revised Golden Revised
You can display these added partition points with the REPORT PARTITION POINTS
command. You can delete the added partition points with the DELETE PARTITION POINTS
command.
The following command example shows how the CUT points are specified for the module
instance in the Golden design, where the corresponding partition points (if any) are
automatically deduced and added in the Revised design:
add partition points -instance instance_name
You can also use ADD PARTITITON POINTS command for correspondence reporting only,
instead of physically adding CUT gates. The following command example shows how you can
specify a list of gate identifiers in the Revised design, and use the -verbose option to report
the corresponding gates, if any, in the Golden design:
add partition points identifier1 identifier2 -revised -verbose -nocut
The -nocut option in the example ensures that the CUT gates are not physically added in
the two designs.
After adding the CUT points, you can add all the compare points (including partition points)
and run compare. If all the compare points (including the partition points) are equivalent, the
designs are proved to be equivalent. However, if one of the compare point is non-equivalent,
you will need to diagnose the non-equivalent points. If the partition points are the cause of
non-equivalence, you can delete these at any time in LEC mode using the DELETE
PARTITION POINTS command. You can add and delete partition points multiple times until
you generate feasible partition points for comparison abort resolution.
To perform a flat run with hierarchical partitioning, add partition points to all module instances
using the following command:
add partition points -instance * -name -input -output
To get better datapath quality, add partition points to all module instances containing datapath
operators using the following command:
add partition points -datapath -name -input -output
For example, when abort points are encountered in comparison, you can run this command
to do functional partitioning for the abort points.
Analyzing Non-Equivalence
Use the ANALYZE NONEQUIVALENT command to help identify the possible causes of non-
equivalent compared points. The following schematics show examples of non-equivalent
analysis:
Example Report
The following shows an example of a report when running the ANALYZE NONEQUIVALENT
command. The lines in bold indicate the cause of the problems:
LEC> analyze noneq 213
//Command analyze noneq 213
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:
Gated clock of of DFF or DLAT. (Occurrence: 1)
Unknown reason. (Occurrence: 1)
LEC> analyze noneq 170 -revised
//Command analyze noneq 170 -revised
Analyzing non-equivalent compared points:
(G) + 167 PO /wbm_sel_o[0]
(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:
Sequential constant. (Occurrence: 1)
Unknown reason. (Occurrence: 1)
Clock Gating
Sequential Constant
The results are displayed in the Schematic Viewer with the following colors:
■ Blue: initial assignments
■ Green: current implication values
■ Red: gates on the conflict path
■ Purple: location where conflict occurred
In the schematic view, you can also right click the gate and set a value. Holding the mouse
pointer on a gate, an information box will show if this gate has redundant fan-in and if it is a
constant gate.
Netlist Analysis
This feature provides another view of the flattened netlist, which could help datapath analysis,
comparison, and diagnosis.
Extracting half and full adders from the synthesized netlist helps reduce the complications
caused by optimizations, and improves datapath analysis and learning quality. To invoke the
extraction, use the following command in LEC mode:
analyze netlist -abstract hfa
When using LEC, the synthesized netlist will most likely be taken as the revised netlist;
therefore, use the command to invoke extractions on the synthesized netlist:
analyze netlist -abstract hfa -revised
This command modifies the specified netlist; these modifications cannot be revoked and can
sometimes have an adverse effect for datapath analysis and comparison. Thus, the
command is not invoked automatically and is recommended only for abort resolution. For
datapath designs with aborts, if the datapath analysis quality is low, try this command before
the ANALYZE DATAPTH command without -MODULE option.
This command has been integrated in the ANALYZE RETIMING command to facilitate
retiming analysis, and can be helpful for diagnosing of retimed designs. For example, using
this command, you can check if the input of a DFF can be implemented as in the following
graph:
D0 Q
DFF
D1
S O D
Sample Dofile
The following is an example of a Conformal dofile that includes the Conformal XL flow.
Note: Retiming can have impact on datapath learning. As a result, if the design has retiming,
you should run the ANALYZE RETIMING command before running ANALYZE DATAPATH.
Likewise, mapping will impact datapath learning and should be performed first.
// To read in the RTL design and the synthesized gate
// netlist
analyze retiming
compare
12
Layout Versus Schematic
Overview
Designers use Conformal L to run logic function verification between an RTL model and a
gate netlist , or between a gate netlist and another gate netlist. Subsequently, a SPICE netlist
representing the circuit and a GDSII netlist representing the physical geometry of the design
are created. Designers use Layout Versus Schematic (LVS), which is a physical verification
tool to verify equivalence between the SPICE netlist and the GDSII netlist. LVS checks
whether the connectivity of the circuit and the layout are equivalent. However, during this flow,
neither the logic function of the SPICE netlist nor GDSII data is verified.
Conformal GXL operates within Conformal L to enable logic verification of the final design
step: circuit implementation. After final place and route, the circuit design is implemented for
tapeout. At this point, Conformal GXL enables functional verification on the final circuit design
represented by the SPICE netlist used as reference to LVS verification. The following figure
illustrates the Conformal GXL LVR process flow.
LVR Functionality
Conformal GXL LVR furnishes designers with two interdependent functions that allow
complete verification from RTL or gate to GDSII: Circuit Library Analysis and Design Logic
Function Verification.
The first phase in the verification process is to isolate design and library problems. Conformal
GXL LVR runs three different checks for circuit library analysis:
■ Automatic Functional Analysis—LVR compares logic function of two libraries on a
cell-by-cell basis. Every cell is automatically compared in this process.
■ Cell Error Repairs—After the analysis, LVR generates error reports. LVR reports those
cells that have errors that can prevent design logic comparisons and replaces those
library cells with the reference logic to allow design verification.
■ Phase Inversion Correction—LVR aligns state element phases between Golden and
Revised library sequential elements to avoid phase inversion problems during the design
level verification phase.
After the Circuit Library Analysis phase completes, it initiates the Design Logic Function
Verification phase. In this phase, Conformal GXL verifies full equivalence between two
designs.
To start the ConformalGXL software in non-graphical mode, run the following command:
lec –gxl -nogui
LVR Flow
This section details the Conformal GXL LVR flow. As mentioned above, the LVR flow consists
of two phases: Circuit Library Analysis and Design Logic Function Verification. Summaries of
the objectives of these two phases of the flow are as follows:
■ Circuit Library Analysis
b. Read Revised library (formats include: Verilog, VHDL, Liberty, and SPICE)
a. Read the reference design model or netlist into the Golden design
-verilog To specify that the reference library format is Verilog, use the
-verilog switch. This option is the default.
-liberty To specify that the reference library format is Liberty, use the
-liberty option.
–vhdl To specify that the reference library format is VHDL, use the
-vhdl option.
–spice To specify that the reference library format is SPICE, use the
-spice switch.
-revised Use the -revised switch to specify that the Revised database
will be validated. This option is the default.
-Golden Use the -Golden switch to specify that the Golden database
will be validated.
❑ Run the READ DESIGN command. The -replace option lets the gate netlist
replace the library data.
>read design <gate netlist> -Golden –replace [-verilog | -vhdl]
LVR Implementation
Suggested Uses
Use Conformal GXL to analyze circuit libraries and compare designs.
Conformal analyzes different formats of a circuit library; for example, Verilog versus Liberty
or Verilog versus SPICE. No manual modeling or setups are required. See LVR Flow on
page 297 for library verification steps.
Design Comparison
Use Conformal GXL to compare a Verilog gate design netlist to a design SPICE netlist. Unlike
comparison with an RTL model where scan function is disabled, using a gate design netlist
as the reference enables Conformal to verify scan function.
The first example illustrates a typical Conformal dofile used to do an equivalence check on an
RTL versus a gate netlist.
lec.dofile:
// Define embedded blocks for black boxing here
// For example: add notranslate module PLL* -both
As illustrated below, with the addition of the LVR flow into Conformal, the dofile requires very
little modification.
lvr.dofile:
13
Conformal Custom
Overview
This chapter describes the standard commands used in a typical Conformal Custom (also
known as Conformal GXL) session and introduces you to the process flow, as shown in the
following figure:
Transistor Abstract
Netlist Conformal Custom Verilog
Model
Automatic
Abstraction
RTL
Model Conformal LEC
or Gate
Netlist
Conformal Custom supports transistor netlists with legal SPICE and some variants (.cir,
.sp, .spi, and .cdl). Conformal Custom also supports Verilog switch-level netlists, but
these netlists do not have the information required for Conformal Custom checking (such as
MOS body connections).
The tool does not support DSPF netlists. A DSPF netlist is a SPICE format created for a GDS
(layout) extraction tools and it includes RC networks. Instead, output the SPICE netlist used
for cell-level LVS, which can be output from the library cell schematic view.
Note: When parsing a SPICE file, any net connected to a PMOS bulk node is assumed to be
VDD. Any net connected to an NMOS bulk node is assumed to be ground. To override this
setting, use the SET SPICE OPTION command with the -NOBulk option.
Important
If you use SET SPICE OPTION -NOBulk, you must use it before reading in the
SPICE file.
You can also write out a Verilog gate-level netlist from the abstracted transistor netlist. This
gate level netlist is used for simulation acceleration, emulation, and ATPG.
Custom Licensing
You must have the Conformal GXL license to use the transistor abstraction capability within
Conformal. To check whether you are licensed to run transistor abstraction, inspect your
license file and look for the following FEATURE lines:
FEATURE Conformal_Custom cdslmd 6.200 14-dec-2006 5…
Contact your Cadence sales representative if you want to obtain this feature.
Abstraction Methods
Conformal GXL automatically abstracts functionality from a transistor netlist using the
following methods:
■ Automatic Functional Analysis
Conformal GXL automatically abstracts the Boolean function of Static CMOS,
Pass-GATE, and Tristate logic. Conformal GXL recognizes MUXs, and abstracts
transistors into latches and DFFs. It also determines signal directions through MOS
transistors and module I/O.
■ Pre-Charge Logic Abstraction
Conformal GXL abstracts the logical function of a dynamic circuit in the evaluate phase.
The tool requires you to identify the pre-charge (off-duty) clock.
■ Pattern Matching
Conformal GXL also recognizes transistor patterns that you define. If you specify the
transistor netlist for the pattern along with its corresponding functional Verilog or VHDL
model, Conformal GXL uses the functional model you supplied every time it encounters
its corresponding pattern in the design during abstraction.
To start the Conformal GXL software in non-graphical mode, run the following command:
lec –gxl -nogui
Read Transistor
Netlist See Reading a Transistor Netlist on page 307
Run Abstraction
See Running Logic Transistor Abstraction
on page 315
Abstract Logic
Transistors
requiring Report MOS See Reporting MOS Direction on page 315
MOS Direction
direction
assignment
NO All transistor
directions
resolved?
YES
Continue
Verification See Continuing the Verification Flow on page 316
Flow
Before reading in a SPICE netlist to Conformal, inspect the netlist to determine the names of
the N-channel and P-channel devices. Conformal automatically recognizes model names
beginning with ‘p’ and the model name ‘up’ as a PMOS type, and recognizes model names
beginning with ‘n’ as an NMOS type. However, if other names are used, such as UNAME1 or
UNAME2, you must do one of the following:
■ Insert a .model card at the top of the netlist.
The .model card maps the device names UNAME2 to NMOS and UNAME1 to PMOS. For
example:
.model UNAME1 PMOS
.model UNAME2 NMOS
.SUBCKT K1 n0 n1 n2
Mx0 n0 n1 n2 n3 UNAME1
Mx1 n0 n1 n2 n3 UNAME2
Xx2 n0 n1 n2 n3 n4 n5 n6 K2
.ENDS K1
■ Use the SET MOS MODEL command to define the MOS model names used in the SPICE
netlist.
■ Insert an *.EQUIV or *.EQUIVALENCE directive at the top of the netlist to replace user-
defined model names with the model names that Conformal can automatically recognize.
For example:
*.EQUIV PMOS=UNAME1 NMOS=UNAME2
SUBCKT K1 n0 n1 n2
Mx0 n0 n1 n2 n3 UNAME1
Mx1 n0 n1 n2 n3 UNAME2
Xx2 n0 n1 n2 n3 n4 n5 n6 K2
.ENDS K1
Note: If the *.EQUIV statement stretches over multiple lines, you must use an asterisk
and plus sign (*+) at the beginning of each additional line to indicate continuation.
Note: Conformal treats resistor definitions in the SPICE netlist as wires and it ignores
capacitors.
SPICE ports and transistors are bidirectional. That is, all ports are defined as INOUT, and
transistor source-drain is interchangeable. During abstraction, Conformal determines signal
To read a transistor netlist into the design space of Conformal, use the READ DESIGN
command with either the -Golden or -revised switch.
The design shown in the following figure can be interpreted as a latch or as a 3-to-1
multiplexer. For this example, the circuit is treated as a multiplexer.
sela
y
b
selb
selc
The following example lists the Verilog transistor netlist (pattern) for the previous design.
module mux3x1 (a, b, c, sela, selb, selc, y);
input a, b, c, sela, selb, selc;
output y;
wire s;
tranif1 t0 (s, a, sela);
tranif1 t1 (s, b, selb);
tranif1 t2 (s, c, selc);
inv d0(y,s);
inv fdbk(s, y);
endmodule
Additionally, the following example lists the substitute Verilog model for this pattern.
module mux3x1 (a, b, c, sela, selb, selc, y);
input a, b, c, sela, selb, selc;
output y;
wire y_;
assign y_ = sela ? a : 1'bz;
assign y_ = selb ? b : 1'bz;
assign y_ = selc ? c : 1'bz;
assign y = ~y_;
endmodule
The following is an example of a command file (dofile) for Conformal GXL LTX that
demonstrates how to execute the multiplexer as shown in the previous example:
read pattern pattern.v -verilog
// reads the mux3x1 transistor netlist or pattern
abstract logic
// calls up LTX abstraction routine
Defining Constraints
The ABSTRACT LOGIC command is included in the dofile shown in the previous example.
However, before you use this command, you must consider issues that can impact the
abstraction.
Conformal GXL automatically recognizes VDD, GND, and VSS global nets in SPICE. If other
global net names are used for power and ground in the netlist, use the ADD TIED SIGNALS
command before transistor abstraction. For example:
add tied signals 0 cds.global.gnd_ -all -Golden
add tied signals 1 cds.global.vdd_ -all -Golden
Use the ADD NET ATTRIBUTE command to identify an internal net as a pre-charge clock to
a dynamic circuit. This case arises when the pre-charge clock is generated internally and is
not available as an external design pin. For example:
add net attribute CLOCK0 net134 -module bitpre -Golden
In this example, CLOCK0 defines the off-state of the pre-charge logic. That is, a zero value on
the net (net134) puts the circuit in pre-charge or off-state mode, while a one value on the
same net puts the circuit in duty-state or evaluate mode.
Conformal GXL automatically resolves modules in simple cases; that is, modules having few
inputs, outputs, and instances. However, in more complex cases that include unnecessary
levels of design hierarchy, use the RESOLVE command to manually resolve modules in the
design hierarchy.
This command un-groups a module and raises its contents one level. For example, when a
flip-flop module instantiates two latches, a master and a slave latch, use the RESOLVE
command to resolve the latch hierarchy. Then, the Conformal GXL abstraction engine
combines the master and slave latch circuitry to create a single flip-flop.
After resolving the hierarchy, the internal database in Conformal is modified. You cannot undo
the changes in the hierarchy.
Important
The hierarchy in the designs should be maintained to the extent possible to simplify
abstraction and diagnosis.
When the design is relatively small, and submodule abstraction fails because of many
hierarchical relationships between pins, use the FLATTEN command to force Conformal to
resolve all submodules. This command can sometimes help improve abstraction. For
example:
flatten -module chip -force -revised
Pin equivalences are used to define the relationship between two or more pins in a module.
When two pins are equivalent through inversion, as shown in the following pass-gate
example, use the ADD PIN EQUIVALENCES command.
Note: If you use the -both option, every primary input pin you list must exist in both designs
(Golden and Revised). If they do not, Conformal returns an error message.
enb
a y
ena
When a design has pre-charge logic, Conformal GXL requires you to identify the pre-charge
clock and define its off-state. Use the ADD CLOCK command to declare a pre-charge clock.
The following figure illustrates a pre-charge NAND gate. In this example, pin pre in module
NAND represents the pre-charge clock.
pre_
pre
pre_
a
To define the off-state for this circuit, specify the following constraint:
add clock 1 pre -Golden
As a result of the ADD CLOCK command, Conformal GXL models the design as a static NAND
gate, as shown in the following figure:
a
NAND y
pre
The SET ABSTRACT MODEL command specifies certain conditions for abstracting transistor
logic. The command’s -pre_charge_keep_clock option includes the defined pre-charge
clock in the abstracted logic function (the default behavior removes the defined pre-charge
clock from the abstracted logic). This is indicated when you define a precharge clock with one
of the following commands:
When you use -pre_charge_keep_clock, the resulting logic is equivalent to RTL that
explicitly models the pre-charge condition, rather than RTL that models only the evaluate
function. In the latter, the output function is not defined during precharging. (See the following
examples.)
Explicit modeling:
always @(clock or a or b) begin
if (clk) y = a ! b;
else y = 1'b1; // precharge
end
Evaluate function:
assign y = a ! b;
Note: Designers employ explicit modeling when the precharge function output is latched
during pre-charge. Thus, the resulting functionality of either method is equivalent. It is strictly
a matter of coding style. Both methods are acceptable.
If you ran the SET ABSTRACT MODEL command to abstract transistor logic from particular
modules, use the REPORT ABSTRACT MODEL command and Conformal GXL reports their
abstraction conditions.
If you ran the SET ABSTRACT MODEL command to abstract transistor logic from particular
modules, use the RESET ABSTRACT MODEL command to reset the abstraction conditions to
their original state.
Although Conformal GXL is capable of determining pin and signal direction, some cases
require manual assistance. For transistor netlists that lack pin direction information, use the
ASSIGN PIN DIRECTION command to make a manual assignment. For example:
assign pin direction in mux2p in0 -revised
Copying Modules
You can copy a module’s logic or pin direction from the RTL to assist in abstraction. Use the
COPY MODULE command:
For Conformal GXL to successfully abstract a logical gate-level model of a transistor netlist,
it must determine signal directions through all transistors in the design. There are three
possible directions a signal can flow in an N channel or P channel transistor:
■ From drain to source
■ From source to drain
■ Both ways (bidirectional)
Note: In SPICE, MOS transistors are all bidirectional. Thus, the source and drain ports are
interchangeable. However, signals always flow into the gate of a transistor, and the burden
falls on Conformal GXL to determine the signal directions. The following figure illustrates this
concept.
In Verilog the task of determining signal direction is simplified because Verilog supports two
transistor definitions:
■ One definition is a unidirectional transistor declaration for which the signal flows from
source to drain, or from drain to source, but not both directions.
■ The other is a bidirectional N or P transistor declaration, where signals can flow in both
directions.
If Conformal GXL cannot determine the direction of a signal through a transistor device,
manually assign the direction using the ADD MOS DIRECTION command. For example:
add mos direction phgx10 M30/N12 ixMM -Golden
For this example shown above, use the -all option as follows to assign direction from vss
to i1:
-all -from_source
In your designs, use -all -from_source to apply MOS direction from source to drain on
all of the transistor-MOS instances in your design.
Likewise, -all -from_drain assigns MOS direction from drain to source on all of the
transistor-MOS instances in your design.
If the resulting abstraction is not complete, Conformal GXL lists the modules and the number
of transistors you must constrain. The following is an example of what the command returns:
Pin Equivalences
In this example, an RTL model and circuit are not equivalent except when Clk and ClkB are
inverted. Before abstracting circuits, use the following command:
add pin equivalence Clk -inv Clkb
Flatten or Resolve
Abstraction works hierarchically but not across hierarchy except for constraint or pin
equivalence propagation. Functions across hierarchy are not abstracted. In the following
illustration of a circuit, the right tinv and hldr cells are parts of the D Latch.
Abstraction Options
Abstraction options affect how certain circuits are abstracted. Use these options to transform
special circuits, such as:
■ Domino (pre-charge) logic modeling
■ RAM pre-charge, sense amp, and pulse clock modeling
■ Custom circuit weak pull-up and level restorer modeling
Before abstracting, use the SET ABSTRACT MODEL command. To limit scope of the
abstraction, use the command’s -module option.
Pulse generators are commonly used in memories. The start of the pulse initiates an access.
The end of the pulse provides a signal to sample the data for reading. Pulse generators have
transient function and are not supported by traditional abstraction or static formal verification
equivalence checking technique.
In the following example, transient pulse generators abstract correctly but cannot be used for
logic verification:
Pulse = Clock && !Clock
To fix this, manually disable the trigger to turn the pulse off:
remove x4
add tied signal 1 n4
Diagram 1 shows an example of a layered switch network of a ROM function. This is the same
logic function as the logic primitive network in Diagram 2. The SET XC command provides
the analysis capability needed to successfully compare these functions.
Custom Menu
This section describes forms are accessible from the Custom menu. This menu contains the
following sub-menus:
Note: These features require a Conformal GXL license.
■ General Setup on page 321
■ Custom Setup on page 330
■ Data Entry Menu on page 340
■ Application Menu on page 344
■ RAM Primitive on page 349
■ ROM Primitive on page 357
General Setup
For each list there are four columns with the headings: Pin, 0, 1, and
GROUPING_CONSTRAINT. The primary input list is shown in the Pin column. Each
primary input is either a system class primary input (S: name) or a user-defined class primary
input (U: name).
In the following procedures, you are asked to select primary inputs. Use any of the following
procedures to select primary inputs:
■ Click a primary input to select it.
■ Click and drag the mouse over a group of adjacent primary inputs to select them.
■ Click the first primary input in a group, press and hold the Shift key, and click the final
primary input in a group to select the entire group.
■ Press the Ctrl-key and click a primary input to add it to the selected group.
The following procedures explain how to add and delete pin constraints.
Use the following procedure to add a constraint to a single primary input using the Pin
Constraints form:
1. In the Pin column, click a primary input to select it.
2. Right-click and choose the Constraint 0 or Constraint 1 constraint from the pop-up
menu.
The selected primary input appears in the appropriate column.
Use the following procedure to add a constraint to a group of primary inputs using the Pin
Constraints form:
1. In the Pin column, select multiple pins with one of the methods described in “Selecting
Primary Inputs” on page 321.
2. Right-click to open the pop-up menu and choose a constraint.
Use the following procedure to delete one or all constraints using the Pin Constraints form:
1. Click a primary input in the 0, 1, or GROUPING_CONSTRAINT column to select it.
2. Right-click and choose one of the following from the pop-up menu:
To delete a constraint from the selected pin, choose Delete Pin Constraint. Conformal
removes the pin constraint. And in the case of GROUPING_CONSTRAINT, Conformal
deletes the entire group.
To delete all constraints, choose Delete All Pin Constraints. Conformal deletes all
constraints from all columns.
Module Name Specifies the module that needs to be updated pins of that
module are converted to a bus.
Pin Specifies the pins of that module are converted to a bus.
The primary input lists for each of the Golden and the Revised designs are displayed in their
respective columns. Conformal displays added pin equivalences below the target primary
input with a connecting line. Inverted pin equivalences are denoted with (-) following the
primary input name.
To alphabetically sort the primary input lists by column, right-click in the column you want to
sort and choose Sort from the pop-up menu.
The Conformal software uses the following two default patterns to group pins or nets into
busses:
■ Name[#]
■ Name<#>
For example, nets blb[3] blb[4] blb[5] will be grouped into bus blb[5:3], and pins
wladd<1> wladd<2> wladd<3> will be grouped into bus wladd[3:1].
Add Bus Expression Specifies expression(s) for rules on signals to bus. You can
specify your own renaming mapping of specific names to two
default patterns, so that it recognizes those names as buses
also.
For example:
"mybus_%d_bar" "mybus_bar[@1]"
maps the following names into the first default bus name:
mybus_12_bar mybus_13_bar mybus_14_bar => mybus_bar[12]
mybus_bar[13] mybus_bar[14]
then the renamed names will be further grouped into bus
mybus_bar[14:12]
All Specifies that when pins of a module are converted to a bus,
all instantiations of that module need to be updated.
Module Name Specifies the module that needs to be updated pins of that
module are converted to a bus.
Pin Specifies the single nets or pins to be grouped into a bus.
Right-click and choose Group Pin from the pop-up menu to
open the form to create a bus.
Flatten
Use the Flatten form, or the FLATTEN command, to remove all hierarchy on a specified
module or for all modules in the database. If you do not specify one or all modules, Conformal
flattens the root module by default. Thus, this expands all of the gate primitive or transistor
primitive devices into the cell that is being flattened.
Ungroup Module
Use the Ungroup Module form, or the RESOLVE command, to ungroup a module in the
Golden or Revised design hierarchy. Resolving or ungrouping is the process of eliminating a
module and promoting its content up one level of the hierarchy.
To open the Ungroup Module form, choose Custom – General Setup – Ungroup Module.
To open the Group Instances form, choose Custom – General Setup – Group Instances
into New Module
Custom Setup
When reading in SPICE netlists, the parser automatically identifies transistor model names
as PMOS and NMOS types. However, if you have models that were not defined using .MODEL
statements, the parser identifies them as ERROR. Instead of altering your SPICE file, you can
use this form.
To open the MOS Devices Name form, choose Custom – Custom Setup – MOS Devices
Names.
Pre-charge Clocks
Use the Pre-charge Clocks form, or the ADD NET ATTRIBUTE and ADD CLOCK commands,
to specify or delete primary inputs as clocks to transistor-MOS. To open this form, choose
Custom – Custom Setup – Pre-charge Clocks.
Click the Golden or Revised tab to switch between the two lists. The primary input list is
shown in the Pin column. Each primary input is either a system class primary input (S: name)
or a user-defined class primary input (U: name).
To add a clock to a primary input, click a primary input under the Net or Pin column to select
it, then right-click to open the pop-up menu and select Add Clock 0 or Add Clock 1.
To alphabetically sort the primary input lists, right-click in one of the columns and choose Sort
from the pop-up menu.
Click the Golden or Revised tab to switch between the two pages, where for each page,
there is a Module Name and Pin List column. All of the design’s modules are listed in the
Module Name column. All of the selected module’s boundary pins are displayed with their
current direction (IN, OUT, or IO) in the Pin List column.
To sort the displayed names, right-click in the column you want to sort to open the pop-up
menu and choose Sort.
Pre-charge Keep Clock For domino logic, regards pre-charge clocks as part of
the logic function.
MOS Direction
Use the MOS Direction form to add and delete unidirection to bidirectional MOS devices. To
open this form, choose Custom – Custom Setup – Transistor Logic Direction Settings.
Click the Golden or Revised tab to switch between the two lists.
This shows the source pin and drain pin in the respective Source and Drain fields.
3. Right-click in the Bi-Direction Instance display area to open the pop-up menu and
choose Add Direction from Source to Drain or Add Direction from Drain to Source.
The selected instance moves to the Uni-Direction Instance column.
To alphabetically sort module and MOS direction instance lists, right-click in the appropriate
column to open the pop-up menu and choose Sort.
Click the Golden or Revised tab to switch between the two lists.
All Defines power and ground ports for all modules within
the given defaults.
Also Apply to Golden/Revised Defines power and ground ports for all modules in the
Side Golden or Revised design.
Module Name Specifies the module to apply the attribute setting.
Net and Pin Specifies the module to apply the attribute setting.
To add a power or ground attribute, click a name in the Net or Pin column to select it, then
right-click to open the pop-up menu and select Add Power Attribute or Add Power
Attribute.
Design
Use the Read Design form, or the READ DESIGN command, to select and configure the
format of the design(s) to read in.
➤ Choose Custom – Data Entry – Design.
Pattern Match
Use the Pattern Match form, or the SET PATTERN MATCH command, to set the pattern
matching modules. To open this form, choose Custom – Data Entry – Pattern Match.
Set Pattern File Specifies that the name of the pattern (that was read in
with the READ PATTERN command) that will apply to
the module(s), as well as its format, type, and whether
the files are handled as case-sensitive.
You can enter the name of the file, or click the Browser
icon select a file from the Log File browser window.
Set Remodel File Specifies the name of the remodel file and its format,
type, and whether the files are handled as case-
sensitive.
You can enter the name of the file, or click the Browser
icon select a file from the Log File browser window.
Cell Remodel
Use the Cell Remodel form to read in a circuit and write it out to a Verilog format. To open this
form, choose Custom – Data Entry – Cell Remodel.
You can enter the name of the file, or click the Browser
icon select a file from the Design File browser window.
Set Remodel File Specifies the name of the remodel version netlist file.
You can enter the name of the file, or click the Browser
icon select a file from the Design File browser window.
Application Menu
Logic Abstraction
Use the Logic Abstraction form to run functional analysis on circuit netlists, which can contain
different devices, including transistors, gates, and state elements. The analysis abstracts a
logically-correct gate and a state primitive model. Use the logic model and compare it to the
RTL model for complete functional verification. You can also write out the logic model and use
it during high-performance simulation or fault grading.
➤ Choose Custom – Application – Logic Abstraction.
The Golden Module and Revised Module columns list all of the relevant design’s modules,
which you can specify for transistor abstraction.
All Abstracts logic information from all cells in the database, including
cells that are not used by the current root module.
Pure Performs basic gate abstraction, which is useful for debugging.
NO_ASM Disables the Advanced State-element Modeling (ASM) algorithm. By
default, Logic Abstraction enables the Advanced State-element
Modeling (ASM) algorithm to analyze loop structure to produce
better modeling of state elements, such as D-Latch, DFF, and bus-
keeping I/O logic.
To post abstraction information to the Transcript window, click the module name, right-click to
open the pop-up menu, and choose Abstract.
To display the schematic view, click a module name to select it, right-click to open the pop-up
menu, and choose Schematic View.
To alphabetically sort the module lists, right-click in the column to open the pop-up menu, and
choose Sort.
Click Refresh to return the displayed modules to their original numerical order or to update
the displayed hierarchy after you read in a design.
The Golden Module and Revised Module columns list all of the relevant design’s modules,
which you can specify for transistor abstraction.
All Abstracts test view information from all cells in the database,
including cells that are not used by the current root module.
Module Name Specifies the module to abstract test view information. double left-
click on the name in list to add it to this field.
The Golden Module and Revised Module columns list all of the relevant design’s modules,
which you can specify for power-aware abstraction.
Library Verification
Use the Library Verification form, or the VALIDATE LIBRARY command, to compare all top-
level cells with matching names. Conformal abstracts the modules on the SPICE side before
comparison. This application is for library verification during library design.
➤ Choose Custom – Application – Library Verification.
The Golden Module and Revised Module columns list all of the relevant design’s modules,
which you can specify for power-aware abstraction.
RAM Primitive
Use the RAM Primitive window to generate Verilog RAM primitive models.
Most of the RAM Primitive forms’s Speciality page options are the same as in the Specialty
and SRAM pages. See RAM Primitive Form Fields and Options on page 353 for more
information. Options that are unique to the Standard page are identified in the descriptions.
Most of the RAM Primitive forms’s Speciality page options are the same as in the Standard
and SRAM pages. See RAM Primitive Form Fields and Options on page 353 for more
information. Options that are unique to the Speciality page are identified in the descriptions.
Most of the RAM Primitive forms’s Speciality page options are the same as in the Standard
and Specialty pages. See RAM Primitive Form Fields and Options on page 353 and R/W
Sub-Page Fields and Options on page 355 for more information. Options that are unique to
the SRAM page are identified in the descriptions.
The following describes all fields and options for all pages of the RAM Primitive form. The
differences in each are noted.
General and Output Module Name specifies the name of the module.
Output File specifies the name of the output file.
Instance File specifies the name of the instance file.
Assertion Checking During Verilog simulation, this specifies the type of
(for the Standard and assertions to trigger for the occurrences: Ignore (the
Specialty pages) default), Warning, or Error. You can select one or more
of the following:
■ Write Collision for multiple write or red/write ports.
■ R/W Collision between different read and write or
read and read/write ports.
■ Illegal Word does not use the entire address space.
Simultaneous Read/Write Specifies the simultaneous read/write behavior. The
(for the SRAM page) default is Read then Write.
Physical Parameters Sets default values for the following physical parameters,
which you can override during instantiation:
■ Words specifies the value for the number of words
(default is 512).
■ Data Bits specifies the value for the number of bits
per word (default is 16).
■ YMUX default is 8. (This is for standard and SRAM
primitives only.)
Depending on what you specified in the Port Configuration section, Conformal displays sub-
pages (tabs) for each port. Use these to configure each of your ports.
X Decode Option Row Clock specifies a clock enable for the row decoder.
(for the Standard page).
Decode Options Address Decode specifies word lines that ere decoded
(for the Specialty page). internally.
Pre-Decode specifies word lines that were previously
decoded.
Column Option Column Clock specifies a clock enable for the column
decoder.
Bit Line Option Choose Differential, Single Wired-AND or Single
Bit Lines Wired-OR.
Out Boundary Specify whether the out boundary should be a buffer,
latch D flip-flop (DFF), or an Inverted Data Line.
For memories that do not have column MUXes, the
Inverted Data Line option brings the bit-line bar directly
out to the output and calls it <>port_doutB. For
memories with YMUXes, this option brings the bit-line
bar out and calls it <>port_doutB.
ROM Primitive
Use the ROM Primitive window to generate Verilog ROM primitive models.
➤ Choose Custom – ROM Primitive.
Click Create to generate the memory primitive, or Close to cancel your settings.
14
Conformal ECO Designer Functionality
and Methodology
An Engineering Change Order (ECO) is a change to a design after it has already been
processed, typically after place and route. There are two different types of ECOs: functional
and non-functional. Functional ECOs change the functionality of the design. Non-functional
ECOs do not change the design functionality and normally deal with timing, design rule, or
signal integrity.
For information on the Conformal ECO methodology, refer to the Conformal ECO User
Guide.
15
FPGA Capabilities and Process Flow
Overview
More and more of today’s designers are using programmable logic devices in their designs.
FPGA designs have been closing the gap on their ASIC counterparts because of
technological advancements in density and performance.
As the size and complexity for FPGA devices increase, conventional verification approaches
that many FPGA designers have been using are no longer adequate. FPGA synthesis
involves steps that are unique to FPGA devices, such as FSM recoding, aggressive
sequential optimization, memory inference, and mapping to embedded on-chip functions.
The Conformal Equivalence Checker’s FPGA feature uses FPGA-specific modeling and
analysis techniques to check functional equivalencies during the FPGA implementation
process.
The FPGA feature is targeted at designs created by the Synplicity FPGA synthesis tool,
Synplify Pro. Better integration with FPGA synthesis means that FPGA runs verification
smoother and more efficiently. The FPGA feature reads in the setup files created by Synplify
Pro, thus creating a correct verification environment for the front end. Additionally, the FPGA
feature addresses the back end by allowing you to verify gate netlists that have been through
place and route (PAR) changes within the Integrated Synthesis Environment (ISE) from
Xilinx. That is, with the FPGA feature you will compare the post-synthesis gate netlists against
the post-PAR gate netlists, thereby allowing functional closure on your designs.
Turn on
Verification Mode
Translate .vif
Files
Run
<implementation_name>.vtc
Conformal L
Yes Mismatched
Debug Results?
No
The first step in the FPGA flow is to generate a gate netlist using the Verification Mode in
Synplify Pro.
To access the Verification Mode from Synplify Pro, do one of the following:
■ Use the Synplify Pro GUI:
a. Choose Project – Implementation Options, or click the Impl Options button from
the Synplify Pro main window.
The Options for Implementation window appears.
e. Click OK.
■ Add the following line to your synthesis project file:
set_option -verification_mode 1
Synplify Pro operates in a verification mode in which it generates scripts and gate netlists
compatible with Conformal. This product records the optimizations it has performed during
synthesis in a verification interface format (VIF) file. The interface is triggered by enabling the
variables: Impl Options...Verification Mode, and Impl
Options...Implementation results...Write Verification Interface
Format (VIF) file in the GUI, or by inserting the following options in the synthesis project
file:
set_option -verification_mode 1
set_option -write_vif 1
Because Conformal does not read the VIF file directly, Synplicity provides a Tcl script called
vif2conformal.tcl to translate the content of this file to Conformal command file format.
You can run this script automatically after logic synthesis using a new mechanism available
in Synplify Pro v8.0. This mechanism provides a method to configure user-defined Tcl
commands at different times during the Synthesis process.
You can specify Tcl commands in a file called synhooks.tcl, and set the environment
variable SYN_TCL_HOOKS as follows:
SYN_TCL_HOOKS =<some path>/synhooks.tcl
The synhooks.tcl file template is available under the Synplify installation and can be
modified as required.
The following portion from the synhooks.tcl file shows how to generate Conformal-specific
side files automatically. The vif2conformal translator is available in the
<Synplify_install>/lib/ directory (accessible through the $LIB variable).
###################################################
proc syn_on_end_run {runName run_dir implName} {
Once logic Synthesis is run, Synplify Pro generates a Verification Interface File
<design>.vif in <project directory>/verif and a Verilog gate netlist
<design>.vm in the <project directory>.
The vif2conformal translation script will generate Conformal command files. For a list of these
files, see Synplify Pro Generated Setup Files on page 367.
Note: Make sure the $XILINX environment variable is defined. This environment variable
points to the Xilinx software tree where the formal verification libraries are stored.
Note: If Conformal encounters issues with any the side files, user can manually edit the
Conformal command files to fix the problem. Issues encountered in the past revolve around
register naming differences between Conformal and Synplify Pro.
After running the Conformal dofile, proceed to debug the designs if there are any
miscompares. For more information see Chapter 8, “Debugging”.
Setup files are generated when you turn on the Verification Mode for Synplify Pro (see
Generating a Gate Netlist on page 364). The files are saved in the implementation directory
that contains the output files, under /verif. Conformal uses the setup files during
verification, thus you must run Conformal from the /verif directory:
■ vtc—Synplify Pro generates this file to run Conformal verification.
■ vlc—This file links Conformal to simulation libraries for the FPGA devices. A sample
vlc file contains something similar to the following:
-y $XILINX/verilog/verplex/unisims
-y $XILINX/verilog/verplex/simprims
You must set the correct path to $XILINX before running the verification.
■ vfc, vmc, vsc—These files give Conformal FSM encoding information, mapping
information, and setup constraints.
■ vif—Verification interface in ASCII format and it contains all of the Synplify Pro
information necessary to perform verification. The vtc, vlc, vfc, vmc, and vsc files are
generated automatically using the vif file.
■ vsq—This file contains sequential constant information. The run script does not utilize
this file because Conformal performs its own sequential constant learning.
Current Capabilities
This section describes FPGA capabilities for front-end verification. The FPGA feature
supports the following:
■ Flattened comparisons
■ Verilog, VHDL, and mixed Verilog/VHDL
■ Output files from Synplify Pro 8.0 on a Sun Solaris, Linux, or Hewlett-Packard HP-UX
platform, but not output files from a Microsoft Windows platform
■ Xilinx Virtex and Spartan family of FPGA devices (Virtex, Virtex-E, Virtex-II, Virtex-II Pro,
Spartan, Spartan-II, Spartan-IIE, and Spartan-3)
■ Xilinx Alliance series (ISE 6.2 or later)
■ syn_pipeline
■ syn_allow_retiming
■ syn_tristatomux.
The following figure shows the process flow, which is described in detail in the sections that
follow.
Synthesized
EDIF Netlist
Mapped NCD
PAR
PARed NCD
NetGen
Conformal L
Yes
Debug Mismatched
No
To generate the post-PAR gate netlist from the Xilinx ISE GUI:
1. Launch the Xilinx software and create a Xilinx ISE project using the EDIF gate netlist.
2. Create a post-PAR Verilog gate netlist using the Xilinx ISE tools.
Historically, Xilinx generated flat post-PAR netlists. However, in Xilinx ISE 5.i releases (or
later), you can maintain hierarchy levels. This allows for better control over blackboxing, and
running gate-to-gate Conformal hierarchically.
To maintain a hierarchy levels, create a file called <filename>.ucf that contains the
following directive:
INST <instance_path> KEEP_HIERARCHY = TRUE;
2. Run MAP
% map <filename>.ngd -o <mapped>.ncd
3. Run PAR
% par -w <mapped>.ncd <par>.ncd <pcffile>.pcf
Note: Netgen generates extra Verilog files that represent the hierarchical models that you
want to keep.
// Flat comparison
set system mode lec
add compared points -all
compare
Xilinx Tips
This section discusses tips for using the Xilinx tools and libraries.
Xilinx distributes two verification libraries for Conformal, which you can download and copy
into your Xilinx ISE 6.2i installation:
■ UNISIMS Xilinx library—A front-end Verilog library referenced by the Synplify Pro netlist.
Note: Designers can instantiate UNISIMS models directly into their RTL code. See
Instantiating UNISIM Models Directly into RTL on page 373.
■ SIMPRIM—A back-end Verilog library for designs that have gone through map or
place-and-route.
To instantiate UNISIM models (such as DCM, clock buffers, LVDS input buffers, and
differential receivers) directly into RTL code, blackbox these instantiated blocks during the
RTL to gate comparison:
➤ Edit the Conformal command file called <design>.vtc by adding the
ADD NOTRANSLATE MODULE command before the READ DESIGN commands. For
example:
add notranslate module DCM IBUFGDS IBUFDS -both
add notranslate module RAMB* -both
.
.
If you are instantiating UNISIM models from the Synplify Pro software tree under
$SYNPLIFY_HOME/lib/xilinx/{virtex.v, virtex2.v, virtexe.v, unisim.v
etc.,}, always reference these libraries in the Synplicity Project file, as follows:
add_file -verilog "$LIB/xilinx/unisim.v"
This ensures that, when Conformal files are created from vif, the Conformal run script
<design>.vtc makes references to the Xilinx FV libraries—not the Synplicity models.
Reason being, the UNISIM models under the Synplify Pro software tree are defined as
blackboxes and, in some cases, models should not be blackboxed during the Conformal run.
This way, you have control over what gets blackboxed in the Golden and Revised design
netlists.
The Xilinx CORE Generator has a catalog of ready-made parameterized functions that range
from simple arithmetic operators (like adders, accumulators, and multipliers) to system-level
building blocks (like filters, transforms, and memory resources).
Xilinx does not provide synthesizable models for these cores, which is a prerequisite for
Conformal. Instead, Xilinx provides:
■ <block>.edn—A tailored, Xilinx implementation netlist with complete relative
placement information to guarantee performance
■ <block>.vho or <block>.veo—VHDL or Verilog instantiation code
■ <block>.vhd or <block>.v—VHDL or Verilog wrappers for simulation support
■ A schematic symbol
The lack of synthesizable models directly affects the equivalency checking flow, because the
implementation netlist generated by the Xilinx CORE generator cannot be verified against a
higher-level RTL Golden model. The assumption is that the generator creates a netlist that is
constructed correctly and that can map directly to a particular Xilinx device.
Where:
❑ <family> can be virtex, virtexe, virtex2, virtex2p, spartan2,
spartan2e, or spartan3.
❑ <platform> can be:
❍ sol—Solaris UNIX workstations
❍ lin— for Linux workstations
❍ nt for PC workstations
generates, matches the RTL hierarchy, the module interfaces (ports) do not. Thus, you cannot
run the HRC flow in Conformal—you can only run the flat (default) runs.
If you want to blackbox a portion of the hierarchy, the module boundaries/pin-out must match
in both netlists. You can specify in Synplify Pro that you want to maintain the module-interface
boundaries using the following directive:
Syn_hier = "hard"
Without this directive, blackboxing results in non-equivalencies when you run Conformal.
RAM Modeling
If you do not use the Xilinx CORE Generator to create RAM memories, you can infer the
memory in your RTL code. Synplify Pro provides directives and coding styles to infer
memories.
For RTL-to-gate comparisons, Conformal can compare distributed/select RAM memories and
single-port block RAM. Inferred dual-port block RAMs are harder to compare, and should be
blackboxed.
Distributed/select ROM implementation is supported in this flow, but mapping a ROM function
to a block RAM is not supported. To work around this, use the Xilinx CORE generator to
create the block RAM/ROM and then blackbox it for equivalence checking.
Handling Multipliers
If the RTL code contains multiplication(s), then Synplify Pro usually map them into Xilinx
MULT18X18 blocks (for Virtex2 devices). Consider the following RTL example:
module mult_11x13 (z, a, b);
output [23:0] z;
input [10:0] a;
input [12:0] b;
assign z = a * b;
endmodule
\z.bmult.multxx_genmulta.0.genmultb.genmultb.0.multx_prod [34],
\z.bmult.multxx_pbuf_0 [33], \z.bmult.multxx_pbuf_0 [32], \z.bmult.multxx_pbuf_0 [31],
\z.bmult.multxx_pbuf_0 [30], \z.bmult.multxx_pbuf_0 [29], \z.bmult.multxx_pbuf_0 [28],
\z.bmult.multxx_pbuf_0 [27], \z.bmult.multxx_pbuf_0 [26], \z.bmult.multxx_pbuf_0 [25],
\z.bmult.multxx_pbuf_0 [24], z_c[23], z_c[22], z_c[21], z_c[20], z_c[19],
z_c[18], z_c[17], z_c[16], z_c[15], z_c[14], z_c[13], z_c[12], z_c[11],
z_c[10], z_c[9], z_c[8], z_c[7], z_c[6], z_c[5], z_c[4], z_c[3], z_c[2],
z_c[1], z_c[0]}),
.A({GND, GND, GND, GND, GND, b_c[12], b_c[11], b_c[10], b_c[9], b_c[8],
b_c[7], b_c[6], b_c[5], b_c[4], b_c[3], b_c[2], b_c[1], b_c[0]}),
.B({GND, GND, GND, GND, GND, GND, GND, a_c[10], a_c[9], a_c[8], a_c[7],
a_c[6], a_c[5], a_c[4], a_c[3], a_c[2], a_c[1], a_c[0]})
);
Notice that the operands of the multiplier were swapped in the gate netlist. To successfully
compare the RTL versus the gate, add the following commands to your Conformal dofile:
> set multiplier implementation csa -Golden
> set multiplier implementation csa -swap -revised
Conformal picks the csa multiplier architecture and swaps the operands on the Revised
netlist. If the swapping fails, Conformal aborts during the comparison.
For multipliers larger than 18x18 (such as 24X24), Synplify Pro uses more than one Xilinx
multiplier block because it cannot fit in a single MULT18X18 block. In this case, comparing the
RTL versus post-synthesis will generate aborts because the structure of the two multipliers is
very different. In such cases, you can either:
■ Use the Xilinx CORE generator to generate the desired large multiplier, rather than infer
it in the RTL. This way, it can be blackboxed during the RTL-to-gate comparison.
■ Or, isolate the multiplier to its own module and then blackbox it during the RTL-to-gate
comparison.
end
end
endmodule
To work around this inconsistency, recode your RTL as follows (using the example above):
module test (clk, rst_l, a, b, q1, q2);
input clk, rst_l, a, b;
output q1, q2;
reg q1, q2;
The following reset coding style is not supported in Conformal. Consider the test case:
module test(in, clk, reset, out);
input clk, in, reset;
output out;
reg rx_reset;
reg out;
endmodule
Conformal does not support conditional expressions with asynchronous and synchronous
signals, in this case if (reset || rx_reset). (Commented in bold.)
For designs that instantiate start-up blocks, such as STARTUP_VIRTEX2, when a reset signal
other than GSR or GTS is connected to the start-up block, the synthesis tool (in the gate-level
netlist), connects this reset signal to all registers in the design. If the same behavior is not
described in the RTL model, Conformal treats the RTL and the gate-level netlist as non-
equivalent, unless the reset pin is constrained (on both designs) to 0. Consider the following
simple RTL example:
module top (in, clk, rst, out);
input in, clk, rst;
output out;
reg out;
Since the asynchronous reset signal rst is not explicitly specified in the sensitivity list of the
always statement, the register synthesized on the RTL does not have a reset connection.
This causes a mis-compare in Conformal. To work around this, add a pin constraint:
> add pin constraint 0 rst -both
Or, modify the RTL code to behave like the actual implementation:
always @(posedge clk or posedge rst) begin
if (rst) out <= 1'b0;
else
out <= in;
end
A
VHDL Support
For a list of Vital packages that are supported, see Vital Package Support on page 387.
The following table lists the RTL VHDL synthesis subset constructs that are:
■ Supported
■ Ignored
■ Unsupported
Note: The * denotes limited support. See the following section for information about
restrictions on these constructs.
Read Design
Important
You must specify all necessary VHDL files explicitly in the READ DESIGN command.
In addition, you must read in all related VHDL files in a single READ DESIGN
command.
Library Mapping
You can specify how VHDL libraries are mapped using the READ DESIGN command’s -map,
-mapfile, or -library options.
The -map and -library options work the same in that they map logical library names to
physical directories. You can use multiple -map commands to map multiple physical
directories to one logical library. Use the -mapfile option for more specific library mapping,
such as specifying that a list of files must be compiled into a specified library. If you read in a
file without specifying its library mapping, that file is stored in a default library called work in
a design space or worklib in a library space.
Note: You can map a file into more than one library. In this case, the file is stored in each
library for which it is mapped.
This section demonstrates how to use the READ DESIGN command to perform library
mapping.
library LIB2;
use LIB2.package2.all;
To achieve the Desired Library Mapping outlined in Table A-1, the READ DESIGN command
should look like one of the following:
■ read design -vhdl top.vhd -map LIB1 lib1 -map LIB2 lib2
■ read design -vhdl top.vhd -library LIB1 lib1 -library LIB2 lib2
■ read design -vhdl top.vhd \
-mapfile LIB1 lib1/pkg1.vhd lib1/pkg1_body.vhd \
-mapfile LIB2 lib2/pkg2.vhd lib2/pkg2_body.vhd
Note: The tool terminates the <file_list> for -mapfile when it encounters the next
option or the end of the READ DESIGN command. For example, the following command does
not generate the desired library mapping for this example. The tool terminates the file list at
top.vhd; because of this, top.vhd is added to the LIB2 library—not the work directory.
read design -vhdl \
-mapfile LIB1 lib1/pkg1.vhd lib1/pkg1_body.vhd \
-mapfile LIB2 lib2/pkg2.vhd lib2/pkg2_body.vhd \
top.vhd
In the following example, top.vhd is correctly added to the work library because the LIB2
file list terminates at lib2/pkg2_body.vhd.
read design -vhdl \
-mapfile LIB1 lib1/pkg1.vhd lib1/pkg1_body.vhd \
-mapfile LIB2 lib2/pkg2.vhd lib2/pkg2_body.vhd \
-Golden \
top.vhd
Architectures
Global Signal
Restriction
The Conformal software does not support a Global Signal when the design includes it in
multiple entities. When the design uses a Global Signal within an entity, it is treated as a local
signal.
Example
In the following example, the Conformal software does not support the Global Signal glob1
because it is used in two entities. See lines 10 and 19 in bold.
1. PACKAGE pack IS
3. END pack;
4.
5. USE work.pack.all;
6. ENTITY test IS
7. … END test;
9. …
12.
13. USE work. pack.all;
15. …
18. …
Configurations
Component Configuration
The Conformal GENERATE support Component Configurations for references to labels and
indices of GENERATE statements. In the following example, the Component Configuration
uses GENERATE labels and indices. See bold lines 17, 20, and 24.
4. BEGIN
6. comp_a (…);
7. END FOR;
9. comp_b (…);
11. END
12.
13. CONFIGURATION real_config OF design IS
28. END;
Nested Configurations
The Conformal software supports nested configurations and configurations with more than
one level of hierarchy. It allows multiple architectures of an entity to exist by creating new
modules with composite names created from the entity and architecture names. The
Conformal software also allows the same architecture to be configured differently internally
for different instances by creating a unique composite name for each such differing sub-
configuration.
architecture e1a0 of e1 is
begin
e1out <= ’0’;
end e1a0;
architecture e1a1 of e1 is
begin
e1out <= ’1’;
end e1a1;
architecture e2arch of e2 is
component C1 is
port (e1out : out BIT);
end component C1;
begin
e2i1 : C1 port map (e1out => e2out);
end e2arch;
-- entity e3
entity e3 is
port (e3out1, e3out2 : out BIT);
end e3;
architecture e3arch of e3 is
component C2 is
port (e2out : out BIT);
end component C2;
begin
e3i1 : C2 port map (e2out => e3out1);
e3i2 : C2 port map (e2out => e3out2);
end e3arch;
configuration e3conf of e3 is
for e3arch
for e3i1 : C2
use configuration work.e2conf; -- nested configuration
end for;
for e3i2 : C2
use entity work.e2(e2arch); -- further configuring sub-hierarchy
for e2arch
for e2i1 : C1 use entity work.e1(e1a1);
end for;
end for;
end for;
end for;
end configuration e3conf;
Declarations
Initial Value
The Conformal software supports Initial Value variables or signals with the READ DESIGN
command’s -initial_value option.
Example
In the following example, signal out1 will get the initial value of high, which is ’1’. This initial
value ’1’ will be discarded if the variable high is assigned.
1. proc1 : PROCESS is
3. BEGIN
Shared Variable
Restriction
The Conformal software does not support Shared Variables when they are declared inside a
package.
Example
In the following example, the Conformal software does not support the SHARED VARIABLE
counter because it is declared inside a package. See line 5, in bold.
1. LIBRARY IEEE;
2. USE IEEE.STD_LOGIC_1164.ALL;
3.
4. PACKAGE pack1 IS
Names
Sliced Names
Restriction
The Conformal software does not support Sliced Names when their ranges are not
computable.
Example
In the following example, the Conformal software does not support Sliced Name in0 (idx
DOWNTO 0) because input idx is not computable. See line 15, in bold.
1. ENTITY test IS
2. PORT (
3. clk : IN BIT;
7. );
8. end test;
9.
10. ARCHITECTURE arch OF test IS
11. BEGIN
13. BEGIN
Predefined Attributes
The Conformal software only supports the following Predefined Attributes:
■ LEFT ■ RIGHT
■ HIGH ■ LOW
■ RANGE ■ REVERSE_RANGE
■ LENGTH ■ ASCENDING
■ LEFTOF ■ RIGHTOF
■ PRED ■ SUCC
■ POS ■ VAL
■ BASE ■ EVENT*
■ STABLE* ■ LAST_VALUE*
■ TRANSACTION*
*See Restriction 2 on page 397.
Restriction 1
Example 1
In the following example, the Conformal software does not support the Predefined Attribute
RANGE because the variable tmp is not computable. See line 13, in bold.
1. ENTITY attributes3 IS
5. );
6. END attributes3;
7.
8. ARCHITECTURE arch OF attributes3 IS
9. BEGIN
12. BEGIN
Restriction 2
The Conformal software supports the asterisked (*) predefined attributes (shown above), but
only when they are used with synthesizable clock expressions.
Example 2a
In this example, the Conformal software supports the Predefined Attribute STABLE because
it is used in a synthesizable clock expression on line 3 (in bold).
1. PROCESS
2. BEGIN
4. ...
Example 2b
In this example, the Conformal software does not support the Predefined Attribute EVENT
because the design uses it in a non-synthesizable clock expression on line 3 (in bold).
1. PROCESS
2. BEGIN
3. IF clk’EVENT THEN
4. …
Out-of-Range Handling
■ LEFTOF ■ RIGHTOF
■ PRED ■ SUCC
■ VAL
If variable x is out-of-range, the Conformal software has two choices to interpret the attribute
value:
■ If -RANGECONSTRAINT is specified in the READ DESIGN command, (or set hdl
compiler rangeconstraint), Conformal will result dont care for attributes when ’x’
if out-of-range
■ If -RANGECONSTRAINT is not specified, the Conformal software will result a value for
attribute as following:
T’VAL(x) x itself
T’SUCC(x) T’RIGHT if T is ascending, T’LEFT is T is descending
T’PRED(x) T’LEFT if T is ascending, T’RIGHT is T is descending
T’RIGHTOF(x) T’RIGHT
T’LEFTOF(x) T’LEFT
For example:
type T is (e0, e1, e2, e3, e4, e5);
attribute ENUM_ENCODING: STRING;
attribute ENUM_ENCODING of T: type is "1100 0110 1000 0110 0100 0001";
subtype ST is T range e4 downto e1;
-- p = 0
ST’val(p) = 0000
-- x = e0 (1100)
ST’succ(x) = e4 (0100)
ST’pred(x) = e1 (0110)
ST’rightof(x) = e1 (0110)
ST’leftof(x) = e4 (0100)
-- x = e1 (0110)
ST’pred(x) = ST’rightof(x) = e1 (0110)
-- x = e4 (0100)
ST’succ(x) = ST’leftof(x) = e4 (0100)
Note: The default values of the attributes are only for the scenarios where x is a variable. If
the argument of these attributes is a constant which is out-of-range, the Conformal software
will error it out.
If you use the READ DESIGN command with the -architecture, -configuration,
-rootconfig, and -lastmod options, the Conformal software links the entity/architecture
based on the following priorities:
1. -rootconfig has the highest priority.
2. -configuration has the second priority.
3. -architecture has the third priority.
4. -lastmod is the fourth priority.
User-Defined Attributes
Restriction
Conformal ignores all User-Defined Attributes except when they are used in one of the
following forms:
■ Form A:
TYPE state_type IS (Init, State1, State2, State3);
ATTRIBUTE enum_encoding : STRING;
ATTRIBUTE enum_encoding OF state_type :
TYPE IS "0001 0010 0100 1000";
SIGNAL current_state, next_state: state_type;
■ Form B:
TYPE state_type IS (Init, State1, State2, State3);
ATTRIBUTE enum_encoding : STRING;
ATTRIBUTE enum_encoding OF state_type :
TYPE IS "Init=0001,State1=0010,State2=0100,State3=1000";
SIGNAL current_state, next_state: state_type;
Expressions
Function Calls
Restriction
The Conformal software does not support a Function Call when the function includes a WAIT
construct or clock signal.
Example
In the following example, the Conformal software does not support FUNCTION func1
because it contains a clock expression on line 3 (in bold).
2. BEGIN
4. …
Sequential Statements
Wait Statements
Caution
The Conformal software supports multiple WAIT statements. However, if
you choose to use multiple WAIT statements, Cadence recommends
verifying that the FSM encoding is what you expected.
Restriction 1
The Conformal software does not support WAIT statements used within subprograms.
Example 1
In this example, the Conformal software does not support the WAIT statement because it is
used within a procedure. See line 3, in bold.
2. BEGIN
4. …
Restriction 2
When a design uses a WAIT statement within one path of a process, all other paths of the
same process must have at least one WAIT statement.
Example 2
In this example, the Conformal software does not support the WAIT statement inside process
proc1 because the WAIT statement is used in the ELSE branch (line 18), but not in the IF
branch.
1. ENTITY test IS
2. PORT (
3. clk : IN BIT;
4. x : IN BIT;
7. );
8. END test;
9.
10. ARCHITECTURE arch OF test IS
11. BEGIN
12.
13. proc1 : PROCESS (clk,x)
14. BEGIN
17. ELSE
21.
22. END PROCESS;
Restriction 3
The Conformal software does not support the WAIT FOR statement.
Example 3
In this example, the Conformal software does not support the WAIT FOR statements in lines
4 and 6.
1. clock_gen: PROCESS
2. BEGIN
3. iclk <=’0’;
5. iclk <=’1’;
9. …
Signal Assignment
The following Signal Assignment information applies to Sequential Statements and
Concurrent Statements.
3. For guarded assignment without guard signal, the Conformal software issues the
following errors:
4. You can use the multi_port portname pragma to specify multi-port latches. In the
following example, port l1 is the multi_port:
library ieee;
use ieee.std_logic_1164.all;
entity test is
port (
a, c, g,b_init, d, s_in, inv_c :in std_logic;
l1_out, l2_out, s_out: out std_logic);
end test;
begin
-- pragma multi_port l1
load : block(c = ’1’ and g = ’1’) begin
l1 <= guarded d;
end block;
scan : block(a = ’1’) begin
l1 <= guarded s_in xor inv_c;
end block;
shft : block(b_init = ’1’) begin
l2 <= guarded l1;
end block;
Example 1
In the following example, the Conformal software does not support the GUARDED signal. See
line 2, in bold.
2. z <= GUARDED x;
3. END bb;
4. …
Restriction 1
The Conformal software ignores delay mechanisms used in signal assignments; for example,
AFTER, TRANSPORT and INERTIAL.
For example, the Conformal software ignores AFTER, INERTIAL, and TRANSPORT. See lines
1, 2, and 3.
3. Output_pin3 <= TRANSPORT Input_pin AFTER 40 ns, NOT Input_pin AFTER 70 ns;
4. …
Procedure Calls
Restriction
The Conformal software does not support Procedure Calls when the procedure includes a
WAIT construct or clock signal.
Example
this example, the Conformal software does not support PROCEDURE proc1 because it
contains a clock expression. See line 3, in bold.
2. BEGIN
4. …
For Loops
Restriction
The Conformal software does not support FOR-LOOP when the loop index range is globally
non-computable.
Example
In the following example, the Conformal software does not support the FOR-LOOP because
the input count is not computable. See line 17, in bold.
1. LIBRARY IEEE;
2. USE IEEE.STD_LOGIC_1164.ALL;
3.
4. ENTITY for_loop IS
6. clk : IN STD_LOGIC;
9. END for_loop;
10.
11. ARCHITECTURE rtl OF for_loop IS
12. BEGIN
15. BEGIN
While Loops
Restriction
Conformal does not support while loops that have loop control statements.
Example
In the following example, the while loop in line 20 is not supported because it contains a loop
control statement.
1. LIBRARY IEEE;
2. USE IEEE.STD_LOGIC_1164.ALL;
3.
4. ENTITY while_loop IS
5. PORT (data : IN STD_LOGIC_VECTOR(3 DOWNTO 0);
6. clk : IN STD_LOGIC;
7. count : IN INTEGER RANGE 0 TO 5;
8. data_out : OUT STD_LOGIC_VECTOR(3 DOWNTO 0) );
9. END while_loop;
10.
11. ARCHITECTURE rtl OF while_loop IS
12. BEGIN
13. PROCESS (clk, count)
14. VARIABLE i: integer;
15. VARIABLE data_temp : STD_LOGIC_VECTOR(3 DOWNTO 0);
16. BEGIN
17. IF (CLK'EVENT AND CLK = '1') THEN
18. i := 0;
19. WHILE(i<4) LOOP
20. NEXT WHEN i = 1;
21. data_temp(i) := data(i);
22. i := i + 1;
23. END LOOP;
24. END IF;
25. data_out <= data_temp;
26. END PROCESS;
27. END rtl;
Concurrent Statements
Signal Assignment
See Signal Assignment on page 403.
B
Verilog Support
Verilog Configurations
A configuration is an explicit set of rules that specify the exact source description to be used
to represent each instance in a design. There could be more than one model describing the
same module if they are at different levels of abstraction, such as behavioral, synthesis, and
simulation. A configuration allows you to specify which model is to be used for each instance
(or selected instances) in the design.
The Conformal software supports a subset of Verilog configurations, as defined in the Verilog
2005 Language Reference Manual. In particular, ‘hierarchical use configurations,’ liblist
ordering, and cell configurations are not supported. The namespace mapping is supported
through the READ DESIGN command’s -map and -mapfile options. The Conformal
software supports the configuration of several levels of hierarchy through instance
configurations.
The Conformal software allows Verilog modules read during READ DESIGN to be stored in a
user defined design namespace using the -map or -mapfile option. If either option is not
specified, the Verilog modules are stored in the default design namespace called ’work’. The
verilog modules read in during READ LIBRARY are automatically stored in a default library
namespace also called ’work’. Thus, ’work’ is the name of two default namespaces in
Conformal: default design namespace and default library namespace. For Liberty library
cells, the name of the library is itself the name of the namespace.
If a module is specified in the configuration along with a library name, for example,
clock_lib.clock_mod_1, then the module clock_mod_1 is searched only in the
namespace clock_lib. However, if a module work.mod_2 or simply mod_2 was specified,
then the design namespace ’work’ is first searched for module mod_2. Only if the module is
not found, is the library space ’work’ searched.
Supported Constructs
The Conformal software supports the configuration of several levels of hierarchy through
instance configurations. For example, the following instance configurations is the supported
constructs:
config cfg;
design work.top;
instance top.i1 use lib1.mybuf;
// the instance i1 of module top is bound to the module mybuf in library lib1
endconfig
Synthesizable UDPs
Conformal tools focus on synthesizable user-defined primitives (UDPs). The behavior,
however, might be different in simulation tools. For example, the following UDPs are
synthesized as the same OR gate in Conformal, but in simulation tools they might have
different behavior.
table
//A1, A2: O
1 0: 1;
0 1: 1;
1 1: 1;
0 0: 0;
endtable
table
//A1, A2: O
1 ?: 1;
? 1: 1;
0 0: 0;
endtable
There is one module mybuf in mybuf.v. The following commands will map the module
mybuf to user defined design namespace lib1/lib2 and map the module top to user
defined design namespace mywork.
read design -root top -noelab \
-mapfile lib1 lib1_src/mybuf.v \
-mapfile lib2 lib2_src/mybuf.v \
-mapfile mywork mywork_src/top.v
The following construct binds instance top.i1 to module mybuf in lib1, and binds instance
top.i2 to module mybuf in lib2 using the liblist constructs.
config cfg;
design mywork.top;
instance top.i1 liblist lib1;
instance top.i2 liblist lib2;
endconfig
Since the liblist is an unsupported construct, the workaround solution is to use instance
configuration as the following:
config cfg;
design mywork.top;
instance top.i1 use lib1.mybuf;
instance top.i2 use lib2.mybuf;
endconfig
TOP TOP
In another example, if a design whose top module has an instance i1 of module m1, and you
want to configure the instance i12 of i1 to use liberty cell m2cell from the Liberty library
cell_lib_W125_V1, you can use the following configuration:
config cfg1;
design work.top;
instance top.i1.i12 use cell_lib_W125_V1.m2cell;
endconfig
TOP TOP
i1 m1 i1 m1_1
Supported
Power Operator
Sign Conversion System Functions
Signed Based Integer Numbers
Signed Functions
Signed Reg, Net And Port Declarations
Sized And Typed Parameter Constants
Variable Vector Part Selects
Limited Support
Arrays of Instance
Conformal supports global hierarchical references to an instance of the array_instance
(for example, array_instance[0].reg1)
Attributes
Conformal supports the following attribute pragmas:
■ (* synthesis, full_case [ = <optional_value> ] *)
■ (* synthesis, parallel_case [ = <optional_value> ] *)
■ (* synthesis, black_box *) - Partial support: black box will apply to the followed module.
■ (* synthesis, async_set_reset [="signal_name1, signal_name2, ..."] *)
■ (* synthesis, fsm_state [ =<encoding_scheme> ] *)
■ (* synthesis, implementation = "<value>" *)
Real Data Types
Conformal supports real type literals mixed with integer type in constant expression
Ignored
Not Applicable
C
SystemVerilog Support
Literals
Data Types
IEEE IEEE
Status
1800-2005 1800-2005
4.3 logic (4-state) data types Supported
4.3 integer and bit (2-state) data types Supported
4.3 byte, shortint, longint Supported
4.4 short real data types Round to Int
value
4.5 void data type (see void functions 12.3.1) Void function
4.6 chandle data type Unsupported
4.7 6.16 string data type Unsupported
4.7 6.16 Parameters and localparams of strings Unsupported
4.7 6.16 string data arrays Unsupported
IEEE IEEE
Status
1800-2005 1800-2005
4.7 6.16 string operator: != Unsupported
4.7 6.16 string operator: == Unsupported
4.7 6.16 string operator: < Unsupported
4.7 6.16 string operator: <= Unsupported
4.7 6.16 string operator: > Unsupported
4.7 6.16 string operator: >= Unsupported
4.7 6.16 string operator: concat {s1,s2} Unsupported
4.7 6.16 string operator: {multiplier{s1}} Unsupported
4.7 6.16 stringo perator: str[i] Unsupported
4.7.1 string len() Unsupported
4.7.2 string putc() Unsupported
4.7.3 string getc() Unsupported
4.7.4 string toupper() Unsupported
4.7.5 string tolower() Unsupported
4.7.6 string compare() Unsupported
4.7.7 string icompare() Unsupported
4.7.8 string substr() Unsupported
4.7.9 string atoi() Unsupported
4.7.9 string atohex() Unsupported
4.7.9 string atooct() Unsupported
4.7.9 string atobin() Unsupported
4.7.10 string atoreal() Unsupported
4.7.11 string itoa() Unsupported
4.7.12 string hextoa() Unsupported
4.7.13 string octtoa() Unsupported
4.7.14 string bintoa() Unsupported
4.7.15 string realtoa() Unsupported
IEEE IEEE
Status
1800-2005 1800-2005
4.8 event data type Unsupported
4.9 User-defined types (use before called) Supported
4.9 User-defined types (interface typedef scoping) Supported
4.10 enumeration data type - 2 state Supported
4.10 enumeration data type - 4 state Supported
4.10.2 Enumeration data type (OOMR to enum constants) Supported
4.10.2 Enumeration data type shorthand (name[N]) Supported
4.10.2 Enumeration data type shorthand (name[N]=C) Supported
4.10.2 Enumeration data type shorthand (name[N:M]) Supported
4.10.2 Enumeration data type shorthand (name[N:M]=C) Supported
4.10.1 typedef enum Supported
4.10.2 enum type ranges Supported
4.10.3 enum type checking Supported
4.10.4 enum methods - numerical expressions Supported
4.10.4 enum methods - constant expression for enum Supported
constant
4.10.4.1 enum methods - first Supported
4.10.4.2 enum methods - last Supported
4.10.4.3 enum methods - next Supported
4.10.4.6 enum methods - name Supported
4.10.4.4 enum methods - prev Supported
4.10.4.5 enum methods - num Supported
4.11 Packed structure data type Supported
4.11 Packed structure data type (initializing members) Supported
4.11 Unpacked structure data type (static arrays/reals) Supported
4.11 Unpacked structure data type (string) Unsupported
4.11 Dynamic objects inside unpacked structs Unsupported
IEEE IEEE
Status
1800-2005 1800-2005
4.11 Unpacked structure data type (OOMR's to Supported
members)
4.11 Packed union data type Supported
4.11 Packed union data type (tagged) Unsupported
4.11 Unpacked Union data type Unsupported
4.11 Unpacked Union data type (tagged) Unsupported
4.12 Class data type - store object handles in dynamic Unsupported
arrays (see 5.6)
4.12 Class data type - store object handles in queues Unsupported
(see 5.14 in 1800-2005, or 7.10 in 1800-2009))
4.12 Class data type - store object handles in Unsupported
associative arrays (see 5.9)
4.12 Class data type - store object handles in mailbox Unsupported
4.14 Enum static casting Supported
4.15 $cast dynamic casting (class type) Unsupported
4.15 $cast dynamic casting (non-class type) Unsupported
4.15 $cast dynamic casting (enums) Supported
4.16 bit stream casting Supported
4.17 Default attribute type Unsupported
Arrays
IEEE IEEE
Status
1800-2005 1800-2009
5.6, 9, 14, 7.5, 6.16 Public access to QDAs and strings Unsupported
and 4.7
5.6, 9, 14, 7.5, 6.16 Local and protected access to QDAs and strings Unsupported
and 4.7
IEEE IEEE
Status
1800-2005 1800-2009
5.6, 9, 14, 7.5, 6.16 QDAs as local variables in tasks/functions/ Unsupported
and 4.7 methods
5.6 7.5 Dynamic arrays of strings Unsupported
5.9, 14, 7.8, 6.16 Queues and associative arrays of strings Unsupported
and 4.7
5.6, 9, 7.5 Hierarchical (OOMR) refereces to QDAs Unsupported
and 14
5.2 array of mailboxes Unsupported
5.2 packed arrays Supported
5.2 unpacked arrays Supported
5.2 packed arrays (slicing any dimension of Supported
multi-dimensional array)
5.4 unpacked arrays (slices) Supported
5.4 indexing of arrays Supported
5.5 7.11 array query functions Supported
5.6 7.5 dynamic arrays (details below) Unsupported
5.6 7.5 dynamic arrays of classes Unsupported
5.6 7.5 dynamic arrays in classes (public/local) Unsupported
5.6 7.5 dynamic arrays in packages Unsupported
5.6 7.5 dynamic arrays i-- multidimensional Unsupported
5.6.1 dynamic arrays with copy, resize Unsupported
5.6.1 dynamic arrays - new[] Unsupported
5.6.2 dynamic arrays - size() Unsupported
5.6.3 dynamic arrays - delete() Unsupported
5.7 array assignment Supported
5.8 arrays as arguments Supported
5.9 7.8 associative arrays Unsupported
5.9 7.8 associative arrays of classes Unsupported
IEEE IEEE
Status
1800-2005 1800-2009
5.9 7.8 associative arrays in classes (public/local) Unsupported
5.9 7.8 associative arrays in packages Unsupported
5.9.1 wildcard index types for integral types Unsupported
5.9.2 string index types Unsupported
5.9.3 class index types Unsupported
5.9.4 integer/int index types Unsupported
5.9.5 signed packed array index types Unsupported
5.9.6 unsigned packed array index types Unsupported
5.9.7 associative arrays - indextype=other user defined Unsupported
type
5.1 associative array methods Unsupported
5.1 associative array locator methods Unsupported
5.11 associative array assignment Unsupported
5.12 associative array arguments - pass by reference Unsupported
5.12 associative array arguments - pass by value Unsupported
5.13 associative array literals Unsupported
5.14 7.10 queues Unsupported
5.14 7.10 queues of classes Unsupported
5.14 7.10 queues in classes (public/local) Unsupported
5.14 7.10 queues in packages Unsupported
5.15 array manipulation methods Unsupported
Data Declarations
IEEE IEEE
Status
1800-2005 1800-2009
6.3 constants (in classes) Unsupported
IEEE IEEE
Status
1800-2005 1800-2009
6.3.3 parameterized types Supported
6.3.5 const keyword parse and ignore (non-classes) Supported
6.4 variables (var keyword support) Supported
6.6 scope/lifetime (global scope - see $root) Supported
6.6 scope/lifetime (unnamed blocks) Supported
6.6 scope/lifetime (static/auto task/function/block data) Supported
6.7 continuous assign to vars Supported
6.8 signal aliasing Supported
6.9 Type compatibility - incl passing subclass arg to Unsupported
superclass formal
6.10 6.23 Type operator Supported
Attributes
IEEE IEEE
Status
1800-2005 1800-2009
8.2 Constraint operators shift, division, modulus, Supported
exponent, logical, concat
8.3 assignment operators as statements Supported
8.3 assignment operators as expressions Supported
IEEE IEEE
Status
1800-2005 1800-2009
8.3 postincrement/decrement statements Supported
8.3 preincrement/decrement statements Supported
8.3 ++ and -- as expressions Supported
8.5 wild equality/inequality Supported
8.6 short real operators Supported
8.12 concatenation Supported
8.13 Unpacked array and structure assignment patterns Supported
except below:
8.13 assignment patterns - unpacked array Supported
8.13 assignment patterns - unpacked structure Supported
8.13 assignment patterns - left hand side assignment Supported
8.13 assignment patterns - associations by type Supported
8.13 assignment patterns - replications factors Supported
8.13 assignment patterns - simple ’ type qualification for Supported
assignments to OOMRs
8.13 assignment patterns - simple ’ type qualification for Supported
port connection expressions
8.13 Structure assignment expressions Supported
8.14 Tagged unions Unsupported
8.15 Aggregate expressions Supported
8.16 Operator Overloading Unsupported
8.17 Streaming Operators Supported
8.18 Conditional operator Supported
8.19 Set membership Unsupported
11.4.7 Logical operators - logical implication (->) and Supported
logical equivalence (<->)
11.13 let construct Supported
Procedural Statements
IEEE IEEE
Status
1800-2005 1800-2009
10.4 Selection statements - if Supported
10.4 Selection statements - case Supported
10.5.1 do while loop Supported
10.5.2 enhanced for loop Supported
10.5.3 foreach loop Supported
10.5.3 foreach loop with procedural assignment Supported
10.6 jump statements (return, break, continue) Supported
10.7 final blocks Supported
10.7 final blocks in programs Unsupported
10.8 named blocks (matching end block name) Supported
10.8 named blocks (statement labels) Supported
10.10 iff event control Supported
10.11 Level-sensitive sequence controls Unsupported
12.4 Conditional if-else statement - unique0-if Supported
12.5 Case statement - unique0-case Supported
Processes
IEEE IEEE
Status
1800-2005 1800-2009
12.1 Task/func called via OOMR Unsupported
12.1 Task/func - return object handle Unsupported
12.1 Function return - string Unsupported
12.1 Pass by value - object handles Unsupported
12.2 default function argument types Supported
12.2 default task argument types direction Supported
12.2 multiple statements without begin/end Supported
12.3 function output arguments Supported
12.3.2 void functions Supported
IEEE IEEE
Status
1800-2005 1800-2009
12.3.2 discarding func return Supported
12.4.2 Pass dynamic types by reference Supported
12.4.2 Pass strings as arguments to tasks/functions Supported
12.4.2 Pass mailboxes as arguments to tasks/functions Supported
12.4.3 Default argument values Supported
12.4.3 Default argument values (task/func referenced Unsupported
by OOMR)
12.4.4 Argument passing by name Supported
12.4.5 Optional argument list Supported
12.5 Pass ref arg of type array as actual to imported Unsupported
task/func having formal argument of type open
array
12.5 Import tasks/functions (DPI) Unsupported
12.5 Export tasks/functions (DPI) Unsupported
13.4.4 Background processes spawned by function Supported
calls - Nonblocking assignment inside a function
Classes
module Test (
input logic [7:0] Addr,
output logic Parity
);
always_comb
begin
Parity = (ParamFuncPkg::Functions
#($size(Addr))::GetParity(Addr));
end
endmodule
Synchronization
Scheduling Semantics
Clocking Blocks
IEEE IEEE
Status
1800-2005 1800-2009
14.14 Global clocking and $global_clock system function Supported
15.2 Clocking blocks (in generate loops) Unsupported
15.3 Input/output skews Unsupported
IEEE IEEE
Status
1800-2005 1800-2009
15.4 Hierarchical expressions Unsupported
15.5 Signals in multiple clocking blocks Unsupported
15.6 Clocking block scope and lifetime Unsupported
15.7 Multiple clocking blocks Unsupported
15.8 Clocking blocks inside interfaces Unsupported
15.9 Clocking block events Unsupported
15.10 Cycle delay:## Unsupported
15.11 Default clocking Unsupported
15.12 Input sampling Unsupported
15.13 Synchronous events Unsupported
15.14 Synchronous drives Unsupported
Program Blocks
Assertions
For more information, see System Verilog Assertions (SVA) on page 448.
IEEE IEEE
Status
1800-2005 1800-2009
17.2 16.3 Immediate Assertions Supported
17.4 Boolean Assertions Supported
17.5 Sequences (see specifics under 17.6 and 17.7) Unsupported
17.5 16.7 Sequences cycle delay range Supported
IEEE IEEE
Status
1800-2005 1800-2009
16.9.4 Global clocking past and future sampled value Supported
functions ($past_gclk, $rose_gclk, $fell_gclk,
$stable_gclk, and $changed_gclk)
16.9.4 Global clocking future sampled value functions Supported
($future_gclk, $rising_gclk, $falling_gclk,
$steady_gclk, and $changing_gclk)
17.6 Declaring sequences Unsupported
17.6.1 Typed formal argument in sequences Unsupported
17.7.1 Sequence operator precedence Unsupported
17.7.2 Sequence repetition in sequences Unsupported
17.7.3 Sequence sampled value functions ($rose, $fell, Supported
$stable)
17.7.4 Sequence AND operation Unsupported
17.7.5 Sequence INTERSECT operation Unsupported
17.7.6 Sequence OR operation Unsupported
17.7.7 Sequence first_match operation Unsupported
17.7.8 Sequence throughout operation Unsupported
17.7.9 Sequence within operation Unsupported
17.7.10 Sequence ended, matched, and triggered Unsupported
Manipulating data in a sequence Unsupported
17.8 Local variables of complex data types Unsupported
17.8 Local variables Unsupported
17.9 Calling subroutines on match of a sequence Unsupported
17.10 system functions ($onehot, $inset, etc) Supported
17.11 Declaring properties (see below) Unsupported
17.11 Decaring properties in a module Unsupported
17.11 Decaring properties in an interface Unsupported
17.11 Declaring properties in a clocking block Unsupported
IEEE IEEE
Status
1800-2005 1800-2009
17.11 Declaring properties in a compilation unit scope Unsupported
17.11 Declaring properties: operators NOT Supported
17.11 Declaring properties: operators AND Supported
17.11 Declaring properties: operators OR Supported
17.11 Declaring properties: operators IFELSE Supported
17.11 Declaring properties: operators |-> Supported
17.11 Declaring properties: operators |=> Supported
17.11 Typed formal arguments in property Unsupported
17.11.2 Implication Supported
17.11.4 recursive properties Unsupported
17.12.1 multiple clock support Unsupported
17.13 concurrent assertions (see below) Unsupported
17.13.1 assert statement Supported
17.13.2 assume statement Supported
17.13.3 cover statement Unsupported
17.13.5 concurrent assertions in procedural code Supported
17.14.1 clock resolution Unsupported
17.14 clocked sequences Unsupported
17.14 clock inferred from always block Supported
17.14 Default clocking Unsupported
17.15 bind directive (not including compilation unit) Unsupported
17.28 assertion control tasks ($assertion/off/kill) Unsupported
17.16 expect statement Unsupported
Coverage
IEEE IEEE
Status
1800-2005 1800-2009
23.2.2.4 Default port values Supported
Interfaces
Packages
IEEE IEEE
Status
1800-2005 1800-2009
26.6 Exporting imported names from packages - Supported
package export
Configuration Libraries
IEEE IEEE
Status
1800-2005 1800-2009
22.2 Elaboration time ’type’ keyword Unsupported
22.3 expression size ($bits) Supported
22.4 Range function $isunbounded Unsupported
22.5 shortreal conversions $shortrealtobits, Unsupported
$bitstoshortreal
22.6 array querying (see 4.5) Supported
22.7 assertion severity functions Unsupported
22.8 assertion control functions ($asserton $assertoff Unsupported
$assertkill)
22.9 assertion system functions Unsupported
22.10 Random number system functions $urandom, Unsupported
$urandom_range
22.11 Program control - need $exit() Unsupported
22.12 Coverage system functions Unsupported
22.13 New format specifiers %u %z Unsupported
22.13 $fread extensions Unsupported
22.14 $readmemb, $readmemh, Unsupported
22.15 $writememb, $writememh Unsupported
22.16 file format considerations for multidimensional Unsupported
unpacked arrays (MDUAs)
22.17 system task args for MDUAs Unsupported
VCD Data
In Verilog, the `define macro text can include a backslash ( \ ) at the end of a line to show
continuation on the next line. SystemVerilog enhances the Verilog `define text substitution
macro compiler directive as follows:
■ The macro text can include `". An `" overrides the usual lexical meaning of " and
indicates that the expansion should include an actual quotation mark. This allows string
literals to be constructed from macro arguments.
■ The macro text can include `\`". A `\`" indicates that the expansion should include
the escape sequence \".
■ The macro text can include ``. This is used to delimit an identifier name without
introducing white space. A `` delimits lexical tokens without introducing white space,
allowing identifiers to be constructed from arguments.
However, the above specification does not describe how to treat escaped Verilog 2001
identifiers that contain macro parameters.
To work around this, the Conformal software has the -KEEP_ESCAPED_ID option for the
READ DESIGN or READ LIBRARY commands.
When used, the -KEEP_ESCAPED_ID option keeps escaped identifiers, as in Verilog 2001.
to
\head_bb
APIs
IEEE IEEE
Status
1800-2005 1800-2009
33.4.3 Local parameter declaration Supported
33.4.3 Named parameter assignment Supported
Annexes
Non-std
To read in SVA constructs in the design, run the READ DESIGN command with the -sva
option. The following example shows a command sequence for reading in the SVA constructs
in the barrel_shifter.v file:
read design -Golden barrel_shifter.v -root barrel_shifter -sva
read design -revised shifter.v
set system mode lec
add compare point -all
compare
The following brief describes what the Conformal software supports for System Verilog:
■ Conformal will read all SVA constructs including property and sequence declarations
without erroring out during parsing.
■ Conformal will support assert/assume property for boolean expressions. These
assertions will be treated as constraints.
■ Simple named property instantiations are also supported. Properties can be referred to
by name inside another assertion. However, formal/actual argument passing in the
named property is not currently supported.
■ Assertions can also be embedded inside clocked always blocks.
■ Simple default clocking block is supported.
■ Sampled value functions are supported including $rose, $past, $fell, $onehot,
$stable, and so on.
■ Property operators are supported including negation, disjunction, conjunction,
implication, and if-else.
■ Binding properties are supported for properties declared inside/outside module
declaration, and in a separate file.
The following brief describes what the Conformal software does not support for System
Verilog:
■ Complex sequential assertions that span over time
■ Immediate assertions
■ Conformal ignores cover statements
■ Sequence operators
For more details, see SV-1800-2005 LRM, 17.7.3 Sampled value functions.
Default Clocking
The clocking_event option specifies the sampling clock edge for the Boolean
expressions. Conformal only handles @(posedge clk) and @(negedge clk). If the
clocking event is not specified, a default clocking must be specified. Conformal supports the
following SVA clocking statements:
clocking clocking_identifier clocking_event ;
endclocking [ : clocking_identifier ]
default clocking clocking_identifier ;
default clocking clocking_event ;
endclocking
default clocking clocking_identifier clocking_event ;
endclocking [ : clocking_identifier ]
Property Declaration
Property can be specified using the following property declaration:
property_declaration ::=
property property_identifier [ ( [ tf_port_list ] ) ] ;
[@(<clocking_event>] [ disable iff (<expression>) ] <property_expr>;
endproperty [ : property_identifier ]
For example:
property GT (x, y); @posedge clk (x > y);
endproperty
p1: assume property (GT (vec1, vec2));
// constraint (vec1 > vec2) @posedge clk
p2: assume property @ posedge clk (vec1 > vec2);
// same effect as p1 above
Property Binding
Conformal supports property binding to specific modules or instances. For more details, see
SystemVerilog LRM 17.15 “Binding properties to scopes or instances”
Binding properties are supported for properties declared, inside/outside module declaration,
and in separate file.
The <property_expr> can be any Boolean expressions, SVA system functions, SVA
sampled value functions connected by Verilog operators and the property operators: not, or,
and, |->, if-else.
The following example shows default clocking applied to the assert property:
default clocking master_clk @(posedge clk);
endclocking
assert property (b2);
Property Specification
Conformal supports the following property declaration and assert or assume property using
the declared property name. For example:
property GT (x, y);
@posedge clk (x > y);
endproperty
p1: assume property (GT (vec1, vec2)); // constraint (vec1 > vec2) @posedge clk
Conformal supports embedded SVA inside clocked always blocks. For more details, see
SystemVerilog LRM, 17.13.5 “Embedding concurrent assertions in procedural code.”
Examples
The following are two shifters. One is the normal shifter and the other is a barrel shifter.
///////////////// normal shifter ///////////////////////////
module shifter(clk, rst_n, in, shift_amoung, out);
input clk;
input rst_n;
input [7:0] in;
input [2:0] shift_amoung;
output [7:0] out;
reg [7:0] out, out_t;
always@(posedge clk or negedge rst_n) begin
if(~rst_n)
out <= #(‘delay) 8’d0;
else
out <= #(‘delay) out_t;
end
always@(shift_amoung or in) begin
if(shift_amoung[0])
out_t = in << 1;
else if(shift_amoung[1])
out_t = in << 2;
else if(shift_amoung[2])
out_t = in << 4;
else
out_t = in;
end
endmodule
///////////////// normal shifter ///////////////////////////
///////////////// barrel shifter ///////////////////////////
module barrel_shifter(clk, rst_n, in, shift_amoung, out);
input clk;
input rst_n;
input [7:0] in;
input [2:0] shift_amoung;
output [7:0] out;
reg [7:0] temp;
reg [7:0] out, out_t;
always@(posedge clk or negedge rst_n) begin
if(~rst_n)
out <= #(‘delay) 8’d0;
else
out <= #(‘delay) out_t;
end
integer i;
always@(i or shift_amoung or in or temp or out_t) begin
temp = in;
for(i=0;i<3;i=i+1) begin
if( shift_amoung[i] )
out_t = temp << (1<<i);
else
out_t = temp;
temp = out_t;
end
end
endmodule
///////////////// barrel shifter ///////////////////////////
The Conformal software reports Non-EQ results for the two shifters. It reports EQ results if
you add an "assert property ($onehot(shift_amoung));" statement to the
barrel_shifter module as follows:
///////////////// barrel shifter ///////////////////////////
module barrel_shifter(clk, rst_n, in, shift_amoung, out);
input clk;
input rst_n;
input [7:0] in;
input [2:0] shift_amoung;
output [7:0] out;
reg [7:0] temp;
reg [7:0] out, out_t;
always@(posedge clk or negedge rst_n) begin
if(~rst_n)
out <= #(‘delay) 8’d0;
else
out <= #(‘delay) out_t;
end
integer i;
always@(i or shift_amoung or in or temp or out_t) begin
temp = in;
for(i=0;i<3;i=i+1) begin
if( shift_amoung[i] )
out_t = temp << (1<<i);
else
out_t = temp;
temp = out_t;
end
end
assert property ($onehot(shift_amoung));
endmodule
///////////////// barrel shifter ///////////////////////////
With the default clocking declaration, the combination property assert property
( $onehot(sel) ) will be translated to clocked constraint assert property
( @(posedge clk) $onehot(sel) ) the same as the following assert property
specified.
////////////////////////////////////////////////////////////
module m_unique(q, d, sel, clk);
input [1:0] d;
input [2:0] sel;
input clk;
output [1:0] q;
reg [1:0] q;
always @(posedge clk) begin
case (sel)
3’b001: q <= d;
3’b010: q <= ~d;
3’b100: q <= {d[0], d[1]};
3’b111: q <= ’b0;
endcase
end
assert property ( @(posedge clk) $onehot(sel) );
endmodule
///////////////// default clocking ///////////////////////
D
Supported Directives
Supported Vendors
The following lists the supported vendors for use with the SET DIRECTIVE command to
enable or disable the specified synthesis directives when they are used with the specified
<vendor_name> prefix:
■ ambit
■ cadence
■ conformal
■ pragma
■ quickturn
■ synopsys
■ synthesis
Supported Directives
The following lists the supported directives for use with the SET DIRECTIVE command to
enable or disable the effects of the specified synthesis directives when reading in a Verilog
or VHDL file:
■ assertion_library
■ async_set_reset
■ black_box
■ built_in
■ clock_hold
■ compile_off
■ compile_on
■ dc_script_begin
■ dc_script_end
■ divider
■ enum
■ fsm_state
■ full_case
■ implementation
■ infer_latch
■ is_isolation_cell (quickturn not supported)
■ is_level_shifter
■ mem_rowselect
■ multi_port
■ multiplier
■ operand
■ parallel_case
■ power_gating_cell
■ set_implementation
■ pragma
■ state_vector
■ synthesis_off
■ synthesis_on
■ synthesis (ambit only)
■ synthesis off (ambit only)
■ synthesis on (ambit only)
■ template
■ translate_off
■ translate_on
Without this directive, the above always process results in a latch array with both clk
and we in the clock logic. And addr is used to mux between din and the old state.
Thus, with this directive, we move the addr into the clock logic of the array. This
directive is useful for register files and memory arrays.
■ infer_latch
This directive instructs Conformal to use a D-latch instead of a DFF when there is an
always statement with an edge-triggered clock. The default is to use a DFF.
Example:
always @(posedge clk) begin // conformal infer_latch
qstate = din;
end
■ multi_port
This directive instructs Conformal to synthesize a multi-port latch or register when
multiple, simultaneous definitions exist for the same state variable.
Example:
always @(clk1 or din1) if (clk1) qstate = din1;
always @(clk2 or din2) if (clk2) qstate = din2;
…
always @(clkn or dinn) if (clkn) qstate = dinn;
This sample case results in n number of latches, each with separate clocks and data
inputs and all outputs wired together. However, the implementation of a multiport cannot
be compared with an n port latch. Thus, you would use the // conformal
multi_port “qstate” directive to synthesize an n port latch with one Q output.
Internally, a primitive UDP model represents the valid function. If a simultaneous write
occurs on multiple ports and the input data on those ports is not equal, the state
becomes an X. This directive is generally used for multi-port memory arrays and custom
designs.
■ mem_rowselect
This directive supersedes the clock_hold directive. It guides memory array RTL
model synthesis so that it includes the same logic in the clock and data cones as in the
implementation. Thus, Conformal can complete equivalence checking. For example:
// conformal mem_rowselect “mem clk addr[7:5] addr[2:0]”
always @(clk or we or addr or din) begin
if (clk && we) mem[addr] = din;
end
The synthesized result creates a row decoder with address bits 7, 6, 5, and 2, 1,
0, and used clk as an enable. The addr bits 3 and 4 are used to column multiplex
input data when we is active. However, when we is not active or a column is selected,
the array data input is in a high Z state, which is representative of memory
implementation.
Note: The wildcard (*) represents any zero or more characters in filenames.
Enabling Directives
The Conformal, Synopsys, and Ambit directives are enabled by default. The Quickturn
directives are disabled by default. To recognize the Quickturn directives, you must first turn
on all of the directives for Quickturn using the following command:
set directive on quickturn
E
Conformal Sample Test Case
This appendix uses a small test case to familiarize you with the command flow of the GUI
windows. It includes step-by-step procedures to compare a Verilog gate-level non-scan
design (Golden) with the same design after inserting scan (Revised).
There is also a dofile example at the end of this appendix. See Standard Dofile Example on
page 474.
Starting Conformal
Start the Conformal software at the UNIX system prompt in the demo/doc_testcase
directory:
demo/doc_testcase% lec
For a description of the Read Library form, see Read Library Form on page 105.
2. When the Read Library window opens, keep the defaults for Format, which is set to
Verilog, and for Type, which is set to Both.
3. Select the Verilog library file (lib.v).
4. Click Add Selected.
The filename appears in the File list display.
5. Click OK to read in the Verilog library.
The Read Library form closes and the Transcript window of the main window notes that
Conformal has successfully read the Verilog library. For the purposes of this test case,
ignore warning messages noted in the transcript window as Conformal reads the library.
procedure, which directs you to open the Read Design window and prepare Conformal to
read the designs.
For a description of the Read Design form, see Read Design Form on page 109.
2. Click Format –Verilog and Type – Golden.
3. Click the Golden Verilog design, Golden.v.
4. Click Add Selected to display the filename in the File list display.
5. Click OK to read in the Golden Verilog design.
The Read Design form closes and the Transcript window of the main CONFORMAL-LEC
window notes that Conformal has successfully read the Verilog design.
For the purposes of this test case, ignore warning messages noted in the transcript
window as Conformal reads the designs.
Repeat the procedure to read in the Revised Verilog design as noted below.
1. To open the Read Design form, choose File – Read Design or click the Read Design
icon.
2. Click Format –Verilog and Type – Revised.
3. Click the Revised Verilog design, revised.v.
4. Click Add Selected to display the filename in the File list display.
5. Click OK to read in the Revised Verilog design.
The Read Design window closes and the Transcript window of the main window notes that
Conformal has successfully read the Verilog design.
For the purposes of this test case, ignore warning messages noted in the transcript window
as Conformal reads the designs.
When Conformal completes the key point mapping, it displays the following in the Transcript
window of the main CONFORMAL-LEC window:
■ Warning messages
■ Summary table of the mapped and unmapped points
In the Diagnosing a Non-Equivalent Point step, you will use the Conformal tools to examine
the unmapped and mapped points.
As you view the Unmapped Points section of the Mapping Manager, note the following:
■ Both the Golden and Revised designs have an extra primary output pin because the
names are not the same The Golden pin name is n3104gat, and the Revised pin name
is m3104gat. Do the following to manually map the unmapped points as mapped key
points.
In the Running a Comparison step, you will run a comparison on all of the mapped points to
determine whether they are equivalent or non-equivalent.
Running a Comparison
1. With the Mapping Manager still open, add all of the mapped points as compare points for
the comparison by clicking the Add All Compare Points icon in the Mapped Points
section.
The compare points are now displayed in the Compared Points section. The question
mark (?) preceding each compare point tells that Conformal has not compared these
points.
2. Compare points in the Compared Points section:
In the main window, the status bar shows the comparison’s progress (shown as a
percentage). On completion, each pair of equivalent points is denoted with a green circle.
The non-equivalent compared points are denoted with red circles. (You can specify
Check Mark indicators, if you prefer.)
3. Scroll down the Compared Points list to find the non-equivalent points, or click the
Class icon in the Compared Points section and deselect the Equivalent check box on
the pop-up menu.
The simulation values for the Golden and Revised designs are displayed in the
Diagnosis Point (active) section. Notice that the simulation values for the Golden and
Revised designs, which are shown in parenthesis ( ), are not the same. The
simulation value for the Revised design is one, while the value for the Golden design
is zero.
❑ Corresponding Support
This section displays the corresponding support key point of the diagnosis point for
both the Golden and Revised designs.
❑ Non-corresponding Support
This section displays the non-corresponding support key point of the diagnosis point
for both the Golden and Revised designs.
The corresponding and non-corresponding support key points are the logic fan-in cone
key points of the diagnosis point.
Support points are color coded as follows:
❑ Red—The support point is a non-equivalent compare point
❑ Green—The support point is an equivalent compare point
❑ Black—The support point either has not been compared yet or cannot be compared
(for example, PI)
Do the following to see the difference in simulation values for the diagnosis points.
1. Click any error pattern in the list (for example, Error Pattern 5).
2. Click another error pattern and examine the change in simulation values listed in the
Corresponding Support section. (Values are shown in parenthesis.)
Next, you will examine the Error Candidate section to try to determine the cause of this
difference.
Opening the Schematic Viewer continues the diagnosis procedure. It describes how you will
access the schematic viewer to examine a schematic representation of the diagnosis point.
To view a schematic representation of the diagnosis point along with the logic fan-in cone for
both the Golden and Revised designs, click on the Schematic icon on the Diagnosis
Manager menu bar.
The schematic viewer opens with two separate windows for the Golden and Revised DFF
logic cones.
In the Golden schematic representation (Figure E-1 on page 470), the NOR gate leads to the
D input of the D flip-flop. In the Revised schematic representation (Figure E-2 on page 471),
the NOR gate also leads to the D input of the MUX-DFF gate. Notice the simulation value
differences.
In the Revised schematic representation, the select line (scan_en) of the MUX gate is
selecting the scan path instead of the functional path. To see the select line, click the net of
the select line of the MUX gate to highlight the scan_en signal.
From your examination of the design, you can see that you must constrain the scan_en pin
to the functional path of the MUX-DFF gate. With this constraint, the non-equivalent point
becomes equivalent. (Also notice that the scan_en pin was listed as a Non-corresponding
Support point in the Revised column of the Diagnosis Manager.)
In the Adding Pin Constraints,step, you will add the pin constraint that disable the scan logic
that was introduced into the Revised design through the and flow. Before proceeding this
step, use the following information to close the Diagnosis Manager and the Schematic Viewer.
1. Click Cancel in the Diagnosis Manager.
2. Use a schematic viewer File drop-down menu to close one schematic window, and its
complementary window closes as well.
In Rerunning the Comparison, Conformal will compare with the newly added pin constraint.
When Conformal completes the comparison, the summary table displayed in the Transcript
window of the main CONFORMAL-LEC window shows that all compared points are
equivalent. Do the following to see that Conformal also displays this information in the
Mapping Manager.
2. In the Mapping Manager, scroll down the Compared Points section to confirm that
each compared point is preceded by a green circle.
Note: When you added the pin constraint you remedied all of the non-equivalent
points.
Exiting
Now that you have verified that the Golden and Revised designs are equivalent, exit
Conformal by doing the following:
1. Choose File – Exit.
The exit confirmation dialog box opens to confirm the exit.
2. Click Yes.
F
Top-level IO Port Modeling
When a top-level port is declared as an inout (IO) port, the Conformal software must verify it
as both an input port and an output port. In static equivalency checking, all possible modes
of operation are verified regardless of how the module was internally configured. Each top-
level IO port is also replaced by three ports (two inputs and one output) in the flattened
design.
The following figure shows a typical IO port configuration where EO, DO, DI are internal
signals and PAD is the top-level IO port. In actual operations, EO is either (i) HIGH and PAD
acts as an output port for DO, or (ii) LOW and PAD acts as an input port to DI. In proper
operations, PAD must not be driven when it is operating as an output port.
The original PAD port is now an internal signal. The software adds separate input and output
ports (with the same name) that correspond to the inout PAD port. The software also adds an
input port PAD_z which tristates the testers output when it is HIGH.
Because the internal PAD signal is now connected to two output devices, it becomes a wire
resolution node. The software creates wire resolution logics which combine the signals EO,
DO, PAD(input)and PAD_z, and produces the two signals driving DI and PAD(output).
Because the buffer in the circuit on the right blocks the tristate output of the tristate driver, DI
and PAD(output) are not the same signals. In particular, PAD(output) is subjected to
output tristate (output-Z) verification so that the following circuits are non-equivalent:
G
Conformal Primitive Gate Types
The following lists the primitive gate types that are used in the Conformal software.
Note: Although the primitives are listed below in all uppercase, Conformal primitives are case
insensitive.