Aborted Points

Printed in Japan
Users Manual

SYSTEM LSI DESIGN
OPENCAD
TM

Formality
Interface
Document No. A14968EJ4V0UM00 (4th edition)
Date Published August 2007 NS
2003

Users Manual A14968EJ4V0UM 2
[MEMO]


OPENCAD is a trademark of NEC Electronics Corporation.
Formality, DesignWare, and PrimeTime are registered trademarks of Synopsys, Inc. in the United States.
Design Compiler is a registered trademark of Synopsys, Inc. in Japan.
Verilog is a registered trademark of Cadence Design Systems, Inc. in the United States.
UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open
Company Limited.
Power Compiler is a trademark of Synopsys, Inc.
Adobe and Acrobat are trademarks of Adobe Systems Incorporated.


The information in this document is current as of August, 2007. The information is subject to
change without notice. For actual design-in, refer to the latest publications of NEC Electronics data
sheets or data books, etc., for the most up-to-date specifications of NEC Electronics products. Not
all products and/or types are available in every country. Please check with an NEC Electronics sales
representative for availability and additional information.
No part of this document may be copied or reproduced in any form or by any means without the prior
written consent of NEC Electronics. NEC Electronics assumes no responsibility for any errors that may
appear in this document.
NEC Electronics does not assume any liability for infringement of patents, copyrights or other intellectual
property rights of third parties by or arising from the use of NEC Electronics products listed in this document
or any other liability arising from the use of such products. No license, express, implied or otherwise, is
granted under any patents, copyrights or other intellectual property rights of NEC Electronics or others.
Descriptions of circuits, software and other related information in this document are provided for illustrative
purposes in semiconductor product operation and application examples. The incorporation of these
circuits, software and information in the design of a customer's equipment shall be done under the full
responsibility of the customer. NEC Electronics assumes no responsibility for any losses incurred by
customers or third parties arising from the use of these circuits, software and information.
While NEC Electronics endeavors to enhance the quality, reliability and safety of NEC Electronics products,
customers agree and acknowledge that the possibility of defects thereof cannot be eliminated entirely. To
minimize risks of damage to property or injury (including death) to persons arising from defects in NEC
Electronics products, customers must incorporate sufficient safety measures in their design, such as
redundancy, fire-containment and anti-failure features.
NEC Electronics products are classified into the following three quality grades: "Standard", "Special" and
"Specific".
The "Specific" quality grade applies only to NEC Electronics products developed based on a customer-
designated "quality assurance program" for a specific application. The recommended applications of an NEC
Electronics product depend on its quality grade, as indicated below. Customers must check the quality grade of
each NEC Electronics product before using it in a particular application.
The quality grade of NEC Electronics products is "Standard" unless otherwise expressly specified in NEC
Electronics data sheets or data books, etc. If customers wish to use NEC Electronics products in applications
not intended by NEC Electronics, they must contact an NEC Electronics sales representative in advance to
determine NEC Electronics' willingness to support a given application.
(Note)
M8E 02. 11-1

(1)
(2)
"NEC Electronics" as used in this statement means NEC Electronics Corporation and also includes its
majority-owned subsidiaries.
"NEC Electronics products" means any product developed or manufactured by or for NEC Electronics (as
defined above).
Computers, office equipment, communications equipment, test and measurement equipment, audio
and visual equipment, home electronic appliances, machine tools, personal electronic equipment
and industrial robots.
Transportation equipment (automobiles, trains, ships, etc.), traffic control systems, anti-disaster
systems, anti-crime systems, safety equipment and medical equipment (not specifically designed
for life support).
Aircraft, aerospace equipment, submersible repeaters, nuclear reactor control systems, life
support systems and medical equipment for life support, etc.
"Standard":
"Special":
"Specific":

Major Revisions in This Edition
Page Description
p.23 2.2 Tool Restrictions
Addition of (3)
pp.28, 29 2.4 Known Problems
Addition of (3)
p.36 3.3 Creating and Using Library for Compiled Memory
Addition of Caution
p.50 4.2.2 Execution of Formality
Modification of execution example
pp.61, 62 Addition of 5.4 Compiled Memory Bus Wrapper
p.91 Table A-6. Outline of Output File
Addition and modification of description
The mark <R> shows major revised points.
The revised points can be easily searched by copying an "<R>" in the PDF file and specifying it in the "Find what:" field.

To obtain the latest documents when designing, contact an NEC Electronics sales office or a distributor.

PREFACE
This manual assumes that OPENCAD has already been installed. If OPENCAD has not been installed, first install
OPENCAD and then read this manual.
To enable LSI design projects to proceed in a timely manner, read this manual carefully.
Be sure to follow the specifications described in this manual (including general items, caution points, and
restrictions). Failure to do so may result in poor quality, poor performance, or operation faults in LSI products.
When designing NEC Electronics ASICs, several restrictions apply concerning circuit design. For information about
these restrictions, read this manual together with the design manual for the corresponding ASIC series.
The commands and logs for Formality described in this manual are based on Formality version 2001.08. When
using another version, read this manual taking the contents of that version as the relevant contents

Readers This manual is intended for users who will design ASICs with the OPENCAD system
using Synopsys formal verification tool Formality.

How to Read This Manual It is assumed that the reader of this manual has general knowledge of electrical
engineering, logical circuits, and microcontrollers. Readers who want to understand
Formality should read this manual according to the contents.

Conventions Note: Footnote for item marked with Note in the text.
Caution: Information requiring particular attention
Remark: Supplementary information

Related Documents The users manual and reference manual for Formality are issued by Synopsys.
Therefore, this manual describes only those items related to OPENCAD. Refer to the
relevant manual for details of other items such as commands.

Document name Description
Formality
User Guide
Supplied by Synopsys.
A PDF file of this manual is available under the Formality
installation directory (<FM_inst_dir>/doc/fm). View this manual
using Adobe
Acrobat
Reader.
Formality
On Line Manual
(Man Page)
Online manual for Formality.
Use this to check the commands, variables, and messages of
Formality.
This can be read in the same way as the UNIX
man command.
Execute the man command to read this manual on Formality.
To read this manual on UNIX, add <FM_inst_dir>/doc/fm/man to
the environmental variable MANPATH and execute the UNIX man
command.
Block Library Supplied by NEC Electronics.
This manual contains the block names and truth tables released
for each technology. Use this manual when checking the block
functions.

Terminology The following terms are used in this manual.

Term Description
Reference circuit A circuit of which operation has been verified.
Implementation circuit A circuit obtained by modifying a reference circuit. For formal verification, it is compared with the
reference circuit to verify that its logic is correct. When executing a tool, it has to be recognized
which is the reference circuit and which is the implementation circuit. For example, if the circuit
includes don't care or wired net, the results of verification may be different.
Container Data area for Formality in which circuit information and libraries are stored. Prepare a container
for each circuit. All information contained in the circuit must be stored in the same container.
ContainerID indicates the name of each container.
LibraryID
DesignID
ObjectID
In Formality, LibraryID indicates the name of the library in which the library and circuit are stored.
If no library name is specified, they are stored in WORK. DesignID indicates the name of a
circuit (hierarchy), and ObjectID indicates the name of a port, net, or register. To specify a circuit,
hierarchy, or port in the setting commands for Formality, specify DesignID or ObjectID instead of
an instance path name. Describe this in the following format.

To specify a circuit or hierarchy: <ContainerID>:/<LibraryID>/<DesignID>
To specify a port: <ContainerID>:/<LibraryID>/<DesignID>/<ObjectID>

The translate_instance_pathname command (command that translates an instance path name
to DesignID or ObjectID) enables setting using an instance name.
Example of executing setting command
Setting command [trans <ContainerID>:/<LibraryID>/instance-path-name]
Cut Point A Gate that is internally made by Formality to cut a combination loop.
Compare Point The output section of a logic cone. It is also known as a verification point. An external output pin,
register, input pin of a black box, and cut point can be a compare point. Verification is executed
for each compare point.
Matched Point A corresponding compare point between two circuits.
Unmatched Point A non-corresponding compare point between two circuits. It contains a point which exists only in
one of the circuits or a point that failed to correspond.
Abort To stop verification midway due to restrictions of the memory or CPU time. The result of
verification at the point it was aborted is match, mismatch, or unknown.
Diagnose When mismatch is the result of verification, simulation can be performed by the diagnose
command in order to indicate a candidate error. It indicates the net or instance that seems likely
to have caused the mismatch.
TESTACT A DFT tool made by NEC Electronics that inserts a test circuit for boundary scan, RAM BIST, and
test bus (macro separation test).
NEC BSCAN A DFT tool made by NEC Electronics that inserts a boundary scan circuit.
NEC BIST A DFT tool made by NEC Electronics that inserts a RAM BIST (built-in self test) circuit.
TESTBUS A DFT tool made by NEC Electronics that inserts a test bus (macro separation test) circuit.
NEC SCAN2 A DFT tool made by NEC Electronics that inserts a scan path circuit.
Design Compiler
A logic synthesis tool made by Synopsys. Design Compiler is the target logic synthesis tool in
OPENCAD.
PrimeTime
A static timing analyzer made by Synopsys. In an OPENCAD environment, PrimeTime and

Formality use the same library in Synopsys DB format.

CONTENTS

CHAPTER 1 INTRODUCTION..................................................................................................................13
1.1 Explanation of Formal Verification............................................................................................. 13
1.1.1 Property check and logic equivalency check..................................................................................... 13
1.1.2 Verification method............................................................................................................................ 14
1.1.3 Correspondence of verification points ............................................................................................... 15
1.1.4 Black box........................................................................................................................................... 15
1.1.5 Bus holder ......................................................................................................................................... 15
1.1.6 Handling of logical value X................................................................................................................ 16
1.1.7 Analysis of mismatch point (simulation) ............................................................................................ 16
1.2 Positioning of Formal Verification in Design Flow................................................................... 17
1.2.1 Positioning of formal verification in design flow................................................................................. 17
1.2.2 Supported verification levels.............................................................................................................. 18
1.3 Formality Execution Flow............................................................................................................ 19
1.4 Operating Environment ............................................................................................................... 20

CHAPTER 2 RESTRICTIONS ..................................................................................................................21
2.1 Circuit Restrictions ...................................................................................................................... 21
2.2 Tool Restrictions .......................................................................................................................... 23
2.3 Library Restrictions...................................................................................................................... 24
2.4 Known Problems .......................................................................................................................... 25

CHAPTER 3 LIBRARY .............................................................................................................................30
3.1 Library Structure .......................................................................................................................... 30
3.2 Creating Formality Setup File ..................................................................................................... 32
3.2.1 OPENCAD environment setting ........................................................................................................ 32
3.2.2 Execution of GUI menu (execution of OPC_FORMALITY) ............................................................... 34
3.3 Creating and Using Library for Compiled Memory................................................................... 36

CHAPTER 4 Formality EXECUTION PROCEDURE.............................................................................39
4.1 Procedure in OPENCAD Environment ....................................................................................... 39
4.1.1 Creation of script file (execution of OPC_FORMALITY).................................................................... 39
4.1.2 Example of script file ......................................................................................................................... 41
4.2 Procedure of Formality................................................................................................................ 42
4.2.1 Command flow .................................................................................................................................. 42
4.2.2 Execution of Formality....................................................................................................................... 50
4.3 Formality Messages to Be Noted................................................................................................ 50
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW...............................52
5.1 (Recommended) Logic Synthesis Method ................................................................................ 52
5.1.1 Logic synthesis facilitating verification................................................................................................52
5.1.2 Two-stage verification before and after logic synthesis......................................................................53
5.1.3 change_names -log option.................................................................................................................54
5.1.4 Bus naming rule .................................................................................................................................55
5.1.5 Array of hierarchy pins (VHDL) ..........................................................................................................56
5.1.6 ungroup..............................................................................................................................................57
5.1.7 Optimization of hierarchy boundary....................................................................................................58
5.2 Complex Computing Unit ............................................................................................................ 59
5.3 Instantiated DesignWare ............................................................................................................. 60
5.4 Compiled Memory Bus Wrapper................................................................................................. 61
5.5 Verification Before and After Retiming...................................................................................... 63
5.6 Verification of Clock-Gated Circuit............................................................................................. 64
5.7 Verification Before and After DFT Execution............................................................................ 66
5.7.1 TESTACT...........................................................................................................................................67
5.7.2 NEC BSCAN......................................................................................................................................67
5.7.3 NEC BIST (RAM BIST) ......................................................................................................................67
5.7.4 TESTBUS ..........................................................................................................................................68
5.7.5 Scan path tool made by EDA vendor .................................................................................................68
5.7.6 NEC SCAN2 ......................................................................................................................................68
5.7.7 Verification before and after scan rechaining.....................................................................................69
5.7.8 Verification before and after eFuse circuit insertion ...........................................................................69
5.8 Handling of Bus Holder ............................................................................................................... 70
5.9 Combination Loop Check............................................................................................................ 72
5.10 Formal Verification Following ECO.......................................................................................... 74

CHAPTER 6 EXAMPLE OF EXECUTION OF Formality....................................................................75
6.1 Example of Execution of Combination Circuit.......................................................................... 75
6.2 Example of Verification Before and After Scan Path Circuit Insertion................................... 79
6.2.1 Verification with default setting...........................................................................................................80
6.2.2 Debugging of mismatch points...........................................................................................................82
6.2.3 Re-verification after setting normal mode...........................................................................................85

APPENDIX A EXPLANATION OF OPC_FORMALITY..........................................................................86
A.1 Method of Execution ................................................................................................................... 86
A.2 OPC_FORMALITY Interface........................................................................................................ 87
A.2.1 Explanation of options .......................................................................................................................87
A.2.2 Output file ..........................................................................................................................................91
A.3 OPENCAD Environment Variables............................................................................................. 92
A.4 Return Values............................................................................................................................... 92
A.5 Error Messages............................................................................................................................ 93
APPENDIX B EXPLANATION OF GUI MENU......................................................................................94
B.1 Menu Structure............................................................................................................................. 95
B.2 Main Menu .................................................................................................................................... 96
B.3 Formality Execution Menu.......................................................................................................... 97
B.4 Reference Circuit Setting Menu ................................................................................................. 98
B.5 Implementation Circuit Setting Menu........................................................................................ 99
B.6 Test Control Pin Information File Name Setting Menu .......................................................... 100

LIST OF FIGURES

Figure No. Title Page

1-1 Composition of Logic Cone............................................................................................................................. 14
1-2 Example of Equivalent Circuits ....................................................................................................................... 14
1-3 Design Flow.................................................................................................................................................... 17
1-4 Formality Execution Flow................................................................................................................................ 19

2-1 Constant Propagation If Black Box Exists on the Propagation Path............................................................... 24
2-2 Constant Propagation If Constant Is Set As Output of Black Box................................................................... 24

3-1 GUI Screen for Setting OPENCAD Environment ............................................................................................ 33
3-2 GUI Menu for Creating Formality Setup File................................................................................................... 34
3-3 GUI Screen of Compiled Memory................................................................................................................... 36

5-1 Two-Stage Verification Flow........................................................................................................................... 53
5-2 Example of Changing Direction of Vector of Pin............................................................................................. 56
5-3 Example of Optimization of Hierarchic Boundary ........................................................................................... 58
5-4 Hierarchical Structure When the Bus Wrapper for Redundant RAM with a Soft Wrapper Is Used................. 62
5-5 Example of Circuit in Which Inverter Is Moved ............................................................................................... 63
5-6 Clock Gating................................................................................................................................................... 64
5-7 Enable Logic................................................................................................................................................... 65
5-8 DFT and Formal Verification Flow .................................................................................................................. 66
5-9 Example of Bus Holder Circuit ........................................................................................................................ 70
5-10 Formal Verification Flow Following ECO ........................................................................................................ 74

6-1 Example of Combination Circuit ..................................................................................................................... 75
6-2 Debug Screens............................................................................................................................................... 78
6-3 Example of Scan Path Circuit Insertion .......................................................................................................... 79
6-4 Mismatch Point Report ................................................................................................................................... 82
6-5 Error Candidate Report................................................................................................................................... 83
6-6 Mismatch Point Report ................................................................................................................................... 84

B-1 Front End Design Menu.................................................................................................................................. 94
B-2 GUI Menu Structure........................................................................................................................................ 95
B-3 Main Menu ..................................................................................................................................................... 96
B-4 Formality Execution Menu .............................................................................................................................. 97
B-5 Reference Circuit Setting Menu...................................................................................................................... 98
B-6 Implementation Circuit Setting Menu.............................................................................................................. 99
B-7 Test Control Pin Information File Name Setting Menu (TESTACT) .............................................................. 100
B-8 Test Control Pin Information File Name Setting Menu (NEC BIST and NEC BSCAN) ................................. 101

LIST OF TABLES

Table No. Title Page

1-1 Explanation of I/O Files................................................................................................................................... 20
1-2 Operating Environment ................................................................................................................................... 20

2-1 Test Clock Pin Name ...................................................................................................................................... 25
2-2 Correspondence Between Specified Library Names and Formality Library Files ........................................... 27

5-1 File Restrictions of rename_object_file ........................................................................................................... 54

