Conformal Collection: Automatic ECO

Product Version: 20.10

September 2020

Copyright Statement

© 2020 Cadence Design Systems, Inc. All rights reserved worldwide. Cadence and the Cadence logo are
registered trademarks of Cadence Design Systems, Inc. All others are the property of their respective
holders
Contents
Conformal Collection: Automatic ECO ......................................................................... 3
How to Run Conformal Flattened ECO Flow ............................................................... 4
Using the Optimize Patch Command ......................................................................... 10
Streamlined ECO Verification .................................................................................... 27
Debug ECO: Preserving Module Contents from Being Flattened When Generating the
Patch ......................................................................................................................... 36
Debug CECO: Diagnosing Unmapped Pin Error Due to Black Box Pin Differences .. 41
Debug CECO: Preventing CECO from Deleting and Adding a New DFF .................. 44
Debug CECO: How to Change the CPU Limit with the Analyze Eco Command ....... 50
Hierarchical Flattened ECO Flow............................................................................... 52
Configuring and Reporting Rule-Based ECO Setup Checks ..................................... 61

September 2020 2 Conformal 20.10

Conformal Collection: Automatic ECO
Summary

This is a collection of user guides and debug guides for using the automatic Conformal
ECO flows.

• Flattened ECO User guide: this guide instructs how to run the recommended
Flatten ECO flow to generate the patch.

• Using the Optimize patch Command: this guide helps user setup patch
optimization for different usage scenarios to obtain the best results.

• Streamline ECO Verification guide: this guide instructs how to setup ECO patch
validation.

• ECO debug guides: these guides instruct how to improve the quality of ECO
patch, debug ECO verification issues.

September 2020 3 Conformal 20.10

How to Run Conformal Flattened ECO Flow

Summary

This document describes the Conformal flattened ECO flow which is the ECO
recommended flow.

In this flow, you run a flat compare on a hierarchical design. This flow can help when
your hierarchical dofile is causing false non-equivalent points (due to things like clock
gate cloning/decloning, inverter pushes, or boundary optimization).

This flow is not ideal for flat designs or when you have clean hierarchical dofiles (for
example, two dofiles with ECO modules are compared and their NEQs match those
reported by analyze_hier_compare).

Benefits of CECO FEF

This flow has the following benefits:

• Focuses ECO analysis on the non-equivalent key points identified from a flat
compare.

• Supports hierarchical clock gating that is not a part of an ECO. For example, if
you have two hierarchical gates that do not match, you can perform a flat
compare, but create a patch to the hierarchical netlist.

• Works with the current hierarchical flow. You can also run a combination of the
hierarchical ECO flow and the FEF flow (running FEF on select modules).

• You can insert ECO pin/ports on demand through an ECO pin dofile.

• Easier set up. You can create all ECO patches with one command, and do not
need to run the hierarchical dofile.

Flow Diagram

September 2020 4 Conformal 20.10

Flow Steps

Once you enter LEC mode, a typical scenario for a flattened ECO flow involves the
following steps:

• Use the analyze_hier_compare command to analyze the hierarchy of

the two flattened designs and determine the module boundaries.

• Use the add_compare_points -all and COMPARE commands to start the

comparison between the flattened designs. This will determine the non-
equivalent points.

• Use the compare_eco_hierachy command to break down the non-equivalent

points (determined in step 2) into their sub-modules, based on the module
boundaries (determined by step 1).

September 2020 5 Conformal 20.10

 • Use the analyze_eco -hierarchical command to create all the necessary
patches.
During this step, you can also create a dofile that creates only ECO pins that are
part of the non-equivalent cones (through the
-ecopin_dofile option).

• Apply and optimize the patch using the apply_patch and optimize_patch
commands, respectively.

Sample Dofile

The following illustrates a sample dofile for a post-mask flattened ECO flow:

Step 1: Setting up
#**********************************************************************
# Sets up the log file and instructs the tool to display usage
# information
#**********************************************************************
set_log_file fef_premask_eco.log.$env(LEC_VERSION) -replace
usage -auto -elapse
#**********************************************************************
# Specifies that the intention is to run the Flattened ECO flow.
# The "set eco option -flat" command executes the following commands:
# SET FLATTEN MODEL -ECO
# SET FLATTEN MODEL -ENABLE_ANALYZE_HIER_COMPARE
# It also automatically adds the following options to the
# ANALYZE HIER_COMPARE command:
# -CONstraints
# -NOEXact_pin_match
# -FUNCTION_Pin_mapping
# -INPUT_OUTPUT_Pin_equivalence
# -THRESHOLD 0
#**********************************************************************
set_eco_option -flat

#**********************************************************************
# Reads in the library and design files
#**********************************************************************
read_library <lib_files> -replace -liberty
read_design <netlist1> -replace -golden
read_design <netlist2> -replace -revised
report_design_data
report_black_box

flatten -nolibrary -matchhierarchy -use_renaming_rules

uniquify -all -nolibrary -revised

#**********************************************************************
# Specifies user constraints for test/dft/etc

September 2020 6 Conformal 20.10

#**********************************************************************
# add_pin_constraint 0 scan_se -golden
# add_pin_constraint 0 scan_tm_i -both
# add_ignored_output scan_out* -golden

#**********************************************************************
# Specifies the modeling directives for constant optimization and
# clock gating
#**********************************************************************
# set_flatten_model -seq_constant
# set_flatten_model -gated_clock
# set_analyze_option -auto

#**************************************************************************
# Flattens, remodels, and maps the design
#**************************************************************************
set_system_mode lec
#**************************************************************************
#* Performs ECO-related checks that will flag potential issues related to
#* setup and offer potential solutions early
#**************************************************************************
check_eco_setup

Step 2: analyzing the hierarchy boundary, comparing and running eco

#**************************************************************************
# Analyzes the hierarchical boundaries of the flattened designs
#**************************************************************************
analyze_hier_compare -dofile hier_analyze.do \
-eco_aware \
-replace
#-constraints \
#-noexact_pin_match \
#-function_pin_mapping \
#-input_output_pin_equivalence \
#-threshold 0

#**************************************************************************
# Compares the flattened designs
#**************************************************************************
add_compared_point -all
compare

#**************************************************************************
#* Performs ECO-related checks that will flag potential issues related to
//* setup and offer potential solutions early
//**************************************************************************
check_eco_setup

//**************************************************************************
//* Breaks down the nonequivalent points to their sub-modules
//**************************************************************************
compare_eco_hierarchy

September 2020 7 Conformal 20.10

//**************************************************************************
//* Performs ECO-related checks that will flag potential issues related to
//* setup and offer potential solutions early
//**************************************************************************
check_eco_setup

#**************************************************************************
# Optional steps:
# Reports the nonequivalent modules found by the tool:
#**************************************************************************
# report eco hierarchy -noneq -verbose
#**************************************************************************
# Creates the hierarchical patch.
# This command also creates the ecopins.do dofile, which adds
# ECO pins when there are extra pins in the Revised design
# (as compared to Golden design)
# and deletes ECO pins when there are extra pins in the Golden design .
#**************************************************************************
analyze_eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
set_system_mode setup
dofile ecopins.do

#**************************************************************************
# Applies the hierarchical patch to the flat netlist
#**************************************************************************
apply_patch -auto -gold -keephierarchy

Step 3: Optimizing the patches and write out the eco netlist.
#**************************************************************************
# Writes out an Genus/RC script (cfm_eco_rc.tcl) in the working
# directory that will optimize the patches and execute the script.
# After OPTIMIZE PATCH successfully completes, the ECO design will be
# in the memory and can be written out. The optimized patches will be
# in the working directory.
#**************************************************************************
optimize_patch -workdir <working_directory> \
-library <lib_file_list> \
-sdc <sdc_filename> \
-instancenaming "ECO2inst_%d" \
-netnaming "ECO2net_%d" \
-sequentialnaming "ECO2reg_%s" \
-SYNCExec "rc/genus -nogui -legacy_ui" \
-verbose

#**************************************************************************
# Reports the ECO changes
#**************************************************************************
report_eco_changes -script -file test.script -replace

#**************************************************************************
# Writes out the G3 ECO netlist
#**************************************************************************

September 2020 8 Conformal 20.10

write_eco_design -newfile %s.pre.G3 -replace -report ECOprelogics.rpt
</sdc_filename></lib_file_list></working_directory> \
</netlist2></netlist1></lib_files>

September 2020 9 Conformal 20.10

Using the Optimize Patch Command
Summary

This Conformal ECO (CECO) user guide helps users set up patch optimization for
different usage scenarios to obtain the desired results.

Conformal ECO Flow

Conformal ECO compares two designs and generates a functional patch that
implements the changes between the two designs. After the patch is created and
applied, it is passed to the synthesis tool through the optimize_patch command. This
command goes through the following steps to complete the patch technology mapping
and optimization:

• Generate a synthesis script (cfm_eco_rc.tcl). This script will include any specified
user scripts.

• Executes the Genus Synthesis Solution (Genus).

• Writes out the optimized patch and returns to CECO.

September 2020 10 Conformal 20.10

Customizing the Patch Optimization

CECO automatically creates a patch optimization script (cfm_eco_rc.tcl) with synthesis

settings that are suitable for most cases. However, users can customize the script with
the following methods:

• Using optimize_patch options:

The optimize_patch command has options (such as -nousetiecell) to
specify commonly encountered synthesis scenarios. When these options are
used, the cfm_eco_rc.tcl includes the corresponding synthesis commands for
that scenario.

