EEE600 VLSI Design Verification andTest

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 DFTknowledgeable 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, let’s make sure you are pointing to the software and know how tobring it up in different modes.

- Typing in “which et” should point to the local install of the code. If this isnot the case, the following labs will not work.- You also need to make sure that you are pointing to the IUS version ofncverilog for later labs. Type in “which ncverilog” and make sure it doesnot 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 user’s .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 lineenvironment 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 thefollowing command:

<your_et_install_path>/tools/cdnshelp/bin/cdnshelp

Lab 1 – Learn the Encounter Test Flow

Primary Objective:

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)Steps:

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 methodologiesfor your use. These are not needed for this exercise since we willbe 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 -> Modelo 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 beaccessed from most Forms or from the “Tools Icon” in theupper 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 itnavigates to that directory.

Click Update Project to save your edits. This will bringyou back to the Build Model form

o Click Runo Click on the Tasks Tab to see the running progress of your

command. If you click on any command in the Task Pane you canlook at its log file in the Log Tab.

o Once finished, check the log file for Severe Warning or Error levelmessages. 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 canrerun that step by clicking the Run tab in the Form.

Build Fault Model – This step takes the model created in the previous stepand applies a fault model to the circuit by placing faults on the appropriatenodes.

o Verification -> Build Models -> Fault Modelo Radio buttons allow you to turn on/off Dynamic Faults. If

selected the tool will apply the static and dynamic fault model tothe circuit. For this lab it doesn’t 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 Runo 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 thetool what the different test pins are and their associated functions. For thiscircuit 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 testmore faults on the reset line.

o This means during shift it will be set to itsdeasserted (1) value but can change duringcapture 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 pinassignments set in the assignfile)

o Verification -> Build Models -> Test Modeo 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 Runo Look for any Severe Warning messages or syntax errorso 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 ourtestmode is set up properly and whether we have contiguous chainsfrom 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 1Load Pin Index / Pin Name 43 / DLX_CHIPTOP_DATA[0]Bit Length 85Scan Section Sequence Scan_Section_Sequence

Observable Register 1Unload Pin Index / Pin Name 50 / DLX_CHIPTOP_DATA[16]Bit Length 85 Unload pin in phase with Load Pin

Scan Section Sequence Scan_Section_SequenceNot proven flushable

o Note that the Bit Lengths of the Controllable and Observable traceare of identical length. This means the tool traced backwards andforwards the same equal length from SI to SO and SO to SI.

o A bad chain might look like this:

Controllable Scan Chain 1Load Pin Index / Pin Name 43 / DLX_CHIPTOP_DATA[0]Bit Length 42Scan Section Sequence Scan_Section_Sequence

...line spacing between them...

Observable Register 1Unload Pin Index / Pin Name 50 / DLX_CHIPTOP_DATA[16]Bit Length 12 Unload pin in phase with Load PinScan Section Sequence Scan_Section_SequenceNot proven flushable

o Note the Bit Lengths are different. When the log file prints outthey will also not be listed together. This is because the tool doesnot know they are supposed to belong to the same scan chain. Thiswill be more evident in LAB2 when we have broken chains.

o Just as a note for future reference. When you get into compressionstructures the format is a bit different. You will have multipleControl Reg points feeding to multiple Observer Reg points.

Verify Test Structures (Design rule checking)o Verification -> Verify -> Test Structureso Test mode name : FULLSCAN

Click on Scan Chain Identification. If you found a chainbroken in the previous step, this will give you more debuginformation.

The rest of the options can be left at default. If you clickon the Tests Tab you can see some of the default settingsand the type of checks the tool is running.

o Click Runo 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 MessageSummary section of the log file. If these occur, you need to verifythat 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 right-

hand 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 andverify_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 moreautomated scripts later in LAB4

Run the scripto Type ./run_ET_flow to run the scripto The script sets your current directory ./ as your working directoryo The command file execution will go to STDIN. The resultant log

files all go to the ./testresults/logs directoryo All binary design data goes into the ./tbdata directoryo 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 beloaded into the GUI.

Click on the Tasks Tabo This will show the commands that were run.

Click on the report_test_structures runo 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 runo The Forms Tab will be filled in with information about the runo By selecting the command that was run in the Task Tab, you are

also setting the Context of the circuit. This is important when youbring 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 pulldownmenu Window -> Analysis Context. What Testmode are you in?

