Aborted Points

Printed in Japan

User’s Manual

SYSTEM LSI DESIGN OPENCADTM

Formality® Interface

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

2003

User’s 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, audioand visual equipment, home electronic appliances, machine tools, personal electronic equipmentand industrial robots.Transportation equipment (automobiles, trains, ships, etc.), traffic control systems, anti-disastersystems, anti-crime systems, safety equipment and medical equipment (not specifically designedfor life support).Aircraft, aerospace equipment, submersible repeaters, nuclear reactor control systems, lifesupport 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 user’s 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 don’t 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 “don’t 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

For

mal

ver

ifica

tion

For

mal

ver

ifica

tion

For

mal

ver

ifica

tion



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 EDIFNote.

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

Setupfile

Library Referencedesign

Scriptfile

Implementationdesign

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 OSNote

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 definedConstant 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>.dbnNote

${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>.dbNote

${OPC_ADD}/lib/common/synopsys/<BlockGroup>/<BlockGroup>.dbNote

${OPC_ADD}/lib/${TECHNOLOGY}/common/synopsys/<BlockGroup>/<BlockGroup>.dbNote

${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 user’s 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 user’s

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 user’s 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 “Don’t 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 pointsNote.

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 “don’t 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 synthesisRTL is mapped to the GATE(compilation by TYP conditions).

Incremental synthesisCompilation 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)

GNDGND

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 WrapperNote

) <RAM name>RD

Redundant RAM (with Soft WrapperNote

) <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

Q5Q4Q3Q2Q1Q0

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 CompilerTM (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

always@(posedge clk) if(en) data_out <=data_in;

Gating

01data_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 user’s 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 tobe set in circuit A'.)

Circuit A'

Formal verification (Normal mode does not need to be set.)

DFTinsertion

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


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


*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)


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

1 Aborted compare points

**************************************************************

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 GATELogic synthesis

GATE

RTL GATELogic 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

Implementation circuit

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’ No target library specified, default is WORK Created container ‘impl’ Current container set to ‘impl’ 1 link impl:/WORK/TEST1 Linking design ‘impl:/WORK/TEST1’ Status: Elaborating design TEST1 ... Status: Implementing inferred operators... 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) Status: Implementing inferred operators... Link of ‘ref:/WORK/TEST1’ completed successfully Linking design ‘impl:/WORK/TEST1’ Status: Implementing inferred operators... Link of ‘impl:/WORK/TEST1’ completed successfully Status: Checking designs... Status: Building verification models... Status: Matching... # Verification point correspondence result log ******************************* Matching Results ****************************** 2 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 ******************************************************************************* 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 0 Passing compare points 2 Failing compare points 0 Aborted compare points -------------------------------------------------------------------------------- Matched Compare Points BBox Loop Net Pin Port DFF LAT TOTAL -------------------------------------------------------------------------------- Passing (equivalent) 0 0 0 0 0 0 0 0 Failing (not equivalent) 0 0 0 0 2 0 0 2 ******************************************************************************* 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