• User-created synthesis scripts:

The optimize_patch command provides options for users to specify scripts that
will be executed at different points during synthesis: -prelibscript, -
postsetupscript, -presyncript, and -postsynscript. For example, -
prelibscript will run the specified script before reading in the libraries. This
allows advanced users to fine tune the entire synthesis process.

For more information on the options of optimize_patch, refer to its MAN page.

A Sample Flow

The following is a sample Conformal ECO flow:

1. Sample of Genus scripts:

presyn.tcl
set_db unmap_scan_flops false
proc eco_pre_synthesis_cmd {patch} {
set_db [vfind $patch] .dft_scan_map_mode preserve
}

2. Sample of CECO dofile and presyn.tcl with the optimize_patch command:

eco.do
set_eco_option -flat
read_design/library
.......
set_system_mode lec
compare_eco_hierarchy
analyze_eco
.....
set_system_mode setup

September 2020 11 Conformal 20.10

dofile ecopins.do
apply_patch -auto
optimize_patch -workdir WORK \
-synexec "genus" \
-presynscript ../presyn.tcl \
-verbose
.....

3. Run CECO
lec -ecogxl -nogui -do eco.do

4. To review the patch optimization log file, go to directory WORK

and check the rc.log
........
Sourcing '../presyn.tcl' (Thu Oct 06 20:30:24 -0700 2016)...
Setting attribute of root '/': 'unmap_scan_flops' = false
Setting attribute of design 'cfm_eco_patch_1': 'dft_scan_map_mode' = preserve
Info : Mapping. [SYNTH-4]
: Mapping 'cfm_eco_patch_1' using 'high' effort.

Global mapping target info

==========================
Cost Group 'm_clk' target slack: 1130 ps
Target path end-point (Port: cfm_eco_patch_1/FE_OFN413_scan_se_2o)

Global mapping status

==========================

Optimize Patch Options

These options are used to specify common used patch optimization scenarios:
optimize_patch
[-NOUSETIEcell]
[-ALLOWTIECELLINVersion]
[-POSTSETUPscript <script_file_name>]
[-AVOID <cell_name>*]
[-USE <cell_name>*]
[-NOFLATTEN_SMALL]

• -NOUSETIEcell: Allows Genus to leave constants as assign statements instead

of using tie high or tie low cells.

• -ALLOWTIECELLINVersion: Allows tie cells with inverters if one of the tie hi/lo
cells is not found.

• -AVOID : Avoids the specified library cells.

September 2020 12 Conformal 20.10

 • -USE : Uses the specified library cells.

• -NOFLATTEN_SMALL: Do not flatten small modules (keep the hierarchy) of

patches smaller than 10k gates.

For more information on the options of optimize_patch, refer to its MAN page.

Integrate User-Created Synthesis Scripts

These options are used to integrated user-created scripts into cfm_eco_rc.tcl.

optimize_patch
[-PRELIBscript <script>]
[-POSTSETUPscript <script>]
[-PRESYNscript <script>]
[-POSTSYNscript<script>]

• -PRELIBscript: Specifies the script to run before reading in the libraries

• -POSTSETUPscript : Specifies the script to run after reading in the design.

• -PRESYNscript: Specifies the script to run before starting to synthesis patch.

The script can include two procedures , eco_pre_synthesis_cmd and
eco_post_synthesis_cmd. The procedures , if defined, are called before and
after synthesizing each patch module.

• -POSTSYNscript: Specifies the script to run after all patches are synthesized.

User Script Format: Common UI or Legacy UI

CECO depends on the specified synthesis executable and generates the patch
optimization script (cfm_eco_rc.tcl ) with a corresponding format.

By default, it generates Genus Common UI script. When using with option -synexec
rc or -synexec genus -legacy_ui, it generates a Legacy UI script.

The user scripts that included in cfm_eco_rc.tcl have to be the same format (They either
both in Legacy UI or Common UI) . Otherwise, the optimize patch fails with the following
error message:
Error : The tool is running in common ui mode. [TUI-509] [::unknown]
: Command 'set_attribute' is a legacy ui command.
: Use set_db/get_db instead or do set_db common_ui
false at start of the run.

September 2020 13 Conformal 20.10

#@ End verbose source synscript/prelib.drcfirst.tcl.rc
#@ End verbose source cfm_eco_rc.tcl

Encountered problems processing file: cfm_eco_rc.tcl

Abnormal exit.

Frequently Asked Synthesis Scenarios

The following are the frequently asked scenarios related to synthesis.;

• Keeping constants in the patch

• Allowing tie cell inversion

• Specifying tie cell types

• Preserve DFF cell types in the patch

• Preserve DFF cells in the patch

• Preserve all cells and nets in the patch

• Preserve clock buffer cell in the patch

• Turn off sequential constant and sequential merge in patch optimization

• Allowing phase mapping for DFFs

• Flexible spare cell mapping

• Report used spare cell coordinates

• Incremental spare cell mapping

• Force fix DRC before timing

• How to read a DEF file with filler in premask physical ECO

• Quit Genus with ECO-ERROR

Each scenario's detail and solution are explained in the following.

September 2020 14 Conformal 20.10

Scenario 1: Keeping Constants in the Patch

By default, patch optimization implements Boolean constants in the patch by connecting

them to tie-hi or tie-low cells.

To preserve the Boolean constants use the command option optimize_patch -

nousetiecell. For example, here is a sample patch:

<patch.v>
module tdsp_data_mux_eco ........;
// pragma no_bbox_empty
assign \t_data[15] = 1'b1;
assign \t_data[14] = 1'b1;
.......
assign \t_data[0] = 1'b0;
endmodule

The following commands apply the patch optimization and preserve patch constants:
apply_patch -auto
optimize_patch -nousetiecell

After optimization, the module looks like the following:

<G3>
module tdsp_data_mux ........;
assign \t_data[15] = 1'b1;
assign \t_data[14] = 1'b1;
.......
assign \t_data[0] = 1'b0;
endmodule

Troubleshooting: Constants Still Exist After Patch Optimization

There are cases when, even after running optimize patch without -nousetiecell, the
output G3 still contains constants (1'b0, 1'b1).

In this case, try the following:

• Check if tie cells in the liberty contain a dont use attribute. If they do, use the -
use <tiecell> option of the optimize_patch command. This will remove the
don't use attribute for the tie cells.

• Check if options -tiefreed0 | -tiefreed1 are used with command

apply_patch. These two options are used to connect the input of freed cells to a
constant. Freed cell constants are not replaced with tie cells during
optimize_patch.

September 2020 15 Conformal 20.10

Scenario 2: Allowing Tie Cell Inversion
If only one type of tie cell exists in the library or spare cell , use the optimize_patch
command option -allowtiecellinversion to allow inverted use of the tie cell. In the
following example, only tielow cell (LOGIC0_X1) is available.

Before optimize patch:

<patch.v>
module tdsp_data_mux_eco ........;
// pragma no_bbox_empty
assign \t_data[15] = 1'b1;
assign \t_data[14] = 1'b1;
.......
assign \t_data[0] = 1'b0;
endmodule

The following commands apply and optimize the patch and allow inversion of the
specified tie cell:
SETUP> apply_patch -auto
SETUP> optimize_patch -allowtiecellinversion -use LOGIC0_X1 \
-avoid LOGIC1_X1

After optimize patch:

<G3>
module tdsp_data_mux ........;
assign t_data[0] = t_data[1];
.........
assign t_data[14] = t_data[15];
LOGIC0_X1 ECO1inst_15(.Z(t_data[1]));
LOGIC0_X1 ECO1inst_16(.Z(ECO1net_1));
INV_X1 ECO1inst_17(.A(ECO1net_1),.ZN(t_data[15]));
endmodule

Scenario 3: Specifying Tie Cell Types

If there are multiple tie cells in the library and you want to specify the tie cell type for
constant mapping, use the command option -avoid <cell> -use <tiehi cell>.

For example:
TCL_SETUP> optimize_patch -use LOGIC0_X1 LOGIC1_X1 \
-avoid TIE0*

September 2020 16 Conformal 20.10

Scenario 4: Preserve DFF Cell Type in the Patch

When the patch includes new DFFs, to ensure the scan or non-scan DFFs cell type is
kept the same before and after patch optimization with the expected result

• a DFF primitive maps to a DFF

• a non-scan DFF keep as non-scan DFF

• a scan DFF will be kept as a scan-DFF

By using the following script:

eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
# Genus Common UI version
set_db unmap_scan_flops false
proc eco_pre_synthesis_cmd {patch} {
set_db [vfind $patch] .dft_scan_map_mode preserve
}
#RC/legacy UI version
set_attribute unmap_scan_flops false
proc eco_pre_synthesis_cmd {patch} {
set_attribute dft_scan_map_mode preserve $patch
}

The patch before optimize_patch:

//Non-scan DFF
DFFR_X2 new_reg1(.CK(clk),.D(write_in),.RN(n_72),.Q(ecow2)); // DFF:1
//Scan DFF
SDFFR_X2 new_reg2(.CK(clk),.D(ecow2),.RN(n_72),.SE(1'b0),.SI(1'b0),.Q(write)); //
DFF:1
//DFF Primitive
DFF read_reg(read,n_175,\read_reg/S ,\read_reg/n$1 ,clk,\read_reg/n$2 );

The patch after optimize_patch:

//DFF types are preserved