Click on the Log Tabo 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 messageso 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 completeo 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 usuallyless choices in logic than tracing forward.

Debug of Broken Scan Chainso Log messages are linked to the Circuit debug environmento Click on the Messages Tabo 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 topof 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 thatare 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. Thismeans there are 7 broken chains.

Select the first message, (DLX_CHIPTOP_DATA[16]) and ClickAnalyze

o This will bring up the Schematic analysis windowo 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 inthe different context windows.

First let’s customize what we see in the Block Information window wesee on the right-hand side.

o Pulldown menu Options -> Information Window… Expand thewindow to see everything

o The left side of the window has the options currently displayedo The right side has the items to add to the displayo Recommended Items to Add if not already added

Function: Scan Path Datao 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 let’s 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 let’s 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 twocolumns?

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 OKo This will allow the internal simulator to propagate values through

sequential elements during debugo 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 isbroken.

OK. Let’s 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 wantto see just the library cell view.

o You will see a number of white rectangles around the cell. Eachof these represents a level of hierarchy. Mouse over each and seewhat 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 seethe 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 traceforward.

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 inthere 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:

Perform ATPG vector generation Write out Verilog and WGL patterns

Steps: 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 shiftingthrough the scan chains. This is mainly for manufacturing debugand to insure you can shift safely from SI to SO.

o ATPG -> Create Tests -> Specific Static Tests -> Scan Chaino Test mode name : FULLSCANo Create tests experiment name : Type in scan (or name of your

choosing)o The defaults for the rest of the options are fine, but let’s look at the

Advanced Tab for informational purposes. The Simulation Tab contains options for controlling 3-

state Contention, Clock Shapers and Keeper Devices. When controlling 3-state contention issues, the ATPG tool

will throw out any vectors which violate the level youselected. For instance if you select Hard Contention, thetool will throw out any vectors containing Hard Contentionbut will allow those with Soft Contention.

o Close the Advanced window by clicking OKo Click Runo 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 Testso This process will apply these vectors (generated for scan chain

integrity) permanently against the Global Fault list. Therefore noother tests will try to go after the faults attained here.

o Pulldown menu ATPG -> Commit Testso Test mode name : FULLSCANo Input experiment name : Type in scan (or whatever you named

it)o Click Runo Make sure you get a TBD-831 message at the end.

Create Logic Testso Now we are going to create the standard Stuck-At model ATPG

patterns.o Pulldown menu ATPG -> Create Tests -> Specific Static Tests -

> Logico Test mode name : FULLSCANo Create tests experiment name : logic (or name of your choosing)

Notice in this step that the previous Experiment scan is no longeravailable. This is because we committed the vectors.

o Notice the default generation efforts.o Click Runo 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-Atcoverage.

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 wantto unselect Overwrite existing experiment. This will sendthe option append=yes to the generator (mouse over checkbox to see commandline option help popup). This means itwill take the statistics from Experiment logic and add on toit.

Let’s 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. Thesepatterns would usually be the vectors you have finalized andcommitted.

o Pulldown menu APTG -> Write Vectorso Test mode name : FULLSCANo Vectors to write : Committed

This means we will be writing out the committed vectorsonly, which in our case are just the scanchain tests.

o Language : WGLo Click Run and review the log file.

Notice the top section lists all of the timing parameters usedto generate the WGL. We will see how to control these inthe 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 patternso This step is for generating patterns for simulation verification. It

can be with committed patterns or just experiments that have beenrun and not committed.

o Pulldown menu APTG -> Write Vectorso Test mode name : FULLSCANo 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 : Verilogo 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:100o 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:

Familiarize the student with the true_time use model script and tt_setupconfiguration file

Process design from Build Model to Write Vectors

Steps: 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 directorystructure <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 scripto 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 tbdatadirectory, the part will automatically be loaded in the GUI

Click on the Tasks Tabo 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 isbefore 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 choiceo For the Methodology file type

in ./et_inputs/VectorSim_CustomMetho Then click OKo 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 thecommandline.

In the Methodology Advisor window right-click on the main title “ATPGTests with/without Bridging Faults” and select Expand All if notalready expanded.

Build Modelo Click on Build Model for Verification and ATPGo 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_TOPo 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 Modeo Click on Build TestMode FULLSCAN nobridgeo Enter Test mode name: FULLSCAN_nobridgeo 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 Structureso Click on TSV Checks for TestMode FULLSCAN_nobridgeo 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 Modelo Click on Build Fault Model with NoBridge Faultso We want to create a standard static(Stuck-At) fault modelo Include Dynamic Faults should be unselected and Fault Cell

