Download Synopsys Tutorial: Using DFT and TetraMax - Laboratory | ECE 128 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
ECE 128 – Synopsys Tutorial: Using DFT & TetraMax Created at GWU by Thomas Farmer
Objectives:
- Use Synopsys Design Compiler's DFT, synthesize ‘scan-cell’ test structures into verilog code
- Use Synopsys TetraMax tool, to generate test patterns (ATPG) for the 'test structures' from the Design Compiler's output
- Use Verilog to test the output of the TetraMax tool's patterns against the synthesized synopsys code
Assumptions :
- Student has completed lab 3 and has a working structural full adder
Introduction:
The ASIC design flow is as follows:
Specification▼
RTL Coding and Simulation▼
Logic Synthesis ▼
Optimization ▼
Gate Level Simulation ▼
Static Timing Analysis▼
Place and Route▼
Static Timing Analysis▼
Preliminary Netlist Handoff
In lab 3 we introduced the Synopsys Logic Synthesis tool called the Design Compiler. In this lab we will use the Design Compiler to insert test structures into our synthesized verilog code. We will then use the Synopsys TetraMAX® tool to exercise these test structures with a pattern of 1’s and 0’s. Prior to using these tools, you should be familiar with the basics of common testing methodologies used throughout the industry:
From lecture, you've learned that circuit testing falls into two main categories: functional testing & manufacturing testing:
- Functional testing verifies that a circuit performs as it was intended to perform. For example, assume you have designed an adder circuit. Functional testing verifies that this circuit performs the addition function and computes the correct results over the range of values tested. However, exhaustive testing of all possible input combinations grows exponentially as the number of inputs increases. To maintain a reasonable test time, you must focus functional test patterns on the general function and corner cases.
- Manufacturing testing verifies that the circuit does not have manufacturing defects by focusing on circuit structure rather than functional behavior. Manufacturing defects include problems such as Power or ground shorts, Open interconnect on the die due to dust particles, Short-circuited source or drain on the transistor due to metal spike-through, etc. Manufacturing defects might remain undetected by functional testing yet cause undesirable behavior during circuit operation.
In this lab, we are at these stages in the ASIC Flow
To test for possible Manufacturing Faults, we use “fault models” to organize ways of detecting these defects:
Fault Models: When a manufacturing defect occurs, the physical defect has a logical effect on the circuit behavior. An open connection can appear to float either high or low, depending on the technology. A signal shorted to power appears to be permanently high. A signal shorted to ground appears to be permanently low. Many manufacturing defects can be represented using the stuck-at fault model. Synopsys TetraMAX® actually provides more fault models than the traditional stuck-at fault. Those fault models are transition, path delay, IDDQ, and bridging.
- Stuck-at Fault Models : The stuck-at-0 model represents a signal that is permanently low regardless of the other signals that normally control the node. The stuck-at-1 model represents a signal that is permanently high regardless of the other signals that normally control the node. For example, assume that you have a two-input AND gate that has a stuck-at-0 fault on the output pin. Regardless of the logic level of the two inputs, the output is always 0. a) Preconditions for detecting Stuck-at Faults: The node of a stuck-at fault must be controllable and observable for the fault to be detected. i) A node is controllable if you can drive it to a specified logic value by setting the primary inputs to specific values. A primary input is an input that can be directly controlled in the test environment. ii) A node is observable if you can predict the response on it and propagate the fault effect to the primary outputs where you can measure the response. A primary output is an output that can be directly observed in the test environment. b) How to detect a stuck-at fault on a target node: i) Control the target node to the opposite of the stuck-at value by applying data at the primary inputs. ii) Make the node’s fault effect observable by controlling the value at all other nodes affecting the output response, so the targeted node is the active (controlling) node. This is known as path sensitization. iii) The set of logic 0s and 1s applied to the primary inputs of a design is called the input stimulus. The resulting values at the primary outputs, assuming a fault-free design, are called the expected response. The actual values measured at the primary outputs are called the output response. If the output response does not match the expected response for a given input stimulus, the input stimulus has detected the fault. (1) For example, if the faulty node is stuck-at-0, you need to apply input stimulus that forces that node to 1. For a two-input AND gate whose output node is stuck-at-0, apply a logic 1 at both inputs. The expected response for this input stimulus is logic 1, but the output response is logic
- This input stimulus detects the stuck-at-0 fault. (2) This method of determining the input stimulus to detect a fault uses the single stuck-at fault model. The single stuck-at fault model assumes that only one node is faulty and that all other nodes in the circuit are good. The single stuck-at fault model greatly reduces the complexity of fault modeling and is technology independent, enabling the use of algorithmic pattern generation techniques.
- Transition Fault Model : The transition delay fault model is used to generate test patterns to detect single- node slow-to-rise and slow-to-fall faults. For this model, TetraMAX launches a logical transition upon completion of a scan load operation and uses a capture clock procedure to observe the transition results.
- Path Delay Fault Model : The path delay fault model tests and characterizes critical timing paths in a design. Path delay fault tests exercise the critical paths at-speed (the full operating speed of the chip) to detect whether the path is too slow because of manufacturing defects or variations.
- IDDQ Fault Model : The IDDQ fault model assumes that a circuit defect will cause excessive current drain due to an internal short circuit from a node to ground or to a power supply. For this model, TetraMAX does not attempt to observe the logical results at the device outputs. Instead, it tries to toggle as many nodes as possible into both states while avoiding conditions that violate quiescence, so that defects can be detected by the excessive current drain that they cause.
- Bridging Fault Model : The bridging fault model tests for shorts between two normally unconnected instance pins or net names. This model reports candidate defects as types bridging fault at 0 (ba0) or bridging fault at 1 (ba1), and victim and aggressor node sets.
In this lab, we will use Synopsys tools to implement the Stuck-At Fault model with your Verilog code. But if you’d like to understand in greater detail about the concepts discussed above, read pages: “A-1 through A-14” in the TetraMax User Guide posted on the VLSI website.
Part III: Creating Test Patterns for Purely Combinational Code:
Overview of Part III:
We will use synopsys design compiler, synopsys tetramax, and verilog to do the following:
- Use Synopsys Design Compiler to synthesize the full adder to AMI .5 technology
- Use Synopsys TetraMAX’s ATPG program to create ‘test patterns’ to determine all ‘stuck-at-faults’ in our synthesized AMI .5 full adder circuit
- Use Verilog to run the 'test patterns' against our synthesized AMI .5 full adder circuit
Note: Before ever attempting to “synthesize” verilog code, you must ensure that it compiles properly (using the verilog simulator) and its waveforms are as you expect (using simvision). Only after the code passes the simulation phase can you move on to the synthesis phase of the ASIC design flow.
Synthesizing the Full Adder using Synopsys Design Compiler:
- In a terminal window, login to hobbes
ssh -X hobbes (accept any warnings, and type in your seas pw when prompted)
Note: For the spring 09 semester, Synopsys tools are only available on hobbes, in future semesters this step may not be necessary
- Change to your working directory
cd ~/ece128/lab
- Start the design compiler's GUI by typing
design_vision (note: do NOT put an “&” after this command, it needs to run in the foreground)
- Run the design compiler script to synthesize your code automatically into AMI .5 technology:
From the menu, choose: File->Execute Script
Browse for the file named: dc_syn.scr (it should be in the lab4 directory)
What this script does is all of the things we did in lab3 automatically:
- It analyzes and elaborates your verilog code
- It sets up a ‘reference clock of 25MHz’ and sets up constraints on the input and output pins
- It then compiles the design with the constraints and synthesizes your design using AMI .5 gates
- It saves the synthesized design in verilog code format
- It writes out reports discussing the progress of the synthesis
- Scroll back up in the design vision’s log window for error messages that occurred during synthesis:
- If any errors occurred, you must go back and solve the problems before continuing to the next step (perhaps it couldn’t find your verilog file, things like this will cause synthesis to fail)
- Once you have a successful synthesis, exit the Design Vision GUI
- Inspect the ‘reports’ generated during the synthesis
- Go into the lab4/reports sub-directory and you will find a list of reports like this:
$ cd ../reports $ ls –al total 512 drwxr-xr-x 2 tfarmer user 2048 Feb 23 09:. drwxr-xr-x 6 tfarmer user 2048 Feb 23 11: .. -rwxr-xr-x 1 tfarmer user 2036 Feb 23 11:27 report.area -rwxr-xr-x 1 tfarmer user 1441 Feb 23 11:27 report.design -rwxr-xr-x 1 tfarmer user 1702 Feb 23 11:27 report.nets -rwxr-xr-x 1 tfarmer user 2964 Feb 23 11:27 report.ports -rwxr-xr-x 1 tfarmer user 859 Feb 23 11:27 report.power -rwxr-xr-x 1 tfarmer user 2040 Feb 23 11:27 report.timing
- Use a text editor (like gedit) to open up each report. As an example, this is what the ‘report.area’ file should contain:
Report : area Design : fulladder Version: B-2008.09-SP Date : Mon Feb 23 11:27:12 2009
Library(s) Used: osu05_stdcells (File: /apps/design_kits/osu_stdcells_v2p7/synopsys/lib/ami05/osu05_stdcells.db) Number of ports: 5 Number of nets: 14 Number of cells: 9 Number of references: 4 Combinational area: 2736. Noncombinational area: 0. Net Interconnect area: undefined (No wire load specified) Total cell area: 2736. Total area: undefined
- This indicates the total area required to synthesize the full adder in AMI .5 is: 2736um^2
- Look through each report (design, nets, ports, power, timing) to ensure that your design was properly synthesized and met the ‘constraints’ (e.g. – like the clock speed) you setup during synthesis
- If the design did not properly synthesize, you must fix these problems before moving onto the next step
- To show that you’ve completed this section of the lab, from the reports, fill in the answers below regarding the full adder, print this page, and hand it in to your GTA before next lab:
- How much area did each HALF ADDER consume? __________________
- Does the full adder’s total area (2736um2) include the wiring? Y/N
- What temperature and voltage are used during the synthesis? __________________
- How many NETs are in the design? __________________
- What was the fanout load set on the cout port? __________________
- What was the total dynamic power estimated for the fulladder? __________________
- What was the actual time (not required) for data to pass from port A to port COUT? _________________ (hint, time cannot be ‘negative’)
- Load the AMI .5 standard cell verilog library:
- Click on the “ NETLIST ” button at the top of the screen
- Browse for file: osu05_stdcells.v (in your src directory):
- Click on the “Library Modules” check box, to indicate that this is a ‘library’
- Click on RUN
- Load your Synthesized full adder:
- Again click on the “ NETLIST ” button at the top of the screen
- Browse for the file: fulladder_syn.v (in your src directory)
- UNCHECK the “Library modules” check box, as this is not a library file, it is your design
- Click on RUN
- BUILD the Full Adder:
- Click on the “ BUILD ” button at the top of the screen
- Ensure that the ‘top module’ in the dialog box, matches your top module name: fulladder
- Once you have a successful ‘build’ notice that the prompt at the bottom switches to DRC mode:
- DRC the Full Adder:
- Click on the “ DRC ” button at the top of the screen
- Accept the defaults an click on the “RUN” button
- This Design Rule Check (DRC) is not the same as a ‘DRC’ in cadence. It is checking to see if your design is in fact valid “Testable” code
- If there are NO DRC errors, then you will successfully be moved into TEST mode.
- Generate the Test Patterns for the Full Adder:
- Click on the “ATPG” button at the top of the screen (stands for ‘automatic test pattern generation’)
- Check the ‘add all faults’ check box at the bottom of the window
- Ensure the ‘stuck’ at fault model is checked
- Click the ‘Basic scan’ button
- Read the generated report & notice three things: o There are 64 possible stuck-at-faults o 100 % of the stuck-at-faults can be tested using the ATPG patterns TetraMax has made o TetraMax has generated 6 test patterns to test all of the possible stuck-at faults in your full adder
- View the 6 patterns TetraMax has generated (with the ATPG basic scan algorithm)
- Click on the ‘ Schematic View’ icon at the top of the screen
- Click on the ‘ Show’ icon that appears in the schematic view window, scroll down and select: ALL
- Click on the ‘ Setup’ o Set the Pin Data Type to: “PATTERN” o Set the Pattern No. to: “0”, click OK
- Click on the ‘Zoom Full’ button and see the schematic:
- You will see a schematic of your full-adder with Pattern #0 (of the 6), showing you what input is at the input PINS and what ‘good-non-faulted’ data should be at the output PINS.
- You can change the ‘ Setup’ to show the 5 other patterns and their expected data
Uncollapsed Stuck Fault Summary Report
fault class code #faults
Detected DT 64 Possibly detected PT 0 Undetectable UD 0 ATPG untestable AU 0 Not detected ND 0
total faults 64 test coverage 100.00 %
Pattern Summary Report
#internal patterns 6 #basic_scan patterns 6
- Notice the 6 patterns are at the bottom of the verilog code
- Go to the very bottom of the code
- Right before the “end module” statement, add the following lines of verilog:
initial begin $shm_open ("shm_atpg.db") ; $shm_probe("AS") ; $shm_save ; end
- This code makes it so the TetraMax test bench will generate simvision waveforms
- Once you’ve save the file, type the following:
verilog osu05_stdcells.v fulladder_tb_patterns.v fulladder_syn.v
- After the run, open up simvision and view the waveforms in the ‘ shm_atpg.db’ directory
- Send the waveforms from the “DUT” sub-module to the waveform viewer
- Send the waveforms from the “DUT” sub-module to the waveform viewer
- Once the waveform view opens, delete the n1-n6 signals, and the wire1-3 signals
- You should see 6 different values for a, b, cin , does cout & s look correct for the full adder?
- To show that you’ve completed this section of the lab, fill in the answers below regarding the full adder, print this page, and hand it in to your GTA before next lab:
- How many inputs combinations are possible for a fulladder? __________________
- How many input combinations did TetraMAX create? __________________
- Why do you think TetraMAX didn’t create all possible input combos? _________________ ( Hint: think of what these patterns are meant to test)
- List all the patterns and their expected outputs that TetraMax generated:
- Draw the schematic from TetraMax, for the stuck-at-1 fault model for pattern #4, for the fulladder; what gate is pattern #4 actually testing?
Part IV: Creating Test Patterns for Sequential Code:
Background
What is design-for-test (DFT) and what is a scan-chain?
In Part III of the tutorial, our full adder had not sequential components (no flip/flops or latches, i.e. –no state) and was a very small design in terms of gate count. Once a design becomes extremely large (many thousands of gates), gates may no longer be ‘observable’ or ‘controllable’ from a primary input and output pins. So the “stuck- at” model will not work. A technique known as ‘design for test’ has been developed in the industry to work around this problem and extend the “stuck-at” fault model.
If a design contains sequential components (like flip/flops), the design compiler can be used to replace these components with what is known as ‘scan-cells.’ A common example is replacing a d-flop-flop with a multiplexed- flip-flop (a flip flop with a MUX in front of it). A multiplexed input allows us to load test data into a flip/flop as opposed the regular data, simply by using the ‘select line’ of the mux. When the select is low, the normal data that was meant to go into the flip-flop passes through to Q, but when the select is high, test data propagates through the flip-flop to the Q output.
By replacing all of the flip-flops in a large design (assuming there are flip-flops throughout the design) with multiplexed flip-flops (scan-cells), we can increase the observability/controllability of all the non-sequential logic throughout the chip. The ‘test data-input’ and the ‘select’ lines of the scan-cells are wired to input pins; this creates what is known as a scan-chain. Now the user can put the chip into ‘scan-mode’ and load data into all the scan-cells. One can think of all the flip-flops in the design as having been stitched together into a giant ‘shift- register’ allowing data to be inputted in at 1 pin (serially) and being able to move test data all over the chip, making the non-sequential portions of the design more observable/controllable then they were before.
Overview of Part IV:
We will use Synopsys Design Vision to automatically insert multiplexed flip/flops into our synthesized design and to interconnect them into scan-chains. Then we will use TetraMax to generate the patterns that will test the scan-chains in our design. Finally we will export the patterns to a verilog test bench and use it to test the scan- chains inserted into our synthesized design. If you wish to understand in greater depth the idea of a scan-chain (including multiple scan-chains), see the TetraMax user’s guide, pages A7-A11.
Inserting the Test Structures:
- Change your setup:
- From the menu, choose: File->Setup
- Add “lsi_10k.db” to the target library list as shown below, then press OK
- Copy & Paste the following commands into the Design_Vision Prompt:
Setup variables for testing
set test_default_delay 0 set test_default_bidir_delay 0 set test_default_strobe 40 set test_default_period 100
set test_default_scan_style multiplexed_flip_flop set_scan_configuration
#Define clocks and asynchronous set and reset signals in your design create_test_protocol -infer_clock -infer_async
#Check test design rules in the RTL source file dft_drc
replace all of the flip-flops with scan flip-flops
compile -scan
tells user if by replacing flip flops with scan ffs, if you violaged any
constraints we previously setup
report_constraint -all_violators
test design rules, according to the scan style you chose
dft_drc
- If the ‘design violation browser’ appears, simply close that window.
- The commands above setup some timing information for the design for test (DFT), but most importantly, the ‘compile -scan’ command replaced all the DFF’s in your ripple-carry adder with Multiplexed DFF’s.
- Open up the schematic window and see what has happened to all of your DFFs.
- Notice the extra ports on all the DFFs:
- Building Scan Chains
- At this point, we have all of the scan-cells inserted into our design, but they are not wired together into a scan-chain. You can see that the “TE” or ‘test-enable’ pin and ‘TI” or ‘test-input’ pins are grounded.
- Copy & Paste the following commands into the design_vision Prompt, to create the scan-chains
connects all scan-enabled ff's together into scan-chain
note, it creates two new ports: test_si & test_se
insert_dft
set drive strength of the test ports to 2 (so it isn't assumed to be infinite)
set_drive 2 test_si set_drive 2 test_se
since you've already inserted scan-ff's, we don't want that to happen again,
when we run insert_dft
set_scan_configuration -replace false
run insert_scan again to set drive-strength constraints
insert_dft
report any constraints that may have been violated by inserting the test
structures
report_constraint -all_violators report_constraint -all_violators > ./reports/report.test.violations
dft_drc dft_drc > ./reports/report.test.drc
report_scan_path -view existing -chain all report_scan_path -view existing -chain all > ./reports/report.test.scanchain
write -hierarchy -format verilog -output src/${top_module}_wscan.v
- close the violation browser
- check for errors, if none, close Design Vision
- Inspect the reports
- In the ‘reports’ directory, three new reports: report.test.violations, report.test.drc, reports.test.scanchain have been created. Check them to see if any errors have occurred
- A new verilog file has been created in the “src” directory, called: “ripplecarry4_clk_wscan.v”
- It contains our ripple_carry_adder synthesized into AMI .5, but with a scan-chain inserted into it
- We will now use this synthesized code in TetraMax to generate patterns for it
- Generate the Test Patterns for the Full Adder:
- Click on the “ATPG” button at the top of the screen (stands for ‘automatic test pattern generation’)
- Check the ‘add all faults’ check box at the bottom of the window
- Ensure the ‘stuck’ at fault model is checked
- Click on “Enable Full Seq ATPG”
- Change the capture cycles to 9
- Next, click on the Full Sequential Settings Tab o Set the merge effort = low
- Click on “Full-Sequential” to generate the patterns
- Read the generated report & notice the # of faults possible, % of coverage:
- View the patterns TetraMax has generated (with the ATPG basic scan algorithm)
- Use the same technique as you did in the last portion of the lab to show the faults
- View the results of a possible stuck-at-fault:
- Write out the test patterns to a verilog file
- Click on the “Write Pat.” Button on the top of the TetraMAX window
- For the Pattern File Name type: ./src/ripplecarry4_clk_tb_patterns.v
- For the File Format , select: Verilog-Single File
- Press OK
- Test the patterns out against your Synthesized full adder
- Close TetraMax
- Now, on a local workstation (NOT HOBBES) type:
cd ~/ece128/lab4/src verilog osu05_stdcells.v class.v ripplecarry4_clk_tb_patterns.v ripplecarry4_clk_wscan.v
- To show that you’ve completed this section of the lab, fill in the answers below regarding the ripple carry adder, print this page, and hand it in to your GTA before next lab:
- How many inputs combinations are possible for a ripple carry adder? __________________
- How many input combinations did TetraMAX create? __________________
- What % coverage did TetraMax obtain with the generated patterns? __________________
- Why do you think it was not 100%?
References
- University of Minnesota ECE Department Web Publication: http://mountains.ece.umn.edu/~sobelman/courses/ee5327/Synlab6_S08.pdf
- Synopsys TetraMAX® ATPG User Guide, Version B-2008.09-SP2, December 2008
- Synopsys DFT Compiler User Guide: Scan, Version B-2008.09-SP2, December 2008
Appendix:
For students viewing this tutorial who do not have access to our server, this is a listing of the contents of the files reference in Part II of this tutorial:
.synopsys_dc.setup:
set search_path [list. ${search_path} /apps/design_kits/osu_stdcells_v2p7/synopsys/lib/ami05 "./src" "./db"] set target_library osu05_stdcells.db set link_library { * osu05_stdcells.db } define_design_lib work -path work;
dc_syn.scr:
############################################################
local variables, designer must change these values
############################################################
variables student must set to synthesize their verilog code:
set top_module fulladder set verilog_files [list ./src/fulladder.v ./src/halfadder.v]
##############################################################
read in, link to standard cells, and uniquify design
##############################################################
remove any other designs from design compiler's memory
remove_design -all
analyzer & elaborate verilog source files
analyze -library WORK -format verilog $verilog_files elaborate $top_module -architecture verilog -library DEFAULT
set design to 'highest' module level
current_design $top_module
link to standard cell libraries
link
make all instances unique
Uniquify ####################################################
setup clock & all input/output constraints
####################################################
create clk with 40ns period, 50% duty cycle (25MHz), and .3ns latency
for combinational designs, with no clk pin:
create_clock -period 40 -waveform {0 20} -name clk
for sequential designs with pin named clk:
#create_clock clk -period 40 -waveform {0 20}
set_clock_latency 0.3 clk
set delays on all inputs & outputs with respect to the clock (in ns)