DFFR_X2 new_reg1(.RN (n_72), .CK (clk), .D (write_in), .Q (ecow2),.QN
(UNCONNECTED0));
SDFFR_X2 new_reg2(.RN (n_72), .CK (clk), .D (ecow2), .SI (1'b0), .SE(1'b0), .Q
(write), .QN (UNCONNECTED));
DFFS_X1 read_reg_Q_reg(.SN (n_1), .CK (clk), .D (n_2), .Q (read), .QN(n_175));

September 2020 17 Conformal 20.10

Scenario 5: Preserve DFFs Cell in the Patch

To preserve the DFFs of the patch without unmapping and remapping to other DFF
cells, the following script can be used:
eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
# Genus Common UI version
proc eco_pre_synthesis_cmd {patch} {
set all_insts [vfind $patch -inst *]
set mapped_seqs [get_db $all_insts -if {.sequential == true && .lib_cell != ""}]
if { [llength $mapped_seqs] > 0 } {
set_db $mapped_seqs .preserve true
}
}
# RC/Legacy UI version
proc eco_pre_synthesis_cmd {patch} {
set mapped [filter -invert libcell "" [find $patch -inst *]]
if { [llength $mapped] > 0 } {
set mapped_seqs [filter sequential true $mapped]
set_attr preserve true $mapped_seqs
}
}

Scenario 6: Preserve All Cells and Nets in the Patch

To preserve all the cells and nets of the patch without remapping or changing them, the
user can use the following script.
eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
# Genus Common UI version
proc eco_pre_synthesis_cmd {patch} {
set all_insts [vfind $patch -inst *]
set mapped [get_db $all_insts -if {.lib_cell != ""}]
if { [llength $mapped] > 0 } {
set_db $mapped .preserve true
}
set all_hnets [vfind $patch -hnet *]
set nonconst_net [get_db $all_hnets -if {.constant == "no_constant"}]
if { [llength $nonconst_net] > 0 } {

September 2020 18 Conformal 20.10

 set_db $nonconst_net .preserve true
}
}
# RC/Legacy UI version
proc eco_pre_synthesis_cmd {patch} {
set mapped [filter -invert libcell "" [find $patch -inst *]]
if { [llength $mapped] > 0 } {
set_attr preserve true $mapped
}
set nonconst_net [filter "constant" "no_constant" [find $patch -net *]]
if { [llength $nonconst_net] > 0 } {
set_attr preserve true $nonconst_net
}
}

Scenario 7: Preserve Clock Buffer Cell

In some post-mask ECO cases, there are clock buffer cells in the patch that need to be
preserved. During patch optimization, to prevent Genus from touching the clock buffer
cells in the patch you can include the presynscript as below. Also, the presyncsript
could be extended to preserve any specific cells.
eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
# Genus Common UI version
# Please replace "*CKBufffer*" to your Clock buffer cell
proc eco_pre_synthesis_cmd {patch} {
set all_insts [vfind $patch -inst *]
set mapped [get_db $all_insts -if {.base_cell.name == "CKBuffer"}]
if { [llength $mapped] > 0 } {
set_db $mapped .preserve true
}
}
# RC/Legacy UI version
# Replace "*CKBufffer*" to the target clock buffer cells
proc eco_pre_synthesis_cmd {patch} {
set mapped [filter libcell "*CKBuffer" [find $patch -inst *]]
if { [llength $mapped] > 0 } {
set_attr preserve true $mapped
}
}

September 2020 19 Conformal 20.10

Scenario 8: Sequential Constant and Sequential Merge in Patch
Optimization

By default, optimize_patch performs constant optimization and sequential merging for

newly added DFFs. If there are new DFFs being merged or modeled to constant during
patch optimization, enabling auto analysis and constant modeling
set_analyze_option -auto and set_flatten_model -seq_constant while
running patch validation.

To disable these optimizations during patch optimization, add the following below to the
presynscript.
eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
# Genus Common UI version
set_db / .optimize_merge_flops false
set_db / .optimize_constant_0_flops false
set_db / .optimize_constant_1_flops false
set_db / .optimize_constant_feedback_seqs false
# RC/Legacy UI version
set_attribute optimize_merge_flops false
set_attribute optimize_constant_0_flops false
set_attribute optimize_constant_1_flops false
set_attribute optimize_constant_feedback_seqs false

Scenario 9: Allowing Phase Inversion for DFFs

During patch optimization,

• A simple DFF can be converted to a DFF with inversion at the input and output.

• An asynchronous reset DFF can be converted to asynchronous set DFF with

inversion at the input and output or vice-versa.

• Phase inversion is useful when the RTL functionality requires a preset function,
but the technology library has only a reset DFF or vice versa.

• When this attribute is set to true during patch validation, set mapping method
-phase needs to be enabled.

DFF phase inversion is disabled by default. To enable it, set it to true in prelib.tcl. This
setting can be useful in the postmask ECO flow when the number of spare cells is

September 2020 20 Conformal 20.10

limited.
eco.do
TCL_SETUP> optimize_patch -prelibscript prelib.tcl

prelib.tcl
# Genus Common UI version
set_db / .lbr_seq_in_out_phase_opto true
# RC/Legacy UI version
set_attribute lbr_seq_in_out_phase_opto true

Scenario 10: Flexible Spare Cell Mapping

By default, optimize_patch prefers using non-degenerate cells for mapping. You can
relax this restriction and allow using degenerate cells for mapping. For example,
allowing a MUX spare cell to be implemented as a AND which may have better timing.
To do this prepare the following presynscript.

eco.do
TCL_SETUP> optimize_patch -prelibscript prelib.tcl

prelib.tcl
# Genus Common UI version
set_db eco_prefer_non_degen 0
# RC/Legacy UI version
set_attribute eco_prefer_non_degen 0 /

Scenario 11: Report Used Spare Cell Coordinates

The following script can be used to report the coordinates of used spare cell locations.

First check the Genus log at <WORKDIR>/rc.log

Note: that the instance name in the report is without applying renaming rules which is
specified by -instancenaming, -sequentialnaming.

eco.do
TCL_SETUP> optimize patch -presynscript presyn.tcl -workdir WORKDIR

presyn.tcl

September 2020 21 Conformal 20.10

# Genus Common UI version
proc eco_post_synthesis_cmd {patch} {
puts "Spare gate mapping and location report for $patch:"
set gates [::legacy::filter -invert spare_gate "" [vfind / -inst -hinst *] ]
foreach gate $gates {
set sp_gate [get_db [vfind $gate] .spare_gate]
set loc_x [get_db [vfind $sp_gate] .location_x]
set loc_y [get_db [vfind $sp_gate] .location_y]
puts "$gate -> $sp_gate ($loc_x $loc_y)"
}
}
# RC/Legacy UI version
proc eco_post_synthesis_cmd {patch} {
puts "Spare gate mapping and location report for $patch:"
set gates [filter -invert spare_gate "" [find / -inst *]]
foreach gate $gates {
set sp_gate [get_attr spare_gate $gate]
set loc_x [get_attr location_x $sp_gate]
set loc_y [get_attr location_y $sp_gate]
puts "$gate -> $sp_gate ($loc_x $loc_y)"
}
}
# <rc.log>
....
Spare gate mapping and location report for cfm_eco_patch_1:
inst:cfm_eco_patch_1/g466 -> inst:dtmf_recvr_core/DMA_INST/spare_29 (186.390 172.200)

Scenario 12: Incremental Spare Cell Mapping

By default Genus maps and optimizes the patches serially as they are passed from
CECO. In a postmask ECO this may not be optimal mapping. Use below option in
prelib.tcl script to have it revisit all the mapping once the last patch is mapped.

Note: This function might significantly increase the runtime.

eco.do
TCL_SETUP> optimize_patch -prelibscript prelib.tcl

prelib.tcl
# Genus Common UI version
set_db .eco_revise_spare_gate_assignment 1
# RC/Legacy UI version
set_attribute eco_revise_spare_gate_assignment 1

September 2020 22 Conformal 20.10

Scenario 13: Force Fix DRC Before Timing

By default timing constraints have higher priority than design rules in Genus. To change
the default setting, you can use the following prelibscript.

eco.do
TCL_SETUP> optimize_patch -prelibscript prelib.tcl

prelib.tcl
# Genus Common UI version
set_db / .drc_first true
# RC/Legacy UI version
set_attribute drc_first true

Scenario 14: How to Read a DEF File with Filler in Premask Physical
ECO

In premask physical ECO, the DEF file is required to have no-filler cell in it. Use the
following script to allow reading a DEF containing filler cells.

Note: This attribute is supported in Genus 15.1 and later.

eco.do
TCL_SETUP> optimize_patch -prelibscript prelib.tcl

prelib.tcl
# Genus Common UI version
set_db / .eco_skip_fillers_in_def 1
# RC/Legacy UI version
set_attribute eco_skip_fillers_in_def 1 /

Scenario 15: Quit Genus with ECO-ERROR

optimize_patch may return Normal exit even there is some ECO-ERROR is present
by default.

For example:
ECO-INFO: Final total library cell availability (GA + spare/freed)
===================================================================
Generated by: Genus(TM) Synthesis Solution GENUS15.20 - 15.20-p004_1
Generated on: Aug 22 2016 09:45:09 pm

September 2020 23 Conformal 20.10

 Interconnect mode: placement
Area mode: physical library
===================================================================
Libcell Library Availability Part of
initial
list
-------------------------------------------------------------------
buf_x4_std std00a_ss_20v_100c 70 YES
dffnrnsna_x1_std std00a_ss_20v_100c -1 NO
......
ECO-INFO: Total ECO Violations - 1
ECO-ERROR: SYNTHESIS FAILED - some cells outside the initial
spare gate list were used for synthesis

