GENUS-MODUS-LBIST Lab 20.10
GENUS-MODUS-LBIST Lab 20.10
Test (LBIST)
Rapid Adoption Kit (RAK)
© 2021 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
Introduction .................................................................................................................. 5
RAK Directory Structure ............................................................................................... 6
Tool Versions ............................................................................................................... 6
Licenses ...................................................................................................................... 7
Running the Lab........................................................................................................... 7
Terms .......................................................................................................................... 7
Lab Flow ...................................................................................................................... 8
General LBIST Information.......................................................................................... 9
General LAB Overview .............................................................................................. 11
Lab 1: JTAG LBIST Insertion into Top-Level Design ................................................ 12
Running Synthesis ................................................................................................. 12
Understanding LBIST Setup in the Lab .................................................................. 12
Running Modus ...................................................................................................... 15
Running Simulation ................................................................................................ 16
Running Conformal ................................................................................................ 17
Lab 1 Summary ...................................................................................................... 17
Lab 2: Direct Access LBIST into Core ................................................................ 18
Running Synthesis ................................................................................................. 18
Understanding LBIST Setup in the Lab .................................................................. 18
Running Modus ...................................................................................................... 22
Running Simulation ................................................................................................. 23
Running Conformal ................................................................................................. 23
Lab 2 Summary ...................................................................................................... 23
Lab 3: JTAG LBIST Insertion with Test Points into Top-Level Design ....................... 24
Running Synthesis ................................................................................................. 24
Understanding LBIST Setup in the Lab .................................................................. 24
Running Modus ...................................................................................................... 26
Running Simulation ................................................................................................ 26
Running Conformal ................................................................................................ 27
Lab 3 Summary ...................................................................................................... 27
Lab 4: JTAG OPCG LBIST into Top Level Design..................................................... 28
Running Synthesis ................................................................................................. 28
Understanding LBIST Setup in the Lab .................................................................. 28
Running Modus ...................................................................................................... 34
Running Simulation ................................................................................................ 35
Running Conformal ................................................................................................ 36
Lab 4 Summary ...................................................................................................... 36
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 3
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
Introduction
In the following labs, you will learn to:
• Add Logic Built-In Self-Test (LBIST) structures into the digital logic using Genus
Synthesis Solution.
• Analyze logic using LBIST test points to recommend test points for improving the
coverage.
Techniques covered in the labs are JTAG Insertion, Scan, 1500 Wrapper insertion,
Shadow Logic, Compression, OPCG insertion, Logic Test Point Analysis, and Logic
BIST. These Labs provide basic information on scan insertion and many of the DFT
concepts, but it does not go into details of all commands. If you are looking for a more
detailed analysis of the commands, refer to other Genus Synthesis DFT and Modus
Test RAKs. The concept of LBIST is a more advanced topic.
Note: Review LBIST-overview document and the Lab instructions given in this
document and use them as a reference throughout the labs.
Tool Versions
The Labs have been designed with the software versions listed below. Some of the
messages and log lines explained in the instructions may not appear with other versions.
• Genus Synthesis Solution 20.10 or later
• Modus DFT Software Solution 20.10 or later
• Xcelium Simulator 18.03 or later
• Conformal Verification 18.10 or later
Licenses
Standard licenses required for LBIST insertion are:
➢ cd to GENUS-MODUS-LBIST_RAK_20.10
Terms
XML Xcelium Simulator
DFT Design for Test
PRPG Pseudo Random Pattern Generator
MISR Multiple Input Shift Register
LFSR Linear Feedback Shift Register
TPI Test Point Insertion
Lab Flow
The figure given below represents the basic design and test structure of the DTMF chip
used for Labs 1, 3, and 4 in this RAK. Lab 2 uses a sub-block of the DTMF chip for
direct access insertion.
The LBIST state machine is depicted below. LBIST pattern sets can be broken down to
SCAN, SET, RESET, STATIC, and DYNAMIC patterns.
When LBIST is inserted, you can control the number of iterations for each set of
patterns. The recommendation is approximately eight scan, set and reset tests. This
allows for a large enough set of random data to fill the channel bits and allows the set
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 9
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
and reset flops to be activated. For static and dynamic tests, it is recommended to use a
number divisible by 64 (for example, 3200, 6400, and 12800). The number divisible by
64 allows the Modus high-speed scan simulator to perform at its optimum performance
level. Anything less than 64 would cause serial simulations that will increase the pattern
generation time.
Support for LBIST Diagnostics is available in the Modus DFT Software Solution. The
Diagnostics solution will require JTAG SETBIST to be part of the LBIST definition so
that it can be enabled to make use of this function during Diagnostics. The debug
method, used to identify the location of the failures, requires special patterns to be
generated to help perform a binary search on the LBIST integration range, which will
isolate a section of LBIST patterns containing failures and then narrow down the
search for the first failing signature. The patterns will then build from that point to
capture all failing signatures. The Diagnostics will be driven from the signature failure
data collection instead of the data captured from scan channel unloads.
An example of how certain options are enabled for each Lab is given below. Highlighted
in RED is the main LBIST option. This identifies the type of LBIST to be inserted. As
mentioned above, each Lab is created to configure a specific LBIST setup. You should
not change the options at this time. As the tool processes the main run scripts, it will, in
turn, call other scripts to define and then insert many of the DFT techniques. You can
define unique options for your designs in following part of runscript.
Running Synthesis
Run the following script from the GENUS-MODUS-LBIST_RAK_20.10 directory:
1. During the JTAG insertion, the instructions given below are defined. These are the
key JTAG instructions that will be used to access and start LBIST. RUNBIST
instructions will run the LBIST with the default setup defined during the insertion (to
be defined in a future step). SETBIST instructions will allow you to customize the
LBIST configuration based on your desired setup (the
SCRIPTS/JTAG/define_jtag.tcl file).
add_shadow_logic \
-mode share \
-test_control test_mode \
-balance \
-test_clock_pin scan_clk \
-around $vars(SRAM) \
-exclude CLOCK
add_shadow_logic \
-mode share \
-test_control test_mode \
-exclude CLOCK \
-balance \
-test_clock_pin scan_clk \
-around $vars(ROM) \
3. With the flow, the following will insert the LBIST logic on top of the existing
compression network (the SCRIPTS/LBIST/add_lbist.tcl file).
add_lbist \
-lbist_clock refclk \
• LBIST will use “refclk” as the input clock during LBIST operations. An internal
hook-up pin is provided as opposed to coming directly from the port.
• LBIST will use the test signal specified with the lbist_test_enable
function to put the LBIST logic under test. If this test signal is not specified,
you must specify -dont_scan_lbist_flops to not test LBIST.
• The clock specified with the dft_clock function will be used to scan
LBIST flops.
• The LBIST macro is being set up to issue a reset test for eight iterations. It
will control the reset and spi_fs pins as internal resets.
• The reset pulse width is being specified as a 3-input oscillator pulse. This
allows you to control the width of the reset pulse (in many cases, this needs to
be larger than the oscillator frequency).
this RAK, it allows for a quick simulation time. In real designs, this number
can be 6400 or higher. It depends on factors such as how long the LBIST can
run, given the length of scan chains and scan frequency.
4. The last task is to generate the LBIST testbench environment. The following
command will generate assign files and scripts to process the design through
Modus:
write_dft_lbist_testbench -tcl \
-run_from_directory \
-library $vars(INSTALL_DIR)/LIBS/atpg/include_libraries.v \
-ncsim_library
$vars(INSTALL_DIR)/LIBS/verilog/include_libraries_sim_atpg.v \
-directory $vars(_OUTPUT_PATH_TEST)/lbist
Running Modus
1. For details on the LBIST scripts, setup files, and execution, refer to Appendix A and
Appendix B.
➢ cd lab1_jtag_lbist/modus_test/lbist
➢ modus –f run_lbist_RUNBIST
2. The following are the steps for ATPG and Boundary Scan Verification:
➢ cd lab1_jtag_lbist/modus_test/bsv
➢ modus –f runmodus.bsv.tcl
➢ cd lab1_jtag_lbist/modus_test/atpg
➢ modus –f runmodus.atpg.tcl
Running Simulation
1. Once the LBIST signature and Verilog testbench has been generated, it is time to
validate the results using the simulation. As part of the Genus LBIST testbench
generation, the xrun script has been generated.
➢ ./run_sim_RUNBIST
2. For the Boundary Scan Verification simulation, you will need to update the mainsim
file to set up an oscillator on the main refclk.
reg osc_49;
wire
osc_pi_49;
always begin
#0;
osc_49 = 0;
#5000.000000; // 5000.000000 ps; From the start of
the cycle.
osc_49 = 1;
#5000.000000; // 10000.000000 ps; From the start of
the cycle.
end
Running Conformal
Lab 1 Summary
After completing this Lab, you have inserted LBIST into your design using Genus
Synthesis. Modus DFT Software Solution was used to generate LBIST signatures and
testbench, and results were validated with Incisive Simulation.
• Inserting scan, 1500 wrappers, and compression (to be used only by LBIST)
• Inserting shadow logic around memories
• Inserting Direct Access LBIST with dynamic clocking
• Generating and processing the design in Modus Test
Running Synthesis
Run the following script from the GENUS-MODUS-LBIST_RAK_20.10 directory:
1. To enable LBIST operations, the scripts will add new pins to be used as the LBIST
enable and pass/fail indicators (the SCRIPTS/LBIST/define_core_lbist.tcl
file).
# Add signal to start LBIST
create_port_bus -input -name go_lbist $vars(DESIGN)
2. To prevent Xs from memories, shadow logic is defined and inserted. These can be
found in the SCRIPTS/SCAN/define_core_shadow_logic.tcl and
SCRIPTS/SCAN/add_core_shadow_logic.tcl files.
add_shadow_logic \
-mode share \
-test_control test_mode \
-balance \
-test_clock_pin scan_clk \
-around $vars(SRAM) \
-exclude clock
add_shadow_logic \
-mode share \
-test_control test_mode \
-balance \
-test_clock_pin scan_clk \
-around $vars(ROM) \
-exclude CLOCK
3. To protect the design against Xs, 1500 wrapper logic is inserted on the primary
input pins (the SCRIPTS/SCAN/add_core_1500.tcl file).
set inputlist [get_db ports:$vars(DESIGN) -if { .direction == in}]
4. With the flow, the following will insert the LBIST logic on top of the existing
compression network (the SCRIPTS/LBIST/add_core_lbist.tcl file).
add_lbist \
-lbist_clock refclk \
-bist_clock_hookup [get_db pin:$vars(DESIGN)/PLLCLK_INST/pins/clk1x]
\
-lbist_clock_ref_period 32000 \
-lbist_clock_osc_period 32000 \
-direct_reset pllrst \
-direct_logic_bist_enable go_lbist \
-direct_bist_done_output bist_done \
-direct_bist_pass_output bist_pass \
-direct_bist_fail_output bist_fail \
-control_inputs_0 scan_in0 scan_in1 scan_in2 \
-scan_patterns 8 \
-reset_patterns 8 -
async_reset_signals "reset spi_fs"
-set_reset_pulse_width 3 -set_reset_test_window 8 \
-static_patterns 64 \
-dynamic_patterns 64 -capture_window_capture_value 5
-capture_window_launch_value 7 \
-capture_window 10 -direct_access
This is used to verify that PRPG, MISR, and channels are working correctly.
o There are two asynchronous reset clocks on the design (reset and spi_fs).
The insertion of the LBIST macro will allow a reset test to occur.
o There will be eight reset tests performed. LBIST will use the random PRPG
data to load the channels, and then, the reset will be issued.
o The pulse width is set up to be three BIST oscillator cycles. The width is
controlled during the insertion of the macro.
• -static_patterns 64: This identifies that the Direct Access LBIST will only
run for 64 static capture iterations
This is considered small number of iterations, but for this RAK, it allows for a
short simulation time. In real designs, this number can be 6400 or higher. It
depends on factors such as how much time you want to run LBIST, the length of
the scan channels (compression), and the scan frequency.
• -dynamic_patterns 64: This identifies that the Direct Access LBIST will only
run for 64 dynamic capture iterations
This is considered small number of iterations, but for this RAK, it allows for a
short simulation time. In real designs, this number can be 6400 or higher. It
depends on factors such as how much time you want to run LBIST, the length of
the scan channels (compression), and the scan frequency.
• -capture_window_capture_value 5 -
capture_window_launch_value 7: This identifies when the release and
capture dynamic pulse should occur
This is a counter that goes from N->1. Therefore, the launch number is larger
than the capture. In this example, there will be one BIST oscillator between the
launch and the capture or a 50% dynamic clocking.
• LBIST will use the test signal specified with the lbist_test_enable function
to put the LBIST logic under test. If this test signal is not specified, you must
specify -dont_scan_lbist_flops to not test LBIST.
• Test clock specified with the dft_clock function will be used to scan LBIST
flops.
One difference between Direct Access LBIST and JTAG LBIST is that there is no
SETBIST or the ability to change LBIST execution options in the hardware. Options
specified with the LBIST insert command are the only LBIST configurations
allowed with the Direct Access LBIST.
5. The last key LBIST item is generating the LBIST testbench environment. This
command will generate assign files and scripts to process the design through
Modus.
write_dft_lbist_testbench -tcl \
-run_from_directory \
-library $vars(INSTALL_DIR)/LIBS/atpg/include_libraries.v \
-ncsim_library
$vars(INSTALL_DIR)/LIBS/verilog/include_libraries_sim_atpg.v \
-directory $vars(_OUTPUT_PATH_TEST)/lbist
Running Modus
1. For detailed information on LBIST scripts, setup files, and execution, refer to
Appendix A and Appendix C. The following commands will generate LBIST
signatures and fault coverage:
➢ cd lab2_direct_lbist/modus_test/lbist
➢ modus –f run_lbist_DIRECT
2. With direct access, the testbench for the simulation and the hardware need to be
generated as a separate step. This is done using:
➢ modus –f run_dft_NCSIM
➢ cd lab2_direct_lbist/modus_test/atpg
➢ modus –f runmodus.atpg.tcl
Running Simulation
Before simulation can be run, add the LBIST signature to the Verilog file. For information
on how to modify the Verilog file, refer to Appendix C: Modus Direct Access LBIST. Here
is a quick summary:
You must add this to the main Verilog file, removing the existing unconnected nets.
After that, you can run the simulation:
➢ ./run_sim_DIRECT
Running Conformal
➢ lec -nogui -xl -tclmode
lab2_direct_lbist/results_syn/lec/fv_map2final.lec.tcl
Lab 2 Summary
You ran through the Genus flow to insert direct access LBIST into a design.
Subsequently, you generated the signature, stored it in the Verilog netlist, and verified it
in the simulation. For more information on the flow specifics, read comments in the
.tcl files in the SCRIPTS directory.
Running Synthesis
Run the following script from the GENUS-MODUS-LBIST_RAK_20.10 directory:
1. The first difference in processing between Lab 1 and Lab 3 is that in Lab 3 test point
analysis is done for the design (the SCRIPTS/LBIST/analyze_lbist_tpi.tcl
file).
add_lbist_test_points \
-library LIBS/atpg/include_libraries_asc.v \
-directory $vars(_OUTPUT_PATH_DFT)/LBIST_TPI \
-verbose -max_number_of_test_points 0 \
-lbist_testpoints_options "-randpatterns 64 -maxtestpts
300"
The above command will call Modus Test under the coverage and analyze the
design for random resistant logic (logic that is not easily tested by random patterns).
Key options used are:
2. The next step is to insert the test points. As mentioned above, it can all be done in a
single step, but it is broken up to allow potential editing of the test points (the
SCRIPTS/LBIST/add_tpi.tcl file).
add_lbist_test_points \
-input_test_point_file
$vars(_OUTPUT_PATH_DFT)/LBIST_TPI/expt.rrfa.tpfile \
-verbose
The key difference will be when the final coverage and signatures are reported. With
test points, the coverage will see an increase.
With TPI:
Running Modus
1. For details on LBIST scripts, setup files, and execution, refer to Appendix A and
Appendix B.
➢ cd lab3_tpi_lbist/modus_test/lbist
➢ modus –f run_lbist_RUNBIST
2. Steps for ATPG and Boundary Scan Verification are given below.
➢ cd lab3_tpi_lbist/modus_test/bsv
➢ modus –f runmodus.bsv.tcl
➢ cd lab3_tpi_lbist/modus_test/atpg
➢ modus –f runmodus.atpg.tcl
Running Simulation
1. Once LBIST signatures and Verilog testbench have been generated, it is time to
validate the results using the simulation. As part of Genus LBIST testbench
generation, the xrun script has been generated.
➢ ./run_sim_RUNBIST
2. For the Boundary Scan Verification simulation, you will need to update the mainsim
file to set up an oscillator on the main refclk.
always begin
#0;
osc_49 = 0;
#5000.000000; // 5000.000000 ps; From the start of the
cycle.
osc_49 = 1;
#5000.000000; // 10000.000000 ps; From the start of the
cycle.
end
Running Conformal
Lab 3 Summary
This Lab highlighted steps to identify and insert test points to help improve the LBIST
test coverage.
Running Synthesis
Run the following script from the GENUS-MODUS-LBIST_RAK_20.10 directory:
The OPCG solution supports multiple oscillator sources and clock domains,
programmable domain macros, and optional clock dividers. Programmable features
include the number of at-speed pulses to generate and the ability to delay the
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 28
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
The LBIST environment is able to use the OPCG domain macros to allow an at-speed
OPCG clocking. You must be careful while doing this as there can be no X-sources
generated due to timing races. All paths must meet the frequency being targeted by
OPCG; otherwise, incorrect signatures will be generated.
Changes to the flow for the steps seen in Lab 1 are given below. Key steps to add
OPCG LBIST are as follows:
1. As before, RUNBIST and SETBIST instructions must be defined to the JTAG macro.
For OPCG, the instruction shown below needs to be defined. This instruction will
allow for the OPCG logic to be programmed before LBIST is started (the
SCRIPTS/JTAG/define_jtag.tcl file).
This attribute must be false; otherwise, Genus will consider the reference clock
specified in the osc_source specification as a test clock, which will cause the OPCG
insertion to fail.
3. You can now start defining OPCG structures. The structure definitions
(define_opcg commands) are in a specific order, based on dependencies. You will
notice this in some of the keywords used for the commands. These are defined in
SCRIPTS/OPCG/define_OPCG.tcl.
c) Next, you will define the OSC sources. This includes defining and specifying the
main reference clock, the free running PLL clocks, and the input and output
period ranges of the PLL. Two OSC sources are running in each core, with the
slower one running at half the speed. Only one of the four cores is shown here.
d) You will now define the Trigger Macro, which supplies signals to domain macros
for resetting and running.
e) Next, you will define the parameters used to build the different domain macros.
You can have a different definition for each macro or use the same definition for
all macros.
Here, you are creating two different sets of parameters. The difference between
the two sets is in the number of clock pulses that can be generated. One set can
generate up to two pulses, while the other set can generate up to four. The
counter_length aspect is interpreted as follows:
The OPCG domain waits for two counter_length number of cycles after
receiving the run signal from the trigger macro before issuing the first clock pulse.
To enable the OPCG domain to immediately issue a clock pulse on receipt of the
run signal, specify a counter length of 0.
f) Now, you can define individual domain macros. There are two macros for each
core instance, one each for the 1x and 2x domains. Core 0 is shown below:
Each domain macro specifies where the main functional clock trunk should be
intercepted using the -location switch. It also specifies which domain
parameter to design into each domain macro. The following figure depicts the
hardware with all these components:
g) The last step is to define the OPCG mode of operation. The main task here is
synching all oscillators together and defining the mode initialization sequence to
start the PLL.
4. The next step of the flow is to insert the OPCG hardware into the design. This can
be found in SCRIPTS/OPCG/add_OPCG.tcl.
add_opcg \
-opcg_enable OPCG_MODE \
-opcg_load_clock DFT_clk \
-test_enable test_mode \
-scan_clock scan_clk \
$vars(DESIGN)
}
• -scan_clock defines the signal that will shift the OPCG logic during the ATPG
FULLSCAN mode.
The resulting logic for each of the core instances should look similar to the logic
shown in the following figure:
5. The definition of the OPCG logic is the next major new addition to the flow.
6. With the flow, the following will insert the LBIST logic on top of the existing
compression network (the SCRIPTS/LBIST/add_lbist.tcl file):
add_lbist \
-lbist_clock refclk \
-lbist_clock_hookup [get_db hpin:$vars(DESIGN)/IOPADS_INST/refclkI]\
-lbist_clock_ref_period 32000 \
-lbist_clock_osc_period 32000 \
-add_masking \
-scan_patterns 8 \
-reset_patterns 8 \
-async_reset_signals "reset spi_fs” \
-set_reset_pulse_width 3 \
-set_reset_test_window 8 \
-static_patterns 64 \
-capture_window 40 \
-capture_window_capture_value 2 \
-scan_enable_delay 3 \
• -capture_window 40: This ensures that the OPCG macro has enough time to
fire all its clocks within the capture window. If this is too small, miscompares will
be seen because only a portion of the LBIST clocking will occur.
7. The last key task is to generate the LBIST testbench environment. The command
shown below will generate assign files and scripts to process the design through
Modus. There are no special options for OPCG and LBIST testbench creation (the
SCRIPTS/MISC/write_modus.tcl file).
write_dft_lbist_testbench -tcl \
-run_from_directory \
-library $vars(INSTALL_DIR)/LIBS/atpg/include_libraries.v \
-ncsim_library
$vars(INSTALL_DIR)/LIBS/verilog/include_libraries_sim_atpg.v \
-directory $vars(_OUTPUT_PATH_TEST)/lbist
Running Modus
1. For details on LBIST scripts, setup files, and execution, refer to Appendix A, B, and
D. Appendix D also has details on modifying the OPCG clocking for LBIST.
➢ cd lab4_opcg_lbist/modus_test/lbist
➢ modus –f run_lbist_RUNBIST
2. Steps for ATPG and Boundary Scan Verification are given below.
➢ cd lab4_opcg_lbist/modus_test/bsv
➢ modus –f runmodus.bsv.tcl
➢ cd lab4_opcg_lbist/modus_test/atpg
➢ modus –f runmodus.atpg.tcl
Running Simulation
1. Once LBIST signatures and Verilog testbench have been generated, it is time to
validate results using the simulation. As part of Genus LBIST testbench generation,
the xrun script has been generated.
➢ ./run_sim_RUNBIST
2. For the Boundary Scan Verification simulation, you must update the mainsim file to
set up an oscillator on the main refclk.
reg osc_49;
wire
osc_pi_49;
always begin
#0;
osc_49 = 0;
#5000.000000; // 5000.000000 ps; From the start of
the cycle.
osc_49 = 1;
#5000.000000; // 10000.000000 ps; From the start of
the cycle.
end
Running Conformal
➢ lec -nogui -xl -tclmode
lab4_opcg_lbist/results_syn/lec/fv_map2final.lec.tcl
Lab 4 Summary
You ran through the Genus flow to insert clock control logic for running the at-speed
delay test and insert LBIST controls to use it.
Files Generated
The files for LBIST processing will be generated in the
./lab#_<name>/modus_test/lbist directory.
LBIST Scripts
Examine the run_lbist_* scripts and the key output expected at each step. On
accessing the run_lbist_RUNBIST script, you will notice that this script is formatted
differently from the normal ATPG/BSV scripts. LBIST scripts are set up with the ability to
turn on/off certain steps. This applies to the majority of steps except the building of the
model. If you need to rerun some steps, it is recommended to comment out the rm
directory and build_model steps.
do_build_parent_mode 1
For LBIST processing, the tool will build two test modes: JTAG test mode and LBIST
test mode. The JTAG test mode initializes the design and loads the JTAG LBIST
instruction to allow the LBIST TDR to be scannable. This is referred to as the parent test
mode. Having the LBIST TDR scannable allows unloading and observing the MISR
through JTAG TDO.
Examine the details of building the JTAG (parent) test mode. The parent test mode uses
the TBDseqPatt.JTAG_RUNBIST, assignfile.JTAG.RUNBIST and
MODE_JTAG_RUNBIST files.
o From the Modus Test perspective, scan sequences that follow will enable the
LBIST TDR to be scannable. This will be used to export the MISR values later
in the process.
Step: Print the scan chain identified in the JTAG test mode
do_print_all_parent 1
It is important that the LBIST TDR is identified; otherwise, it will not be possible to
export the MISR expect values correctly. The above will report the scan chain reports to
ensure there are valid scan flops.
Step: do_build_child_mode 1
The test mode where LBIST signatures are generated is referred to as the child test
mode. As the name depicts, this test mode uses the JTAG test mode (parent) for the
initialization. In this mode, MISR, PRPG, and channels need to be established to allow
for the high-speed signature simulation and fault coverage calculations.
The assignfile:
• Holds the JTAG pins stable to ensure the JTAG state machine is not changed.
o This instructs Modus Test to do special processing from the end of the mode
init of the other test mode.
o If you change the JTAG/parent test mode name, the name in this file also
needs to change.
o With the SETBIST script, individual flops inside the LBIST TDR are loaded to
a value with a Scan_Load event.
• Pulses the LBIST oscillator four times to move the LBIST state machine past the
“bist_start” stage.
o During this processing, MISR and PRPG clocks are pulsed, as seen in the
waveforms in the figure given below.
o As seen in the figure given below, the pins in the waveforms are:
o The JTAG state machine is then moved to the Run-Test Idle state.
With a free-running clock, LBIST will start to take control and run to
completion.
o After moving to Run-Test Idle, the BIST oscillator will pulse the cut point six
times. This moves the LBIST state machine to a point right before scan
clocking is starting. In the waveform, four pulses are between Marker 1 and
Marker 2.
The pulse on the right side of Marker 2 is the start of the channel flush.
The LBIST mode needs to be set up before the flush state.
• This moves the Modus Test processing into a position where all cut points should
be set up and PRPG/MISRs are set to their default values.
o For RUNBIST, the PRPG will be all 1’s and MISR will be all 0’s.
o For SETBIST, the starting values will be determined by the value loaded into
the TDR.
• The Scan protocol in this file is used to establish the LBIST environment.
At this point, the LBIST test mode should be complete. MISRs, PRPGs, and channels
should be fully scannable.
do_print_all_child 0
Given some larger designs, this feature is not ON by default as it can generate a very
large file.
do_child_tsv 1
This step will run verify_test_structures on the LBIST test mode. The tool
validates:
Another key check is the X-source identification. LBIST requires a zero X-source
environment. Potential X-sources are identified by TSV-101 and TSV-102
messages. Some parent/child test mode checks (which are message limited) are
also performed by the tool.
As mentioned in Genus scripts, some logic has been added to prevent contention
on this design. In subsequent Labs, this will not be done so you can see the
messages.
do_faultmodel 1
The default signature generation will calculate the test coverage that LBIST patterns will
achieve.
do_read_testseq 1
Unlike ATPG, LBIST cannot generate just any sequence to get the coverage. LBIST
signature calculation is a simulation-based approach. The clocking used to calculate the
LBIST signature needs to be based on what the real hardware will do during the capture
window. As a result, you need to explicitly specify during the LBIST simulation how the
clocking will look like. For each Test Section that was enabled for LBIST (Scan,
Asynchronous SET/RESET, Static, or Dynamic), there will be a unique test sequence to
correspond to the capture window.
This step will read in the TestSequence.seq file. For our standard static LBIST, this is
simply a single clock pulse in the capture window.
Looking at the static capture sequence (Static_Test), the first event in the test
sequence ensures the scan enable is off:
Then, it performs the channel scan. This is similar to the Scan_Unload event for ATPG
but uses a different name when performing the LBIST.
do_testgen_fault 1
This takes the following as input: the LBIST Test mode, Test Sequences, and the
information about how long to run LBIST (number of iterations per Test Section). Then,
it performs the simulation to identify the expected signature and the coverage achieved
by it.
The number of iterations must match what is found in the LBIST hardware. When the
Modus Test scripts are created, the default RUNBIST values are specified for both the
SETBIST/RUNBIST environments. If you change the number of iterations, you need to
ensure that the RUNBIST hardware is updated to reflect the number of iterations (OR)
use SETBIST to set up the counters for the number of desired LBIST iterations.
If you enabled a scan chain test during the insertion, create_lbist_tests has -
scantestsequence Scan_Test.
When all create_lbist_tests commands have run, it will report the PRPG/MISR
values at predefined iterations (typically every 64).
The final create_lbist_tests log will also include the final coverage achieved:
During the signature calculation, if Modus Test identifies an X-source, it will issue a
TWT- 033 message. It will force a 0 value into the MISR at the location, but this is a
severe issue as any X-source will corrupt the complete MISR; thus, making it useless.
Ensure all the TWT-033 locations are debugged (use verify_test_structures
TSV-101/TSV-102, if possible) to help identify the source of the Xs.
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 44
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
do_export_verilog 1
This step will run write_vectors on the LBIST test mode. The tool will use the LBIST
and Parent test mode to process the patterns. The signatures stored in the experiment
data will be translated to the scan chain identified in the JTAG test mode. This allows
the expected signature to be written out and compared at the end of the LBIST
execution.
Now, run the LBIST Verilog simulation to verify the signatures that were calculated. To
run this script, make sure you have ncverilog in your path. If you use a different
simulator, you need to edit the run script to execute the commands and keywords for
that simulator.
➢ run_sim_RUNBIST
Observe using SETBIST to run LBIST for only two static iterations instead of 64.
➢ cd lab1_jtag_lbist/modus_test/lbist
This file contains values to program the flops during the LBIST initialization. This file is
slightly different from TBDseqPatt.LBIST_RUNBIST; it uses a Scan_Load
TBDpatt event to load values into the LBIST TDR. You can modify values in this file or
potentially use a “linehold” file to force new values on the basic counter values (does not
work for LBIST scan length or LBIST masking flop values).
In this example, modify the program counter to run only two iterations.
The current program counter should look like as shown below. In this case, the seventh
bit is set to 1, which is a binary 64. LBIST counters are made to fit the default RUNBIST
iteration count. If you want the option to run additional LBIST lengths, you can use
variables in Genus to increase the default counter sizes.
"BIST_MACRO.static_pc_reg[6].Q"=1
"BIST_MACRO.static_pc_reg[5].Q"=0
"BIST_MACRO.static_pc_reg[4].Q"=0
"BIST_MACRO.static_pc_reg[3].Q"=0
"BIST_MACRO.static_pc_reg[2].Q"=0
"BIST_MACRO.static_pc_reg[1].Q"=0
"BIST_MACRO.static_pc_reg[0].Q"=0
To reset LBIST to run only two iterations, you need to make the following changes:
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 46
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
"BIST_MACRO.static_pc_reg[6].Q"=1 to "BIST_MACRO.static_pc_reg[6].Q"=0
"BIST_MACRO.static_pc_reg[1].Q"=0 to "BIST_MACRO.static_pc_reg[1].Q"=1
This will program the hardware to run only two static LBIST iterations.
➢ edit run_lbist_SETBIST
As the design was built as part of the RUNBIST processing, you can comment out the
removal and rebuilding of the design.
##----------------------------------------------------------------------
## BUILD THE LOGIC MODEL
##----------------------------------------------------------------------
#build_model \
# -cell dtmf_chip \
# -techlib .../LBIST_v4_run/LIBS/atpg/include_libraries.v \
# -designsource $WORKDIR/dtmf_chip.test_netlist.v \
# -blackboxoutputs z \
# -allowmissingmodules yes \
As you are changing how the hardware is being programmed, you need to ensure that
Modus Test LBIST signature calculation also stops at two iterations. Go to the section
identified by:
if { $do_testgen_fault eq 1 } {
puts "Begin Fault Coverage LBIST Signature Generation"
Find the create_lbist_tests command line that uses the Static_Test sequence.
In this Lab, it is the third create_lbist_tests command line:
-testsequence Static_Test \
…
-detectInterval 64 -signatureInterval 64 \
-maxseqpatterns 64 -maxpatterns 64 \
to
-testsequence Static_Test \
…
-detectInterval 2 -signatureInterval 2 \
-maxseqpatterns 2 -maxpatterns 2 \
This instructs Modus Test to stop after two iterations. Save and close the file.
➢ modus –f run_lbist_SETBIST
After the script completes, compare the signatures calculated between RUNBIST and
SETBIST. Go to the lbist_lab1_jtag_workdir/testresults/logs directory.
Signatures are different for different number of loops, as shown below:
log_create_lbist_tests_MODE_LBIST_RUNBIST_lbist_test_RUNBIST
Cycle <64> Product MISR <1> After-Scan Signature : 757a8bab18000000
log_create_lbist_tests_MODE_LBIST_RUNBIST_lbist_test_SETBIST
Cycle <2> Product MISR <1> After-Scan Signature : ee6c02ffe8000000
Files Generated
Files for LBIST processing will be generated in the
./lab#_<name>/modus_test/lbist directory.
LBIST Scripts
Examine the run_lbist_* scripts and the key output expected at each step.
set do_faultmodel 1
set do_read_testseq 1
Learn more at Cadence Learning and Support Portal - https://support.cadence.com
© 2021 Cadence Design Systems, Inc. All rights reserved worldwide. Page 49
Genus and Modus: Logic Built-In Self-Test (LBIST): RAK
set do_testgen_fault 1
Some major differences between Direct Access LBIST and JTAG LBIST are as follows:
• In Direct Access LBIST, there is only the LBIST test mode (no parent/child test
mode). This is because in Direct Access LBIST, the macro is not scan unloaded.
• The basic run_lbist_DIRECT script follows the same basic flow as seen in Lab 1,
except that there is no exporting of Verilog. The output of the script is the signature
to be added to the netlist.
• For Direct Access LBIST, the macro is reset. This forces LBIST into an inactive state
and clears all the gating logic used by bist_running.
• After a certain period, the go_lbist (Direct Access Enable) signal goes high. This
instructs LBIST to start processing.
• At the end, the signature is compared within the hardware. If there is a signature
match, the bist_pass signal will go to 1.
1. After the Modus Test signature and processing is complete, the computed signature
needs to be added to the netlist to allow an internal MISR comparison.
You need to add the final signature-based MISR order to the main Verilog file.
Start searching from the bottom and look for the .misr_compare definition call in
bist_macro. In this case, it looks like:
You need to comment this out and add the expected MISR signature to the patterns.
Example:
.bist_pass (bist_pass),
.misr_compare(20'b01100010001000001101),
// .misr_compare ({UNCONNECTED202, UNCONNECTED201,
** Make sure you do not comment out other connections besides those that are
part of the .misr_compare bus. You just want to modify the misr_compare
bus. **
➢ modus –f run_dft_NCSIM
This will build a new test mode that only has the clock pin defined. It will read in a
TBDpatt file (TBDpatt.NCSIM) to issue the start of Direct Access. The pattern
pulses a clock for a number of times and then starts LBIST by holding the lbist-
enable pin high, as shown in the waveform in Figure 5.
3. Now, run the Verilog simulation to verify the LBIST signatures that were stored in the
Verilog.
Note: BEFORE RUNNING any of these scripts, make sure you have ncverilog in
your path. If you are using a different simulator, you need to edit the run script to
execute using the commands and keywords for that simulator.
➢ ./run_sim_DIRECT
The simulation should generate zero miscompares. As a test, you can change the
signature that was stored in the netlist (change a 0 to 1) and try to rerun. A
miscompare should be reported using an incorrect signature.
Files Generated
The files for OPCG LBIST processing are the same, but the contentions are different.
The differences are:
• TBDseqPatt.JTAG_RUNBIST/SETBIST
o The scan operation now comprises of multi-scan sections to allow both the
LBIST and OPCG registers to be scan loaded and unloaded.
• TBDseqPatt.LBIST_RUNBIST/SETBIST
o Points to the JTAG/Parent test mode by name to reference how to scan load the
OPCG flops.
This instructs Modus Test to perform special processing from the end of the
other test mode ‘mode init’.
This is a complex process and helps ensure the cut points are at the correct
value.
If you change the JTAG/Parent test mode name, you need to change the
name in this file.
o The next event does a Scan_Load of the OPCG TDR. These are the default
values that OPCG will use.
You can modify these values in the test mode or can control using the
Appendix D: Modus LBIST OPCG Customization
The default clocking is to pulse all OPCG domains at the same time
o After the OPCG is loaded, the RUNBIST instruction is loaded into the JTAG state
machine and moved to Run-Test Idle.
This applies the LBIST instruction and allows the state machine to start.
o After this, the RUNBIST instruction is loaded and the LBIST processing starts.
• TestSequence.seq
o Currently, in the OPCG LBIST flow, the tool generates a test sequence where all
OPCG clocks are overlapped. This will most likely not work in the hardware,
given the domain crossing and just the basic timing. You should update the Test
Sequence to match your OPCG programming values.
o The Static_Test sequence will use the output of the OPCG domain macros.
For Static_Test, the default is to have a dynamic OPCG clock firing. You will
have to modify this if you want static-only tests.
o The tool then pulses the capture clocks. Notice how all the release/capture
pulses are overlapped:
o The tool then has a static pulse for non-OPCG clock domains:
Waveform Analysis
The capture window in SimVision should display the following:
LBIST is not aware of the internal clock domains and their clocking relationship to one
another. Test sequences for the OPCG capture window have all release/capture clocks
occurring at the same time. If you look at the simulation waveforms, this is not the case.
The 2x clocks are pulsed prior to the 1x ones.
sequence being used. In this case, as you have two different clock speeds, you should
separate them in the Test Sequence file, as getting them to align would be difficult.
You should identify the correct clocking for your OPCG logic. The following should be
considered:
• Ensure all paths within the targeted domain will achieve OPCG clock speeds.
Waveform Modification
Currently, the static test is generating two clock pulses. You can modify the clocking to
just do static pulses.
1. Create a copy of the lbist directory before continuing to keep the original files.
➢ cp TestSequence.seq TestSequence.seq.orig
➢ cp TBDseqPatt.LBIST_RUNBIST TBDseqPatt.LBIST_RUNBIST.orig
3. Modify the Test Sequence file. Look at modifying the OPCG loading in the correct
waveform and then updating the sequences to disable some clocks.
➢ edit TestSequence.seq
#"core1_domain2x.ppi"=+
#"core1_domain1x.ppi"=+
#"core2_domain2x.ppi"=+
#"core2_domain1x.ppi"=+
#"core3_domain2x.ppi"=+
#"core3_domain1x.ppi"=+ ;
] Pattern ;
4. Modify the LBIST mode init sequences. Change the OPCG clocking to allow a single
clock pulse per clock domain.
➢ edit TBDseqPatt.LBIST_RUNBIST
a. For each OPCG domain (there are eight total), update the files as follows:
Original:
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[0].Q"=1
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[1].Q"=1
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[2].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[3].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[4].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[5].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[6].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[7].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[8].Q"=1
Modified:
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[0].Q"=1
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[1].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[2].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[3].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[4].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[5].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[6].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[7].Q"=0
"DTMF_INST0.DFT_ITC_core0_domain2x.i_opcg_pgm_reg.shift_reg_reg[8].Q"=1
5. Rerun the run_lbist_RUNBIST script (note that this will remove existing workdir
unless the delete directory / build_model processing has been commented out).
** Remember that if you change the OPCG sequence, you need to also update the
clocking to ensure it matches the real hardware. **
o To know how to program the OPCG bits, you need to refer to the clocking and
sequences generated by the prepare_opcg_sequences ATPG command.
LBIST does not have these analysis capabilities yet. Refer to the ATPG
processing steps for more information.
Both the Scan_Test and Static_Test sequences were updated with the lineholds.
Depending on how Modus Test stores the signatures and Scan information, all
sequences that are appended together in the processing should have the same linehold
information.
Looking at the new clocking, you can see that the clocking is only one pulse or a static
waveform (as programmed).
This approach allows you to manipulate the OPCG clocking to achieve the desired
waveforms. The signatures also pass because the test sequence matches the behavior
programmed into the OPCG macros.
Support
Cadence Learning and Support Portal provides access to support resources, including
an extensive knowledge base, access to software updates for Cadence products, and
the ability to interact with Cadence Customer Support. Visit
https://support.cadence.com.
Feedback
Email comments, questions, and suggestions to [email protected].