Lab using Encounter Test

The following labs assume that paths to Encounter Test 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 : 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>/ 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)
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 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
Scan_Section_Sequence
Not proven flushable

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 ATPG Vector generation

Primary Objective:

Steps:

Perform ATPG vector generation

Write out Verilog and WGL patterns

Change directory to LAB1

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 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 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 LAB1/testresults/verilog
Close down all windows after complete.