Adding the following postsynscript, Genus will exit with an error code when ECO-
ERROR is present.

eco.do
TCL_SETUP> optimize_patch -postsynscript postsyn.tcl

postsyn.tcl
# Genus Common UI version
if { [get_db / .total_eco_violation] > 0 } {
exit 1
}
# RC/Legacy UI version
if { [get_attr total_eco_violation /] > 0 } {
exit 1
}

Scenario 16: Report Timing Paths That Go Through Each ECO

Instance

You can report the N-worst timing paths that go through each ECO instance before and
after the optimize_patch command.

Adding the following 2 procs to the presynscript, Genus will output the N-worst timing
paths before and after Genus optimization.

eco.do
TCL_SETUP> optimize_patch -presynscript presyn.tcl

presyn.tcl
proc eco_pre_synthesis_global_cmd {eco_insts} {
foreach inst $eco_insts {

September 2020 24 Conformal 20.10

 redirect -append ../presyn.rpt {report_timing -through [vfind [vfind $inst] -
pin *] -nworst 20 }
}
}
proc eco_post_synthesis_global_cmd {eco_insts} {

foreach inst $eco_insts {

redirect -append ../postsyn.rpt {report_timing -through [vfind [vfind $inst] -
pin *] -nworst 20 }
}
}

In this example N is 20 and presyn.rpt and postsyn.rpt are the respective output files.

Below is an example of postsyn.rpt

============================================================
Generated by: Genus(TM) Synthesis Solution 19.12-e080_1
Generated on: Oct 17 2019 10:59:39 am
Module: vga_enh_top
Operating conditions: TypTyp_0.8V_25C
Interconnect mode: placement
Area mode: physical library
============================================================

Path 1: VIOLATED (-129390 ps) Setup Check with Pin

pixel_generator/vtgen/ver_gen/state_reg[4]/CK->D
Group: clk1
Startpoint: (R) pixel_generator/vtgen/ver_gen/cnt_reg[1]/CK
Clock: (R) clk1
Endpoint: (R) pixel_generator/vtgen/ver_gen/state_reg[4]/D
Clock: (R) clk1

Capture Launch
...

In a premask physical or postmask flow, you can report the paths along with location
information after Genus has done placement.

eco.do
TCL_SETUP> optimize_patch -postsynscript postsyn.tcl

postsyn.tcl
# Genus Common UI version
proc eco_final_global_cmd {eco_insts} {
foreach inst $eco_insts {
redirect -append ../final.rpt { report_timing -through \
[vfind [vfind $inst] -pin *] -nworst 20 }

September 2020 25 Conformal 20.10

 }
}

In this example N is 20 and final.rpt is the output file.

Adding the the proc eco_final_global_cmd, Genus will output the N-worst timing
paths after Genus placement. This can be added to the postsyn script.

Here is example of final.rpt:

# Timing Point Flags Arc Edge Cell Fanout
Load Trans Delay Arrival Instance
#
(fF) (ps) (ps) (ps) Location
#------------------------------------------------------------------------------------
--------------------------------------------------------------
pixel_generator/vtgen/ver_gen/cnt_reg[1]/CK - - R (arrival) 33 -
500 - 0 (-,-)
pixel_generator/vtgen/ver_gen/cnt_reg[1]/Q - CK->Q F SDFF_X2 2 8.4
333 1020 1020 (34.7200,44.5200)
pixel_generator/vtgen/ver_gen/g1619/ZN - A2->ZN R NOR2_X1 3 13.4
3681 2038 3058 (39.0900,43.1200)
pixel_generator/vtgen/ver_gen/g1593/ZN

Note the column with the Instance Location.

September 2020 26 Conformal 20.10

Streamlined ECO Verification

Summary

Streamlined ECO verification provides a complete solution for setting up the ECO patch
validation. This solution can reduce setup and comparison runtime, and can eliminate
setup related NEQs due to mapping or sequential modeling issues. The feature was
released in Conformal 14.20.

CECO contains the following enhancements in streamlined ECO verification starting

from Conformal ECO 18.20-p100:

• Support for the customized naming of new flops

• Support of flop replacement

• Support of sequential merge for new flops

• Update the recommendation flow setting to have set_flatten_model -

noauto_modeling

Background

In the CECO flow, two netlists G1 and G2 are read in and compared. ECO changes will
result in non-equivalences and CECO will create a patch which can be applied to G1 to
implement the functional changes. The resulting netlist is called G3.

The expectation is that the patched netlist G3 will be equivalent to G2. However, this
requires the setup for comparison to be the same as when the ECO patch was
computed. If the setup is different, the functional mapping may map some key points
differently. This can result in a comparison that shows non-equivalence even though the
patch was computed correctly.

September 2020 27 Conformal 20.10

How Streamlined ECO Verification Works

Streamlined ECO verification works based on verification information from the G1 and
G2 designs. This includes mapping and sequential modeling information from the patch
generation stage. Streamlined ECO verification captures all the correct setup during
G1G2 run and is applied to G3G2 comparison to ensure the keypoints are mapped and
modeled correctly.

To ensure a clean patch verification environment, it is recommended to separate the

streamlined ECO verification into 2 runs: patch generation and patch validation.

The Recommended Streamlined ECO Verification Flow

A complete streamlined ECO verification contains two stages:

• Patch generation stage: Setup, collect and save the before-ECO design
information and ECO changes to verification information

• Patch validation stage: Apply verification information to LEC compare for G3G2
validation

Command Syntax and Usage: Patch Generation

set_verification_information <verification_information_directory>

• Setup a directory to save the verification information.

• Run at the beginning of patch generation stage to capture all the verification
information.
write_verification_information <verification_information_directory>

September 2020 28 Conformal 20.10

 • Save the verification information to the specified directory.

• Run at the very last step of patch generation stage, after optimize_patch

Command Syntax and Usage: Patch Validation

set_verification_information <verification_information_directory> -setup all

• Setup the directory for LEC to load the verification information.

• Run at the beginning of patch validation stage.

set_flatten_model -specified_setup_only -noauto_modeling

• Specify that LEC only performs sequential constant and sequential merge
modeling specified in verification information. Also enables mapping from the
verification information.

• Disables the auto-modeling feature.

• Run along with set_verification_information -setup all, which is also in

the patch validation stage.

External Constraints for Patch Validation

There may be constraints that are applied to G1 or G2 during patch generation. For
example: pin/instance constraints, pin/instance equivalence, ignored test inputs/outputs.
For example, constraints on the scan enable pins in G1:
add_pin_constraint 0 scan_en -golden

Note the same constraints should be applied on G3 when validating the patch.
Currently, such external constraints are not captured by the verification information, so
they need to be put explicitly before validating the patch, for example:
# Make use of verification information
set_verification_information ver_info -setup all
# Specify to use exact setup
set_flatten_model -specified_setup_only
set_flatten_model -noauto_modeling
...
add pin constraint 0 scan_en -golden
...
set_system_mode lec
add_compared_points -all
compare

September 2020 29 Conformal 20.10

Sample Dofile - Patch Generation Stage

A typical dofile with streamlined ECO verification in patch generation stage:

set_verification_information ver_info
read_library
read_design G1 -gold
read_design G2 -rev
...
compare_eco_hier
analyze_eco -hier patch.v -ecopin ecopins.do -replace
set_system_mode setup
dofile ecopins.do
apply_patch -auto
optimize_patch -SYNExec rc/genus
write_verification_information ver_info
write_eco_design -newfile G3

Sample Dofile - Patch Validation Stage

A typical dofile with streamlined ECO verification in patch validation stage:

# Make use of verification information
set_verification_information ver_info -setup all
# Specify to use exact setup
set_flatten_model -specified_setup_only -noauto_modeling
...
read_library
read_design G3 -gold
read_design G2 -rev
...
set_system_mode lec
add_compared_points -all
compare

Streamlined ECO Information Reporting - Patch Generation

In the patch generation stage, when running the command optimize_patch, the
keypoint mapping and flop merging information will be collected to the verification
information. The following is a sample output:
...
// Command: set_verification_information ver_info
// Verification information is set to ver_info.
...
...
// Command: optimize_patch ...
// Note: Collect 185 mapping information(s) in the patch to verification information.
// Note: Collect 86 merge flop(s) in the patch to verification information.
...

September 2020 30 Conformal 20.10

// Command: write_verification_information ver_info
// Verification information is written to ver_info.
...

Streamlined ECO Information Reporting - Patch Validation

In the patch validation stage, with the command set_system_mode lec, the modeling
message F21 shows merged flops defined from verification information. Mapping from
verification information are shown in USER class. The following is a sample output:
// Command: set_verification_information ver_info -setup all
// Verification information is set to ver_info.
// Command: set_flatten_model -specified_setup_only -noauto_modeling
0
...
// Command: set_system_mode lec
// Read in 329 merge group(s) from verification information.
// Processing Golden ...
// Modeling Golden ...
// (F21) Merged 88 DFF/DLAT(s) due to added instance equivalences (flatten)
...
// Mapping key points ...
// Mapped 11310 key points by verification information
...
Mapped points: USER class
--------------------------------------------------------------------------------
Mapped points PI PO DFF Total
--------------------------------------------------------------------------------
Golden 96 44 11170 11310
--------------------------------------------------------------------------------
Revised 96 44 11170 11310
================================================================================

Enhancement: Customized Naming For New Flops

