EEE600 VLSI Design Verification and Test

Winter 2012-12

Lab Assignment II Tools: Cadence Encounter Test and Diagnosis Cadence Incisive Unified Simulator
Step-by-step Tutorials to perform Lab assignment -2

Objective: The following labs are designed to help educate DFT knowledgeable engineers on the concepts and flows for Encounter Test.

The following labs assume that paths to Encounter Test and IUS (ncverilog) software have been added to your environment path. First off, lets make sure you are pointing to the software and know how to bring it up in different modes. - Typing in which et should point to the local install of the code. If this is not the case, the following labs will not work. - You also need to make sure that you are pointing to the IUS version of ncverilog for later labs. Type in which ncverilog and make sure it does not point to the encounter test area. How to bring up and execute Encounter Test: - To bring up the ET GUI directly type: et gui & or simply et & - To bring up the ET environment in command-line mode type: et f c The c puts you into the ET command line. The f command tells the interpreter to not execute the users .cshrc in a csh environment. - To bring up the ET tchl environment type: et tcl - You can force the tool to use 32/64 bit machine code by using the -32 and 64 switches. - You can also send an Encounter Test command to the command line environment and still stay in your normal command shell by typing: et e et_command For example et e build_model .... This is great for shell scripting. - To see a list of all options for a specific command type: et et_command H This help switch brings up a man page of all the available switches for this command. et et_command h brings up a subset of the more commonly used switches for this command. - To bring up the new Cadence Help systems (cdnshelp), just type in the following command: <your_et_install_path>/tools/cdnshelp/bin/cdnshelp

Lab 1 Learn the Encounter Test Flow