A-1 Explanation of Options (Creation of Formality Setup File) .............................................................................. 88
A-2 Explanation of Options (Specification of Circuit Information) .......................................................................... 88
A-3 Explanation of Options (Specification of Test Control Pin Information File) .................................................... 89
A-4 Explanation of Options (Specification of OPC_FORMALITY Operation and Output File Name) .................... 90
A-5 Explanation of Options (Other) ....................................................................................................................... 90
A-6 Outline of Output File...................................................................................................................................... 91
A-7 OPENCAD Environment Variables ................................................................................................................. 92

CHAPTER 1 INTRODUCTION

This manual describes the usage method and cautions that apply when using Formality (formal verification tool)
from Synopsys in an OPENCAD environment.

In the OPENCAD environment, the following are provided for Formality.
Library
Shell script, GUI menu (support creation of a Formality setup file and a script file for Formality)
This manual

1.1 Explanation of Formal Verification

This section outlines formal verification.

1.1.1 Property check and logic equivalency check
Formal verification means the mathematical verification of the logic of a circuit, and is mainly used to execute the
following two checks.

Property check
Logic equivalency check

The property check means checking whether the circuit is made in compliance with the specifications. Each
property check tool has a language that describes the properties. The user describes the properties and verifies that
the circuit is operating correctly by comparing its properties with those of the circuit using the tool.

On the other hand, the logic equivalency check verifies whether the logic of two circuits is correct. For example, a
circuit that has been proven to be operating in compliance with the specifications (termed reference circuit in
Formality) and a modified reference circuit (termed implementation circuit in Formality) are prepared and it is checked
whether the former is logically equivalent to the latter. If it is proved to be equivalent, it can be said that the
implementation circuit is operating correctly.

In the past, logic was verified by Gate-level simulation each time the circuit was modified. However, verification
can now be performed using a logic equivalency check tool. When circuit operations are verified by simulation or a
property simulation tool at the RTL stage, logic verification of the subsequent design, in terms of logic equivalency
verification of two circuits, can be performed before and after logic synthesis, test circuit insertion, or layout. The time
required for logic equivalency verification depends on the scale of the circuit, complexity of the logic, and degree of
circuit modification, but the TAT can be greatly shortened compared to the gate-level simulation.

Formality is a program that checks logic equivalency in formal verification.
Hereafter, unless otherwise stated, formal verification means the logic equivalency check.
1.1.2 Verification method
This section describes the general verification method for formal verification.

(1) The two circuits to be compared are divided into external pins, registers, and black boxes (verification points)
to create a logic cone composed of combination logic (refer to Figure 1-1).

(2) The logic in the logic cone is converted into logical information such as a BDD (Binary Decision Diagram) to
verify the logic equivalency of the logic cones corresponding to the two circuits.

(3) If the logic is proved to be equivalent in all the logic cones, it means the two circuits are logically equivalent.

Figure 1-1. Composition of Logic Cone

When the circuit in Figure 1-2 is verified, it is reported the logic is equivalent in each of them. However, formal
verification only tells whether the logic of two circuits is equivalent or not. Other information on circuit modification
such as a buffer is added or two inverters are inserted cannot be ascertained.

Figure 1-2. Example of Equivalent Circuits

H
L
Level generator
H
L
L
H
S
R
S
R
1.1.3 Correspondence of verification points
In order to correctly verify the logic of each logic cone, correct correspondence between the verification points to be
compared on the two circuits must be made. A non-corresponding verification point has no counterpart for
comparison, and is therefore not verified. Consequently, the setting of which section is to be verified or not verified is
very important for formal verification. Therefore, care must be taken with the correspondence status of verification
points reported by the tool.
The following methods can be employed to ensure correspondence.

(1) Names of verification points
The simplest method is that correspondence is made between those verification points with the same names
as keys. Consequently, names must not be changed greatly when modifying the circuit.

(2) Logical structure
Corresponding verification points can be found by checking the logical structure of circuit. Note that a longer
execution time than name-based correspondence is necessary.

(3) User setting
When there are verification points whose correspondence cannot be made by the tool using the above two
methods, the user must set the modification rules for the names and specify their correspondence.

1.1.4 Black box
A black box means a model that is defined only by a pin and for which there is no internal logic.
The current libraries for Formality are created based on logically synthesized libraries, and therefore there are
macro blocks such as memories and cores for which logic cannot be defined. Furthermore, when there is no
description for a hierarchy in a design file, this becomes an unknown section for the formal verification tool. These
are handled as a black box and their internal logic is not to be verified.
However, in Formality, each input pin of a black box that exists with the same instance name on both circuits to be
compared is handled as a verification point to verify the logic of its periphery. When the number of pins of the black
box and the pin names of two circuits are equal and the logic of the logic cone of the input pins matches, the black box
is determined as equivalent.
In this way, Formality has a verification method that determines the equivalence of a black box according to the
relationship between the instance name of the black box and the boundary and a verification method that checks that
the block name (or hierarchy name) of the black box itself is the same. For the setting of these verification methods,
refer to the explanation of the Formality variable verification_blackbox_match_mode in 4.2.1 (2) Initial setting.

1.1.5 Bus holder
The bus holder is a device that holds the level of a bus net. It is defined by a black box model in a library of
Formality. Consequently, if the number of bus holders is not equal in two circuits, it is reported as a mismatch. For
the verification methods before and after bus holders are added, refer to 5.8 Handling of Bus Holder.

1.1.6 Handling of logical value X
The meaning of logical value X may be dont care (no problem occurs regardless of the value assigned to a
specific node) or undefined (the value of the node is not determined).
For example, the logical value X is also X assignment in RTL, or is generated in the case of a logical collision due
to an error in the bus net control conditions or when the clock pin of a register is clamped. Formality can treat the
logical value X as both dont care and undefined. For the setting of the method for verifying these, refer to the
explanation of the Formality variable verification_passing_mode in 4.2.1 (2) Initial setting.

1.1.7 Analysis of mismatch point (simulation)
When a mismatch is detected as the result of verification, its cause must be analyzed.
The basic debug method is to perform simulation for a logic cone in which a mismatch was detected. Formality
creates a test pattern indicating the mismatch for the logic cone. The test pattern is not executed in normal logic
simulation, but can be used only by the diagnose command of Formality. Furthermore, on the GUI of Formality, the
circuit structure of the logic cone is indicated, and thus, based on the result of diagnose, the portions that seem to
cause the mismatch are displayed in different colors on the schematic diagram.
1.2 Positioning of Formal Verification in Design Flow

1.2.1 Positioning of formal verification in design flow
Formal verification is positioned in the design flow as shown in Figure 1-3.
Although formal verification is shown in three places in Figure 1-3, it is recommended to execute formal verification
each time the circuit is modified. When verification is executed for a small modification, it is easier than verifying
many modifications at one time and thus the total execution time can be shortened. Furthermore, when a mismatch is
detected, debugging can be performed more easily and the degree of back-track to the design flow due to circuit
modification can be minimized.

Figure 1-3. Design Flow

RTL
RTL check
RTL
RTL simulation
Logic synthesis
GATE
Test circuit insertion
Scan circuit insertion
Design criteria check
Circuit configuration check
Estimated wiring delay calculation
STA
GATE SDF Restriction
GATE Restriction
1st sign-off
Layout
SI/EM check
Design criteria check
Circuit configuration check
Actual wiring delay calculation
STA
GATE SDF Restriction
GATE Restriction
2nd sign-off
1st sign-off
Layout verification
EB processing
F
o
r
m
a
l

v
e
r
i
f
i
c
a
t
i
o
n
F
o
r
m
a
l

v
e
r
i
f
i
c
a
t
i
o
n
F
o
r
m
a
l

v
e
r
i
f
i
c
a
t
i
o
n

1.2.2 Supported verification levels
OPENCAD supports the following formal verifications.

RTL vs GATE verification
GATE vs GATE verification

The relevant designs and cautions are explained for these verification levels below.

(1) RTL vs GATE verification
Use a design that is the target of logic synthesis for a RTL.
Formality cannot handle a description of the behavior level. Consequently, use an RTL instantiated for
logic synthesis rather than for simulation as the module of the compiled memory and the model of the core
provided by NEC Electronics.
The formats in which RTL can be input are Verilog
-HDL and VHDL.

Verification is more difficult for RTL vs GATE than for GATE vs GATE, so it is recommended to verify in the
units of logic synthesis rather than verifying the entire chip at one time.

(2) GATE vs GATE verification
The formats in which GATE can be input are Verilog-HDL, VHDL, and EDIF
Note
.

Note Another format PWC is also used for OPENCAD, but this format is unique to NEC Electronics, so
convert the PWC format beforehand to a format that can be input, by using a netlist conversion tool
(e.g., Netlist Utilities in the OPENCAD environment).

(3) Other cautions
Design at the transistor level is not supported.
Formality itself cannot handle design at the transistor level.
The entire chip can be verified at one time.
When the circuit is modified within a hierarchy, verification can be executed for each hierarchy.
When logic moves beyond a hierarchy or the number of hierarchy pins increases/decreases, verification
must not be executed for these hierarchies. If verification is executed, an unnecessary mismatch is
reported.
As a countermeasure, start verification from a hierarchy higher than the one in which the modification took
place.
When the same file is used for a reference circuit and implementation circuit for verification of each
hierarchy (e.g., the top hierarchy is the same for RTL and GATE), verification is not necessary. Only the
modified hierarchies need to be verified.
Check what modifications have been implemented in the two circuits to be compared and then execute
verification.
The information is needed for setting the formal verification tool and debugging. For example, to execute
RTL vs GATE verification, it is recommended to prepare a logically synthesized script and the log that
executed it.
1.3 Formality Execution Flow

Under an OPENCAD environment, Formality is executed in the flow shown in Figure 1-4.

Figure 1-4. Formality Execution Flow

OPENCAD environment
Formality setup file creation OPC_FORMALITY execution
Formality execution
Setup
file
Library
Reference
design
Script
file
Implementation
design
Script file editing

An outline of the Formality execution flow under an OPENCAD environment is described below.
Refer to CHAPTER 4 Formality EXECUTION PROCEDURE for details.

(1) OPENCAD environment setting
Start OPENCAD and set the environment for OPENCAD.
Refer to 3.2.1 OPENCAD environment setting for details.

(2) Formality setup file creation
An environment is provided in OPENCAD to facilitate creation of the setup file (.synopsys_fm.setup) where the
library read command of Formality is described. Create the setup file according to the procedure in 3.2.2
Execution of GUI menu (execution of OPC_FORMALITY).

(3) OPC_FORMALITY execution
OPC_FORMALITY, which is a shell script for support of Formality, is provided in OPENCAD. By executing
OPC_FORMALITY, a script file where the command required for Formality verification is described can be
created.
Refer to 4.1.1 Creation of script file (execution of OPC_FORMALITY) for details.

(4) Script file editing
Edit the script file according to the user environment, if necessary.

(5) Formality execution
Execute the script file edited on Formality.
Refer to 4.2.2 Execution of Formality for details.
The GUI menu for Formality is provided in OPENCAD as an environment that facilitates execution of GATE vs
GATE verification. By entering circuit information according to the menu, (3) OPC_FORMALITY execution and (5)
Formality execution can be automated. For how to use the GUI menu, refer to APPENDIX B EXPLANATION OF
GUI MENU.

Table 1-1. Explanation of I/O Files
File Explanation
Reference design Reference circuit
Implementation design Implementation circuit
Library Library for Formality. Prepared in the OPENCAD environment. For the explanation and use method
of library, refer to CHAPTER 3 LIBRARY.
Setup file Setup file for Formality (.synopsys_fm.setup).
The contents of the file are the search_path settings and library read commands.
The commands in the file are executed immediately after Formality is started.
Script file Script file for Formality.
The default file name is opc_formality.fms.
For the file name specification method, refer to A.2.1 Explanation of options.

1.4 Operating Environment

This section describes the operating environment assumed in this manual.
For execution, check that the environment shown in Table 1-2 has been set.

Table 1-2. Operating Environment
File Description
Supported OS
Note
Consult Synopsys.
Formality version Refer to the documents OPENCAD Release Notification or ASIC Product Lineup published by NEC
Electronics.
Note This OS is supported when Formality is used alone.
The OS supported by OPENCAD can be used when Formality is used in an OPENCAD environment.

CHAPTER 2 RESTRICTIONS

This chapter describes the current restrictions for executing Formality. There are many types of restrictions, such
as those specific to formal verification and Formality itself and problems in the flow. The following restrictions must be
taken into consideration when executing Formality. The contents of the restrictions may be changed due to future
improvement of tools.

2.1 Circuit Restrictions

The following circuit structures cannot be handled on Formality or can only be handled within a restricted range.

(1) Combination loop [prohibited]
A formal verification tool basically cannot verify a combination loop, therefore logic cones with a combination
loop are not verified. Moreover, because combination loops cause problems in other tools such as STA, care
must be taken so that they do not exist in a circuit.
For the method of checking whether a combination loop exists or not, refer to section 5.9 Combination Loop
Check.

(2) alias declaration (VHDL) [prohibited]
Formality ignores a VHDL alias declaration.
If VHDL where alias is described is read, the error message The variable (variable declared by alias) is not
defined is output. Therefore, do not use the alias declaration.

(3) Optimization of FSM [prohibited]
When the FSM (Finite State Machine) is optimized at logic synthesis, is very difficult, depending on how the
status is obtained (e.g., the status number may differ). Consequently, do not optimize the FSM. Check with the
design engineer whether the FSM was optimized.
Note that there is no problem in synthesizing the FSM with no optimization.

<Logic synthesis-related commands>
minimize_fsm, set_fms_minimize, set_fms_encoding, set_fms_encoding_style,
set_fms_order, extract

(4) When the name of a verification point is greatly changed
In this case, the formal verification tool will fail to make correspondence between two circuits. Consequently,
do not modify the circuit so that its name is greatly changed. If modification of a name is inevitable, set a
naming rule in the formal verification tool or directly make correspondence.
(5) Complex computing unit
When a complex computing unit such as a multi-bit multiplier or divider is designed, the result of verification
may be aborted in some cases. This is because a complex computing unit causes large logic in the logic cone
and substantial changes in the circuit structure due to a change in the architecture.
For the countermeasures and verification method for a complex computing unit, refer to section 5.2 Complex
Computing Unit.

(6) Retiming
A formal verification tool is provided with a setting for verification before and after retiming. However, because
a verifiable circuit structure has restrictions, the range of the logic cone is enlarged for verification as a
processing inside the tool, and therefore verification may be aborted in some cases (care must be taken on
this point). Check with the design engineer whether retiming was performed in logic synthesis.
For verification before and after retiming, refer to section 5.5 Verification Before and After Retiming.

balance_registers, set_balance_registers, optimize_registers, set_optimize_registers

(7) Clock gating
Formality can be set to verify a circuit with clock gating. Depending on the clock gating configuration,
however, verification may not be performed in batch.
For verification of a circuit with clock gating, refer to 5.5 Verification of Clock-Gated Circuit.

(8) Use of module without reference destination
If a module that does not exist in a circuit or library exists, Formality can automatically use this module as a
black box if the following setting is applied.

fm_shell> set hdlin_unresolved_modules black_box

If the circuit is described in Verilog-HDL, however, this setting is not recommended because of the following
problem. For such a module, prepare a library or a dummy module with only pins defined.

<Problem>
If a module that should be referenced does not exist in the description in Verilog-HDL, the direction of the
pins of the module is unknown.
Depending on the connection status, Formality may assume a pin direction that is different from the actual
direction, because it determines the direction of these pins based on the connection relationships of the
peripherals.
If an incorrect pin direction is assumed in this manner, verification cannot be performed correctly and a false
error may occur.

2.2 Tool Restrictions

(1) Environment variable LANG setup (when GUI is used)
The value of the environment variable LANG must be C in order to start the GUI of Formality. When another
value is set, start the GUI as shown below.

[In case of bsh]
# LANG=C ; export LANG
# formality &
Remark # is the prompt

[In case of csh]
% setenv LANG C
% formality &
Remark % is the prompt

[In case of using the env command]
% env LANG=C formality &
Remark % is the prompt

(2) VITAL (VHDL)
Because VITAL is a description that cannot be synthesized, Formality cannot recognize VITAL. In the
OPENCAD environment, a library for Formality is provided. If VITAL is defined in the design file, output the
comment and then make the tool read it.

[Example of VITAL definition comment out]
Library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
-- library OPC_VITAL;
-- use OPC_VITAL.all;

(3) Abolition of EDIF input
The EDIF input function of Formality is abolished from Z-2006.12.
To use Formality of Z-2006.12 or later, convert EDIF to another format, such as Verilog-HDL, in advance for
input.

<R>
2.3 Library Restrictions

(1) Setting for constant propagation exceeding black box
The constants of Formality are propagated in accordance with the logic of a block defined in a library.
Therefore, if a black box block exists on the path of constant propagation, the constants cannot be propagated
in excess of that block.

Figure 2-1. Constant Propagation If Black Box Exists on the Propagation Path

Black-Box
1 ???
DATA BBIN BBOUT
Output cannot be determined
because the logic is not defined Constant is set
Constant is not propagated
to subsequent stages