Streamlined ECO verification supports customized naming rules for new flops in the
patch. The user can specify the naming rules using either one of the following settings:
set_eco_option -SEQuentialnaming "CFM_ECO_%s"
optimize_patch -SEQuentialnaming "CFM_ECO_%s"

When there is a customized naming setting specified, a new flop will be named
according to user setup. For example, given the naming format CFM_ECO_%s, a flop
copied from G2 named REG1 will be named as CFM_ECO_REG1 in G3. The command
write_verification_information will update the mapping information for G3 side to
be (CFM_ECO_REG1, REG1).

September 2020 31 Conformal 20.10

Enhancement: Flop Replacement

Streamlined ECO verification also supports the flop replacement. Flop replacement
happens when there is a flop type change such as asynchronous reset changed to
asynchronous set. For these scenarios, CECO preserves the original flop in order to
keep scan chain intact. To avoid naming conflict, the name of the new flop is appended
with a number to differentiate the flops.

The enhancement updates the mapping of new flop when a naming change happens. In
the example below, the streamlined ECO verification updates the correct mapping for
the new flop, REG1_1 to be (REG1_1, REG1).

Enhancement: Support Sequential Merge Verification

Streamlined ECO verification can also record sequential merge information which helps
in G3 modeling.

Consider the following scenario below: G2 has duplicated flops. When the flop /REG1 is
patched to G3, /ModA/REG1 and /REG1_dup should be sequentially merged. With the
command write_verification_information, the sequential merge information of
/ModA/REG1 and /REG1_dup is recorded.

September 2020 32 Conformal 20.10

Benchmark 1: Turn Around Time Improvement Over Human Validation

• Design statistics:

G1 G2

Gate count 128931 131788

DFF/DLAT count 11681 12066
• Compare result: EQ: 10681, NEQ: 348

• Patch information:

• Patch size: 3235, patched flops: 320

• New flop mapping: 234, New duplicated flops:86

• Streamlined ECO verification result:

EQ NEQ

G3-G2 without 11240 80

streamlined ECO
verification
G3-G2 with streamlined 11263 0
ECO verification
• G3-G2 human validation time: 5 hours

• Streamlined ECO verification time: 1 min

• Runtime improvement: 300x

September 2020 33 Conformal 20.10

Benchmark2: Streamlined ECO Verification Enhancement

The benchmark result of streamlined ECO verification is shown below. There are 385
ECO test cases in the benchmark. CECO in Conformal 18.20 passes 12 more cases
with the help of streamlined ECO verification.

Version # Cases # Pass cases with # Pass cases

Streamlined ECO without
Verification Streamlined ECO
Verification
18.20 385 385 373

Benchmark 2: Summary

ECO Category Scenarios of RTL Design ECO Flows

Change Characteristics

Multi-bit clock change of one with/without FEFHier-FEF

bitasync. reset sharing of Customized naming
to/from sync. reset scan/data rules
portwith/without
multi-bit
implementation
with/without
sharing of ICG cell
with/without flop
duplication
Integrated Clock add/removal of
Gating (ICG) cell tool/manual added
ICG cellenable
condition change of
ICG cell
Scan chain clock
inversionadd/removal
of registers
Others change of register
default valuechange
of if-else
condition/operation
change of port
connection

September 2020 34 Conformal 20.10

 add/removal of
synchronizer

September 2020 35 Conformal 20.10

Debug ECO: Preserving Module Contents from Being
Flattened When Generating the Patch
Flattening G2 Modules in the Flattened ECO Flow

In the Flattened ECO Flow (recommended flow), the G2 is flattened to match the
hierarchy in G1. This makes it easier to find corresponding nets during patch creation. If
the G2 netlist contains additional modules, these modules will be flattened. The
flattened modules' contents get added to the patch in the next hierarchy of the flattened
modules.

Module preservation is useful for verification, DFT, or Place and Route. This guide will
show you the steps to preserve the additional modules' hierarchy in the final G3 netlist.

Reporting Modules in the Revised G2 Netlist

Using the report_modules command, you can see there is an additional module
vga_tclk that is introduced in the Revised G2 netlist.
TCL_LEC> report_modules
Golden:
vga_top
vga_htim
vga_vtim
vga_tgen
Revised:
vga_top
vga_htim
vga_vtim
vga_tgen
vga_tclk

In the Flattened ECO Flow, vga_tclk is flattened to make the hierarchies between G1
and G2 match. To preserve the vga_tclk module in the final G3 netlist, this module must
not be flattened in the Conformal ECO flow.

Module Flattening in the Flattened ECO Flow

The module boundary of vga_tclk will get flattened in the Revised by the flatten
command option, which is recommended in the FEF flow.
TCL_SETUP> flatten -nolibirary -matchhierarchy -revised
TCL_SETUP> report_modules
Golden:
vga_top

September 2020 36 Conformal 20.10

 vga_htim
vga_vtim
vga_tgen
Revised:
vga_top
vga_htim
vga_vtim
vga_tgen

The contents of vga_tclk will now be passed to the Final G3 netlist. Note that the
module vga_tclk is no longer there in the Revised G2 netlist. Its logic is now in the top
module vga_tclk.

Preventing Module Flattening with Black Boxes

To make sure the output patch has the vga _tclk module, black box this module prior to
the flatten command. This will prevent it from being flattened by the flatten
command.
TCL_SETUP> add_black_box vga_tclk -revised
TCL_SETUP> report_black_box
USER: (R) vga_tclk
TCL_SETUP> flatten -nolibrary -matchhierarchy -revised
TCL_SETUP> report_modules
Golden:
vga_top
vga_htim
vga_vtim
vga_tgen
Revised:
vga_top
vga_htim
vga_vtim
vga_tgen
vga_tclk (black box)

Note that the vga_tclk module is still present in the Revised design as a black box.

Reporting Black Boxes as Not-Mapped Point

Since the vga_tclk module is a black box only in the Revised, LEC will classify it as a
not-mapped point.
TCL_SETUP> set_system_mode lec
// Processing Golden ...
// Modeling Golden ...
...
Unmapped points:
=======================================================

September 2020 37 Conformal 20.10

Golden:
-------------------------------------------------------
Unmapped points DFF Z Total
-------------------------------------------------------
Unreachable 100 121 221
=======================================================
Revised:
-------------------------------------------------------
Unmapped points BBOX Total
-------------------------------------------------------
Not-mapped 1 1
=======================================================
...

Now continuing with the flatten ECO flow, this black box will be copied over to the final
G3 netlist.

Generating the Patch with Module Preservation

During the analyze_eco command process, the patch will contain the vga_tclk module
and its contents.
TCL_LEC> analyze_eco -hierarchical patch.v -replace
// analyzing vga_top (path: vga_top)
// Grouping
...
// Note:5 group(s) added
// Note 20 library cell(s) in the patch
// 1 module instance(s) are in the patch

The one module instance in the patch refers to the vga_tclk black box module.

Applying the Patch to Create the Final G3 netlist

To create the final G3 netlist, with the vga_tclk module, use the apply_patch
command.
TCL_LEC> set_system_mode setup
TCL_SETUP> apply_patch -auto
// Note: read_design patch.v -append -lastmod -norulesummary
// Parsing file patch.v
// Apply patch vga_top vga_top_eco
...
// Warning: 1 module instance(s) are in the patch
TCL_SETUP> report_modules
Golden:
vga_top
vga_htim
vga_vtim
vga_tgen

September 2020 38 Conformal 20.10

 vga_tclk
Revised:
vga_top
vga_htim
vga_vtim
vga_tgen
vga_tclk (black box)

From the report_modules command, the vga_tclk module is now in the final G3 netlist.

Optimizing the Patch

The last step in the CECO flow is to optimize the patch with the optimize_patch
command. During this step, you should use the option -noflatten_small. The default
behavior in Genus is to flatten modules smaller than 10k gates. This option will instruct
Genus to not flatten these modules and keep the hierarchy.
TCL_SETUP> optimize_patch -noflatten_small ...
// Note: Executing 'genus -bg -version'
...
// Normal exit.
// Parsing file work/cfm_eco_patch1.gv
// Flatten patch vga_top -instance eco

Note that the ECO module vga_top_eco that was created by

the analyze_eco command is automatically flattened back into its root module at the
completion of the optimize_patch command.

Validating the Patch

To validate the patch in the same session, remove the vga_tclk black box in Revised
with the delete_black_box command. This is done to make sure that Conformal ECO
copied over the contents of vga_tclk correctly from the G2.
TCL_SETUP>optimize_patch -noflatten_small ...
// Note: Executing 'genus -bg -version'
...
// Normal exit.
// Parsing file work/cfm_eco_patch1.gv
// Flatten patch vga_top -instance eco
TCL_SETUP> delete_black_box -all -both
TCL_SETUP> report_modules
Golden:
vga_top
vga_htim
vga_vtim
vga_tgen
vga_tclk
Revised:

September 2020 39 Conformal 20.10

 vga_top
vga_htim
vga_vtim
vga_tgen
vga_tclk
TCL_SETUP> set_system_mode lec
// Processing Golden ...
// Modeling Golden ...
...
TCL_LEC> add_compare_points -all
// 1089 compared points added to the compare list
TCL_LEC> compare
============================================
Compared points PO DFF Total
--------------------------------------------
Equivalent 353 736 1089
============================================

Now the patch is validated with the addition of the vga_tclk module hierarchy in the final
G3 netlist.

September 2020 40 Conformal 20.10