Primary Objective: Steps: Learn how to use the GUI/Pull down menus to process a basic design. Learn the basic Encounter Test flow. (build_model, build_testmode and verify_test_structures) Go to lab directory : JumpStart_LABS/LAB1 Launch Encounter Test GUI : et & Create New Project (This step registers this project and allows you to bring up this design from any directory with the GUI). o File -> New (or the white paper icon on the upper left side) o Working Directory = <path>/JumpStart_LABS/LAB1 (should be filled in for you) o Name LAB1 (This can be anything and will be a unique name for this particular project) o Setup and Methodology are blank. If you click on the methodology tab you will see a number of default methodologies for your use. These are not needed for this exercise since we will be running our commands and flow from the pull down menus. The setup file is usually used for project-wide setup. o Click OK to create a new porject Build Model This step will read in your netlist and libraries and compile them into an Encounter Test binary model to be used for all future steps. o Verification -> Build Models -> Model o Design Source : DLX_TOP.v (Click on DLX_TOP.v to add to the Design Source pane) o Cell Name : DLX_TOP (The top module name of your design) o Setup library technology paths Defined in Setup Window. This Setup window can be accessed from most Forms or from the Tools Icon in the upper left side of the GUI. The libraries you need to add are in ../TECHLIB/*.v Click each file to be added Notice when you click on a directory/file it adds it to the path. When you double-click on the folder icon it navigates to that directory. Click Update Project to save your edits. This will bring you back to the Build Model form o Click Run o Click on the Tasks Tab to see the running progress of your command. If you click on any command in the Task Pane you can look at its log file in the Log Tab.

o Once finished, check the log file for Severe Warning or Error level messages. If these occur, you need to verify if they are ok or not. What are the TEI-110 messages? If you click on one of the Warnings in the Log file output (Log Tab), what information is shown in the Session Log? o Also notice that when you select a command in the Task Pane, that the Form tab matches what was run in that step. You can rerun that step by clicking the Run tab in the Form. Build Fault Model This step takes the model created in the previous step and applies a fault model to the circuit by placing faults on the appropriate nodes. o Verification -> Build Models -> Fault Model o Radio buttons allow you to turn on/off Dynamic Faults. If selected the tool will apply the static and dynamic fault model to the circuit. For this lab it doesnt make a difference. o You can also tell the tool to apply faults at the Cell boundaries. For this lab you should select Fault Cell Boundary only. o Click Run o The log file contains information about the number of faults. How many Static Faults are there in the entire design? Next we want to build the test view of our circuit. We need to tell the tool what the different test pins are and their associated functions. For this circuit we have the following test pins. o Information 16 Scan Ins : DLX_CHIPTOP_DATA[15:0] 16 Scan Outs : DLX_CHIPTOP_DATA[31:16] Scan Enables : DLX_CHIPTOP_SE (Active high asserted(enable)) DLX_CHIPTOP_RESET2 (Active low asserted) o You can treat a reset as a scan enable to test more faults on the reset line. o This means during shift it will be set to its deasserted (1) value but can change during capture if the tool desires. Test Enables : (Tied to 1) DLX_CHIPTOP_TEST_ENABLE DLX_CHIPTOP_TCK Test Enables: (Tied to 0) DLX_CHIPTOP_TDI DLX_CHIPTOP_TMS DLX_CHIPTOP_TRST Clocks used for Shift and Capture : DLX_CHIPTOP_TEST_CLOCK (Off state is 0)

 DLX_CHIPTOP_SYS_CLK (Off state is 0) Clocks used only for Capture : DLX_CHIPTOP_RESET (Off state is 1) o You now need to create an assign file for ET that contains the above pin information. Here are a few examples to get you started: assign pin=DLX_CHIPTOP_DATA[15] SI; assign pin=DLX_CHIPTOP_SE +SE; assign pin=DLX_CHIPTOP_TCK +TI; Please attempt to create this file first before looking at the working one. Then compare your assign file to the file DLX.working_assignfile. o Did the polarity on the test_functions match? o Was your syntax correct? o What does + in +TI mean versus +ES? Build TestMode (Creates a test view of your circuit based on the pin assignments set in the assignfile) o Verification -> Build Models -> Test Mode o Test mode name : FULLSCAN This is a default mode for an ATPG SI to SO configuration There can be multiple testmodes per design o Input pin assignment file : <your_assignfile> o Click Run o Look for any Severe Warning messages or syntax errors o How many Static faults are active in this mode? o Is this value different from the results in build_faultmodel? If so, Why? Do we have valid scan chains? o Before we run full design-rule checking, we can see if our testmode is set up properly and whether we have contiguous chains from SI to SO o Report -> Test Structures... This tells the tool to trace the scan chains from SO backwards and SI forwards Select testmode FULLSCAN in form and click Run o How many Controllable chains do we have? o How many Observable chains do we have? o A good chain in the report file would look like this: Controllable Scan Chain 1 Load Pin Index / Pin Name 43 / DLX_CHIPTOP_DATA[0] Bit Length 85 Scan Section Sequence Scan_Section_Sequence Observable Register 1 Unload Pin Index / Pin Name 50 / DLX_CHIPTOP_DATA[16] Bit Length 85 Unload pin in phase with Load Pin

Scan Section Sequence Not proven flushable

Scan_Section_Sequence

o Note that the Bit Lengths of the Controllable and Observable trace are of identical length. This means the tool traced backwards and forwards the same equal length from SI to SO and SO to SI. o A bad chain might look like this: Controllable Scan Chain 1 Load Pin Index / Pin Name 43 / DLX_CHIPTOP_DATA[0] Bit Length 42 Scan Section Sequence Scan_Section_Sequence ...line spacing between them... Observable Register 1 Unload Pin Index / Pin Name 50 / DLX_CHIPTOP_DATA[16] Bit Length 12 Unload pin in phase with Load Pin Scan Section Sequence Scan_Section_Sequence Not proven flushable o Note the Bit Lengths are different. When the log file prints out they will also not be listed together. This is because the tool does not know they are supposed to belong to the same scan chain. This will be more evident in LAB2 when we have broken chains. o Just as a note for future reference. When you get into compression structures the format is a bit different. You will have multiple Control Reg points feeding to multiple Observer Reg points. Verify Test Structures (Design rule checking) o Verification -> Verify -> Test Structures o Test mode name : FULLSCAN Click on Scan Chain Identification. If you found a chain broken in the previous step, this will give you more debug information. The rest of the options can be left at default. If you click on the Tests Tab you can see some of the default settings and the type of checks the tool is running. o Click Run o Informational message TSV-381 identifies how many complete scan chains were found. o Informational messages TSV-384 and TSV-385 will identify chains that are broken, which you will see in Lab 2.

o Look for any Severe Warning or Error messages in the Message Summary section of the log file. If these occur, you need to verify that you understand them and handle each one appropriately. o Do you have any TSV-390 messages? o If so, how can you get a listing of all the floating/non-scan flops? (hint report_test_structures ...go ahead and try it) You have now taken your circuit through the build and verify process. It is now ready for vector generation. Go ahead and close down the GUI by clicking the X in the upper righthand side of the GUI or by selecting File -> Exit...

Lab 2 How to Debug Broken Scan Chains

Primary Objective: Learn how to run commands outside of the GUI Learn how to use the Circuit Display to debug design rule violations found in verify_test_structures

Steps: Go to the lab directory : JumpStart_LABS/LAB2 Take a look at the file run_ET_flow o This is a command line file that executes build_model, build_testmode, report_test_structures and verify_test_structures. The same flow you did in LAB1. o Notice the syntax of the commands. o Each command has et e in front of it. This is a way of sending the command to the Encounter Test shell. We will look at more automated scripts later in LAB4 Run the script o Type ./run_ET_flow to run the script o The script sets your current directory ./ as your working directory o The command file execution will go to STDIN. The resultant log files all go to the ./testresults/logs directory o All binary design data goes into the ./tbdata directory o Wait for the script to finish and then continue Launch Encounter Test GUI : et & o If you launch at the directory level that contains tbdata and testresults then all of the design data and log file info will be loaded into the GUI. Click on the Tasks Tab o This will show the commands that were run. Click on the report_test_structures run o Take a look at the log file and scan chain report. o Are any of the chains broken? o How can you tell? (Compare lengths to LAB1). Click on the verify_test_structures run o The Forms Tab will be filled in with information about the run o By selecting the command that was run in the Task Tab, you are also setting the Context of the circuit. This is important when you bring up the Schematic debug window. Why is this important? o You can see what the context is by clicking on the Arrow/Pencil icon in the upper right had corner of the GUI or the pulldown menu Window -> Analysis Context. What Testmode are you in?

Click on the Log Tab o This loads the log file that is in testresults/logs. o Notice the messages are color-coded according to severity. Use the Message Summary section on the left to find TSV-385 messages o This message indicates that there are 7 observable scan chains that are not controllable. o Message TSV-384 indicated controllable scan chains that are not observable. These messages mean the chains are not complete o If you click on the Blue message number it will give you information in a pop-up window. o Since we know something is broken we need to debug it. o It is easier to debug observable scan chains that are not controllable because when tracing back in logic, there are usually less choices in logic than tracing forward. Debug of Broken Scan Chains o Log messages are linked to the Circuit debug environment o Click on the Messages Tab o You will see an icon (View Messages Icon) that will link to the error messages if you click on it. This same icon exists at the top of the GUI in the center. Click on the View Messages Icon The Verify Test Structure Message Summary window opens up. o For this lab we will just be debugging the Observable chains that are not controllable (TSV-385). Click on the WARNING (TSV-385) Messages Click View o This will bring up the 7 individual instances of the message. This means there are 7 broken chains. Select the first message, (DLX_CHIPTOP_DATA[16]) and Click Analyze o This will bring up the Schematic analysis window o For this type of Message, the schematic will navigate to the last GOOD cell it encountered in the analysis. At this time it is best to customize some of the default setting of the Schematic window. These options change the information that you see in the different context windows. First lets customize what we see in the Block Information window we see on the right-hand side. o Pulldown menu Options -> Information Window Expand the window to see everything o The left side of the window has the options currently displayed o The right side has the items to add to the display o Recommended Items to Add if not already added Function: Scan Path Data o Shows whether pins are a part of the scan chain Function: Flop/Latch Scan Data

o Shows the flop scan bit position Function: Clock Affiliation Shows Clock information on pins Values: Possible Value Set Shows the values a pin can attain o Click OK to apply Next lets customize the way the nets/ pins are displayed. o Pulldown menu Options -> Circuit Display Select Pin Tab and click on Show All Pins. This will show all the pins on a cell instead of collapsing them Click OK to apply Now lets customize some of the circuit tracing options . o Pulldown menu Options -> Circuit Tracing Scroll to bottom of window Set Minimum Hierarchical Level When Tracing to Cell What do you think the three columns Trace, Probe and Path control? What do you think the number 1 under the Trace column controls? How about the blank boxes for the other two columns? Click Apply and Save and then Close One final setting to change. o Pulldown menu Options -> Simulate o Select Enable Simulation of Latches and Click OK o This will allow the internal simulator to propagate values through sequential elements during debug o Each of the 7 broken chains has a different cause of why the scan chain is broken. For the rest of this lab identify why each chain is broken. OK. Lets debug this broken scan chain. As stated earlier, the schematic comes up to the last good register. The current view you will see is the ET primitive of the library cell. We want to see just the library cell view. o You will see a number of white rectangles around the cell. Each of these represents a level of hierarchy. Mouse over each and see what changes in the Block Information window o What is the Cell Name of the innermost white rectangle? o How about the next one further out? o You should see a cell name of SDFFRX1. This is the library cell, which is the view we want to see. o Left-click on the white rectangle representing the SDFFRX1 cell. o Now right-click on the rectangle and select Implode. This will collapse that level of hierarchy selected and you should now see the library cell SDFFRX1 in its entirety. o Select the SDFFRX1 cell and then right-click. Click Explode. Now you should see the whole scan flop cell.

 How can you easily get back to the previous circuit view? o Go back to the library cell view so we can start tracing errors. o Take a look at the values specified on the pins of the cell and compare them to what was discussed in the lecture. o Hints for tracing: Click on a pin and type b to trace backward and f to trace forward. Revisit the pulldown menu Options -> Circuit Tracing in order to control how far the tool traces backward. Pay attention to the Information Window and values in there as you mouse over different pins.

Why is Scan Out DLX_CHIPTOP_DATA[16] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[17] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[18] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[19] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[20] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[21] chain broken?

Why is Scan Out DLX_CHIPTOP_DATA[23] chain broken?

Close down the GUI after complete.

Lab 3 ATPG Vector generation

Primary Objective: Steps: Perform ATPG vector generation Write out Verilog and WGL patterns

Change directory to JumpStart_LABS. Bring up the Encounter Test GUI (et &). Use the File->Open... pulldown to bring up a project that was created in some other directory. Open the part used in LAB1. o The GUI now points to working directory of the project selected. o There is no need to re-import the design. Encounter Test has built and saved the design under your working directory. o You can continue where you left off and see all the status of commands already run. Remember the TASK pane. Click on it. Create Scan Chain integrity tests o The first tests you always create are those that do simple shifting through the scan chains. This is mainly for manufacturing debug and to insure you can shift safely from SI to SO. o ATPG -> Create Tests -> Specific Static Tests -> Scan Chain o Test mode name : FULLSCAN o Create tests experiment name : Type in scan (or name of your choosing) o The defaults for the rest of the options are fine, but lets look at the Advanced Tab for informational purposes. The Simulation Tab contains options for controlling 3state Contention, Clock Shapers and Keeper Devices. When controlling 3-state contention issues, the ATPG tool will throw out any vectors which violate the level you selected. For instance if you select Hard Contention, the tool will throw out any vectors containing Hard Contention but will allow those with Soft Contention. o Close the Advanced window by clicking OK o Click Run o The ATPG engine is now generating test patterns that test the scan chain. Take a look at the log file. Make sure there are no Severe Warnings. The top section of the log file contains all the run-time info. The next section describes Pin Information in that TestMode. Make sure these match your assignfile. What is your resultant Fault Coverage for that Testmode? How about your Global Coverage?

Why are they different? How many Test Sequences were generated? Commit Tests o This process will apply these vectors (generated for scan chain integrity) permanently against the Global Fault list. Therefore no other tests will try to go after the faults attained here. o Pulldown menu ATPG -> Commit Tests o Test mode name : FULLSCAN o Input experiment name : Type in scan (or whatever you named it) o Click Run o Make sure you get a TBD-831 message at the end. Create Logic Tests o Now we are going to create the standard Stuck-At model ATPG patterns. o Pulldown menu ATPG -> Create Tests -> Specific Static Tests > Logic o Test mode name : FULLSCAN o Create tests experiment name : logic (or name of your choosing) Notice in this step that the previous Experiment scan is no longer available. This is because we committed the vectors. o Notice the default generation efforts. o Click Run o The ATPG engine is now generating test patterns that will test the structural integrity of the design. Take a look at the log file. Why did the test start with a non-zero fault coverage? What is your resultant Fault Coverage for that Testmode? How about your Global Coverage? How many Test Sequences were generated? Create Logic Tests (top-off with higher effort) o As part of a normal methodology we would want to increase the effort level of the ATPG engine to try to attain higher Stuck-At coverage. o Click on the create_logic_tests run in the Tasks Pane. o Notice the Form Tab is populated with what was run. So we want to take this run and change the options. Since this test was not committed we do not want to reset the fault statistics for this experiment. In that case we want to unselect Overwrite existing experiment. This will send the option append=yes to the generator (mouse over check box to see commandline option help popup). This means it will take the statistics from Experiment logic and add on to it. Lets also change the Test generation effort to High. o Click Run and take a look at the log file. What fault coverage did the ATPG generator start at?

Were any tests added? Write out WGL patterns o This step is usually saved for final manufacturing patterns. These patterns would usually be the vectors you have finalized and committed. o Pulldown menu APTG -> Write Vectors o Test mode name : FULLSCAN o Vectors to write : Committed This means we will be writing out the committed vectors only, which in our case are just the scanchain tests. o Language : WGL o Click Run and review the log file. Notice the top section lists all of the timing parameters used to generate the WGL. We will see how to control these in the next section. What is your Total Cycle Count? What does this mean? o The results will be in JumpStart_LABS/LAB1/testresults/wgl Write out Verilog patterns o This step is for generating patterns for simulation verification. It can be with committed patterns or just experiments that have been run and not committed. o Pulldown menu APTG -> Write Vectors o Test mode name : FULLSCAN o Vectors to write : UnCommitted Vectors input Experiment name Select the Experiment name from the pulldown and you will see that logic is the only one available. o Language : Verilog o Notice you can select the Scan format of serial or parallel. This controls how the scan chains are loaded during simulation. Parallel load format is much faster. o Click on the Advanced/Timing tab. This is where you can control the timings of the vectors written out. The Test and Scan Timing Tabs can control Period, Strobes, Primary Input offsets , etc. o Close down the Advanced/Timing window. o Only write out the first 100 vectors Select Limit output to range of patterns: Enter 1:100 o Click Run and review the log file. o Try writing all patterns and notice the difference in the log files. o The results are in JumpStart_LABS/LAB1/testresults/verilog Close down all windows after complete.

Lab 4 Complete Flow using Automated True-Time Script

Primary Objective: Steps: Familiarize the student with the true_time use model script and tt_setup configuration file Process design from Build Model to Write Vectors

Go to lab directory : JumpStart_LABS/LAB4 You will see two files here that we want to look further at. The first file is the execution script true_time. o This file is distributed with the software release under the directory structure <install>/tools/tb/etc/tb/contrib. o This file is to be used as-is and should not be edited. The second file is the configuration file tt_setup. o This file is also distributed with the software. The file tt_setup.orig is the original release format. The file tt_setup.LAB4 is the updated configuration for this lab. Look at the differences between the two files. What testmode are we running in? What type of faultmodel is being used? What does the RESTART option mean? Run the script o Enter into the Encounter Test commandline. et f c. o Run the script as follows: ./true_time tt_setup.LAB4 and wait till completion. o The script sets your working directory to ./ o The logfiles are sent to ./testresults/logs, which will give you an indication of all of the steps that were run. o The easiest way to see the steps is to bring the design up in the GUI. Launch Encounter Test GUI : et & o By running this command from the directory above the tbdata directory, the part will automatically be loaded in the GUI Click on the Tasks Tab o This will show the commands that were run. o You can look at each one to verify that this part ran in FULLSCAN mode and with a Stuck-At model. Close down the windows after viewing the logs. Type exit <CR> at the commandline to exit out of the ET environment.

Lab 5 Vector Simulation and Debug

Primary Objective: Familiarize the student the simulation and debug environment. Understand bridging faults and how to create an Alternate Fault Model. Familiarize the student with Simvision and NCVerilog

Flow information: First make sure that the IUS (ncverilog) software is in your path and that it is before the ET software. Type which ncverilog. We will create a standard faultmodel (stuck-at) and generate tests for them. o Simulate the tests in NCsim and verify they pass. o Bring up the passing vectors in ET and trace them in the schematic viewer. Create an Alternate Faultmodel which contains only a small set of faults. o Create targeted tests for these few faults and simulate them. o Simulate the patterns against a faulty circuit and see how the tests detect the failures. o Bring up the tests in simulation debug environment and analyze the failures.

Steps: Change directory to JumpStart_LABS/LAB5. Launch Encounter Test GUI : et & Create a New Project o Name it VectorSim or a name of your choice o For the Methodology file type in ./et_inputs/VectorSim_CustomMeth o Then click OK o This will load a custom methodology into the GUI which was created for part of this lab. The rest of the lab will be run from the commandline. In the Methodology Advisor window right-click on the main title ATPG Tests with/without Bridging Faults and select Expand All if not already expanded. Build Model o Click on Build Model for Verification and ATPG o This brings up the form for this step on the right side. o The netlist files are in the netlist directory. Add /netlist to the end of the Directory entry and hit return Select DLX_CORE.v and DLX_TOP.v.

o The cell name is DLX_TOP o Click on the Setup button to define the libraries. Make sure you click on Model on the left side. The libraries are in the directory techlib. Double-Click on the techlib folder to display the files in that directory. Select both of these files. Click Update Project o Click Run. o Make sure there are no Severe Warning messages. Build Test Mode o Click on Build TestMode FULLSCAN nobridge o Enter Test mode name: FULLSCAN_nobridge o Mode definition file name : FULLSCAN Why is the Mode definition different from the testmode? o Input pin assignment file : dlx_assignfile in et_inputs directory. o Click Run. o Make sure there are no Severe Warning messages. Verify Test Structures o Click on TSV Checks for TestMode FULLSCAN_nobridge o Select the Test mode name FULLSCAN_nobridge. o Click Run. o This should run successfully with 16 Controllable and Observable scan chains. (Look for TSV-381 messages) Build Fault Model o Click on Build Fault Model with NoBridge Faults o We want to create a standard static(Stuck-At) fault model o Include Dynamic Faults should be unselected and Fault Cell Boundary Only selected o Click Run. o How many Static faults in this testmode? o How many Shorted Net faults in this testmode? Create Scan Chain Tests o Click Create ATPG ScanChain Tests for FULLSCAN_nobridge o Testmode: FULLSCAN_nobridge o Experiment: test_nobridge o Click Run. Create Logic Tests o Click Create ATPG Logic Tests for FULLSCAN_nobridge o Testmode: FULLSCAN_nobridge

o Experiment: test_nobridge o Make sure Overwrite existing experiment is unselected. This tells the tool to not append to the last test in this experiment. (switch is append=no). The methodology file should have done this for you. o Click Run This will be the full ATPG tests for this testmode Write Vectors o Click on Write Vectors in Verilog for Analysis o Testmode: FULLSCAN_nobridge o Click Uncommitted Vectors since we havent committed these vectors yet and select Experiment test_nobridge. o Notice from the selections that we are writing out in parallel format. o Click Run to generate the verilog vectors We have now created a full set of verilog vectors for scan chain tests and logic tests. We are now ready to verify them using NCverilog. Leave the GUI open and go back to a command window. Change directory to LAB5/verilogsim Take a look at the script run_ncsim_nobridge_good. Executing ./run_ncsim_nobridge_good will run NCsim and verify the vectors you just created. You should see zero miscompares. Take a look at ncverilog_test_nobridge_logic.good.log and ncverilog_test_nobridge_scan_good.log files for results. You shold see zero miscompares.

So, to summarize. We have processed the netlist through the ET flow. Created ATPG vectors. Simulated and verified them against the verilog design. Now lets go off and create another fault model which will only contain a set of bridging fault rules. This concept is called an Alternate Fault Model. This will become clearer as we go. The next steps will be referencing the script run_altfault in your main directory Jumpstart_LABS/LAB5. We want to learn how to incorporate new fault types into our fault model. We are going to concentrate on bridging faults. A bridging fault is a fault relationship between two nets that have a physical proximity but might not have a functional relationship. First we need to come up with net pairs to analyze. o Take a look at the file et_inputs/netpair.list. This simple ASCII format is the input needed to allow Encounter Test to create a bridging pattern fault.(i.e, ET will create the bridging faults between the nets which are listed in the text file netpair.list. This file written by user).

This text file is the input for create bridging faults(shorted net faults). So give an ET command called create_shorted_net_faults. The above is the first command in the run script run_altfault. o create_shorted_net_faults(command) will create a fault rule file that describes the fault relationship of the analyzed nets. This file is then an input to the building of the alternate fault model. When this command is run, it will create the file et_inputs/bridgefault_rule. If you look at this file you will see that it contains fault rule information that ET understands. The bridgefault_rule file will then be an input for the building of the fault model. These faults will then show up as Shorted Net faults. o The script then builds a new TESTMODE called FULLSCAN_bridge and runs Test Structure Verification (TSV) against it to make sure it passes rule checking. o The script then builds the Alternate Fault Model using bridgefault_rule, which will include the above bridging faults. This is like having a totally separate fault model than the one originally created. In our case we are going to create one that ONLY contains the bridging faults. This will allow us to do targeted testing against just those faults. o The script then generates ATPG logic tests and writes out the patterns. o So, lets go ahead and run the script to do all of this. Execute ./run_altfault. Or et f c run_altfault o Once done, take a look at the file et_inputs/bridgefault_rule to see what was created by create_shorted_net_faults. How many fault rules are there for each net pair? o Next take a look at the log file for the build_alternate_faultmodel in the LAB5/testresults/logs directory. Look for the file link of log_build_alternate_faultmodel. How many faults are in this fault model? How many faults are in the original fault model? o Then look at the log file for the create_logic_tests. How many tests were created? How many were created for the original run against the large fault model? o

Hopefully you noticed that we have now created targeted tests directly addressing Shorted Net faults. Now lets see how the above targeted tests can find a failure in a design. To induce a failure we have inserted a pull-up on a net inside the DLX_CORE. This net happens to be one that is listed in the netpair.list

file that we created bridging faults for. Our goal is to show that with targeted tests it can be easier to find faults and in some cases the only way to find these faults in manufacturing. We can now run both verilog testbenches (FULLSCAN_nobridge and FULLSCAN_bridge) against the faulty netlist DLX_CORE_fault.v. Then we can see if the normal Stuck-At fault model finds this fault or whether the bridging fault tests find it. Change directory to verilogsim again. Execute ./run_ncsim_nobridge_bad o How many good comparing vectors are there?(620707) o How many bad comparing vectors are there?(2) o You should see a small number of miscompares in a pretty large vector set. This could make it hard to debug if you have to dump out a VCD or simvision data file. o Keep in mind also that the term comparing vectors in the log file does not translate to the Vector count of patterns. It refers to the bits being compared as they are shifted out of the SO pins. o Also note that by using the switch +FAILSET in your verilog sim, the tool will automatically write out the fail log. This log goes to the directory where the verilog files reside. Take a look in ../testresults/verilog to see this file. Look for a file with VER.FULLSCAN_nobridge.test_nobridge.data.logic.ex1.ts2_F AILSET in the name. So, instead of debugging the large simulation vector set, lets use the more targeted test to debug the failure. In your verilogsim directory there is a script called run_ncsim_bridge_bad. If you look in this script you will see a couple of extra switches have been added. o +define+simvision This tells the verilog testbench that we want to create s debug file o +simvision This tells the verilog testbench to create a Simvision database. You could also use +vcd to create a VCD dump file. Go ahead and execute ./run_ncsim_bridge_bad. o How many good comparing vectors are there?(48) o How many bad comparing vectors are there?(491) o The vector set is much smaller than before and will give us a much smaller dump file. Look inside the log file(ncverilog_test_bridge_bad.log) and search for the text miscompare. Depending on the vector generation your first error should be a PO at pattern number 1.1.1.3.1.5. This is the odometer reading. If your first failure is different, please use that pattern number. Included in this lab area is a script that converts our internal odometer reading into actual vectors, which you might be used to. If you want to see odometer versus vectors then run the scripts run_report_vectors_bridge and run_report_vectors_nobridge. The results are written to the files vectors.bridge and vectors.nobridge.

So, now we know we have failures in our simulation. What we want to do next is to bring up the failed simulation database in Simvision. Then compare it(BAD) to what Encounter Test is expecting(GOOD). GOOD machine versus BAD machine. o We know the error is in the faulty netlist (which could be your real silicon) o We can bring up that BAD simulation in SimVision and bring up the GOOD simulation in Encounter Test and compare. o First lets bring up the GOOD machine in Encounter Test. o If your GUI is still up go back to that window. If you closed it down, go to the LAB5 directory and type et&. o Click on the TASK pane. Notice all of the commands that we ran for the alternate fault model. If you dont see them, you need to refresh your TASK pane. This is done by clicking the arrow in the lower right hand corner of the TASK pane. o Next we want to Analyze (Simulate) our vectors in ET Click Tools->Vectors->Analyze TESTMODE is FULLSCAN_bridge Click Uncommitted tests and the Experiment name is test_bridge Output Experiment name is test_bridge_out Click Set up information for waveform analysis and click Options Click Watch nets list file: and fill in ET_watch.list (It contains the nets we look at(to be analyzed)) Click OK Now click the COMMAND button because we want to add another switch which is not in the GUI. Click at the end of the command and add (space) ALTFAULT=bridging and then hit return. This tells the tool that the above test is part of the Alternate Fault model. You have now simulated the vector patterns and stored them in the database as test_bridge_out and created a simulation results database. o Now we want to make sure the GUI is pointing to the correct vector set. In the main GUI click View Analysis Context (setup to view what to be analyzed in background running experiment) icon on the upper right side of the GUI. This will bring up the Analysis Context window. The TESTMODE should be FULLSCAN_bridge The Experiment should now test_bridge_out

o o o o

Click the Yellow arrow on the left side. This will apply the settings. Close the window. This sets the GUI pointing to our correct experiment database. On the right-hand side now click on the View Vectors GUI button which is the 5th from the left of the large icons. This will bring up the TBDbin vector set we just simulated. Now we want to find that failed vector from the NCsim log file. If you dont remember, it was 1.1.1.3.1.5 Expand out the tree until you get to Pattern 1.1.1.3.1.5 You can now click on it once and then right-click on your mouse and choose View Circuit Values This will actual go off and simulate the full vector set up to and including that point. So now you can bring up elements in the circuit and trace back their values. Try this out by clicking View ->Pin and type in DLX_CHIPTOP_A[30] and hit return. This will bring up the top module with this pin selected. If you now hit the b button it will start tracing back the logic and you can mouse over the pins and see the actual circuit values of the GOOD machine. What is the GOOD machine expected value for DLX_CHIPTOP_A[30]? Does this match the expected value in our verilog sim? You can continue to trace back logic to compare good machine values to the failed sim. Lets also look at the GOOD machine values in SimVision. Go back to the main ET GUI and click on the View Waveforms GUI button which is on the right-side, 7th from the left of the large icons. A popup window comes up. You should see a file with a .trn extension which was created when you Set up information for waveform analysis above. Select this file (*.trn) and click OPEN. This will launch Simvision. Once opened, you should see the vector set in the waveform viewer. o You will see Experiment, TestSection, TestProcedure, TestSequence, etc on the left hand side of the waveform window. o What is nice is you can easily get to the pattern 1.1.1.3.1.5. o The test pattern odometer is organized in the waveform vertically. You want to find the vertical binary combination of 1 1 1 3 1 5 in the waveform window. So, the first 1 value is the Experiment, the next 1 is the TestSection, etc. o Just try left clicking anywhere in the waveform and you will see values in the Cursor value window to your left.

o Try to find that pattern listed above. To help you, use the View menu to zoom in and out of the waveform. You can also make it zoom to your current cursor position by clicking View->Center on Cursor. Once you have found the proper vector, click your cursor on it. It should be at time 100s. o We now want to bring up the Simvision Design browser to add signals to our waveform. On the left-hand hidden pane there are 3 tabs. Click on the top one. This brings up the Design Browser. Remember when we Analyzed the Vectors and imported a watch list? These signals are now available in this Design Browser. Click on tbdata. You will see two signals listed in the window below. Click on each of these and they will be added to the waveform. These signals happen to be where the PO miscompare was happening in the Faulty machine. Keep in mind, this waveform is showing us the good machine values. What is the value of DLX_CHIPTOP_A[30] at odometer 1.1.1.3.1.5?(1) You can use the Design Browser to add additional signals by clicking further down in the hierarchy and adding them. At this point we could use SimVision to trace back in the logic to find its driving sources. This is done by using the 3rd tab on the left side of the Simvision window. We could also trace back the logic in the Encounter Test schematic browser and should see the same values.

The above was an exercise to show you two different avenues to view the GOOD machine values. One was through the ET schematic and the other through Simvision. The next logical step would be to bring up SimVision on the BAD machine simulation. This means loading in our Faulty verilog simulation and comparing waveforms. Go back to the command window and change directory to verilogsim. You should see a new directory called simvision.shm. This is where the verilog testbench wrote the dump file. The script run_simvision pulls in the dump file and a watch nets setup file called NC_watch.sv. Type ./run_simvision. This will bring up the SimVision waveform viewer

Click View->Zoom->FullX Click View and select Show Full Signal Names o The signal list imported is the fanin cone to the SO pin DLX_CHIPTOP_A[30]. o Show the full signal names. Click on View-> Show Full Signal Names. o You will notice a number of RED glitches in some of the signals around 880ns. These are X-values propagating through the logic. o The top signal in the waveform, DLX_CHIPTOP_A[30], is set to an X as a result. o Remember the simulation had its first miscompare at 1,030ns. If you look at that time in the waveform the value is an X. In the GOOD machine this net should be at a 1 at this time. Scroll to the bottom of the signals window. Left-click on the red pulse on the very last signal line ...THE_ALU.i_1111.Y. Click Alt-i to zoom in a couple of times. Then click Alt-c to center on the cursor. o Gate i_1111 is a NOR gate. In this case both inputs i_1111.A and i_1111.B are a 0. So you should see a 1 on the output. Instead you see an X. o This is because a strong0 pull-up was placed on this net in the faulty netlist. o Take a look at the file ./netlist/DLX_CORE_fault.v. o Search for ADDED and you will see the fault added.

So, we initially brought up the GOOD machine in order to see the logic and correct values. What we didnt do in this exercise was trace all of the logic back in the schematic browser. We could have then taken a snapshot of the circuit and created a watchlist. How would you do that in Encounter Test? (Hint: go to schematic browser and right click in the window and look for Add to Watch List commands) Outside of this exercise we traced the logic cone and created a watchlist, ET_watch.list. This went into the Analyze Vectors phase and was also used to create the NC_watch.sv file, which we used to view the BAD machine waveforms. This enabled us to trace back the miscompare to an X-state on the gate i_1111.

Of course the normal debug process isnt this set up for you. Hopefully this exercise gave you an introduction to the power and flexibility of the Encounter Test debug environment.

Lab 2 Debugging Broken Scan Chains Answers

The cause of the broken scan chains are: Scan Out DLX_CHIPTOP_DATA[16] chain is broken because: o Scan path into latch is driven by any logic. o Unconnected net o Net DLX_CORE.THE_CONTROLLER.MAR_OUT_EN1 Scan Out DLX_CHIPTOP_DATA[17] chain is broken because: o Feeding Flip/Flop is not being clocked by a scan clock o Clock is not connected. o Flip/Flop block DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_934.I0.I0 o Unconnected clock at net DLX_CORE.THE_REG_FILE.NET$2 Scan Out DLX_CHIPTOP_DATA[18] chain is broken because: o Clear on feeding Flip/Flop is not controlled. o Pin DLX_CORE.THE_CONTROLLER.TEMP_ENABLE_N52_reg.RN Scan Out DLX_CHIPTOP_DATA[19] chain is broken because: o Scan enable pin does not control mux to select scan path. o Pin DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_805.SE Scan Out DLX_CHIPTOP_DATA[20] chain is broken because: o Observable scan bit 9 Flip/Flop DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_719.I0 receives it scan data from Observable scan bit 6. o Tracing backward identifies a loop in the scan chain data that does not allow controllable scan data to enter in. o Net DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE[716] should not be driving Pin DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_719.SI Scan Out DLX_CHIPTOP_DATA[21] chain is broken because: o Scan Out is not driven by any Flip/Flops o Net DLX_CORE.SCAN_OUT[10] is not driven Scan Out DLX_CHIPTOP_DATA[23] chain is broken because: o The driving Flip/Flop DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_474 does not have a controllable clock. o Tracing the clock on the above Flip/Flop finds block DLX_CORE.THE_REG_FILE.i65129.AND$1. Since the clock comes through this block and it is an AND block, the clock should be on 1 leg and the other leg should be a 1 in the scan state. In this case, the nonclock leg is not at a 1 during the scan state. This leg must be controlled to a 1 during scan for complete scan chains.