Академический Документы
Профессиональный Документы
Культура Документы
Users Manual
SYSTEM LSI DESIGN
OPENCAD
TM
Formality
Interface
Document No. A14968EJ4V0UM00 (4th edition)
Date Published August 2007 NS
2003
Users Manual A14968EJ4V0UM 2
[MEMO]
Users Manual A14968EJ4V0UM 3
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.
Users Manual A14968EJ4V0UM 4
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)
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.
Users Manual A14968EJ4V0UM 7
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
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.
[Example of setting]
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.
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 61
5.4 Compiled Memory Bus Wrapper
With the compiled memory in OPENCAD, since pins do not use a bus, RTL and the compiled memory cannot be
connected via a bus, and each pin has to be connected one-to-one.
To solve this problem, a compiled memory Bus Wrapper (hereinafter Bus Wrapper) which uses a bus topology for
the compiled memory pins, can now be output with OPENCAD that has OPC_COMPMEM V3.0.0 or later mounted.
RTL and the compiled memory can easily be connected using Bus Wrapper.
Cautions when performing verification using Bus Wrapper are explained below.
(1) Reading Bus Wrapper as part of the design
When reading RTL, make sure to add Bus Wrapper-related files.
[When RTL is described in Verilog]
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/buswrapper/<RAM name>_bus.v
[When RTL is described in VHDL]
${OPC_MODULE}/lib/${TECHNOLOGY}/${CONDITION}/buswrapper/<RAM name>_bus.vhd
Remark <RAM name> varies as follows depending on the type of RAM to be used.
RAM Type <RAM Name>
Normal RAM (no redundancy) <RAM Name>
Redundant RAM (without Soft Wrapper
Note
) <RAM name>RD
Redundant RAM (with Soft Wrapper
Note
) <RAM name>RDU
Note Type of Wrapper which performs the redundant RAM logic by normal RAM and
a combination circuit.
Bus Wrapper is handled as a part of RTL, not as a library. Consequently, the read processing of Bus Wrapper
is not included in the Formality setup file output by OPC_FORMALITY.
<R>
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 62
(2) Cautions when connecting RTL and Bus Wrapper
(a) Module name
The Bus Wrapper module name is <RAM name>_bus. Instantiate to RTL after having checked the RAM
type to be used.
(b) When using redundant RAM with Soft Wrapper
The hierarchical structure when using a redundant RAM with a Soft Wrapper is a structure consisting of a
Bus Wrapper for redundant RAM placed onto a Soft Wrapper for redundant RAM, as shown in Figure 5-4.
To instantiate to RTL, read the Bus Wrapper for redundant RAM and the Soft Wrapper for redundant RAM
at the same time. The Bus Wrapper for normal RAM which is referenced within the Soft Wrapper for
redundant RAM is not required to be read.
Figure 5-4. Hierarchical Structure When the Bus Wrapper for Redundant RAM with a Soft Wrapper Is Used
D5
D4
D3
D2
D1
D0
A3
A2
A1
A0
WEN
CEN
CLK
Q5
Q4
Q3
Q2
Q1
Q0
Soft Wrapper for redundant RAM (XXXRDU)
Normal RAM (XXX)
D[3:0]
A[3:0]
WEN
CEN
CLK
Bus Wrapper for redundant RAM (XXXRDU_bus)
ERDLF
ERDL[4:0]
ERDHF
ERDH[4:0]
Q[3:0]
The Bus Wrapper for normal RAM
is not referenced.
The Bus Wrapper and Soft Wrapper
for redundant RAM are referenced.
(c) Connecting pins that use a bus topology
When instantiating to RTL, the definition of the pins on the RTL side must be checked before connecting
the pins.
The definition of pins using a bus with Bus Wrapper is always in descending order, such as A[3:0]. If the
definition on the RTL side is in ascending order, such as A[0:3], the intended verification may not be able
to be performed when the pins are simply connected.
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 63
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.
[Example of command execution]
fm_shell > set verification_inversion_push true
Figure 5-5. Example of Circuit in Which Inverter Is Moved
DATA
CLK
DATA
CLK
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 64
5.6 Verification of Clock-Gated Circuit
One of techniques for lowering the power consumption of the circuit is clock gating. Clock gating is a technique in
which a control gate is inserted into the clock line to temporarily stop supplying the clock to the registers that do not
need to be operated. There are the following two methods of implementing clock gating.
<1> The designer performs clock gating in the RTL stage.
<2> Use an EDA tool such as Power Compiler
TM
(supplied by Synopsys) to automatically implement clock gating.
When clock gating is performed, the logic of the clock signal is changed, and a verification point is created in the
clock signal for latch-based clock gating. Therefore, verification in the default state causes a mismatch.
Figure 5-6. Clock Gating
en
clk
clk
en
al ways@( posedge cl k)
i f ( en)
dat a_out <=dat a_i n;
Gating
0
1 data_in
data_out
data_in data_out
RTL description
Circuit structure
Circuit structure after clock gating
If clock gating has been performed, the Formality variable verification_clock_gate_hold_mode must be set.
To set the value, specify the enable logic when the clock supply is stopped as low, high, or any (depending on
the version used, any may not be specified). For example, in Figure 5-6, set low.
[Example of setting]
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).
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 65
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.
[Example of setting]
set_constant type port ref:/WORK/top/en 1
set_constant type port impl:/WORK/top/en 1
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 66
5.7 Verification Before and After DFT Execution
Because a test circuit is inserted into the implementation circuit in verification before and after DFT (design for test)
tool execution, a mismatch occurs in default verification. The effect on the test circuit can then be nullified by setting
the implementation circuit in the normal mode, and whether a logic change was made or not in the users circuit can
be checked.
In Formality, execute the set_constant command before executing the verify command and set the value from
normal mode to the test pin of the implementation circuit.
[Example of setting fixed value]
fm_shell set_constant -type port impl:/WORK/top/scan_en 0
The method to obtain a test pin name and normal mode value in each DFT tool is explained below.
In the verification flow following the insertion of a test circuit, the same test circuit exists in the reference circuit and
implementation circuit, so the normal mode does not need to be set. (Note that, as an exception, verification is
performed before and after scan rechaining. Refer to 5.7.7 Verification before and after scan rechaining.) When
no normal mode is set, verification including the logic of the test circuit can be performed.
Figure 5-8. DFT and Formal Verification Flow
Formal verification
(Normal mode needs to
be set in circuit A'.)
Circuit A'
Formal verification
(Normal mode does not
need to be set.)
DFT
insertion
User
circuit change
Test
circuit
Circuit A''
Test
circuit
Circuit A
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 67
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
normal mode. (${CIRCUIT} indicates the name of the top hierarchy of the circuit.)
The format of the ${CIRCUIT}.set file is as follows.
Function name Test pin name
(same as above)
The item required for setting the normal mode is the pin whose [Function name] is TRST. Set 0 for [Test pin
name]. When the pin whose [Function name] is CTRI is used, set 0 for [Test pin name].
5.7.3 NEC BIST (RAM BIST)
Refer to the RAM PIN file (${CIRCUIT}.rpi) in order to set a circuit after executing NEC BIST in the normal mode.
(${CIRCUIT} indicates the name of the top hierarchy of the circuit.) The RAM PIN file is created using the items [RAM
BIST check] [RAM PIN file] from the GUI menu for the OPENCAD simulator.
The format of the ${CIRCUIT}.rpi file is as follows.
/ Circuit name
#MAXWORD Number of words ;
#TEB TEB pin name ;
#TIN TIN pin name ;
#TOUT TOUT pin name ;
The item required for setting the normal mode is the #TEB pin. Set 1 for [TEB pin name].
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 68
5.7.4 TESTBUS
Refer to the ${CIRCUIT}.epf file output by TESTBUS in order to set a circuit after executing TESTBUS in the
normal mode. (${CIRCUIT} indicates the name of the top hierarchy of the circuit.)
The format of the ${CIRCUIT}.epf file is as follows.
*EXTERNAL_PIN Circuit name
Test pin name Attribute before execution Attribute following execution Function name
(same as above)
*END_OF_EXTERNAL_PIN
The items required for setting the normal mode are the pins whose [Function name(s)] are TMC and BUNRI. Set 0
for [Test pin name].
5.7.5 Scan path tool made by EDA vendor
In the scan path tools released by each EDA vendor, the user can specify any test pin name and value in the
normal mode. Check, beforehand, the setup of normal mode with the test circuit design engineer.
5.7.6 NEC SCAN2
The method for setting a circuit after executing NEC SCAN2 in the normal mode varies between when NEC
SCAN2 is used with TESTACT or NEC BSCAN and when NEC SCAN2 is used alone.
(1) When NEC SCAN2 is used with TESTACT
When the TESTACT circuit is set in the normal mode, the NEC SCAN2 circuit is also set in the normal mode.
Refer to 5.7.1 TESTACT to set the circuit.
(2) When NEC SCAN2 is used with NEC BSCAN
When the NEC BSCAN circuit is set in the normal mode, the NEC SCAN2 circuit is also set in the normal
mode. Refer to 5.7.2 NEC BSCAN to set the circuit.
(3) When NEC SCAN2 is used alone
Refer to the ${CIRCUIT}.primpin file output by NEC SCAN2 (${CIRCUIT} indicates the name of the top
hierarchy of the circuit).
The format of the ${CIRCUIT}.primpin file is as follows.
Function name Test pin name (test mode value)
(same as above)
The items required for setting the normal mode are the pins whose [Function name(s)] are AMC and SMC. Set the
inverted logic of the test mode value for [Test pin name].
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 69
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.
[Example of command execution]
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.
[Example of command execution]
fm_shell> set_constant -type pin impl:/WORK/EFUSECNT/EFMGR1/OUT3 1
fm_shell> set_constant -type pin impl:/WORK/EFUSECNT/EFMGR1/OUT2 1
fm_shell> set_constant -type pin impl:/WORK/EFUSECNT/EFMGR1/OUT1 1
fm_shell> set_constant -type pin impl:/WORK/EFUSECNT/EFMGR1/OUT0 1
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 70
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.
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 71
<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).
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 72
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.
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 73
[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
CHAPTER 5 NOTES AND SETTING METHODS FOR VERIFICATION FLOW
Users Manual A14968EJ4V0UM 74
5.10 Formal Verification Following ECO
Formal verification is also valid in logic verification following ECO (Engineering Change Order). At that time,
modify the circuit of RTL similarly and verify the format of RTL following ECO vs GATE following ECO. If RTL vs
GATE verification is difficult in terms of the performance, modify the circuit for the GATE in the design flow (e.g. GATE
after initial synthesis) similarly to ECO, and perform formal verification in steps.
It is not recommended to use a GATE that was created by logically synthesizing an RTL following ECO for formal
verification. For example, if the way of handling don't care has changed by optimizing logic synthesis, a GATE of a
different logic may be created. When that GATE is compared with the other GATE following ECO in formal verification,
a mismatch is reported.
Figure 5-10. Formal Verification Flow Following ECO
RTL GATE GATE Logic synthesis
GATE
RTL GATE Logic synthesis
GATE
GATE
GATE
Formal verification
Formal verification
ECO
ECO
ECO
Following initial synthesis
Users Manual A14968EJ4V0UM 75
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
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 76
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
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 77
(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
---- ---- ----
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 78
(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.
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 79
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
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 80
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
********************************************************************************
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 81
(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 >
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 82
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.
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 83
(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
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 84
(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.
CHAPTER 6 EXAMPLE OF EXECUTION OF Formality
Users Manual A14968EJ4V0UM 85
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 >
Users Manual A14968EJ4V0UM 86
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...
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 87
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
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 88
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)
Option Argument Description
-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].
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 89
Table A-3. Explanation of Options (Specification of Test Control Pin Information File)
Option Argument Description
-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.
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 90
Table A-4. Explanation of Options (Specification of OPC_FORMALITY Operation and Output File Name)
Option Argument Description
-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)
Option Argument Description
-Version Outputs version information.
-Help Outputs Usage.
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 91
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>
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 92
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
APPENDIX A EXPLANATION OF OPC_FORMALITY
Users Manual A14968EJ4V0UM 93
A.5 Error Messages
The messages that are output when OPC_FORMALITY has detected an error are shown below.
Message:
Cause:
Action:
<<ERROR>> Environment variable name : Not defined
An essential environment variable is not defined.
Set a value for the environment variable indicated.
Message:
Cause:
Action:
<<ERROR>> File name : Not found
The specified file does not exist.
Specify a correct file path.
Message:
Cause:
Action:
<<ERROR>> Character string : Not supported (value)
An item that is not supported is specified.
Specify the item correctly.
Message:
Cause:
Action:
<<ERROR>> File name : Failed to create.
The file could not be created successfully.
Refer to the log file for OPC_FORMALITY to check the details of the problem.
Message:
Cause:
Action:
<<ERROR>> Option name : Illegal Option.
An invalid option is specified.
Specify the option correctly and then re-execute.
Message:
Cause:
Action:
<<ERROR>> Option name : Operand is missing.
The option argument is invalid.
Specify the argument correctly and then re-execute.
Message:
Cause:
Action:
<<ERROR>> Option 1 Option 2 : These value shouldnt be the same.
The same argument cannot be specified for these options.
Specify the argument correctly and then re-execute.
Message:
Cause:
Action:
<<ERROR>> Option name : Too many arguments.
Too many arguments are specified in the option.
Specify the argument correctly and then re-execute.
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.
Users Manual A14968EJ4V0UM 94
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
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 95
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
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 96
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.
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 97
B.3 Formality Execution Menu
When [Formality Execution] in Figure B-3 is clicked, the Figure B-4 is displayed.
This menu inputs information on the reference circuit and implementation circuit and executes Formality.
Figure B-4. Formality Execution Menu
Select the execution mode
Note1
for Formality.
Execute Formality in accordance
with the information set here.
Execution returns to Figure B-3 without executing Formality.
The information set here will be saved even if execution has
returned to Figure B-3.
Inputs reference circuit information.
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 necessary
Note2
.
Select the execution mode
Note1
for Formality. Select the execution mode
Note1
for Formality.
Execute Formality in accordance
with the information set here.
Execution returns to Figure B-3 without executing Formality.
The information set here will be saved even if execution has
returned to Figure B-3.
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 necessary
Note2
. Create a script file and specify it here as necessary
Note2
.
Note 1. The execution mode is as follows.
Batch: In the batch mode, the command line (fm_shell) of Formality is activated, and verification is
executed as batch processing, in accordance with the information input to Reference
Setting and Implementation Setting shown above.
Select this mode when verification is performed for the first time.
If a mismatch is detected, a session file (*.fss) is generated. In this case, restart Formality
and use the restore_session command to restore the session.
Because the system returns to the state after verification, the mismatch point can start to be
debugged unchanged.
Interactive: The interactive mode starts the GUI for Formality (formality), reads libraries and circuits, and
then waits for command entry.
Select this mode to add settings for verification.
2. If settings other than the information input in Reference Setting and Implementation Setting are also
required, create a script file and specify it for this item. The contents of the file are executed after the
netlist is read.
In batch mode, the script is executed and the verify command is then executed.
In interactive mode, the script is executed and the system then waits for command entry.
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 98
B.4 Reference Circuit Setting Menu
When [Reference Setting] in Figure B-4 is clicked, the Figure B-5 is displayed.
This menu inputs reference circuit information.
Figure B-5. Reference Circuit Setting Menu
Enables the input information and returns to the
Figure B-4.
Then, enter the implementation circuit information
(Figure B-6).
Discards the input information
and returns to the Figure B-4.
Specify the top hierarchy name.
Select the netlist type.
Specify the file name of reference circuit.
Clicking the button on the right opens the file selection browser.
Specify the ContainerID of the container that contains
the reference circuit. The default value is ref.
Enables the input information and returns to the
Figure B-4.
Then, enter the implementation circuit information
(Figure B-6).
Discards the input information
and 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.
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 99
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.
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. 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.
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.
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.
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 100
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)
Enables the input information
and returns to the Figure B-6.
Discards the input information
and returns to the Figure B-6.
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.
Clicking the button on the right opens the file selection browser.
Enables the input information
and returns to the Figure B-6.
Discards the input information
and returns to the Figure B-6.
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.
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.
Clicking the button on the right opens the file selection browser.
APPENDIX B EXPLANATION OF GUI MENU
Users Manual A14968EJ4V0UM 101
(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)
Enables the input information
and returns to the Figure B-6.
Discards the input information
and returns to the Figure B-6.
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.
Enables the input information
and returns to the Figure B-6.
Discards the input information
and returns to the Figure B-6.
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 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.