Debug CECO: Diagnosing Unmapped Pin Error Due to
Black Box Pin Differences
Black Box Pin Differences

In Conformal ECO the G1 and G2 netlists may contain black boxes. These can be from
the libraries, such as memories and RAMs, and user defined with the add_black_box
command. In either case, the black box pins should match if they are a part of the ECO
since Conformal ECO can not change the black box interface. If they do not, it can lead
to an error during the analyze_eco command.

Unmapped Pin Error During analyze_eco

The following error message Patch reaches unmapped pin occurs during the
analyze_eco command. This prevents Conformal ECO from creating a successful
patch.
TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v -replace
// Analyzing vga_vtim (path: /vtgen/ver_gen)
...
// Error: Patch reaches unmapped pin Blackbox/o2 in TOP

You first need to get more information on this unmapped black box pin with the following
step.

Diagnosing Unmapped Pin Error Message

Run the report_eco_check -verbose command to determine if there is a potential
setup issue. This command is run automatically after the set_system_mode lec,
compare, compare_eco_hierarchy and analyze_eco commands.

TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v -replace

// Analyzing vga_vtim (path: /vtgen/ver_gen)
...
// Error: Patch reaches unmapped pin Blackbox/o2 in TOP
TCL_LEC> report_eco_check –verbose
...
// Warning: (ECO1.6) Extra black-box pins (input). (occurence 1)
1: (R) BUF /Top/Blackbox/b
// Warning: (ECO1.6) Extra black-box pins (output). (occurence 1)
1: (R) BUF /Top/Blackbox/o2

September 2020 41 Conformal 20.10

The report_eco_check command reports an extra blackbox input pin b and output pin
o2 in G2 that do not exist in the G1. This check is available after set_system_mode lec.
Next, let's examine the netlist to check on these pins.

Examine the Extra Black Box Pins in the Netlist

The following diagram shows the extra black box input pin b and output pin o2 in the G2
netlist. The warning occurs since CECO cannot modify the interface of a black box. It
cannot patch the non-equivalences due to these extra pins.

TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v -replace

// Analyzing vga_vtim (path: /vtgen/ver_gen)
...
// Error: Patch reaches unmapped pin Blackbox/o2 in TOP
TCL_LEC> report_eco_check –verbose
...
// Warning: (ECO1.6) Extra black-box pins (input). (occurence 1)
1: (R) BUF /Top/Blackbox/b
// Warning: (ECO1.6) Extra black-box pins (output). (occurence 1)
1: (R) BUF /Top/Blackbox/o2

Resolving Extra Black Box Pins

To address the extra black box pins, check whether the library or module definition of
the black box in G1 and G2 are the same. Use the write_design -bbox_only
command to write out the G1 and G2 black boxes to a file.
TCL_LEC> write_design -bbox_only gol.bbox -golden -replace
TCL_LEC> write_design -bbox_only rev.bbox -revised -replace

You can use tkdiff or a text viewer to compare the module definitions.

September 2020 42 Conformal 20.10

Also review whether the modules are correctly intended to be black boxed with the
report_black_box command.

TCL_LEC> report_black_box -detail

USER: (G R) blackbox

September 2020 43 Conformal 20.10

Debug CECO: Preventing CECO from Deleting and
Adding a New DFF
Summary

This guide explains a simple way to prevent CECO from deleting and adding in a new
DFF when changing a set DFF to a reset DFF or reset to set. If there is a mapped DFF
that is a different type in G2, the default behavior in CECO is to copy the DFF from G2.
This will add in a new DFF and delete the original one. This can break the scan chain,
and make it more difficult in a post-mask ECO since a new spare DFF needs to be used
and rerouted.

Reporting the Non-Equivalent Results to be Used for Changing the

DFF Type

In this example, the ECO is changing a set DFF, dout_reg, to a reset DFF. When there
is a DFF type change in the CECO flow, the DFF, dout_reg, will be non-equivalent after
comparison between the G1 and G2 netlists. After compare has completed use the
report_compare_data -nonequivalent command to report the non-equivalent
points.
TCL_LEC> compare
===========================================
Compared points PO DFF Total
-------------------------------------------
Equivalent 1 0 1
-------------------------------------------
Non-equivalent 0 1 1
============================================

TCL_LEC> report_compare_data -nonequivalent

Compared points are: Non-equivalent
+ 6 DFF /dout_reg/U$1 + 7 DFF /dout_reg/U$1

The next step in the FEF flow is to run the compare_eco_hierarchy and analyze_eco
commands.

Creating the Patch

The compare_eco_hierarchy command breaks down the non-equivalent points to their

appropriate modules. The analyze_eco command creates the patch based on the non-
equivalent points.

September 2020 44 Conformal 20.10

TCL_LEC> compare
...
TCL_LEC> compare_eco_hierarchy
...
TCL_LEC> analyze_eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
// Analyzing conv_subreg (path:/)
// Grouping
// Note: 1 group(s) added
// Note: 1 library cell(s) is in the patch
// Warning: 1 DFF(s) is in the patch

A new DFF has been added to the patch during the patch creation process from the
analyze_eco command. The next step is to apply the patch.

Applying the Patch

The apply_patch command applies the patch to the original G1 netlist to create the
new G3 netlist.
TCL_LEC> analyze_eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
...
TCL_LEC> apply_patch -auto
// Note: read design patch.fef.v -append -lastmod -norulesummary
// Parsing file patch.fef.v ...
// Note: Read VERILOG design successfully
// Note: Apply patch conv_subreg conv_subreg_eco
// Note: 1 library cell is in the patch
// Warning: 1 DFF is in the patch
// Note: 1 library cell was freed
// Warning: 1 DFF was freed
// Note: No library cells were recycled

A new DFF has been added and the original one has been freed (deleted). We can also
see the DFF, dout_reg, in the patch file, patch.v.
patch.v

// (G) MODULE conv_subreg INSTANCE

// (R) MODULE conv_subreg INSTANCE
module conv_subreg_eco(dout,scan_out_wire,pr,rc_clk,din);
// pragma no_bbox_empty
output dout,scan_out_wire;
input pr,rc_clk,din;
wire scan_out_wire,dout,scan_in,din,pr,N1,rc_clk;
SDFFR_X1 dout_reg(.CK(rc_clk),.D(din),.RN(pr),.SE(N1),
.SI(N1),.Q(dout),.QN(scan_out_wire)); // DFF:1
assign N1 = 1'b0;
endmodule

September 2020 45 Conformal 20.10

Since the DFF type has changed, CECO has added a new DFF and deleted the original
one to fix the non-equivalence. Next, we will use phase mapping to prevent this from
happening.

Preventing the DFF from being Added and Deleted by using Phase
Mapping

Since we are changing the DFF from a set to reset, we can use phase mapping so
Conformal ECO can just add an inverter to the output of the DFF. The
set_mapping_method -phase command will map key points with an inverted phase.
Use this command before set_system_mode lec. Once the patch has been applied,
the Golden database has been permanently changed. You will need to add this
command to the dofile and rerun CECO.
TCL_SETUP> set_mapping_method -phase
...
TCL_SETUP> set_system_mode lec
// Processing Golden ...
// Modeling Golden ...
// Processing Revised ...
// Modeling Revised ..
...
Mapped points: SYSTEM class
-----------------------------------------------
Mapped points PI PO DFF Total
-----------------------------------------------
Golden 4 1 1 6
-----------------------------------------------
Revised 4 1 1 6
================================================

The DFF, dout_reg, is now mapped by phase. We can confirm this by reporting the
mapping points with the -inverted_phase option.

Using a Mapping File for Phase Mapping

Another way to map the DFF by phase is by using a mapping file. In cases where the
user knows the DFFs that are changing type, it map be easier to manually maps these.
In this file you specify which DFF's are to be mapped by phase. In this example, we
create a file named map.f which contains the mapping information.
add_mapped_point dout_reg dout_reg -invert

The first dout_reg is the Golden (G1) DFF name and the second dout_reg is the
Revised (G2) DFF name.

September 2020 46 Conformal 20.10

Specifying the Mapping File in the Dofile

To use the mapping file in the Conformal ECO dofile, it specified with the
set_analyze_option -mapping_file command. Use this command before
set_system_mode lec. The phase mapped DFF will now be in the USER class.

TCL_SETUP> set_analyze_option -auto -mapping_file map.f

...
TCL_SETUP> set_system_mode lec
// Processing Golden ...
// Modeling Golden ...
// Processing Revised ...
// Modeling Revised ..
...
Mapped points: SYSTEM class
-----------------------------------------------
Mapped points PI PO Total
-----------------------------------------------
Golden 4 1 5
-----------------------------------------------
Revised 4 1 5
================================================
Mapped points: USER class
-----------------------------------------------
Mapped points DFF Total
-----------------------------------------------
Golden 1 1
-----------------------------------------------
Revised 1 1
================================================

The DFF, dout_reg, is now mapped by phase. We can confirm this by reporting the
mapping points with the -inverted_phase option.

Check the Mapping Results for Phase Inversion

After mapping has completed, use the report_mapped_points -inverted_phase

command to report any inverted mapped points.
TCL_SETUP> set_system_mode lec
// Command: set_system_mode lec
// Processing Golden ...
// Modeling Golden ...
// Processing Revised ...
// Modeling Revised ..
...
===============================================
Mapped points: SYSTEM class
-----------------------------------------------
Mapped points PI PO DFF Total

September 2020 47 Conformal 20.10

-----------------------------------------------
Golden 4 1 1 6
-----------------------------------------------
Revised 4 1 1 6
===============================================