In such a case, perform verification by setting a fixed value to a point that exceeds the black box, as follows.
fm_shell> set_constant -type port impl:/WORK/TEST/BLACK_BOX/BBOUT 1

Figure 2-2. Constant Propagation If Constant Is Set As Output of Black Box

Black-Box
DATA BBIN BBOUT
1 1
Constant is set as output of black box Constant is propagated to subsequent stages

The existence of a black box in a library can be checked by the following command.
fm_shell> report_libraries
:
######################################################################
#### SHARED TECH LIB - XXXX
######################################################################
Library Cell Attributes
------------ ----------
YYYYYYYYY b If b is output here, this indicates a black box.
ZZZZZZZZZ b

2.4 Known Problems

(1) Pseudo error in verification before and after TESTACT
When TESTACT, which is a DFT tool of NEC Electronics, is used, a mismatch (pseudo error) may be reported
on the RAM test clock pin in formal verification before and after use. The test clock pin name is shown below.

Table 2-1. Test Clock Pin Name
1 Port RAM 2 Port RAM
Pin name TBE TBEA, TBEB

Before executing TESTACT, the test clock pin is logically fixed by a clamp block on the operation flow of
TESTACT. However, if a circuit after executing TESTACT is set in the normal mode when executing formal
verification, the inverted logic of the clamped value is sent to the test clock pin. Therefore formal verification
results in a mismatch. If this is the cause of the mismatch, it is a pseudo error, so ignore it.

With the following OPENCAD kits, 0 is always propagated to a clock pin for testing, if a circuit after executing
TESTACT is set in the normal mode. Output of this false error can be suppressed by clamping the circuit
before executing TESTACT to 0.

OPENCAD V5.5a or later
OPENCAD CB11 V3.1.0 or later
OPENCAD CB12 V3.1.0 or later
Kit for technologies other than the above

(2) Warning when a link command is executed in EDIF netlist
If Formality reads the EDIF netlist created by the following method, many warning messages (message ID:
FE-LINK-20) are displayed when the link command is executed.

(a) Conversion to EDIF by Netlist Utilities in the OPENCAD environment
(b) EDIF output by the write command of Design Compiler

[Example of warning message]
fm_shell> read_edif -c TEST TEST.edf
fm_shell> link TEST:/WORK/TEST
Linking design TEST:/WORK/TEST
Warning: Could not resolve cell /WORK/TEST/CC0 to its reference design /L/F312.
Using design F312 in library BASIC instead. (FE-LINK-20)
Warning: Could not resolve cell /WORK/TEST/BB0 to its reference design /L/F611.
Using design F611 in libray PRIMITIVE instead. (FE-LINK-20)
(Warning messages are subsequently displayed per number of blocks.)

The EDIF file contains a description that specifies a library. The first specified library is referenced as the
Formality specification. However, if no library exists, the Formality library for OPENCAD is used instead. This
is displayed as a warning with the message ID FE-LINK-20. Therefore, the warning message itself will not
affect the verification result. Because messages are output for all blocks in the netlist, it is likely that the size
of the log file will be large or that important logs get lost.
Output of warning messages can be suppressed by the following method.