Boundary Only selectedo Click Run.o How many Static faults in this testmode?o How many Shorted Net faults in this testmode?

Create Scan Chain Testso Click Create ATPG ScanChain Tests for

FULLSCAN_nobridgeo Testmode: FULLSCAN_nobridgeo Experiment: test_nobridgeo Click Run.

Create Logic Testso Click Create ATPG Logic Tests for FULLSCAN_nobridgeo Testmode: FULLSCAN_nobridge

o Experiment: test_nobridgeo 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 donethis for you.

o Click Run This will be the full ATPG tests for this testmode

Write Vectorso Click on Write Vectors in Verilog for Analysiso Testmode: FULLSCAN_nobridgeo Click Uncommitted Vectors since we haven’t 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 andlogic 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 seezero miscompares.

So, to summarize. We have processed the netlist through the ET flow.Created ATPG vectors. Simulated and verified them against the verilogdesign.

Now let’s go off and create another fault model which will only contain a setof 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 maindirectory 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 faultrelationship between two nets that have a physical proximity but might nothave a functional relationship. First we need to come up with net pairs toanalyze.

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, ETwill create the bridging faults between the nets which arelisted in the text file netpair.list. This file written by user).

o This text file is the input for create bridging faults(shorted netfaults). 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 fileis 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 upas Shorted Net faults.

o The script then builds a new TESTMODE calledFULLSCAN_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 usingbridgefault_rule, which will include the above bridging faults.This is like having a totally separate fault model than the oneoriginally created. In our case we are going to create one thatONLY contains the bridging faults. This will allow us to dotargeted testing against just those faults.

o The script then generates ATPG logic tests and writes out thepatterns.

o So, let’s 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 tosee 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_faultmodelin the LAB5/testresults/logs directory. Look for the file link oflog_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?

Hopefully you noticed that we have now created targeted tests directlyaddressing “Shorted Net” faults.

Now let’s 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 withtargeted tests it can be easier to find faults and in some cases the only wayto find these faults in manufacturing.

We can now run both verilog testbenches (FULLSCAN_nobridge andFULLSCAN_bridge) against the faulty netlist DLX_CORE_fault.v.Then we can see if the normal Stuck-At fault model finds this fault orwhether 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 dumpout a VCD or simvision data file.

o Keep in mind also that the term “comparing vectors” in the logfile does not translate to the Vector count of patterns. It refers tothe 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 tothe directory where the verilog files reside. Take a lookin ../testresults/verilog to see this file. Look for a file withVER.FULLSCAN_nobridge.test_nobridge.data.logic.ex1.ts2_FAILSET in the name.

So, instead of debugging the large simulation vector set, let’s use the moretargeted test to debug the failure.

In your verilogsim directory there is a script calledrun_ncsim_bridge_bad. If you look in this script you will see a couple ofextra switches have been added.

o +define+simvision – This tells the verilog testbench that we wantto create s debug file

o +simvision – This tells the verilog testbench to create a Simvisiondatabase. 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 errorshould be a PO at pattern number 1.1.1.3.1.5. This is the odometerreading. If your first failure is different, please use that pattern number.

Included in this lab area is a script that converts our internal odometerreading into actual vectors, which you might be used to. If you want tosee odometer versus vectors then run the scriptsrun_report_vectors_bridge and run_report_vectors_nobridge. Theresults are written to the files vectors.bridge and vectors.nobridge.