TCL_SETUP> report_mapped_points -inverted_mapped

Mapped points: SYSTEM class

Golden Revised
+ 6 DFF /dout_reg/U$1 - 7 DFF /dout_reg/U$1

==============================================
Mapped points DFF Total
----------------------------------------------
Golden 1 1
----------------------------------------------
Revised 1 1
=============================================

The DFF, dout_reg, is now mapped by phase inversion. This is represented with the
symbol "-" in the Revised DFF.

Create the Patch using the Phase Mapped DFF

Use the analyze_eco command to generate the patch with phase mapping enabled.

TCL_LEC> compare
// Command: compare
===========================================
Compared points PO DFF Total
-------------------------------------------
Equivalent 1 0 1
-------------------------------------------
Non-equivalent 0 1 1
============================================

TCL_LEC> compare_eco_hierarchy
...
TCL_LEC> analyze_eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
// Command: analyze eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
// Analyzing conv_subreg (path:/)
// Grouping
// Note: 2 group(s) added
// Note: 0 library cell(s) is in the patch
// Note: 1 primitive(s) is in the patch

In this original run, there was a DFF added to the patch. Now with phase mapping, only
a single primitive is added to the patch and there are no DFFs added.

September 2020 48 Conformal 20.10

Apply the Patch

Apply the patch to the original G1 netlist.

TCL_LEC> analyze_eco -hierarchical -ecopin_dofile ecopins.do patch.v -replace
...
TCL_LEC> apply_patch -auto
// Command: apply_patch -auto
// Note: read design patch.fef.v -append -lastmod -norulesummary
// Parsing file patch.fef.v ...
// Note: Read VERILOG design successfully
// Note: Apply patch conv_subreg conv_subreg_eco
// Note: 0 library cell is in the patch
// Note: 1 primitive is in the patch
// Note: No library cells were freed
// Note: No library cells were recycled

Only a single primitive is added to the patch and no cells are freed (deleted). The
original DFF is kept with its set inverted.

September 2020 49 Conformal 20.10

Debug CECO: How to Change the CPU Limit with the
Analyze Eco Command
Summary
In the Conformal ECO flow, the analyze_eco command is used to generate the ECO
patch. In some cases where there are a large number of ECO changes, the CPU limit
for this command may be reached. When this happens, the effort level is reduced to
medium effort. Medium effort will skip some optimization steps that are used in
high(default) or ultra effort. This debug guide will show you how to increase the CPU
limit to avoid using medium effort to generate the patch.

Analyze ECO and CPU Limit with High Effort

The following warning message CPU limit exceeded can occur during
the analyze_eco command when the default limit of 36000 seconds is reached. The
default is high effort.
TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v -replace
// Analyzing vga_vtim (path: /vtgen)
// Grouping
// Note: 2 group(s) added
// Warning: CPU limit is exceeded, effort lowered to medium
// Note: 15 library cell(s) is in the patch
// Note: 16 primitive(s) are in the patch
// Warning: 2 DFF(s) are in the patch

In this case, the effort level is reduced from high to medium effort. Next we will show
you the CPU limits affect on post optimization.

Analyze ECO and CPU Limit and Post Optimization

Post optimization occurs with high effort, when the -post_optimization option is specified
or automatically with ultra effort. Post optimization tries to further reduce the patch size
after the patch is generated. You may see this message that post optimization is
skipped when running the analyze_eco command when the CPU limit is reached.

TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v \

-effort ultra -replace
// Analyzing vga_vtim (path: /vtgen)
// Grouping
// Note: 2 group(s) added
// Warning: CPU limit is exceeded, effort lowered to medium
// Post Optimization

September 2020 50 Conformal 20.10

// Warning: CPU limit exceeded, post optimization is skipped
// Note: 15 library cell(s) is in the patch
// Note: 16 primitive(s) are in the patch
// Warning: 2 DFF(s) are in the patch

Next we will show you have to increase the CPU limit to avoid skipping post
optimization to get the smallest patch possible.

Changing the CPU Limit

There is a new option -cpulimit introduced in Conformal ECO 19.20-p100 for the
analyze_eco command. This option is specified in seconds. The default is 36000
seconds. This number can be increased or decreased. There is no maximum limit.
TCL_LEC> analyze_eco -ecopin_dofile ecopin.do patch.v -replace \
-effort ultra -cpulimit 64000
// Analyzing vga_vtim (path: /vtgen)
// Grouping
// Note: 2 group(s) added
// Post Optimization
// Note: 2 nets found by post optimization
// Note: 10 library cell(s) is in the patch
// Note: 12 primitive(s) are in the patch
// Warning: 2 DFF(s) are in the patch

Increasing the CPU limit to 64000 seconds now allows the patch to be created with the
specified effort level (in this case ultra) without switching to medium effort. In this case
the patch size is reduced from 15 to 10 library cells and 16 to 12 primitives.

September 2020 51 Conformal 20.10

Hierarchical Flattened ECO Flow
Summary

Hierarchical flattened ECO flow (Hier-FEF) combines the hierarchical ECO flow for its
runtime advantage and the flattened ECO flow (FEF) for its quality advantage. The Hier-
FEF can reduce the turnaround time by as much as 10x while delivering high-quality
patches.

In Hier-FEF, we generate the targeted ECO blocks dofile using Conformal hierarchical
dofile extraction and then execute individual FEF on ECO blocks to create the ECO
patches.

When ECOs are deep in the design hierarchies, the Hier-FEF avoids processing non-
ECO modules and analyzes only the designated ECO sub-module. As a result, the
turnaround time becomes much faster.

This feature is available in Conformal ECO 19.10-p100.

Hier-FEF Advantages

Hier-FEF is a combination of FEF and Hierarchical ECO flow.

• Faster turnaround time. Up to 10x faster than FEF.

• Less restrictive ECO block requirements than Hierarchical ECO flow.

• Supports multiple ECO blocks in one run.

• Utilizes FEF advantages that analyze ECO blocks and automatically identify the
ECO location and ECO module pin changes.

• Utilizes hierarchical dofile generation to speed up the runtime and the module pin
mapping.

• Utilizes automatic ECO setup checks to see if an ECO block is compatible with
this flow.

ECO Flows

Conformal ECO provides three main ECO flows

September 2020 52 Conformal 20.10

 • Flattened ECO Flow (FEF )

• Hierarchical ECO Flow

• Hierarchical Flattened ECO Flow (Hier-FEF)

Hierarchical Flattened ECO Flow

Hier-FEF runs FEF on each ECO block where an ECO block is a module including ECO
submodule(s). The ECO block has no interface changes which enables it to be written
out during hierarchical dofile generation.

In the example below, the ECO is to modules modA_1 and modA_2. User can set
modA as ECO block and run Hier-FEF. The other modules are excluded from
comparsion, which saves the turnaround time.

September 2020 53 Conformal 20.10

Configure Hier-FEF by setting the command:
set_eco_option -hier_flat

Hier-FEF Recommended Scenarios

Hier-FEF is recommended for ECO designs with the following characteristics:

• ECO occurs in a deep hierarchy.

• ECO block(s) are relatively small compared to the whole design.

• Flattened-comparison and modeling for the entire design take a long time.

• There are no changes on the ECO block interface.

Hier-FEF Flowchart

September 2020 54 Conformal 20.10

Hier-FEF ECO Flow

Hier-FEF consists of the following steps:

• Set the intention to run Hier-FEF.

set_eco_option -hier_flat

• Specify the verification information directory for streamlined patch validation.

set_verification_information UVI

• Provide a list of ECO blocks and tag these modules with an attribute for
the hierarchical dofile generation.

September 2020 55 Conformal 20.10

set eco_blocks [list modA]
foreach module $eco_blocks
{ add_module_attribute $module -flat_eco_module -both }

• Generate the hierarchical dofile for these ECO blocks.

write_hier_compare_dofile hfef.hier.do -replace

• Check if the ECO block is qualified to run Hier-FEF

check_eco_setupIf there is any violation in the report, check the hierarchical dofile
for the reason it was not written out.

• Run FEF on ECO blocks

foreach module $eco_blocks
{ run_hier_compare hfef.hier.do -root_module $module $module -nodynamic_hierarchy }

• Apply the patch, optimize the patch and write out G3 (ECO netlist)
delete_black_box -all -both
set_root_module top -both
foreach module $eco_blocks { dofile ${module}.ecopins.do }
apply_patch -auto
optimize_patch -workdir genus_work -library cells.lib
write_eco_design -newfile g3.v

• Save the verification information

write_verification_information

ECO Validation

After the ECO-change process is done, the next step is patch validation which is done
by running regular equivalence checking on G3 versus G2.

In the ECO netlist validation step, we verify that the ECO blocks are functionally
equivalent as well as the entire final ECO netlist.

ECO Validation - Verify ECO Patch

To verify Hier-FEF ECO patch results use the following steps:

• In a separate run, apply the verification information which was saved in Hier-FEF
run.
set_verification_information UVI -setup all
set_flatten_model -specified_setup_only
set_hier_compare_option -ignore_top_merge_constraint

September 2020 56 Conformal 20.10

 • Run the hierarchical dofile generated in the Hier-FEF ECO run on all ECO
blocks. Use the same hierarchical dofile and verification information to reduce the
possibility of false non-equivalences.
set eco_blocks [list modA]
foreach module $eco_blocks {
run_hier_compare hfef.hier.do -root_module $module $module -nodynamic_hierarchy
add_black_box $module -hier -both }