(a) Conversion to EDIF by Netlist Utilities in OPENCAD environment
If EDIF is created by Netlist Utilities in OPENCAD, the library specification becomes L (the description
in the EDIF file is (library L (edifLevel 0)). Add the -libname L option to all library read commands of
Formality.

[Example of description of library read command]
% cat .synopsys_fm.setup

set search_path . \
$OPC_PATH/lib/common/synopsys/basic \
... (Omitted)

read_db -libname L { \
basic.db iobuffer.db \
primitive.db nec_bscan.db nec_scan.db scan.db special.db \
}
read_verilog -tec -libname L primitive.v
read_verilog -tec -libname L nec_bscan.v
read_verilog -tec -libname L nec_scan.v
read_verilog -tec -libname L scan.v
read-verilog -tec -libname L special.v
Remark Shaded area: Edited section

(b) EDIF output by write command of Design Compiler
If EDIF is output by the write command of Design Compiler, the library is specified by the description of
libraryRef in EDIF. Table 2-2 shows the correspondence between the specified library names and
Formality libraries. Specify the library name in the -libname option according to Table 2-2.

Table 2-2. Correspondence Between Specified Library Names and Formality Library Files
Library Name Formality Library File
${TECH}_${COND}_<PVT>_ANALOG analog.db
${TECH}_${COND}_<PVT>_BASIC basic.db
${TECH}_${COND}_<PVT>_DRIVE clockdriver.db
${TECH}_${COND}_<PVT>_IO iobuffer.db
${TECH}_${COND}_<PVT>_BSCAN nec_bscan.db
${TECH}_${COND}_<PVT>_NSCAN nec_scan.db
${TECH}_${COND}_<PVT>_PRIM primitive.db
${TECH}_${COND}_<PVT>_SCAN scan.db
${TECH}_${COND}_<PVT>_SPECIAL special.db
${TECH}_${COND}_<PVT>_TESTACT testact.db
${TECH}_${COND}_<PVT>_{character-string} {character-string}.db
(For CSR (Customer Specific Request))
Remark ${TECH}: Technology name of OPENCAD
${COND}: Condition name of OPENCAD
<PTV>: Delay condition (MIN, TYP, or MAX)

[Example of description of library read command]
% cat .synopsys_fm.setup

set search_path . \
$OPC_PATH/lib/common/synopsys/basic \
... (Omitted)

read_db -libname CB10VX_CMOS_25V_MAX_BASIC basic.db
read_db -libname CB10VX_CMOS_25V_MAX_IO iobuffer.db
read_db -libname CB10VX_CMOS_25V_MAX_PRIM primitive.db
read_db -libname CB10VX_CMOS_25V_MAX_BSCAN nec_bscan.db
read_db -libname CB10VX_CMOS_25V_MAX_NSCAN nec_scan.db
read_db -libname CB10VX_CMOS_25V_MAX_SCAN scan.db
read_db -libname CB10VX_CMOS_25V_MAX_SPECIAL special.db
read_verilog -tec -libname CB10VX_CMOS_25V_MAX_PRIM primitive.v
read_verilog -tec -libname CB10VX_CMOS_25V_MAX_BSCAN nec_bscan.v
read_verilog -tec -libname CB10VX_CMOS_25V_MAX_NSCAN nec_scan.v
read_verilog -tec -libname CB10VX_CMOS_25V_MAX_SCAN scan.v
read_verilog -tec -libname CB10VX_CMOS_25V_MAX_SPECIAL special.v
Remark Shaded area: Edited section

(3) Abnormal termination with VHDL when the std_logic_arith package is used
In the std_logic_arith package of VHDL, the functions which convert values to the corresponding type among
the UNSIGNED, SIGNED, INTEGER, and STD_LOGIC_VECTOR types are defined; however, when a VHDL
using these functions is read, Formality may be terminated abnormally.
In such a case, this problem may be avoided by taking the following measure. Handle this problem by
referring to this measure.
This bug is being corrected by Synopsys.

<Problem content>
When a VHDL using the following functions is read and if the set_top command is executed with Formality,
Formality may be terminated abnormally.

[Target functions]
CONV_INTEGER, CONV_UNSIGNED, CONV_SIGNED, CONV_STD_LOGIC_VECTOR

[Description in problem]
library IEEE;
use IEEE.std_logic_unsigned.all ;
use IEEE.std_logic_arith.all ;

entity func_call is
port (
I1 : in std_logic_vector(31 downto 0);
O1 : out std_logic_vector(4 downto 0)
);
end func_call;

architecture ARCH of func_call is

function FUNC (
DUMMY : std_logic_vector
) return std_logic_vector is
variable bit : integer ;
begin
bit := 5 ;
-- An error occurs with the following description.
return std_logic_vector(conv_unsigned(DUMMY'right, bit));
end FUNC ;

begin
O1 <= FUNC( I1 );
end ARCH;

<R>
[Error output example]
fm_shell (setup)> set_top r:/WORK/func_call
Setting top design to 'r:/WORK/func_call'
Status: Elaborating design func_call ...
Error: vhsynCDFGRoutines.cxx line 1975
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhIsIntegerExpression() (FMR_VHDL-435)
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhGetExpressionType() (FMR_VHDL-435)
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhGetActualObj() (FMR_VHDL-435)
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhGetTypeDef() (FMR_VHDL-435)
Error: vhsynUtilities.cxx line 562
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhGetStaticType() (FMR_VHDL-435)
Error: vhsynUtilities.cxx line 1902
Unexpected Object Type VH_ERROR_OBJECT_TYPE in vhGetStaticType() (FMR_VHDL-435)
Error: Switch falls into default. (File: vhsynCDFGRoutines.cxx Line: 2542) (FMR_ELAB-010)
Error: Failed to set top design to 'r:/WORK/func_call' (FM-156)

<Workarounds>
This problem may be avoided by directly substituting the conversion function size by a constant and not a
variable.

[Corrected VHDL description]
library IEEE;
use IEEE.std_logic_unsigned.all ;
use IEEE.std_logic_arith.all ;

entity func_call is
port (
I1 : in std_logic_vector(31 downto 0);
O1 : out std_logic_vector(4 downto 0)
);
end func_call;

architecture ARCH of func_call is

function FUNC (
DUMMY : std_logic_vector
) return std_logic_vector is
variable bit : integer ;
begin
-- The size is specified with a constant.
return std_logic_vector(conv_unsigned(DUMMY'right, 5));
end FUNC ;

begin
O1 <= FUNC( I1 );
end ARCH;

CHAPTER 3 LIBRARY

The Synopsys DB format library and the netlist format library that complements it are provided as libraries for
Formality in the OPENCAD environment. When executing Formality, be sure to use the library for Formality indicated
here.

Cautions 1. Formality and PrimeTime use the same DB format library files.
2. The DB format library file for Design Compiler is separated from the library file shared by
Formality and PrimeTime. Therefore, if Formality uses the DB format library file, the result is
not guaranteed.
3. Formality itself can also read the library for Verilog-HDL simulation as a library, but the
library is not supported in the OPENCAD environment. Therefore, the result is not
guaranteed if a library for Verilog-HDL simulation is used with Formality.
4. The result is not guaranteed if a library for Verilog format is used.

3.1 Library Structure

The library structure used by Formality is shown below.

(1) Primitive block library
This library contains blocks such as primitive blocks and interface blocks. Some blocks are black box models
due to library description restrictions.

(2) Netlist format library
This is a library to complement the logic of a block (which is a black box model in (1) above) in the Verilog-
HDL netlist. It is mainly prepared for matching in formal verification before and after DFT.

(3) Macro block library
This library contains analog macros and mega macros. Only pin information is defined for macro blocks, which
are treated as a black box.

(4) Added block library
This library is added by CSR (Customer Specific Request).

(5) Library for compiled memory
This library is for compiled memory created by the Module Generation Memory Compiler.
For selection of the memory type and method for using the library, refer to 3.3 Creating and Using Library
for Compiled Memory.

CHAPTER 3 LIBRARY

${OPC_PATH}/lib/common/synopsys/<BlockGroup>/<BlockGroup>.dbn
Note
${OPC_PATH}/lib/common/stm/<BlockGroup>/<BlockName>_lib.db
${OPC_PATH}/lib/common/synopsys/softmacro/<BlockGroup>.v
${OPC_PATH}/lib/${TECHNOLOGY}/common/synopsys/<BlockGroup>/<BlockGroup>.db
Note
${OPC_ADD}/lib/common/synopsys/<BlockGroup>/<BlockGroup>.db
Note
${OPC_ADD}/lib/${TECHNOLOGY}/common/synopsys/<BlockGroup>/<BlockGroup>.db
Note
${OPC_ADD}/lib/common/synopsys/softmacro/<BlockGroup>/<BlockGroup>.v
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/<BlockName>_lib.db
(1)
(2)
(3)
(4)
(5)

Note The structure following /<BlockGroup>/ may be changed, depending on the release block.

Remarks 1. The meaning of each term in the library structure is as follows.
${OPC_PATH}: Top directory in which OPENCAD has been installed.
${OPC_ADD}: Top directory of the library added by CSR.
${OPC_MODULE}: Top directory of the compiled memory library.
${TECHNOLOGY}: Technology name of OPENCAD.
${CONDITION}: OPENCAD condition name.
<BlockGroup>: Block group name such as primitive, iobuffer, and mega.
<BlockName>: Block name.

2. With OPENCAD CB90L V1.0.0, the library structure of OPENCAD will be reviewed and
${OPC_PATH}/lib/common and ${OPC_PATH}/lib/${TECHNOLOGY}/common will be aborted.
Consequently, the library structure that Formality references will be changed as follows.

${OPC_PATH}/lib/${TECHNOLOGY}/${CONDITION}/synopsys_sta/<BlockGroup>/<BlockGroup>.db
Note
${OPC_PATH}/lib/${TECHNOLOGY}/${CONDITION}/synopsys_sta/softmacro/<BlockGroup>/<BlockGroup>.v
${OPC_PATH}/lib/${TECHNOLOGY}/${CONDITION}/synopsys_sta/<BlockGroup>/<BlockGroup>.db
Note
${OPC_ADD}/lib/${TECHNOLOGY}/${CONDITION}/synopsys_sta/<BlockGroup>/<BlockGroup>.db
Note
${OPC_ADD}/lib/${TECHNOLOGY}/${CONDITION}/synopsys_sta/softmacro/<BlockGroup>/<BlockGroup>.v
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/<BlockName>_lib.db
(1)
(2)
(3)
(4)
(5)

Note The structure following /<BlockGroup>/ may be changed, depending on the release block.

CHAPTER 3 LIBRARY
3.2 Creating Formality Setup File

Functions are provided in the OPENCAD environment for acquiring library paths for Formality and facilitating
creation of library read commands. These commands are described in the Formality setup file (.synopsys_fm.setup)
and the libraries are automatically read when Formality is started.
This section describes the procedure for creating the Formality setup file. The procedures that the user must
execute are divided into the following.

<1> OPENCAD environment setting: Refer to 3.2.1
<2> Execution of GUI menu for Formality (or OPC_FORMALITY) : Refer to 3.2.2

Caution When using Formality 2002.03 or later, be sure to use a Formality setup file created with
OPC_FORMALITY V3.0.0 or later. A Formality setup file created with an earlier version cannot be
used.

3.2.1 OPENCAD environment setting
This section describes the OPENCAD environment settings required for creating a setup file.

(1) OPENCAD startup
Display the GUI screen of OPENCAD by inputting the following command and executing OPC_VSHELL.

% OPC_VSHELL &

(2) OPENCAD environment setting
Set the following (a) and (b) for setting the OPENCAD environment related to Formality.

(a) Setting of technology and conditions of OPENCAD [essential]
Select [Environment] [Technology...] on the GUI screen of OPENCAD.
Set the technology and conditions for OPENCAD under Technology: and Condition: on the window
opened.

(b) Path setting for added libraries and compiled memory [when necessary]
Select [Environment] [Path...] on the GUI screen of OPENCAD as shown in Figure. 3-1.

<1> When using an additional library by CSR
Set the top directory of the additional library under Library for CSR on the window.

<2> When using the compiled memory (Memory Compiler)
Set the top directory in which the library of compiled memory is located under Module Library on the
window.
Then, refer to section 3.3 Creating and Using Library for Compiled Memory create the compiled
memory library for Formality.

CHAPTER 3 LIBRARY
Figure 3-1. GUI Screen for Setting OPENCAD Environment

CHAPTER 3 LIBRARY
3.2.2 Execution of GUI menu (execution of OPC_FORMALITY)
This section describes how to create a setup file by executing the GUI menu for Formality or by executing
OPC_FORMALITY.

(1) Creating a setup file on the GUI menu
Select [Formal Verification] [Formality] on the GUI screen of OPENCAD.
If [Set Configuration File (.synopsys_fm.setup)] is selected from the main menu (Figure 3-2) of Formality, a
setup file (.synopsys_fm.setup) is created in the current directory.

Figure 3-2. GUI Menu for Creating Formality Setup File

CHAPTER 3 LIBRARY
(2) Creating a setup file by executing OPC_FORMALITY
On the UNIX command prompt, execute OPC_FORMALITY with the -cf option added (OPC_FORMALITY
exists under $OPC_PATH/bin). The setup file (.synopsys_fm.setup) is generated in the current directory.

[Example of executing OPC_FORMALITY]
% OPC_FORMALITY -cf
==============================================================
OPC_FORMALITY Vx.x.x
Copyright (C)
==============================================================
Setting configuration file(.synopsys_fm.setup)... Done.

Log message is saved as 'opencad.log/OPC_FORMALITY.xxxx.log'.
%

If 3.2.1 OPENCAD environment setting is completed, options other than -cf are not necessary.
For details of OPC_FORMALITY, refer to APPENDIX A EXPLANATION OF OPC_FORMALITY.

CHAPTER 3 LIBRARY
3.3 Creating and Using Library for Compiled Memory

This section describes how to use a library for compiled memory created by the Module Generation Memory
Compiler in Formality. When using the library, the user must create a part of the library for Formality, according to the
following procedure.

Caution The Bus Wrapper and Soft Wrapper for redundant RAM which are generated by Memory
Compiler are handled not as libraries, but as part of RTL, and become GATE-level circuits
through logic synthesis.
OPC_FORMALITY therefore does not generate read commands for these files as being libraries.
Separately read the files as required.

(1) Memory type selection
Specify the path for compiled memory (Module Library) on the GUI screen for setting the OPENCAD
environment, select [Module Generation] [Memory Compiler] [Generate Memory] on the screen
shown in Figure. 3-1, and then select the type of memory.

Figure 3-3. GUI Screen of Compiled Memory

<R>
CHAPTER 3 LIBRARY
(2) Compilation of memory and script creation for Formality
By selecting [Compile Memory...] in Figure. 3-1, all the libraries of the compiled memory are placed under the
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITON}/ directory.
A makelib.scr file is also created with the libraries under the directory above. makelib.scr is a script file for
creating a Synopsys DB format library for PrimeTime (Formality and PrimeTime share the DB format library).
The makelib.scr execution method will vary depending on the OPENCAD environment being used.
Accordingly, confirm the OPENCAD environment being used when executing (3) and (4) below.

(3) Creation of compiled memory library for Formality

(a) If using versions before 2.8.0 of OPC_COMPMEM included in OPENCAD
With versions before 2.8.0 of OPC_COMPMEM, the makelib.scr created acts as an execution script for
PrimeTime. It should be confirmed in advance that PrimeTime can be executed in the users environment.
If PrimeTime cannot be executed, refer to the explanation in (5) Using DB format library for Design
Compiler (reference). However, the method requires Design Compiler in order to generate a DB format
library.

Move to the ${OPC_MODULE]/lib/${TECHNOLOGY}/${CONDITON}/ directory as shown below to
execute PrimeTime.
After execution, a library (in DB format) with the character string _lib.db is created under that directory.

[Example of executing PrimeTime]
% cd ${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}
% pt_shell -f makelib.scr

(b) If using versions 2.8.0 and later of OPC_COMPMEM included in OPENCAD
With versions 2.8.0 and later of OPC_COMPMEM, the makelib.scr created acts as an execution script for
Design Compiler. It should be confirmed in advance that Design Compiler can be executed in the users
environment. It is not necessary to prepare a PrimeTime execution environment.

Move to the ${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITON}/ directory as shown below to
execute Design Compiler.
After execution, a library (in DB format) with the character string _lib.db is created under that directory.

[Example of executing Design Compiler]
% dc_shell-xg-t f makelib.scr
Caution The Design Compiler version used must be 2004.12 or later.

CHAPTER 3 LIBRARY
(4) Creation of Formality setup file
Refer to the explanation in 3.2 Creating Formality Setup File to create a Formality setup file. The library
path for compiled memory created in (3) is added to the library read commands.

(5) Using DB format library for Design Compiler (reference)
This section describes how to create a DB format library for Design Compiler and read with Formality, for
users who correspond to (3) (a) and do not have a PrimeTime execution environment.
It should be confirmed in advance that Design Compiler can be executed in the users environment.

(a) Creating DB format library for Design Compiler
Move to the ${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/ directory as shown below to
execute Design Compiler.
After execution, a DB format library with the file name ${TECHNOLOGY}_${CONDITION}-MCOM_<PTV>.db is
created under the current directory. Select MIN, TYP, or MAX for <PVT>.

[Example of executing Design Compiler]
% dc_shell
dc_shell> read_lib ${TECHNOLOGY}_${CONDITION}-MCOM_<PVT>.lib
dc_shell> write_lib ${TECHNOLOGY}_${CONDITION}-MCOM_<PVT>
dc_shell> quit
Remark dc_shell> indicates the prompt of Design Compiler.

(b) Creating Formality setup file
Refer to the explanation in 3.2 Creating Formality Setup File to create a Formality setup file.

(c) Editing Formality setup file
Use an editor to open the Formality setup file (.synopsys_fm.setup) to add the path for the DB format
library created in (a) to the library read commands.

CHAPTER 4 Formality EXECUTION PROCEDURE

This chapter describes the procedure for executing Formality in the OPENCAD environment.
The procedures that the user must execute are the following two procedures.

<1> Procedure in OPENCAD environment: Refer to 4.1
Creation of script file for Formality (execution of OPC_FORMALITY): Refer to 4.1.1

<2> Procedure of Formality: Refer to 4.2
Script file editing: Refer to 4.2.1
Execution of Formality: Refer to 4.2.2

4.1 Procedure in OPENCAD Environment

This section describes the procedure to be executed in the OPENCAD environment.
OPENCAD environment settings (refer to 3.2.1 OPENCAD environment setting) must be completed beforehand.

4.1.1 Creation of script file (execution of OPC_FORMALITY)
By executing OPC_FORMALITY, the script file (file name: opc_formality.fms) for Formality can be generated. The
series of commands necessary for verification are described in this script file.

When using Formality 2002.03 or later, use a script file created with OPC_FORMALITY V3.0.0 or later. A script file
created with an earlier version cannot be used directly.
When using OPC_FORMALITY V3.0.0, specify the numeric values of the Formality version to be used to the
environmental variable OPC_FM_VERSION, before execution. This specification will create a script file supporting
the Formality version to be used.

[Example of setting]
% setenv OPC_FM_VERSION 2002.09

An example of executing OPC_FORMALITY is shown below.
In the example of execution, the following circuit information is specified.
File name of Reference circuit: ref_netlist.v
File name of Implementation circuit: impl_netlist.v
Top hierarchy name: TOP for both circuits
Netlist type: Verilog-HDL for both circuits

[Example of executing OPC_FORMALITY]
% OPC_FORMALITY \
-s_netlist ref_netlist.v \
-i_netlist impl_netlist.v \
-circuit TOP -nettyp VERILOG
==========================================================
OPC_FORMALITY Vx.x.x
Copyright (C)
==========================================================
[ Creating Script File (opc_formality.fms) ]
Log message is saved as opencad.log/OPC_FORMALITY.xxxx.log.
Remark % indicates the prompt of UNIX.
\ is a character that cancels a line feed.

For details of other options of OPC_FORMALITY, refer to APPENDIX A EXPLANATION OF OPC_FORMALITY.

4.1.2 Example of script file
An example of a script file (opc_formality.fms) output by OPC_FORMALITY is shown below (# is a comment line).
The contents may differ depending on the version of OPC_FORMALITY.

# ======== set default parameters ========
set verification_blackbox_match_mode identity
set verification_set_undriven_signals PI
set verification_passing_mode consistency
# set name_match_flattened_hierarchy_separator_style _
set hdlin_error_on_mismatch_message false
set hdlin_ignore_full_case false
set hdlin_ignore_parallel_case false
# ======== set reference netlist ========
read_verilog -c ref ref_netlist.v
link ref:/WORK/TOP
set_reference_design ref:/WORK/TOP
memory
cputime
# ======== set implementation netlist ========
read_verilog -c impl impl_netlist.v
link impl:/WORK/TOP
set_implementation_design impl:/WORK/TOP
memory
cputime
# ======== user defined script ======================
# (Supplement) When the -cmd option is used in OPC_FORMALITY,
# the contents of the file are added here.
# ===================================================
# =========================================================
# (Supplement) If OPC_FORMALITY is executed in interactive mode,
# the command prompt of Formality is returned here.
# ==========================================================
if {[verify] != 1} {
report_aborted_points
report_failing_points
save_session -replace -full opc_formality
}
memory
cputime
quit
Reference circuit
read and link
Initial setting
Implementation circuit
read and link
If the result is other than
a match
Display of mismatch
section
Display of abort section
Saving of session file
Termination of Formality
Verification

4.2 Procedure of Formality

This section describes the procedure by which the user executes Formality.
First, the command flow of Formality is explained based on the contents of the script file output by
OPC_FORMALITY. Edit the script file and add new commands and settings if necessary. For the verification method
in each case, refer to CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW. The method to
execute the script file on Formality is explained at the end.

4.2.1 Command flow
Execute the Formality commands using the procedure described below

(1) Library read
(2) Initial setting
(3) Design read and link
(4) Fixed value setting
(5) Naming rule setting
(6) Checking of correspondence between verification points
(7) Verify execution
(8) Verification result reporting
(9) Mismatch analysis (debug)

The procedure is explained below.

(1) Library read
If the setup file (.synopsys_fm.setup) has been created in 3.2 Creating Formality Setup File, libraries are
automatically read after Formality is started.
When using Formality 2002.03 or later, however, the script file must be partially edited because some libraries
must be read when the design is read. For how to edit the script file, refer to 4.2.1 (3) Design read and link.
The script file does not have to be edited when a version earlier than Formality 2002.03 is used.

(2) Initial setting
When making initial settings, set the RTL recognition, circuit modeling, matching, and verification operations.
For example, the commands described in the script file (refer to 4.1.2 Example of script file) output by
OPC_FORMALITY are as follows.

Command set verification_blackbox_match_mode <any | identity>
Description Setting of how the blocks (or hierarchies) that exist under the same instance name in two circuits are
compared during verification if they are black boxes. The setting values include any (default value)
and identity.
any: They are regarded as a match when the block names (hierarchy names) are different but
the input/output pins are the same.
identity: They are not regarded as a match unless the block names (hierarchy names) are the same
in addition to the condition for any.
In RTL vs GATE, the hierarchy names may be changed in the same way as when uniquify is
executed during logic synthesis. In this case, set any to prevent them from being regarded as a
mismatch during verification of each hierarchy. In GATE vs GATE, set identity to ensure more
precise checking.

Command set verification_set_undriven_signals PI
Description Handles a floating input signal as an external input pin (primary input).
Setting for detecting a floating input signal. If a floating input signal exists in one circuit, the
verification result becomes a mismatch. Because a floating input signal is prohibited in OPENCAD,
modify the circuit if the signal is detected.

Command set verification_passing_mode consistency
Description Regards logical value X of the reference circuit as Dont care to verify with the circuit and
implementation circuit. That is, verifies that applying the same pattern to both circuits brings the
same result.

Command set hdlin_error_on_mismatch_message <true | false>
Description Variable that controls tool operation if RTL contains a description that causes different simulation
results in RTL and GATE. The setting values include true (default value) and false.
true: An error is output to stop read processing when the relevant RTL description exists during
design read.
false: Read processing is continued although a warning is output.
Use this setting value to report how many relevant RTL descriptions exist during design.
For the problem of a description that causes different simulation results, refer to 4.3 Formality
Messages to Be Noted.

Command set hdlin_ignore_full_case false
Description Recognizes the Synopsys full_case directive.

Command set hdlin_ignore_parallel_case false
Description Recognizes the Synopsys parallel_case directive.

To check the setting value of a Formality variable, execute the printvar command.

fm_shell> printvar # Display setting values of all variables
fm_shell> printvar hdlin_* # Display setting values of variables starting with the character string hdlin_

(3) Design read and link
Read the design for a reference circuit and implementation circuit.
Specify ContainerID in the -c (-container) option. Change ContainerID for each circuit.
The design read command differs depending on the netlist type as follows.

Netlist Type Design Read Command
Verilog-HDL read_verilog -c ContainerID netlist_file.v
Verilog-HDL (GATE only) read_verilog -c ContainerID netlist_file.v -netlist
VHDL read_vhdl -c ContainerID netlist_file.vhd
EDIF read_edif -c ContainerID netlist_file.edf

When using Formality 2002.03 or later, a command that reads a netlist format library and the corresponding
primitive block library must be added before reading the design.

[Additional library read command]
read_db c ContainerID LibraryName.db
read_verilog c ContainerID tec libname LibraryName LibraryName.v

A Formality setup file created with OPC_FORMALITY V3.0.0 or later can read a netlist format library only by
adding the command shown below, because it defines a procedure for reading the netlist format library. If a
script file for Formality 2002.03 is created with OPC_FORMALITY, this command is automatically added, and
therefore the script file does not have to be edited.
To use a Formality setup file created with OPC_FORMALITY V4.2.0 or later, only the following procedure will
read all of the necessary libraries. Consequently, be sure to add the following command when using the setup
file together with a script file created by the user.

[Additional library read command]
read_neclib c ContainerID

After reading the design, use the set_reference_design and set_implementation_design commands to
specify the reference circuit, implementation circuit, and the hierarchy to be verified (normally, top hierarchy).
Continuously, execute the link (set_top with 2002.03 or later) command to elaborate the circuits and map
the libraries.
The hierarchies specified by the set_reference_design and set_implementation_design commands are
stored in the Formality variables ref and impl.

[Example of reading reference circuit]
fm_shell> read_verilog -c ref ref_netlist.v
fm_shell> set_reference_design ref:/WORK/TOP
fm_shell> link $ref

[Example of reading implementation circuit]
fm_shell> read_verilog -c impl impl_netlist.v
fm_shell> set_Implementation_design impl:/WORK/TOP
fm_shell> link $impl

[Example of reading circuit when Formality 2002.03 or later is used]
fm_shell> read_db c ref primitive.db
fm_shell> read_verilog c ref tech libname primitive primitive.v
fm_shell> read_verilog c ref ref_netlist.v
fm_shell> set_reference_design ref:/WORK/TOP
fm_shell> set_top $ref

[Example of reading circuit by using read_neclib]
fm_shell> read_neclib c impl
fm_shell> read_verilog c impl impl_netlist.v
fm_shell> set_reference_design impl:/WORK/TOP
fm_shell> set_top $impl

(4) Fixed value setting
By setting a fixed value at the external input pin, the section of the circuit to which the value is sent can be
excluded from verification. For example, when verifying data before and after DFT circuit insertion, a fixed
value must be set at the test control pin of the implementation circuit so that the system can enter the normal
mode.
Furthermore, a fixed value can be set to narrow the range of verification. Use the set_constant command to
set a fixed value. Specify whether a fixed value is to be set at the pin or net in the -type option.

fm_shell> set_constant -type <port|net> <ObjectID> <0|1>

(5) Naming rule setting
If a renaming that prevents correspondence from being made for verification points using the default function
of Formality occurs, the user should set the naming rule in the tool. Particularly in RTL vs GATE verification, it
is necessary to make Formality interpret RTL according to the naming rule of GATE. However, if logic is
synthesized according to 5.1 (Recommended) Logic Synthesis Method, this setting is unnecessary in many
cases.
To set the naming rule, execute the set_compare_rule command in the following format. The description of
naming rule is the same as in the sed command (Stream Editor) of UNIX. It is recommended to use the sed
command to test whether the description is correct beforehand.

set_compare_rule <ContainerID>:/WORK/<DesignID> \
-form {naming-rule-of-reference-circuit} -to {naming-rule-of-implementation-circuit}

Setting examples if the following renaming occurs are shown below.

[a_reg[0] a_reg0]
fm_shell> set_compare_rule $ref -from {$.*$\[$[0-9]*$\]} -to {\1\2}

[a_reg[1][0] a_reg1_0]
fm_shell> set_compare_rule $ref -from {$.*$\[$[0-9]*$\]\[$[0-9]*$\]}\
-to {\1\2_\3}

[abc/def abc_def]
fm_shell> set_compare_rule $ref -from {$.*$\/$.*$} -to {\1_\2}

(6) Checking of correspondence between verification points
Before verification, it is necessary to check whether the correspondence between verification points is correct.
Execute the verify -matchonly command as follows (function added from Formality version 2001.06).

[Example of execution]
fm_shell> verify -matchonly
Reference design is gate1:/WORK/top
Implementation design is gate2:/WORK/top
...
************************** Matching Results *******************************
3591 Compare points matched by name
0 Compare points matched by signature analysis
0 Compare points matched by topology
0(0) Unmatched reference (implementation) compare points
0(0) Unmatched reference (implementation) primary inputs, black-box outputs
***************************************************************************
... (The rest is omitted)

Caution In Formality, only verification points classified as Compare points matched (verification
points for which correspondence has been made) are to be verified; the verification points
classified as Unmatched reference (implementation) compare points (verification points
for which correspondence has not been made) are not subject to verification.
If verification points for which correspondence has not been made exist, it is necessary to
check whether they can be excluded from verification.
Execute the report_unmatched_inputs command to check the verification points.
If verification points to be verified exist among them, take one of the following actions, then
re-execute the verify -matchonly command to check whether correspondence has been
made.

Execute the set_compare_rule command to set the naming rule (refer to (5) Naming rule
setting).
Execute the set_compare_point command to make correspondence directly.

(7) Verify execution
Verify all verification points for which correspondence has been made. Execute the verify command as
follows. If the set_reference_design and set_implementation_design commands have been used to set the
reference circuit and implementation circuit beforehand, the verify command arguments are unnecessary.

[Example of execution if all verification points for which correspondence has been made are verified]
fm_shell> verify

The verify command can also be executed for individual verification points. For example, when the external
output pin OUT is to be verified, execute the command as follows.

[Example of execution if individual verification points are to be verified]
fm_shell> verify -type port ref:/WORK/TOP/OUT impl:/WORK/TOP/OUT
(8) Verification result reporting
Execute the following commands to report the result of verification.

Command Description
report_passing_points Displays the matched verification points.
report_failing_points Displays the mismatched verification points.
report_aborted_points Displays the aborted verification points.
report_unmatched_inputs Displays the non-input section of the logic cone. This command is used to find
verification points for which correspondence has not been made.
Caution This command cannot be used with 2002.03 or later.
Use the report_unmatched_points and report_matched_points
commands in place of this command.

Reporting the verification result in Formality has some peculiarities. Refer to the following examples and note
the report contents.

(a) If the number of mismatched verification points varies between verify and report_failing_points
The number of mismatches reported by verify is the result of counting the corresponding verification
points whose verification result is a mismatch. However, in the report by report_failing_points, the
contents of report_unmatched_inputs are also counted in addition to those mismatched verification
points. This must be noted because there are cases in which verification points for which correspondence
has not been made cause a mismatch.
Therefore, for debugging, analyze the cause of the mismatch from the verification points for which
correspondence has been made.

(b) If many aborted points are displayed
When the mismatch points reach the number of points specified by the Formality variable
verification_failing_point_limit (default: 20) during verification, verification processing (execution of
verify command) is stopped. In this case, all verification points that have not been verified yet are
reported as aborted points
Note
.
Many of these cases occur as a result of a verification point correspondence not being assigned between
two circuits. (check the cause in the report using the report_unmatched_inputs command).
Check the mismatch points, take actions such as adding settings and modifying the circuit, and then
perform re-verification.

Note From Formality 2005.12, in order to clearly distinguish a verification point between an abort and
unverified status, Unverified has been added as a verification point status so that this type of
verification point will no longer be reported as an Abort. To report these types of verification
points, use the command report_unverified_points.

[Message]
********************************* Verification Results *********************************
Verification FAILED
-------------------
Reference design: r:/WORK/TOP
Implementation design: i:/WORK/TOP
94 Passing compare points
20 Failing compare points
0 Aborted compare points
108 Unverified compare points
----------------------------------------------------------------------------------------
Matched Compare Points BBPin Loop BBNet Cut Port DFF LAT TOTAL
----------------------------------------------------------------------------------------
Passing (equivalent) 31 0 0 0 0 52 11 94
Failing (not equivalent) 20 0 0 0 0 0 0 20
Unverified 35 0 1 0 10 58 4 108
****************************************************************************************

(c) If many verification points for which correspondence has not been made are displayed in both circuits
It is likely that not all naming rules are set.
Refer to (5) Naming rule setting to set the naming rules, and then re-execute verification.

(9) Mismatch analysis (debug)
When a mismatch is reported as the result of verification, a diagnose command is provided to estimate its
cause. The diagnose command generates a test pattern that reproduces the mismatch for the specified
verification point. The mismatch candidates (error candidates) are then indicated together with a number
indicating the accuracy by executing the report_error_candidates command. On the GUI of Formality, the
logic cone can also be displayed graphically and debugged.

Caution When checking the cause of a reported mismatch, it is often found that not all the necessary
tools are set. For formal verification, the sections to be verified in the circuit and those not
to be verified must be set by the user correctly. Check that the settings are correct
according to the command flow described above.

4.2.2 Execution of Formality
This section describes the method used to execute Formality by specifying a script file (e.g., file name:
opc_formality.fms). Execute the script file edited on Formality from the UNIX command line as follow.

[Execution from Formality command line]
% fm_shell f opc_formality.fms // Execution of 32-bit version
% fm_shell -64bit f opc_formality.fms // Execution of 64-bit version

[Execution on Formality GUI]
% formality f opc_formality.fms & // Execution of 32-bit version
% formality -64bit f opc_formality.fms & // Execution of 64-bit version

For the environment variable and license settings required to execute Formality, refer to the User Guide supplied
by Synopsys, Inc.

4.3 Formality Messages to Be Noted

When Formality is executed, Error, Warning, and Info messages may be output.
The message contents can be checked by referring to the Formality online manual.

fm_shell> man <message-ID>

Note the following messages in particular.

(1) Message that indicates insufficient library and design

[Message]
Warning: Cannot link cell DesignID to its reference(implementation) design Block Name. (FE-LINK-2)

Warning: # blackbox designs were created for missing references. (FM-064)
Remark This message is output when the link command is executed.

[Explanation]
Because the library or design with the displayed block name is insufficient, it is handled as a black box.

[Action]
Restart Formality, then make it read the necessary library or design and perform verification.
The following command can also be used to check a black box in the circuit.

fm_shell> find_ref -black_box -hierarchy <DesignID>

<R>
(2) Message that indicates the existence of a description whose simulation result varies between RTL and GATE

[Message]
Error: RTL interpretation messages were produced during read.
Verification results may disagree with a logic simulator. (FM-089)
or
ATTENTION: RTL interpretation messages were produced during read.
Verification results may disagree with a logic simulator.

Remark This message is output when the design is read or the link command is executed.

[Explanation]
RTL contains a description whose simulation result varies between RTL and GATE.
If such a description exists during design, the operation of the actual device is unpredictable.
This occurs because RTL recognition varies between RTL simulation and logic synthesis. Because formal
verification basically recognizes RTL in the same way as the logic synthesis tool, the verification result will
not become a mismatch. Formality checks the RTL description that becomes erroneous when RTL is read,
and handles it as an error by default.

[Action]
The Warning message related to the erroneous description is always output in front of the message ID FM-
089. Examples of messages are FMR_VLOG-079 (insufficient sensitivity list) and FMR-ELAB-146
(array index overflow). Check the Warning contents using the online manual (man command) to correct
the RTL description if necessary. If it does not need to be corrected, the severity can be changed from
Error to Warning by setting the following variable.

(a) Changing severity of RTL description
Before reading RTL, specify the message ID list of the message to be changed to Warning in the
Formality variable hdlin_warn_on_mismatch_message.

set hdlin_warn_on_mismatch_message FMR_VLOG-079 FMR_ELAB-146

(b) Changing severity of all problematic RTL descriptions to Warning
All RTL descriptions whose simulation result becomes a mismatch can be handled as Warnings by setting
the following before reading RTL.

set hdlin_error_on_mismatch_message false

CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW

This chapter describes different verification flows, and the notes and Formality command execution that
correspond to each case.

5.1 (Recommended) Logic Synthesis Method

RTL vs GATE verification is more difficult than GATE vs GATE verification, and therefore takes a longer time. The
cause of difficulty resides in the size of the logic cone, which becomes large due to the existence of dont care, and
changes in the names and logical structure due to logic synthesis. That is, some methods for logic synthesis cause
verification points for which correspondence has not been made and aborted points and make verification difficult.
This section explains, from the viewpoint of the logic synthesis script, the verification flow, variable settings, and
command usage recommended for easier formal verification of RTL vs GATE.
Hereafter, a command starting with a dc_shell> prompt indicates a command of Design Compiler.

5.1.1 Logic synthesis facilitating verification
Logic synthesis must be performed by taking into consideration the following three points for easier formal
verification.

(1) Outputting GATE following initial synthesis
Be sure to output a GATE following initial synthesis (mapping from RTL to GATE).
If RTL vs GATE verification takes time or is aborted, RTL vs GATE verification can be executed easily by
using a GATE following initial synthesis as described in section 5.1.2 Two-stage verification before and
after logic synthesis.

(2) Facilitating name correspondence
Verification point correspondence is basically made using a name as a key. It is widely known that logic
synthesis changes the expressions of registers and buses and the names of separator characters of
hierarchies, etc., and so formal verification tools automatically ensure correspondence for representative name
changes (changing register aaa to aaa_reg).
For a verification point that the tool cannot correspond, the tool is assisted by the user setting renaming rules.
If correspondence cannot be made by the method above, the user must check the correspondence
relationships and execute a command to make correspondence directly. Consequently, it is recommended not
to perform logic synthesis and execute a command that greatly changes the names.

(3) Verification can be executed for each hierarchy
Verification at each hierarchy can divide a vast logic cone that extends from one hierarchy to another, because
a hierarchy pin is the verification point. As a result, the verification time can be shortened and aborts may be
prevented.
Consequently, avoid performing logic synthesis effects the verification for each hierarchy and in which
hierarchy pin names are changed or logic is optimized over the hierarchy.

5.1.2 Two-stage verification before and after logic synthesis
This section describes a method of two-stage verification including the GATE following initial synthesis, which can
be used to verify data easily before and after logic synthesis.
For logic synthesis in OPENCAD, it is recommended to perform compilation step by step by altering the conditions
as shown in Figure 5-1. When thinking of verification before and after logic synthesis, comparison with the GATE
following execution of RTL and the logic synthesis tool may come to mind. However, by outputting GATE 1 following
initial synthesis, verification can be executed in the following two stages.

<1> RTL vs GATE 1: Verification before and after initial synthesis
<2> GATE 1 vs GATE 2: Verification before and after circuit optimization

Figure 5-1. Two-Stage Verification Flow

Formal verification
(1)
RTL GATE1 GATE2
Formal verification
(2)
Initial synthesis
RTL is mapped to the GATE
(compilation by TYP conditions).
Incremental synthesis
Compilation by changing max/min conditions.
Optimizes the circuit to meet the restrictions.

The above verification flow utilizes the fact that verification of GATE vs. GATE is easier than that of RTL vs. GATE.
RTL vs. GATE comparison is performed in the simplest case and a substantial circuit change such as optimization is
verified by GATE vs GATE.
Consequently, only map RTL to the GATE for initial synthesis and perform circuit optimization, such as ungroup
and boundary_optimization, for the GATE following initial synthesis.

5.1.3 change_names -log option
When using the change_names command, be sure to specify the -log option.
A log file for name change is output, which can be referenced when making correspondence of verification points.
Two examples of execution are shown below.

[Example of execution 1]
dc_shell> change_names rules OpenCAD log file_name
or
[Example of execution 2]
dc_shell> report_names rules OpenCAD -nosplit log file_name

In Formality, the correspondence of verification points in the log file can be made by using the rename_object -file
command to read the log file of the change_names command. However, it is not recommended to make
correspondence using the rename_object -file command for the following reasons.

Measures explained in sections 5.1.4 to 5.1.7 enable Formality to automatically make correspondence in most
cases.
The log file of the change_names command may not be able to be read unchanged, and editing is troublesome.

fm_shell> set_reference_design rtl:/WORK/top
fm_shell> current_design $ref
fm_shell> rename_object -file file_name

Table 5-1. File Restrictions of rename_object_file
Restriction Measure
The correspondence between verification points is
described in one line (change_names outputs characters
across multiple lines if many characters exist in one line).
Edit multiple lines to one line.
Add a backslash, which cancels the line feed, to the end of line.
Use the report_names -nosplit command.
A slash / is described. Add a backslash \ to all slashes / in the name of reference circuit
(like \ /).
Design with the hierarchy expanded by logic synthesis If the ungroup command has been executed in Design Compiler,
execute the ungroup command in Formality.
Renaming of bus members is not supported. The user should make correspondence directly.

5.1.4 Bus naming rule
The following setting is recommended to change the default setting of the bus naming rule.

bus_naming_style = %s_%d ;
bus_dimension_separator_style = _;
change_names_dont_change_bus_members = true ;

Each variable of Design Compiler is explained below.

(1) bus_naming_style
Specifies the bus naming style. In the case of %s_%d, Formality can make correspondence automatically, so
the user does not need to additionally set a naming rule.
For example, if there is no separator between a character string and an index like %s%d, a formal verification
tool cannot determine which name, A2[0] or A[20] (the name of RTL), to correspond with A20 of the GATE.
Formality can automatically support a verification point even with the default setting (%s[%d]). Therefore, if
any inconvenience arises as a result of specifying this variable, it does not have to be specified.

(2) bus_dimension_separator_style
Specifies a separator for a multi-dimensional bus. When _ is set, the tool can automatically make
correspondence of verification points. Be sure to specify separators similarly to bus_naming_style.
Formality can automatically support a verification point even with the default setting (][). Therefore, if any
inconvenience arises as a result of specifying this variable, it does not have to be specified.

(3) change_names_dont_change_bus_members
This variable controls the changing of the name of a bus member.
When false (default value) is set, the following name change may occur and the formal verification tool
cannot automatically make correspondence of verification points. Set true so that the name is not changed.

Example of bus member change
RTL GATE RTL GATE
A[0][0] A_0 A[32] A32
A[0][1] A_1 A3[2] A32B
A[1][0] A_2
A[1][1] A_3
Two-dimensional vector changes to one-dimensional. Changed when names are duplicated.

A bus member change is reported as a Warning in the change_names log.

[Example of bus member change warning]
Warning: In design sub_mode, port bus member A32 changed to A32B.(NMA-16)

5.1.5 Array of hierarchy pins (VHDL)
When RTL is described in VHDL, a GATE (in which the direction of the vector of a low hierarchy pin is in the
ascending order) is created when the default is set for Design Compiler.

Figure 5-2. Example of Changing Direction of Vector of Pin

reg[0]
reg[7]
pin[0]
pin[7]
reg[0]
reg[7]
reg[0]
reg[7]
pin[7]
pin[0]
reg[0]
reg[7]
Synthesis
RTL GATE
Vector is defined in the descending
order (7 down to 0).
Vector is changed to the
ascending order.

The direction of a vector is changed on the hierarchy pin, so the circuit operation is not affected. However, the
hierarchy pin does not match for formal verification, therefore verification of the hierarchy results in a mismatch.

[Countermeasures]
A GATE with a vector direction that accords with the user's description can be created by the following setting.

vhdlout_bit_type = std_logic ;
vhdlout_bit_vector_type = std_logic_vector ;
vhdlout_single_bit = user ;
vhdlout_preserve_hierarchical_types = user ;
Remark Only vhdlout_preserve_hierarchical_types differs from the default value (vector).

5.1.6 ungroup
ungroup is used to expand the hierarchy and optimize the surrounding circuit. ungroup not only changes the
hierarchical structure but can also greatly change the names, depending on the use. Therefore, the following (1) and
(2) are recommended.

ungroup
compile -ungroup_all
set_ungroup

(1) Execute ungroup only on those sections on which formal verification can be performed
As the hierarchy expands, the logic cone may become larger, the processing time of the formal verification tool
may be lengthened, or verification may be aborted. Do not execute ungroup in such sections.
A hierarchy with a computing unit must be released from execution of ungroup.

(2) Prohibit use of -prefix and -simple_names options
Do not use the -prefix and -simple_names options when executing ungroup. Otherwise, the history of the
hierarchy does not remain in the name and correspondence of verification points becomes difficult.
Note the following points when not using the above options.

(a) A name contains a slash (/), which indicates the separation of hierarchy, so it may need to be converted
to another character using the change_names command due to the restriction on the number of
characters in the subsequent flow.

(b) To prevent a name from being omitted because of a restriction on the number of characters, the number
of characters must be increased by recording the hierarchy history.

<Measures against the restriction on the number of characters in OPENCAD environment>
Edit the restriction on the number of characters in the script file (NAME_RULE.scr), to make it match
the naming rule of OPENCAD, to a maximum of 255.

[Example of modifying restriction on number of characters]
define_name_rules OpenCAD max_length 255

The NAME_RULE.scr file is located in either one of the following directories, depending on the kit of
OPENCAD. The most recent kit is the latter directory.

${OPC_PATH}/lib/${TECHNOLOGY}/${CONDITION}/synopsys/script/
${OPC_PATH}/lib/common/dc_setup/script/

5.1.7 Optimization of hierarchy boundary
When optimization is performed over a hierarchic boundary, the name of hierarchy and logic are changed as
shown in Figure 5-3. In addition, floating hierarchy pins can also be deleted. In these cases, formal verification for
each hierarchy cannot be performed.

compile -boundary_optimization
set_boundary_optimization
remove_unconnected_ports

Figure 5-3. Example of Optimization of Hierarchic Boundary

(a) Logic of hierarchy pin is inverted (_BAR added to name)

pinA
Optimization
pinA_BAR

(b) Logic optimization by fixed value transmission (floating pins in hierarchy)

GND GND
Optimization

When a hierarchic boundary is optimized (similarly to the description in 5.1.6 ungroup), a formal verification tool
performs verification with an expanded hierarchy, so the verification time is lengthened. It is recommended not to
optimize a hierarchic boundary beforehand or, if it is optimized, not to invert the logic of the hierarchy pin by using the
following setting.

[Setting to prevent logic inversion of hierarchy pin]
compile_disable_hierarchical_inverter_opt = "true ;

When verification is aborted before or after optimization of a hierarchic boundary, the section must not be
optimized but synthesized again.

5.2 Complex Computing Unit

When there is a computing unit in the design, verification may be difficult. Care must be taken on this point.
Multipliers and dividers are complex in logic and make the logic cone large, so verification may be aborted more often
as the number of bits increases. Furthermore, when multiplication and division are described in a multi-cascaded
structure, verification may be aborted because the circuit structure is changed by logic synthesis (to a tree structure).
When using a complex computing unit, it is recommended to create, beforehand, an independent module containing
the computing unit.
Measures to avoid this problem are described below, using an example of a multiplier.

(1) Only the multiplier is separated as an independent module and verified [measure 1]

(a) Creation of a module that performs only multiplication (procedure 1)
Only the logic of multiplication is verified by separating the multiplier from the other logic and the
correspondence of verification points can be made easily, making verification easier for the tool.

(b) Verification of multiplier modules (procedure 2)
Verify the modules of the multiplier.

(c) Setting the multiplier module to be handled as a black box (procedure 3)
Set the multiplier module that matched in verification to be handled as a black box. By setting a verified
module to be handled a black box, high hierarchies can be verified in a short time. The method for setting
a black box is explained below.

<Black box specification method>
Specify the module to be handled as a black box for both reference and implementation circuits using
the remove_design command. Then, execute the link command (or execute the verify command
without using the -nolink option). The deleted module is not handled as a black box until the link
command is executed.

fm_shell> remove_design ref:/WORK/U1
fm_shell> remove_design impl:/WORK/U1
fm_shell> link ref:/WORK/TOP
fm_shell> link impl:/WORK/TOP

(d) Verification of other modules (procedure 4)
Compare and verify modules other than the multiplier.

(2) Verification by simulation [measures 2]
If the operation is also aborted when using method (1) above, create a pattern for a module containing a
multiplier and verify its logic with a simulator.
5.3 Instantiated DesignWare

This section explains the verification method when DesignWare provided by Synopsys is instantiated.
Because Formality uses the DesignWare library, a setting for reading the library is necessary. Before reading the
instantiated design file, set the directory in which Design Compiler is installed in the Formality variable hdlin_dwroot.
The DesignWare library is automatically read from the directory path set when the link command is executed.

fm_shell> set hdlin_dwroot <Synopsys_inst_dir>

Note that NEC DesignWare instantiation provided in OPENCAD cannot be used because it is not supported by the
tool.

5.4 Compiled Memory Bus Wrapper

With the compiled memory in OPENCAD, since pins do not use a bus, RTL and the compiled memory cannot be
connected via a bus, and each pin has to be connected one-to-one.

To solve this problem, a compiled memory Bus Wrapper (hereinafter Bus Wrapper) which uses a bus topology for
the compiled memory pins, can now be output with OPENCAD that has OPC_COMPMEM V3.0.0 or later mounted.
RTL and the compiled memory can easily be connected using Bus Wrapper.
Cautions when performing verification using Bus Wrapper are explained below.

(1) Reading Bus Wrapper as part of the design
When reading RTL, make sure to add Bus Wrapper-related files.

[When RTL is described in Verilog]
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/buswrapper/<RAM name>_bus.v

[When RTL is described in VHDL]
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/buswrapper/<RAM name>_bus.vhd

Remark <RAM name> varies as follows depending on the type of RAM to be used.
RAM Type <RAM Name>
Normal RAM (no redundancy) <RAM Name>
Redundant RAM (without Soft Wrapper
Note
) <RAM name>RD
Redundant RAM (with Soft Wrapper
Note
) <RAM name>RDU
Note Type of Wrapper which performs the redundant RAM logic by normal RAM and
a combination circuit.

Bus Wrapper is handled as a part of RTL, not as a library. Consequently, the read processing of Bus Wrapper
is not included in the Formality setup file output by OPC_FORMALITY.

<R>
(2) Cautions when connecting RTL and Bus Wrapper

(a) Module name
The Bus Wrapper module name is <RAM name>_bus. Instantiate to RTL after having checked the RAM
type to be used.

(b) When using redundant RAM with Soft Wrapper
The hierarchical structure when using a redundant RAM with a Soft Wrapper is a structure consisting of a
Bus Wrapper for redundant RAM placed onto a Soft Wrapper for redundant RAM, as shown in Figure 5-4.
To instantiate to RTL, read the Bus Wrapper for redundant RAM and the Soft Wrapper for redundant RAM
at the same time. The Bus Wrapper for normal RAM which is referenced within the Soft Wrapper for
redundant RAM is not required to be read.

Figure 5-4. Hierarchical Structure When the Bus Wrapper for Redundant RAM with a Soft Wrapper Is Used
D5
D4
D3
D2
D1
D0

A3
A2
A1
A0

WEN
CEN
CLK
Q5
Q4
Q3
Q2
Q1
Q0
Soft Wrapper for redundant RAM (XXXRDU)
Normal RAM (XXX)
D[3:0]
A[3:0]
WEN
CEN
CLK
Bus Wrapper for redundant RAM (XXXRDU_bus)
ERDLF
ERDL[4:0]
ERDHF
ERDH[4:0]
Q[3:0]
The Bus Wrapper for normal RAM
is not referenced.
The Bus Wrapper and Soft Wrapper
for redundant RAM are referenced.

(c) Connecting pins that use a bus topology
When instantiating to RTL, the definition of the pins on the RTL side must be checked before connecting
the pins.
The definition of pins using a bus with Bus Wrapper is always in descending order, such as A[3:0]. If the
definition on the RTL side is in ascending order, such as A[0:3], the intended verification may not be able
to be performed when the pins are simply connected.

5.5 Verification Before and After Retiming

Retiming means adding/deleting registers or moving the combination logic over a register in order to meet the
requirements for timing and area. In a formal verification in which two circuits are compared with the verification point
as the reference, if the circuit, before and after retiming, is verified with its default settings, then the correspondence of
the verification points may not be made, or the result may mismatch.
The retiming at which verification can be executed by Formality and the method to set verification is explained
below. Retiming that is not supported by the tool results in a mismatch in formal verification, and must therefore be
avoided.

(1) Pipeline processing
If pipeline processing has been performed by the balance_registers command of Design Compiler or by
manual operation of the designer, execute the set_parameters -retimed command before executing the
verify command. However, this command increases the verification time, so specify only the retimed
hierarchies.

[Example of command execution]
fm_shell > set_parameters -retimed rtl:/WORK/sub_mod

In the following cases, verification cannot be performed.
If logic moves for a loop that includes a register
If the number of stages of the pipeline is changed (verification can be performed if the number of registers
is different.)

(2) Movement of inverter before and after a register
When an inverter is moved before and after a register as shown in Figure 5-5, set the Formality variable
verification_inversion_push to true, then perform verification. This type of retiming can also be verified
when an inverter is moved for a loop that includes a register.

fm_shell > set verification_inversion_push true

Figure 5-5. Example of Circuit in Which Inverter Is Moved

DATA
CLK
DATA
CLK

5.6 Verification of Clock-Gated Circuit

One of techniques for lowering the power consumption of the circuit is clock gating. Clock gating is a technique in
which a control gate is inserted into the clock line to temporarily stop supplying the clock to the registers that do not
need to be operated. There are the following two methods of implementing clock gating.

<1> The designer performs clock gating in the RTL stage.
<2> Use an EDA tool such as Power Compiler
TM
(supplied by Synopsys) to automatically implement clock gating.

When clock gating is performed, the logic of the clock signal is changed, and a verification point is created in the
clock signal for latch-based clock gating. Therefore, verification in the default state causes a mismatch.

Figure 5-6. Clock Gating

en
clk
clk
en
al ways@( posedge cl k)
i f ( en)
dat a_out <=dat a_i n;
Gating
0
1 data_in
data_out
data_in data_out
RTL description
Circuit structure
Circuit structure after clock gating

If clock gating has been performed, the Formality variable verification_clock_gate_hold_mode must be set.
To set the value, specify the enable logic when the clock supply is stopped as low, high, or any (depending on
the version used, any may not be specified). For example, in Figure 5-6, set low.

fm_shell> set verification_clock_gate_hold_mode low

When Power Compiler is used, the setting is always low. This is because Power Compiler inserts an inverter to
the en signal even if the RTL description in Figure 5-6 is if(!en).

For clock gating verification with Formality as shown above, enable logic to stop clock supply is specified but only a
uniform value can be set for all of the objects to be verified.
Note, therefore, that circuits including clock gating with different enable logics cannot be verified at once if low or
high is set.
Figure 5-7 shows an example of a circuit whose enable logic is judged by Formality to be low or high. As shown in
this example, different settings may be necessary depending on the clock polarity of a register, even if the clock gating
block is the same.

Figure 5-7. Enable Logic

(a) Example of circuit whose enable logic is judged as low

en
clk
data_in
data_out
en
clk
data_in
data_out

(b) Example of circuit whose enable logic is judged as high

en
clk
data_in
data_out
en
clk
data_in
data_out

Even with the setting above, a mismatch caused by a clock gating circuit may be reported, depending on the circuit
configuration.
In a case like this, set a fixed value for the Enable logic for clock propagation (for everything following the clock gating
circuit) for both circuits to verify.

set_constant type port ref:/WORK/top/en 1
set_constant type port impl:/WORK/top/en 1

5.7 Verification Before and After DFT Execution

Because a test circuit is inserted into the implementation circuit in verification before and after DFT (design for test)
tool execution, a mismatch occurs in default verification. The effect on the test circuit can then be nullified by setting
the implementation circuit in the normal mode, and whether a logic change was made or not in the users circuit can
be checked.
In Formality, execute the set_constant command before executing the verify command and set the value from
normal mode to the test pin of the implementation circuit.

[Example of setting fixed value]
fm_shell set_constant -type port impl:/WORK/top/scan_en 0

The method to obtain a test pin name and normal mode value in each DFT tool is explained below.
In the verification flow following the insertion of a test circuit, the same test circuit exists in the reference circuit and
implementation circuit, so the normal mode does not need to be set. (Note that, as an exception, verification is
performed before and after scan rechaining. Refer to 5.7.7 Verification before and after scan rechaining.) When
no normal mode is set, verification including the logic of the test circuit can be performed.

Figure 5-8. DFT and Formal Verification Flow

Formal verification
(Normal mode needs to
be set in circuit A'.)
Circuit A'
Formal verification
(Normal mode does not
need to be set.)
DFT
insertion
User
circuit change
Test
circuit
Circuit A''
Test
circuit
Circuit A

5.7.1 TESTACT
Refer to the ${CIRCUIT}.dft_set file output by TESTACT in order to set a circuit after executing TESTACT in the
normal mode. (${CIRCUIT} indicates the name of the top hierarchy of the circuit.)
The format of the ${CIRCUIT}.dft_set file is as follows.

*PIN_CONST
Test pin Normal mode value
(same as above)
*END PIN_CONST

The circuit enters the normal mode when a [Normal mode value] is set to the [Test pin] described in the file.

Cautions 1. Pseudo errors may occur in some cases of formal verification before and after TESTACT. For
details, refer to 2.4 Known Problems.
2. When you build SCAN into BIST in TESTACT, also set SCAN circuit to normal mode.
Following only the settings mentioned previously will result in a mismatch.

5.7.2 NEC BSCAN
Refer to the ${CIRCUIT}.set file output by NEC BSCAN in order to set a circuit after executing NEC BSCAN in the
The format of the ${CIRCUIT}.set file is as follows.

Function name Test pin name
(same as above)

The item required for setting the normal mode is the pin whose [Function name] is TRST. Set 0 for [Test pin
name]. When the pin whose [Function name] is CTRI is used, set 0 for [Test pin name].

5.7.3 NEC BIST (RAM BIST)
Refer to the RAM PIN file (${CIRCUIT}.rpi) in order to set a circuit after executing NEC BIST in the normal mode.
(${CIRCUIT} indicates the name of the top hierarchy of the circuit.) The RAM PIN file is created using the items [RAM
BIST check] [RAM PIN file] from the GUI menu for the OPENCAD simulator.
The format of the ${CIRCUIT}.rpi file is as follows.

/ Circuit name
#MAXWORD Number of words ;
#TEB TEB pin name ;
#TIN TIN pin name ;
#TOUT TOUT pin name ;

The item required for setting the normal mode is the #TEB pin. Set 1 for [TEB pin name].

5.7.4 TESTBUS
Refer to the ${CIRCUIT}.epf file output by TESTBUS in order to set a circuit after executing TESTBUS in the
The format of the ${CIRCUIT}.epf file is as follows.

*EXTERNAL_PIN Circuit name
Test pin name Attribute before execution Attribute following execution Function name
(same as above)
*END_OF_EXTERNAL_PIN

The items required for setting the normal mode are the pins whose [Function name(s)] are TMC and BUNRI. Set 0
for [Test pin name].

5.7.5 Scan path tool made by EDA vendor
In the scan path tools released by each EDA vendor, the user can specify any test pin name and value in the
normal mode. Check, beforehand, the setup of normal mode with the test circuit design engineer.

5.7.6 NEC SCAN2
The method for setting a circuit after executing NEC SCAN2 in the normal mode varies between when NEC
SCAN2 is used with TESTACT or NEC BSCAN and when NEC SCAN2 is used alone.

(1) When NEC SCAN2 is used with TESTACT
When the TESTACT circuit is set in the normal mode, the NEC SCAN2 circuit is also set in the normal mode.
Refer to 5.7.1 TESTACT to set the circuit.

(2) When NEC SCAN2 is used with NEC BSCAN
When the NEC BSCAN circuit is set in the normal mode, the NEC SCAN2 circuit is also set in the normal
mode. Refer to 5.7.2 NEC BSCAN to set the circuit.

(3) When NEC SCAN2 is used alone
Refer to the ${CIRCUIT}.primpin file output by NEC SCAN2 (${CIRCUIT} indicates the name of the top
hierarchy of the circuit).
The format of the ${CIRCUIT}.primpin file is as follows.

Function name Test pin name (test mode value)
(same as above)

The items required for setting the normal mode are the pins whose [Function name(s)] are AMC and SMC. Set the
inverted logic of the test mode value for [Test pin name].
5.7.7 Verification before and after scan rechaining
The logic of scan-in viewed from each register is changed in a circuit before and after scan rechaining (scan
reordering), so verification with the default setting results in a mismatch. For this reason, set data according to the
following procedure before performing verification.

(1) Procedure 1
Set the normal mode for both circuits before and after scan rechaining.

(2) Procedure 2
When the scan-out external output pin is not shared with a user pin, do not verify the scan-out pin. This is an
action taken to prevent a mismatch from being reported at the scan-out pin. In order not to verify this pin,
execute the remove_compare_point (set_dont_verify_point with 2002.03 or later) command.

fm_shell> remove_compare_point ref:/WORK/top/SOUT
fm_shell> remove_compare_point impl:/WORK/top/SOUT

5.7.8 Verification before and after eFuse circuit insertion
Since the eFuse macro used when inserting the eFuse circuit is a black box model, verification with default settings
causes a mismatch in circuits before and after eFuse circuit insertion.
To prevent this mismatch, assign 1 to all eFuse macro output pins.

fm_shell> set_constant -type pin impl:/WORK/EFUSECNT/EFMGR1/OUT3 1

5.8 Handling of Bus Holder

The bus holder is a block that holds the level of a bus.
Because the bus holder is a black box model having one bidirectional pin, the verification result becomes a
mismatch unless that pin is placed at the same location in the two circuits to be verified.

Figure 5-9. Example of Bus Holder Circuit

Black Box
Bus holder
Bidirectional pin

A bus holder may exist in a circuit for the following two reasons.

(1) If the bus holder is placed in a user-designed 3-state bus
(2) If the NEC Electronics DFT tool (TESTBUS or TESTACT) automatically inserts a bus holder

The verification method in each case is explained below.
For the block name and pin name of the bus holder, refer to the NEC Electronics manual Block Library.

(1) If a bus holder is placed in a user-designed 3-state bus
It is recommended to place the bus holder in the circuit from the RTL stage.
When the bus holder exists in RTL, the mismatch caused by the bus holder is not found in the result of RTL vs
GATE. If the bus holder is added to GATE later, perform verification according to the procedure in (2).

(2) If the NEC Electronics DFT tool (TESTBUS or TESTACT) automatically inserts a bus holder
TESTBUS or TESTACT-executed TESTBUS automatically inserts a bus holder if the test output of the NEC
core is a 3-state bus (the bus may be replaced by a 2-state bus instead of inserting the bus holder). Perform
verification before and after insertion of the bus holder according to the following procedure.

(a) Checking of bus holder connection
Check whether the bus holder is connected to the 3-state bus. If this has been checked, go to step (b).

<1> Execute the verify command in the default state (procedure 1).
As previously described, a mismatch is reported. Check that the correspondence of verification
points is not made at the bus holder section.

<2> Analyze the mismatch point to check whether the bus holder is connected to the 3-state bus
(procedure 2).
This involves checking of the difference of logic between the state in which high impedance (Hi-Z) in
the reference circuit is output to the bus and the state in which this does not occur after the bus
holder is inserted.

(b) Change of pin attribute of bus holder and re-verification
The circuits can be matched by eliminating the effect of the bus holder. Perform re-verification according
to the following procedure.

<1> Change of pin attribute of bus holder (procedure 1)
Verification before and after insertion of the bus holder results in a mismatch because the pins with
output attributes of the bus holder (black box model) pins are input to a logic cone. Use the following
command to forcibly change the pin attribute.

<Example of changing pin attribute of bus holder>
Execute the remove_resistive_drivers command, and then execute the set_direction command
for both circuits (because the library for the bus holder is stored in each container).
The bus holder is stored in the library named SPECIAL.
An example of execution if TBCLHOLD is used as a bus holder block is shown below.

fm_shell> remove_resistive_drivers
fm_shell> set_direction ref:/SPECIAL/TBCLHOLD/N01 in -shared_lib
fm_shell> set_direction impl:/SPECIAL/TBCLHOLD/N01 in -shared_lib

<2> Execute the verify command to perform re-verification (procedure 2).

5.9 Combination Loop Check

This section explains the method to check whether a combination loop exists in the circuit.
Such a loop may exist over some hierarchies, and must therefore be checked carefully, especially when an entire
chip is read into the tool.

<Checking method>
Whether a combination loop exists during execution of the verify command is displayed.
The checking method varies between if a combination loop could be cut (cut point is generated) and if it could not
be cut. In order to automatically cut a combination loop, set verification_auto_loop_break true must be set
beforehand (true is the default value).

(1) If a combination loop could be cut
Information is displayed to indicate that a combination loop could be cut. As indicated by the message, check
the contents of the formality.log file to identify the cut point.

[Example of combination loop cut message]
Status: Building verification models...
Info: 1 (1) cycles broken in reference (implementation) design; see
formality.log for list.

(2) If a combination loop could not be cut (or when set verification_auto_loop_break false is set)
If a combination loop could not be cut, a warning message is reported.

[Example of combination loop existence message]
Warning: Design LOOP1 contains a combinational cycle (FM-159)
Warning: Net net1 belongs to a combinational cycle.
Warning: Non-equivalence of downstream compare points cannot be proven.

As the execution result of the verify command, INCONCLUSIVE is reported to indicate that verification was
aborted. If any mismatch point is detected, FAILED is reported even if a combination loop exists.

[Result of verify command]
******************** Verification Results ********************
Verification INCONCLUSIVE
(Equivalence checking aborted due to complexity)
---------------------------------------------------
Reference design : ref:/WORK/LOOP1
Implementation design: impl:/WORK/LOOP1
**************************************************************

To check the logic cone containing a combination loop, execute the verify command and then execute the
report_aborted_points command.

[Example of executing report_aborted_points command]
fm_shell> report_aborted_points
Aborted compare points:
0 Unver (unverified because of interrupt or limit reached)
1 Loop (driven by a state holding asynchronous loop)
0 Hard (too complex to solve)

Loop : ref (Port) ref:/WORK/LOOP1/OUT
Impl (Port) impl:/WORK/LOOP1/OUT

To check the cell, net, and pin that make up a combination loop, execute the verify command and then
execute the report_loops command.

[Example of executing report_loops command]
fm_shell> report_loops -ref
There were 1 loops found in the reference design :
Loop 1 :
(Cell) ref:/WORK/LOOP1/U0
(Cell) ref:/WORK/LOOP1/U2
(Pin) ref:/WORK/LOOP1/U2/N01
(Net) ref:/WORK/LOOP1/N$0010005
(Pin) ref:/WORK/LOOP1/U0/H02

fm_shell> report_loops -impl
There were 1 loops found in the implementation design :
Loop 1 :
(Cell) impl:/WORK/LOOP2/U0
(Cell) impl:/WORK/LOOP2/U2
(Pin) impl:/WORK/LOOP2/U2/N01
(Net) impl:/WORK/LOOP2/N$0010005
(Pin) impl:/WORK/LOOP2/U0/H02

5.10 Formal Verification Following ECO

Formal verification is also valid in logic verification following ECO (Engineering Change Order). At that time,
modify the circuit of RTL similarly and verify the format of RTL following ECO vs GATE following ECO. If RTL vs
GATE verification is difficult in terms of the performance, modify the circuit for the GATE in the design flow (e.g. GATE
after initial synthesis) similarly to ECO, and perform formal verification in steps.
It is not recommended to use a GATE that was created by logically synthesizing an RTL following ECO for formal
verification. For example, if the way of handling don't care has changed by optimizing logic synthesis, a GATE of a
different logic may be created. When that GATE is compared with the other GATE following ECO in formal verification,
a mismatch is reported.

Figure 5-10. Formal Verification Flow Following ECO

RTL GATE GATE Logic synthesis
GATE
RTL GATE Logic synthesis
GATE
GATE
GATE
Formal verification
Formal verification
ECO
ECO
ECO
Following initial synthesis

CHAPTER 6 EXAMPLE OF EXECUTION OF Formality

This chapter shows an example of Formality execution using various kinds of circuit data.

6.1 Example of Execution of Combination Circuit

Figure 6-1 shows an example of combination circuit.
When looking at the external output pin OUT18, the value is ascertained by IN36 to IN38 in the reference circuit,
while the logic of IN39 is also taken into consideration in the implementation circuit. The logic of OUT19 similarly does
not match. Consequently, this is a circuit for which a mismatch should be reported.

Figure 6-1. Example of Combination Circuit

IN36
IN37
IN38
IN39
OUT18
OUT19
BB18
BB19
Reference circuit
IN36
IN37
IN38
IN39
OUT18
OUT19
BB18
AA9

The result of Formality execution is shown below ( shaded area: command section, #: comment section).
(1/3)
Formality (R)
Version 2001.08-FM1-SP1 -- Oct 2, 2001
Copyright (C) 1988-2002 by Synopsys, Inc.
ALL RIGHTS RESERVED

This program is proprietary and confidential information of Synopsys, Inc.
and may be used and disclosed only as authorized in a license agreement
controlling such use and disclosure.
# Library read
Loading db file ${OPC PATH}/lib/common/synopsys/basic/basic.db
Loading db file ${OPC_PATH}/lib/common/synopsys/iobuffer/iobuffer.db
Loading db file ${OPC_PATH}/lib/common/synopsys/nec_bscan/nec_bscan.db
Loading db file ${OPC_PATH}/lib/common/synopsys/nec_scan/nec_scan.db
Loading db file ${OPC_PATH}/lib/common/synopsys/primitive/primitive.db
Loading db file ${OPC_PATH}/lib/common/synopsys/scan/scan.db
Loading db file ${OPC_PATH}/lib/common/synopsys/special/special.db
. . .
Loading verilog file ${OPC_PATH}/lib/common/synopsys/softmacro/nec_scan/nec_scan.v
Loading verilog file ${OPC_PATH}/lib/common/synopsys/softmacro/special/special.v

# ======== Set default parameters ======== # Initial setting
set verification_blackbox_match_mode identity
set verification_set_undriven_signals PI
set verification_passing_mode consistency
# ======== Set reference netlist ===== # Reference circuit read
read_verilog -c ref TEST1.v
Loading verilog file /home/user/TEST1/test1.v
No target library specified, default is WORK
Created container ref
Current container set to ref
1
link ref:/WORK/TEST1
Linking design ref:/WORK/TEST1
Status: Elaborating design TEST1 ...
Status: Implementing inferred operators...
Link of ref:/WORK/TEST1 completed successfully
1
set_reference_design ref:/WORK/TEST1 # Reference circuit specification
Reference design set to ref:/WORK/TEST1
1
# ======== Set implementation netlist ======== # Implementation circuit read
read_verilog -c impl TEST1_mod.v
Loading verilog file /home/user/TEST1_mod.v
Created container impl
Current container set to impl
1
link impl:/WORK/TEST1
Linking design impl:/WORK/TEST1
Status: Elaborating design TEST1 ...
Link of impl:/WORK/TEST1 completed successfully
1
set_implementation_design impl:/WORK/TEST1 # Implementation circuit specification
Implementation design set to impl:/WORK/TEST1
1
verify # Verification execution
Reference design is ref:/WORK/TEST1
Implementation design is impl:/WORK/TEST1
Linking design ref:/WORK/TEST1

(2/3)

Link of ref:/WORK/TEST1 completed successfully
Linking design impl:/WORK/TEST1
Link of impl:/WORK/TEST1 completed successfully
Status: Checking designs...
Status: Matching...
# Verification point correspondence result log
******************************* Matching Results ******************************
0(0) Unmatched reference(implementation) Compare points
0(0) Unmatched reference(implementation) primary inputs, black-box outputs
*******************************************************************************
Status: Verifying...
Compare point OUT18 failed (is not equivalent)
Compare point OUT19 failed (is not equivalent)

# Verification result log
***************************** Verification Results *****************************
Verification FAILED
--------------------------------------------------------------------------------
Reference design: ref:/WORK/TEST1
Implementation design: impl:/WORK/TEST1
0(0) Unmatched reference(implementation) inputs
--------------------------------------------------------------------------------
Matched Compare Points BBox Loop Net Pin Port DFF LAT TOTAL
--------------------------------------------------------------------------------
*******************************************************************************
0
report_failing points # Indication of mismatch points
2 Failing compare points:
ref (Port) ref:/WORK/TEST1/OUT18
impl (Port) impl:/WORK/TEST1/OUT18
ref (Port) ref:/WORK/TEST1/OUT19
impl (Port) impl:/WORK/TEST1/OUT19
[BBox: black-box input pin
Loop: cycle break point
Net: multiply-driven net
Pin: hierarchical block input pin
Port: output port
reg: register component]
1
diagnose # Analysis of mismatch points
Status: Diagnosing impl:/WORK/TEST1 vs ref:/WORK/TEST1...
Status: Diagnosis initializing...
Status: Analyzing patterns...
Analysis completed
Diagnosis completed
1
repot_error_candidates # Indication of error candidates
Error candidates:
% type Name
---- ---- ----

(3/3)

100.0 net BB18/N01
100.0 net OUT18
50.0 net BB18/H01
50.0 net BB18/H04
50.0 net IN36
50.0 net IN39
50.0 net OUT19
50.0 net \*Logic1\*
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Max error coverage found: 100.0% (2 instances)
1
fm_shell>

By executing the report_error_candidates command after the diagnose command, the candidate nets likely to
have caused a mismatch are output. The higher the number of this percentage, the higher the probability of being the
cause of the mismatch. However, regard this as a rough standard.
When Formality is started on the GUI, debugging can be performed via the GUI. Figure 6-2 shows the results
reported as a mismatch displayed as a schematic diagram of the logic cone on the GUI. It also shows the logical
value of the pattern in which a mismatch occurred.

Figure 6-2. Debug Screens

As seen on the screens above, inputs IN36 to IN38 determine the logic of OUT18 in the reference circuit, while in
the implementation circuit, IN36 to IN39 are the inputs. Furthermore, a mismatch occurs when IN36 to IN38 are 1 and
IN39 is 0.
6.2 Example of Verification Before and After Scan Path Circuit Insertion

This example of verification before and after scan path circuit insertion is shown in Figure 6-3.
NESP_TS is a scan controller and has a lower hierarchy.

Figure 6-3. Example of Scan Path Circuit Insertion

RESET
D1
CLK
OUT
Reference circuit
U3 U4
AMC
D1
CLK
RESET
SMC
SIN
U3 U4
OUT
SOUT
NESP_C0
NESP_TS
NESP_C5

6.2.1 Verification with default setting
The result of verification with the default setting is shown first. The following example is the log of Formality
executed on the GUI. (shaded area: command section, #: comment section).
(1/2)
formality > read_verilog -c ref TEST.V
Loading verilog file /home/user/TEST.v
Created container ref
Current container set to ref
1
formality > link ref:/WORK/test
Linking design ref:/WORK/test
Status: Elaborating design test ...
Link of ref:/WORK/test completed successfully
1
formality > set_reference_design ref:/WORK/test
Reference design set to ref:/WORK/test
1
formality > read_verilog -c impl TEST.nesp.v
Loading verilog file /home/user/TEST.nesp.v
Created container impl
Current container set to impl
1
formality > link impl:/WORK/test
Linking design impl:/WORK/test
Status: Elaborating design test ...
Status: Elaborating design NESP_TS ...
Status: Elaborating design SCKGZ ...
Link of impl:/WORK/test completed successfully
1
formality > set_implementation_design impl:/WORK/test
Implementation design set to impl:/WORK/test
1
formality > verify # Verification execution
Reference design is ref:/WORK/test
Implementation design is impl:/WORK/test
Status: Matching...
# Verification point correspondence result log
# (non-corresponding verification points found)
******************************* Matching Results *************************************
0(5) Unmatched reference(implementation) compare points
--------------------------------------------------------------------------------
Unmatched Objects REF IMPL
--------------------------------------------------------------------------------
Input ports (port) 0 3
Output ports (port) 0 1
Registers (reg) 0 4
Constant 0 0 2
Constant 1 0 2
********************************************************************************
(2/2)

Compare point U3 failed (is not equivalent)
Compare point U4 failed (is not equivalent)
Compare point OUT failed (is not equivalent)
Verification FAILED
-------------------
Reference design: ref:/WORK/test
Implementation design: impl:/WORK/test
# Verification result (mismatch) log
***************************** Verification Results *****************************
Verification FAILED
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
********************************************************************************
0
formality >

6.2.2 Debugging of mismatch points

(1) Display of mismatch points
From the pull-down menu of the Formality main window, select [Report] [Failing Points]. A list of
ObjectIDs of the mismatched verification points appears as shown in Figure 6-4.

Figure 6-4. Mismatch Point Report

In the list, the line in which a verification point appears in both Ref Object and Impl Object (e.g.,
ref:/WORK/test/OUT) indicates that the corresponding verification point exists. The line in which a verification
point appears in only Ref Object or Impl Object (e.g., impl:/WORK/test/SOT) indicates that the verification
point is judged to exist in only one of the circuits. If a verification point for which correspondence is not made
appears, check the following points.

Whether the settings of the naming rules of the bus, hierarchy separation, etc. are correct or not.
When a DFT circuit is inserted, whether the settings of the normal mode have been made or not.

In this circuit, the fixed value of normal mode is not set for the test pin. However, continue debugging.

(2) Execution of diagnose
In the Failing Points - Report window (refer to Figure 6-4), right-click the OUT pin, which is one of the
mismatch points, and select [Diagnose Point]. The diagnose command is executed to generate a test
pattern that indicates the mismatch.

(3) Display of error candidates
From the pull-down menu of the Formality main window, select [Report] [Error Candidates]. The net that
is likely to have caused a mismatch appears (refer to Figure 6-5).

Figure 6-5. Error Candidate Report

(4) Display of logic cone
Return to the Failing Points - Report window (refer to Figure 6-4), right-click the OUT pin, and select [View
Logic Cone]. The logic cone containing the mismatch verification point appears (refer to Figure 6-6). In the
window, the upper area indicates the reference circuit and the lower area indicates the implementation circuit.
Nets are separated by color for each value of percentage displayed for the error candidates.

(5) Display of mismatch pattern
From the pull-down menu of the Schematic Diagram window of the logic cone, select [View] [Apply First
Pattern]. The result of simulating the test pattern generated by diagnose appears (refer to Figure 6-6).
When multiple test patterns are generated, the test patterns can be switched and displayed by selecting [Next
Pattern] or [Previous Pattern].

Figure 6-6. Mismatch Point Report

(6) Debugging method
To perform debugging on the schematic diagram, refer to the error candidates and test pattern results to
narrow down the analysis range and specify the difference of logic in both circuits.
When the range is narrowed down, the function ([Remove Subcone] or [Remove Non-Controlling]) that
deletes the common section of both circuits from schematic diagram display and the function ([Isolate
Subcone]) that displays only a specific partial circuit are convenient.

6.2.3 Re-verification after setting normal mode
A case, in which a mismatch has occurred because the normal mode is not set in the implementation circuit, and
verification is executed again by setting the fixed values of the normal mode to AMC = 0, SMC = 0 as a result, is
shown below. (shaded area: Command section, #: Comment section).

formality > set_constant -type port impl:/WORK/test/AMC 0 # Fixed value setting (AMC = 0)
set impl:/WORK/test/AMC to constant 0
1
formality > set_constant -type port impl:/WORK/test/SMC 0 # Fixed value setting (SMC = 0)
Set impl:/WORK/test/SMC to constant 0
1
formality > verify # Re-verification
Reference design is ref:/WORK/test
Implementation design is impl:/WORK/test
Status Implementing inferred operators...
Status: Matching...

****************************** Matching Results *********************************
0(5) Unmatched reference(implementation) compare points
---------------------------------------------------------------------------------
Unmatched Objects REF IMPL
---------------------------------------------------------------------------------
Input ports (port) 0 3
Output ports (port) 0 1
Registers (reg) 0 4
Constant 0 0 2
Constant 1 0 2
*********************************************************************************
# Verification result (match) log
****************************** Verification Results *****************************
Verification SUCCEEDED
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
*********************************************************************************
1
formality >

APPENDIX A EXPLANATION OF OPC_FORMALITY

OPC_FORMALITY is a shell script that supports the use of Formality in the OPENCAD environment. This chapter
describes the functions of OPC_FORMALITY in detail.
The major functions of OPC_FORMALITY are as follows.

Generation of Formality setup file
The contents of this file are the command script that reads the Formality libraries.

Execution of Formality
The Formality script file is generated as specified in the option to execute Formality.

A.1 Method of Execution

Set the top directory of OPENCAD in the environment variable OPC_PATH. Then set a path in
${OPC_PATH}/bin and execute as follows.

% OPC_FORMALITY options...

A.2 OPC_FORMALITY Interface

A.2.1 Explanation of options
The options of OPC_FORMALITY are as follows.

% OPC_FORMALITY -Help

OPC_FORMALITY V4.2.0
Copyright (C) NEC Electronics Corporation 1997, 2004. All rights reserved.

<Set Configuration File>
Usage : OPC_FORMALITY -cf

<Execute Formality>
Usage : OPC_FORMALITY
-s_container : Container name (reference)
-i_container : Container name (implementation)
-circuit : Design name (reference and implementation)
-s_circuit : Design name (reference)
-i_circuit : Design name (implementation)
-nettyp : PWC|VERILOG|EDIF|VHDL|CONTAINER(reference and implementation)
-s_nettyp : PWC|VERILOG|EDIF|VHDL|CONTAINER(reference)
-i_nettyp : PWC|VERILOG|EDIF|VHDL|CONTAINER(implementation)
-s_netlist : Netlist file (reference)
-i_netlist : Netlist file (implementation)
-testact : Testact DFT pin const file (.dft_set)
-dft_db : Testact DFT database file (.dft_db)
-rpi : RAMBIST pin file (.rpi)
-bscan : Bscan pin file (.set)
-epf : Testbus external pin file (.epf)
-scan : Scan pin file (.primpin)
-cmd : User defined script file
-exemode : batch | int | noexec
-script : output Script file
-log : Formality Log file
fm_version : Formality Version

Usage : OPC_FORMALITY -Version
Usage : OPC_FORMALITY -Help

The options are explained in Tables A-1 to A-5 below.

Table A-1. Explanation of Options (Creation of Formality Setup File)
Option Argument Description
-cf Creates the Formality setup file (.synopsys_fm.setup). The contents of the file are the
command script that reads the Formality libraries. The options that can be specified
concurrently are only -technology and -condition.
-technology technology_name Specifies the technology name of OPENCAD. If the technology has already been set on
OPENCAD, this option is unnecessary.
-condition condition_name Specifies the condition name of OPENCAD. If the conditions have already been set on
OPENCAD, this option is unnecessary.

Table A-2. Explanation of Options (Specification of Circuit Information)
-s_container container_name Specifies the container name of the reference circuit. Unless it is specified, the container
name is ref.
-i_container container_name Specifies the container name of the implementation circuit. Unless it is specified, the
container name is impl.
-circuit Design_name Specifies the circuit name (top hierarchy name) of the reference circuit and
implementation circuit. However, use this option only if the circuit name of both circuits is
the same. Be sure to specify one of the following options -s_circuit, -i_circuit, or -
circuit.
-s_circuit Design_name Specifies the circuit name of the reference circuit.
-i_circuit Design_name Specifies the circuit name of the implementation circuit.
-nettyp PWC
VERILOG
VHDL
EDIF
CONTAINER
Specifies the netlist type of the reference circuit and implementation circuit. However,
use this option only if the type is the same in both circuits. Be sure to specify one of the
following options -s_nettyp, -i_nettyp, or -nettyp. Be sure to specify the argument of
the option in capital letters.
-s_nettyp PWC
VERILOG
VHDL
EDIF
CONTAINER
Specifies the netlist type of the reference circuit.
-i_nettyp PWC
VERILOG
VHDL
EDIF
CONTAINER
Specifies the netlist type of the implementation circuit.
-s_netlist netlist_name Specifies the netlist file name of the reference circuit [essential].
-i_netlist netlist_name Specifies the netlist file name of the implementation circuit [essential].

Table A-3. Explanation of Options (Specification of Test Control Pin Information File)
-testact testact_DFT_set_file Specifies the fixed DFT pin file of TESTACT (extension: .dft_set).
Use this option during verification before and after TESTACT is executed or during
verification if NEC SCAN2 is executed after TESTACT. The implementation circuit can
be set in normal mode.
-dft_db testact_DFT_DB_file Specifies the DFT database file of TESTACT (extension: .dft_db).
Use this option during verification before and after TESTBUS is executed by TESTACT.
Pin attribute changes and bus holder additions by TESTBUS can be supported.
-rpi rampin_pin_file Specifies the RAM PIN File for NEC BIST check (extension: .rpi).
Use this option during verification before and after NEC BIST is executed. The
implementation circuit can be set in normal mode.
-bscan bscan_pin_file Specifies the control pin information file of NEC BSCAN (extension: .set).
Use this option during verification before and after NEC BSCAN is executed or during
verification if NEC SCAN2 is executed after NEC BSCAN. The implementation circuit
can be set in normal mode
-epf epf_pin_file Specifies the control pin information file of TESTBUS (extension: .epf).
Use this option during verification before and after TESTBUS is executed. The
implementation circuit can be set in normal mode. Pin attribute changes and bus holder
additions by TESTBUS can be supported.
-scan nec_scan_pin_file Specifies the control pin information file of NEC SCAN2 (extension: .primpin).
Use this option during verification before and after NEC SCAN2 is executed. The
implementation circuit can be set in normal mode.

Table A-4. Explanation of Options (Specification of OPC_FORMALITY Operation and Output File Name)
-cmd user_cmd_file Specifies the name of the user-defined script file.
The contents of the file are executed between design read and verify command
execution. Use this option to add a new setting.
-exemode batch
int
noexec
Specifies the start mode of Formality.
Specify batch, int, or noexec in lowercase letters. Unless this option is specified, the
default is noexec.
Batch mode (batch)
The Formality command line starts and performs verification.
After verification, Formality is terminated. Use this mode during the first verification.
Interactive mode (int)
The Formality GUI is started to read the libraries and design, and then the Formality
command prompt is returned. Use this mode to make additional settings and perform
debugging.
No execution mode (noexec)
The script file for Formality is only created and Formality is not started.

Remark Because batch and int automatically start Formality, set the path and license
for Formality beforehand.
-script script_file Specifies the name of script file for Formality created by OPC_FORMALITY.
Unless this option is specified, the opc_formality.fms file is created.
-log log_file Specifies the name of the file to which the execution result of Formality is output.
Unless this option is specified, the result is output to opc_formality.flog.
-fm_version formality_version Specifies the numeric values of the Formality version to be used.
This option creates a script file supporting the specified version (however, it can only be
specified with V3.0.0 or later).

Table A-5. Explanation of Options (Other)
-Version Outputs version information.
-Help Outputs Usage.

A.2.2 Output file
An outline of the output file of OPC_FORMALITY is shown in Table A-6.

Table A-6. Outline of Output File
Output File Name Description
.synopsys_fm.setup Formality setup file.
This file is created when the -cf option is specified.
The contents of the file are the search_path settings and library read commands.
The contents of the file are executed immediately after Formality is started.
opc_formality.fms Command script file for Formality.
The contents of the script file are created based on the option specification of OPC_FORMALITY.
OPC_FORMALITY.$$.log Log file for OPC_FORMALITY.
$$ indicates the process number of a parent process.
opc_formality.flog Log file for Formality.
This file is generated when OPC_FORMALITY is executed in batch mode or interactive mode
opc_formality.fss Formality session file.
This file is generated if the verification result is a mismatch when OPC_FORMALITY is executed in
batch mode.
Restart Formality, and then use the restore_session command to restore the session. Because
the system returns to the state after the verify command is executed, the mismatch point can start
to be debugged unchanged.
netlist_name.v
(netlist_name.ref.v
netlist_name.impl.v)
File converted to Verilog inside OPC_FORMALITY if PWC is specified in the -nettyp, -s_nettyp, or
-i_nettyp option. Formality reads this Verilog file.
If the netlist file name except the extension is the same in the reference circuit and implementation
circuit, the extension of the output file becomes .ref.v and .impl.v, respectively.
When OPC_FORMALITY V4.2.0 or an earlier version is used, the file is converted into EDIF and
not Verilog.
netlist_name.ref.vhd
netlist_name.impl.vhd
VHDL file from which the VITAL definition is deleted. This file is generated if VITAL is defined in
the user-specified VHDL file. Formality reads this VHDL file from which the VITAL definition has
been deleted.

<R>
A.3 OPENCAD Environment Variables

The OPENCAD environment variables used by OPC_FORMALITY are shown below.
The priority of setting these variables is as follows.

<1> Option specification of OPC_FORMALITY. (only the -technology and -condition options are applicable.)
<2> Environment variables set by the user (e.g., .cshrc)
<3> Environment setting on OPENCAD. (other than OPC_FM_VERSION)

Table A-7. OPENCAD Environment Variables
Environment Variable Name Description
OPC_PATH Top directory of OPENCAD (essential)
OPC_ADD Top directory of added library (CSR library)
OPC_MODULE Top directory of compiled memory (Memory Compiler) library
TECHNOLOGY Technology name of OPENCAD (essential)
CONDITION Condition name of OPENCAD (essential)
TRTYPE Transistor type name of OPENCAD (essential for CB12_KIT and later)
OPC_FM_VERSION Numeric values of Formality version to be used (essential for V3.0.0 or later)

A.4 Return Values

OPC_FORMALITY returns the following return values as status.

Return Value Description
0 Normal termination
1 Abnormal termination

A.5 Error Messages

The messages that are output when OPC_FORMALITY has detected an error are shown below.

Message:
Cause:
Action:
<<ERROR>> Environment variable name : Not defined
An essential environment variable is not defined.
Set a value for the environment variable indicated.
Message:
Cause:
Action:
<<ERROR>> File name : Not found
The specified file does not exist.
Specify a correct file path.
Message:
Cause:
Action:
<<ERROR>> Character string : Not supported (value)
An item that is not supported is specified.
Specify the item correctly.
Message:
Cause:
Action:
<<ERROR>> File name : Failed to create.
The file could not be created successfully.
Refer to the log file for OPC_FORMALITY to check the details of the problem.
Message:
Cause:
Action:
<<ERROR>> Option name : Illegal Option.
An invalid option is specified.
Specify the option correctly and then re-execute.
Message:
Cause:
Action:
<<ERROR>> Option name : Operand is missing.
The option argument is invalid.
Specify the argument correctly and then re-execute.
Message:
Cause:
Action:
<<ERROR>> Option 1 Option 2 : These value shouldnt be the same.
The same argument cannot be specified for these options.
Message:
Cause:
Action:
<<ERROR>> Option name : Too many arguments.
Too many arguments are specified in the option.
Message:
Cause:
Action:
<<ERROR>> Keyword : Liner error.
opc_liner ends abnormally.
Correct the cause of the abnormal termination.
Message:
Cause:
Action:
<<ERROR>> Tool name : Cannot execute
The tool called inside OPC_FORMALITY cannot be executed.
Refer to the log file for OPC_FORMALITY to check the details of the problem.

APPENDIX B EXPLANATION OF GUI MENU

This chapter describes the GUI menu for Formality in the OPENCAD environment.
The GUI menu provides the user with the following functions.

Generation of Formality setup file: Refer to B.2
The contents of the file are the command script that reads the Formality libraries.

Execution of Formality : Refer to B.2 to B.6
Formality can be executed by entering information on the reference circuit and implementation circuit
according to the menu items.

Caution Because the above function in Execution of Formality automatically starts Formality, check that
the settings of the license and path for Formality are correct beforehand.

The GUI menu window for Formality is opened by clicking [Formal Verification] [Formality] on the Front End
Design menu for OPENCAD (refer to Figure B-1).

Figure B-1. Front End Design Menu

B.1 Menu Structure

A GUI menu that has the structure shown in Figure B-2 is provided for Formality in the OPENCAD environment.
The menus are described in B.2 Main Menu and subsequent sections.

Figure B-2. GUI Menu Structure

Main Menu
Set Configuration File (.synopsys_fm.setup)
Formality Execution
Reference Setting
Design Name
Netlist Type
Netlist File Name
Container Name
Implementation Setting
Design Name
Netlist Type
Netlist File Name
Container Name
Test Control Pin File Setting
NEC BIST(RPI) Test Pin File Name
NEC BSCAN(SET) Test Pin File Name
TESTACT(DFT_SET) Test Pin File Name
Execution Mode
Batch Script File Name
TESTACT(DFT_DB) DFT Database File Name

B.2 Main Menu

When [Formal Verification] [Formality] in Figure B-1 is clicked, the main menu is displayed (refer to Figure B-3).
This section describes the main menu.

Figure B-3. Main Menu

Closes the GUI menu
without executing Formality.
Creates the Formality setup file (.synopsys_fm.setup).
The commands in the Formality setup file are executed after Formality is started.
Inputs information on the reference circuit and implementation circuit and executes Formality.
Clicking this item displays the Figure B-4.
Closes the GUI menu
without executing Formality.
Creates the Formality setup file (.synopsys_fm.setup).
The commands in the Formality setup file are executed after Formality is started.
Inputs information on the reference circuit and implementation circuit and executes Formality.

B.3 Formality Execution Menu

When [Formality Execution] in Figure B-3 is clicked, the Figure B-4 is displayed.
This menu inputs information on the reference circuit and implementation circuit and executes Formality.

Figure B-4. Formality Execution Menu

Select the execution mode
Note1
for Formality.
Execute Formality in accordance
with the information set here.
Execution returns to Figure B-3 without executing Formality.
The information set here will be saved even if execution has
returned to Figure B-3.
Inputs reference circuit information.
Inputs implementation circuit information.
Create a script file and specify it here as necessary
Note2
.
Select the execution mode
Note1
for Formality. Select the execution mode
Note1
for Formality.
Execute Formality in accordance
with the information set here.
Execution returns to Figure B-3 without executing Formality.
The information set here will be saved even if execution has
returned to Figure B-3.
Create a script file and specify it here as necessary
Note2
. Create a script file and specify it here as necessary
Note2
.

Note 1. The execution mode is as follows.
Batch: In the batch mode, the command line (fm_shell) of Formality is activated, and verification is
executed as batch processing, in accordance with the information input to Reference
Setting and Implementation Setting shown above.
Select this mode when verification is performed for the first time.
If a mismatch is detected, a session file (*.fss) is generated. In this case, restart Formality
and use the restore_session command to restore the session.
Because the system returns to the state after verification, the mismatch point can start to be
debugged unchanged.
Interactive: The interactive mode starts the GUI for Formality (formality), reads libraries and circuits, and
then waits for command entry.
Select this mode to add settings for verification.

2. If settings other than the information input in Reference Setting and Implementation Setting are also
required, create a script file and specify it for this item. The contents of the file are executed after the
netlist is read.
In batch mode, the script is executed and the verify command is then executed.
In interactive mode, the script is executed and the system then waits for command entry.

B.4 Reference Circuit Setting Menu

When [Reference Setting] in Figure B-4 is clicked, the Figure B-5 is displayed.
This menu inputs reference circuit information.

Figure B-5. Reference Circuit Setting Menu

Enables the input information and returns to the
Figure B-4.
Then, enter the implementation circuit information
(Figure B-6).
Discards the input information
and returns to the Figure B-4.
Specify the top hierarchy name.
Select the netlist type.
Specify the file name of reference circuit.
Clicking the button on the right opens the file selection browser.
Specify the ContainerID of the container that contains
the reference circuit. The default value is ref.
Enables the input information and returns to the
Figure B-4.
Then, enter the implementation circuit information
(Figure B-6).
Specify the top hierarchy name. Specify the top hierarchy name.
Select the netlist type. Select the netlist type.
Specify the file name of reference circuit.

B.5 Implementation Circuit Setting Menu

When [Implementation Setting] in Figure B-4 is clicked, the Figure B-6 is displayed.
This menu inputs implementation circuit information.

Figure B-6. Implementation Circuit Setting Menu

Enables the input information
the implementation circuit. The default value is impl.
Specify the top hierarchy name.
Select the netlist type.
Specify the file name of implementation circuit.
To perform verification before and after execution of the NEC Electronics DFT tool,
specify the file in which test control pin information is described.
Clicking this item displays the Figure B-7 or B-8.
the implementation circuit. The default value is impl.
Specify the top hierarchy name. Specify the top hierarchy name.
Select the netlist type. Select the netlist type.

B.6 Test Control Pin Information File Name Setting Menu

When Test Control Pin File Setting in Figure B-6 is clicked, Figure B-7 or B-8 is displayed, depending on the DFT
tool used.
This menu specifies the test control pin information file for verification before and after execution of the NEC
Electronics DFT tool. Information for setting the implementation circuit in normal mode is acquired from the file.
${CIRCUIT} indicates the name of top hierarchy of the circuit.

(1) When TESTACT is used as DFT tool
When TESTACT is used as the DFT tool, the menu shown in Figure B-7 appears.

Figure B-7. Test Control Pin Information File Name Setting Menu (TESTACT)

Specify the DFT database file (file name: ${CIRCUIT}.dft_db) output by TESTACT.
Specify the fixed DFT pin file (file name: ${CIRCUIT}.dft_set) output by TESTACT.
Specify the DFT database file (file name: ${CIRCUIT}.dft_db) output by TESTACT.

(2) When NEC BIST and NEC BSCAN are used as DFT tool
When NEC BIST and NEC BSCAN (DFT environment before TESTACT) are used as the DFT tool, the menu
shown in Figure B-8 appears.

Figure B-8. Test Control Pin Information File Name Setting Menu (NEC BIST and NEC BSCAN)

Specify the test pin information file (file name: ${CIRCUIT}.set) output by NEC BSCAN.
Specify the RAM PIN File (file name: ${CIRCUIT}.rpi).
The RAM PIN File is created by selecting [RAM BIST Check] [RAM PIN File]
from the GUI menu for the OPENCAD simulator.
Specify the test pin information file (file name: ${CIRCUIT}.set) output by NEC BSCAN.

Aborted Points

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Aborted Points

Diunggah oleh

Hak Cipta:

Format Tersedia

Printed in Japan

M8E 02. 11-1

A static timing analyzer made by Synopsys. In an OPENCAD environment, PrimeTime and

-HDL and VHDL.

Anda mungkin juga menyukai