So, now we know we have failures in our simulation. What we want to donext is to bring up the failed simulation database in Simvision. Then compareit(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 let’s 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 alternatefault model.

If you don’t see them, you need to refresh your TASK pane.This is done by clicking the arrow in the lower righthand 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 addanother 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 thetool that the above test is part of the Alternate Fault model.

You have now simulated the vector patterns and storedthem in the database as test_bridge_out and created asimulation results database.

o Now we want to make sure the GUI is pointing to the correctvector set. In the main GUI click View Analysis Context (setup to

view what to be analyzed in background runningexperiment) icon on the upper right side of the GUI. Thiswill bring up the Analysis Context window.

The TESTMODE should be FULLSCAN_bridge The Experiment should now test_bridge_out

Click the Yellow arrow on the left side. This will apply thesettings. Close the window.

This sets the GUI pointing to our correct experimentdatabase.

o On the right-hand side now click on the View Vectors GUI buttonwhich is the 5th from the left of the large icons. This will bring upthe TBDbin vector set we just simulated.

o Now we want to find that failed vector from the NCsim log file. Ifyou don’t remember, it was 1.1.1.3.1.5

o Expand out the tree until you get to Pattern 1.1.1.3.1.5o You can now click on it once and then right-click on your mouse

and choose View Circuit Valueso 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 thecircuit and trace back their values.

o Try this out by clicking View ->Pin and type inDLX_CHIPTOP_A[30] and hit return. This will bring up the topmodule with this pin selected.

o If you now hit the b button it will start tracing back the logic andyou can mouse over the pins and see the actual circuit values of theGOOD 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. Let’s 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 largeicons.

A popup window comes up. You should see a file with a .trnextension which was created when you “Set up information forwaveform analysis” above. Select this file (*.trn) and clickOPEN. 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 waveformwindow.

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 binarycombination of 1 1 1 3 1 5 in the waveform window. So,the first ‘1’ value is the Experiment, the next ‘1’ is theTestSection, etc.

o Just try left clicking anywhere in the waveform and youwill see values in the Cursor value window to your left.

o Try to find that pattern listed above. To help you, use theView menu to zoom in and out of the waveform. You canalso make it zoom to your current cursor position byclicking View->Center on Cursor.

Once you have found the proper vector, click your cursor on it. Itshould be at time 100s.

o We now want to bring up the Simvision Design browser toadd 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 nowavailable in this Design Browser.

Click on tbdata. You will see two signals listed inthe window below.

Click on each of these and they will be added to thewaveform.

These signals happen to be where the POmiscompare was happening in the Faulty machine.Keep in mind, this waveform is showing us thegood machine values.

What is the value of DLX_CHIPTOP_A[30] atodometer 1.1.1.3.1.5?(1)

You can use the Design Browser to add additionalsignals by clicking further down in the hierarchyand adding them.

At this point we could use SimVision to trace back in the logic tofind its driving sources. This is done by using the 3rd tab on theleft side of the Simvision window.

We could also trace back the logic in the Encounter Test schematicbrowser and should see the same values.

The above was an exercise to show you two different avenues to viewthe GOOD machine values. One was through the ET schematic andthe other through Simvision.

The next logical step would be to bring up SimVision on the BADmachine simulation. This means loading in our Faulty verilogsimulation and comparing waveforms.

Go back to the command window and change directory toverilogsim. 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 netssetup 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 pinDLX_CHIPTOP_A[30].

o Show the full signal names. Click on View-> Show FullSignal Names.

o You will notice a number of RED glitches in some of thesignals around 880ns. These are X-values propagatingthrough 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 at1,030ns. If you look at that time in the waveform the valueis an X. In the GOOD machine this net should be at a 1 atthis 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 onthe output. Instead you see an X.

o This is because a strong0 pull-up was placed on this net inthe 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 thelogic and correct values. What we didn’t do in this exercise was traceall of the logic back in the schematic browser. We could have thentaken a snapshot of the circuit and created a watchlist.

How would you do that in Encounter Test? (Hint: go toschematic browser and right click in the window and look forAdd to Watch List commands)

Outside of this exercise we traced the logic cone and created awatchlist, ET_watch.list. This went into the Analyze Vectorsphase and was also used to create the NC_watch.sv file, whichwe used to view the BAD machine waveforms.

This enabled us to trace back the miscompare to an X-state on thegate i_1111.

Of course the normal debug process isn’t this set up for you.Hopefully this exercise gave you an introduction to the power andflexibility 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 neto 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 clocko Clock is not connected.o Flip/Flop block

DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE_reg_934.I0.I0o 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.I0receives it scan data from Observable scan bit 6.

o Tracing backward identifies a loop in the scan chain data that does notallow controllable scan data to enter in.

o Net DLX_CORE.THE_REG_FILE.\REG.REGISTER_FILE[716] shouldnot be driving PinDLX_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/Flopso 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 doesnot have a controllable clock.

o Tracing the clock on the above Flip/Flop finds blockDLX_CORE.THE_REG_FILE.i65129.AND$1. Since the clock comesthrough this block and it is an AND block, the clock should be on 1 legand the other leg should be a 1 in the scan state. In this case, the non-clock leg is not at a 1 during the scan state. This leg must be controlled toa 1 during scan for complete scan chains.