Sample Dofile - Patch Generation

Hier-FEF sample dofile. This supports multiple ECO blocks.

#Step 1: Set the ECO Flow as Hier-FEF
set_eco_option -hier_flat
set_verification_infomration UVI
read_library -liberty lib.lib
read_design -golden g1.v
read_design -revised g2.v
flatten -nolibrary -matchhierarchy -use_renaming_rules -revised
uniquify -all -nolibrary -revised
#Step 2: Tag ECO blocks with flat_eco_module attribute
set eco_blocks [list moduleA moduleB submoduleC]
foreach module $eco_blocks {
add_module_attribute -flat_eco_module $module }
#Step 3: Generate hierarchy dofile
write_hier_compare_dofile hfef.hier.do -replace -verbose
#Step 4: Check HFEF feasiblity
check_eco_setup -verbose
#Step 5: Run FEF on ECO blocks
foreach module $eco_blocks {
run_hier_compare hfef.hier.do -root_module $module $module -nodynamic_hierarchy }
#Step 6: apply patch, optimize_patch, write out eco design
set_system_mode setup ; set_root_module top -both
foreach module $eco_blocks {
if { [file exists ${module}.ecopins.do ] } { dofile ${module}.ecopins.do}}
delete_black_box -hier -all -both
apply_patch -auto
optimize_patch -workdir genus_work -library cells.lib
write_verification_information UVI
write_eco_design -newfile g3.v -replace

Sample Dofile - Patch Validation

The following is a sample dofile script for validating the ECO netlist G3.
#Step1: Set the flow as a regular lec run
read_library -liberty lib.lib
read_design -golden g3.v
read_design -revised g2.v

September 2020 57 Conformal 20.10

flatten -nolibrary -matchhierarchy -use_renaming_rules -revised
uniquify -all -nolibrary -revised
#Step2: Verify each eco blocks
set_verification_information UVI -setup all
set_flatten_model -specified_setup_only
set_flatten_model -noauto_modeling
set_hier_compare_option -ignore_top_merge_constraint
set eco_blocks [list moduleA moduleB submoduleC]
foreach module $eco_blocks{
run_hier_compare hfef.hier.do -root_module $module $module -nodynamic_hierarchy
add_black_box $module -hier
}
report_hier_compare_result -all

Hier-FEF Commands

There are three command options specialized for Hier-FEF.

• set_eco_option -hier_flat

• add_module_attribute -flat_eco_module

• add_module_attribute -analyze_eco_string

Command set_eco_option -hier_flat

Setting the set_eco_option -hier_flat command enables the subsequent tool
settings as follows:

• Specifies the intention is to run Hier-FEF.

• Automatically adds the following options to the

command write_hier_compare_dofile:

-balanced_extraction
-constraints
-noexact_pin_match
-function_pIn_mapping
-input_output_pin_equivalence
-extract_icg
-threshold 0

Command add_module_attribute -flat_eco_module

SYNTAX
add_module_attribute <module> -FLAT_ECO_MODULE

September 2020 58 Conformal 20.10

Setting the command add_module_attribute -FLAT_ECO_MODULE enables the
subsequent tool settings automatically:

• Specifies <module> is an ECO block and is intended to run FEF.

• Hierarchy generation only writes out modules of ECO blocks. Others are
excluded from hierarchical generation by the command add_noblack_box

• During a normal ECO run hierarchical dofile generation will output these
commands:
add_compared_points -all
compare
In the Hier-FEF the following commands are output during hierarchical dofile
generation:
analyze_hier_compare -eco_aware
add_compared_points -all
compare
compare_eco_hierarchy
check_eco_setup
analyze_eco -hierarchical -ecopin_dofile <module>.ecopins.do <module>.patch.v -
replace

Command add_module_attribute <module> -analyze_eco_string

SYNTAX
add_module_attribute <module> -ANALYZE_ECO_STRING <command string>

During hierarchical dofile generation in Hier-FEF, the output of command analyze_eco

is replaced with <command string> for the <module>. This requires that the
<module> <module> is also an ECO block specified with add_module_attribute -
flat_eco_module.

For example, if the user wants to include the option -preserve_clock in the command
analyze_eco, the user can use the command:

add_module_attribute moduleA -analyze_eco_string \

'analyze_eco -hierarchical -ecopin_dofile A.ecopins A.patch -preserve_clock -
replace'

Then the output hierarchical dofile for moduleA will include commands:
analyze_hier_compare -eco_aware
add_compared_points -all
compare
compare_eco_hierarchy -verbose
check_eco_setup
analyze_eco -hierarchical -ecopin_dofile A.ecopins A.patch -preserve_clock -replace

September 2020 59 Conformal 20.10

ECO Setup Checks for Hier-FEF

There are two ECO setup checks for Hier-FEF. These checks are automatically
performed after the commands
write_hier_compare_dofile and compare_eco_hierarchy.

CECO performs the following setup checks:

• Hierarchical ECO module: This check reports the ECO block was not written out
during hierarchical generation.

• Shared pin change in Hier-FEF: This check reports a shared pin of the ECO
block requires the ECO be made at its parent module. A shared pin drives both
function and scan path.

See Conformal ECO Setup Check for more details.

Benchmark Results

From the benchmark results, it shows that Hier-FEF helps to improve turnaround time,
especially for a small ECO block in a large design.

DesignSize ECO block FEF Hier-FEF SpeedUp

(K) Size (%) Runtime (s) Runtime (s) (X)

case1 7800 0.2 18812 2087 9.0

case2 1800 59.6 3647 2108 1.7
case3 100 9.1 93 41 2.3
case4 200 5.0 487 428 1.1
case5 1100 0.1 11689 209 56

September 2020 60 Conformal 20.10

Configuring and Reporting Rule-Based ECO Setup
Checks
Summary

Conformal ECO setup checks streamline the ECO process by flagging potential issues
and suggesting possible resolutions early in the ECO process. Starting from 19.20-
p100, Conformal ECO provides the capability to customize automated setup checks.
Each ECO setup check is rule-based and reports detailed information about the setup
check. Users can configure each ECO setup check for severity and to stop the tool
execution if needed.

In Conformal ECO 20.10, additional setup checks are added to cover more ECO setup
issues. With these setup checks, users can identify issues upfront and improve
turnaround time up to 10X for diagnosis and resolving ECO setup related issues.

ECO Checks Naming Convention

Every check name consists of <prefix>.<number>. The prefix depends on when the
check is available. All prefixes are listed below.

• ECO1.* - After the set_system_mode lec command (modeling and mapping).

• ECO2.* - After the compare command.

• ECO3.* - After the compare_eco_hierarchy command.

• ECO4.* - After the analyze_eco command.

• ECO5.* - After the write_hier_compare_dofile command.

New ECO Setup Checks in Conformal ECO 20.10

The following ECO setup checks are added since Conformal ECO 19.20-p100. For the
details and example of each rule, refer to the appendix at the end of this documentation.

ECO Rule Severity Description

ECO1.11 Error The 'set_mapping_method

-nobbox_name_match'

September 2020 61 Conformal 20.10

 command is enabled in
physical difference flow
ECO1.12 Error Golden design hierarchy is
changed by the 'resolve' or
'flatten' command
ECO1.13 Error Module name in Golden
design is changed by the
'uniquify' command
ECO1.14 Warning Design(s) is changed by
the 'commit_power_intent -
insert_isolation' or
'read_power_intent -
insert_isolation' command
ECO2.7 Warning Non-equivalent shift
register(s) is detected
ECO3.4 Warning There is a not-mapped
supported key point in the
extra hierarchy in a non-
equivalent logic cone
ECO4.1 Warning There is an undriven
signal(s) in the ECO patch
ECO5.2 Warning The
'write_hier_compare_dofile'
command fails to output
module(s) which are sub-
modules of the ECO
modules specified by the
'add_module_attribute -
ECO_MODULE' command

Diagnosing ECO Setup Checks

A check with Error severity can cause a patch generation failure or an incorrect patch.
To help users to find the issue and review the setting as early as possible, by default the
process is stopped when an error is detected.

To diagnosis the details of eco setup check, users can use the report_eco_check -
verbose command:

TCL_SETUP> set_system_mode lec

...
// Running automatic ECO setup check...
// Error: (ECO1.12) Golden design hierarchy is changed by the 'resolve' or
'flatten' command. (occurrence 2)
// Please use the 'report_eco_check' command to see the details of each ECO check.

September 2020 62 Conformal 20.10

// Automatic ECO setup check finished.

TCL_LEC> report_eco_check -verbose

// Error: (ECO1.12) Golden design hierarchy is changed by the 'resolve' or
'flatten' command. (occurrence 2)
Golden design hierarchy is changed by the 'resolve' command. (occurrence 1)
1. resolved_module
Golden design hierarchy is changed by the 'flatten' command. (occurrence 1)
1. flattened_module

If users confirm the error is expected and want to continue the ECO process, the check
severity can be lowered from Error to Warning with the set_eco_check command.

Benchmark Result

The following are the benchmark results from cases which have missing DFT
constraints (ECO2.3 and ECO2.4).

Case Design Runtime without Runtime Missing Speedup

Size (M) ECO Setup with ECO DFT (X)
Check (secs) Setup Constraint
Check
(secs)

1 0.1 19003 286 2 66.4

2 0.1 6020 845 2 7.1
3 1.2 4275 821 4 5.2
4 1.3 20269 5161 6 3.9

September 2020 63 Conformal 20.10