Implementation 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’ No target library specified, default is WORK Created container ‘ref’ Current container set to ‘ref’ 1 formality > link ref:/WORK/test Linking design ‘ref:/WORK/test’ Status: Elaborating design test ... Status: Implementing inferred operators... 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’ No target library specified, default is WORK 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 ... Status: Implementing inferred operators... 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’ Linking design ‘ref:/WORK/test’ Status: Implementing inferred operators... Link of ‘ref:/WORK/test’ completed successfully Linking design ‘impl:/WORK/test’ Status: Implementing inferred operators... Link of ‘impl:/WORK/test’ completed successfully Status: Checking designs... Status: Building verification models... Status: Matching... # Verification point correspondence result log # (non-corresponding verification points found)******************************* Matching Results ************************************* 3 Compare points matched by name 0 Compare points matched by signature analysis 0 Compare points matched by topology 0(5) Unmatched reference(implementation) compare points 0(3) Unmatched reference(implementation) primary inputs, black-box outputs -------------------------------------------------------------------------------- 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) Status: Verifying... 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 0(7) Unmatched reference(implementation) inputs 0 Passing compare points # Verification result (mismatch) log ***************************** Verification Results ***************************** Verification FAILED -------------------------------------------------------------------------------- Reference design: ref:/WORK/test Implementation design: impl:/WORK/test 0(7) Unmatched reference(implementation) inputs 0 Passing compare points 8 Failing compare points 0 Aborted compare points -------------------------------------------------------------------------------- Matched Compare Points BBox Loop Net Pin Port DFF LAT TOTAL -------------------------------------------------------------------------------- Passing (equivalent) 0 0 0 0 0 0 0 0 Failing (not equivalent) 0 0 0 0 1 2 0 3 ******************************************************************************** 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’ Linking design ‘ref:/WORK/test’ Status: Implementing inferred operators... Link of ‘ref:/WORK/test’ completed successfully Linking design ‘impl:/WORK/test’ Status Implementing inferred operators... Link of ‘impl:/WORK/test’ completed successfully Status: Checking designs... Status: Building verification models... Status: Matching... ****************************** Matching Results ********************************* 3 Compare points matched by name 0 Compare points matched by signature analysis 0 Compare points matched by topology 0(5) Unmatched reference(implementation) compare points 0(3) Unmatched reference(implementation) primary inputs, black-box outputs --------------------------------------------------------------------------------- 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 ********************************************************************************* Status: Verifying... # Verification result (match) log ****************************** Verification Results ***************************** Verification SUCCEEDED --------------------------------------------------------------------------------- Reference design: ref:/WORK/test Implementation design: impl:/WORK/test 3 Passing compare points --------------------------------------------------------------------------------- Matched Compare Points BBox Loop Net Pin Port DFF LAT TOTAL --------------------------------------------------------------------------------- Passing (equivalent) 0 0 0 0 1 2 0 3 Failing (not equivalent) 0 0 0 0 0 0 0 0 ********************************************************************************* 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 shouldn’t 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.The contents of this file are the command script that reads the Formality libraries.

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.The contents of this file are the command script that reads the Formality libraries.

Inputs information on the reference circuit and implementation circuit and executes Formality. Clicking this item displays the Figure B-4.



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 modeNote1 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.Clicking this item displays the Figure B-5.

Inputs implementation circuit information.Clicking this item displays the Figure B-6.

Create a script file and specify it here as necessaryNote2.

Select the execution modeNote1 for Formality.Select the execution modeNote1 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.Clicking this item displays the Figure B-5.Inputs reference circuit information.Clicking this item displays the Figure B-5.

Inputs implementation circuit information.Clicking this item displays the Figure B-6.Inputs implementation circuit information.Clicking this item displays the Figure B-6.

Create a script file and specify it here as necessaryNote2.Create a script file and specify it here as necessaryNote2.

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 informationand 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).

Discards the input informationand returns to the Figure B-4.

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.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”.Specify the ContainerID of the container that contains the reference circuit. The default value is “ref”.



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 and returns to the Figure B-4.

Discards the input information and returns to the Figure B-4.

Specify the ContainerID of the container that contains the implementation circuit. The default value is “impl”.

Specify the top hierarchy name.

Select the netlist type.

Specify the file name of implementation circuit.Clicking the button on the right opens the file selection browser.

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.



Specify the ContainerID of the container that contains 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.

Specify the file name of implementation circuit.Clicking the button on the right opens the file selection browser.Specify the file name of implementation circuit.Clicking the button on the right opens the file selection browser.





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.

Clicking the button on the right opens the file selection browser.

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. Clicking the button on the right opens the file selection browser.

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. Clicking the button on the right opens the file selection browser.



Specify the test pin information file (file name: ${CIRCUIT}.set) output by NEC BSCAN. Clicking the button on the right opens the file selection browser.





Date post:	02-May-2017
Category:	Documents
Upload:	saravanan-gajendran-g
View:	229 times
Download:	1 times