test - TU Ilmenau

Transcription

test - TU Ilmenau

IHS 3: Test of Digital Systems
R.Ubar, A. Jutman, H-D. Wuttke
Integrierte Hard- und Softwaresysteme
Organisatorisches
Nächste Termine:
Blockveranstaltung Dr. Jutman
23.1. 24.1. 2014
2
Copyright 2000-2003 by Raimund Ubar
Technical University Tallinn, ESTONIA
Experiments
• Use the example A+B/2 (avarage value)
• Find for each test method best parameters
–
–
–
–
–
Functional test
Deterministic test
Functional BIST
Logical BIST
Circular BIST
• Note them and compare results
3
Ad Hoc Design for Testability Techniques
Method of Test Points:
Block 1
Block 1 is not observable,
Block 2 is not controllable
Block 2
Improving controllability:
1
Block 1
CP1
&
Block 2
CP2
Block 1
CP1
CP2
MUX
Block 2
Normal working mode:
CP1 = 0, CP2 = 1
Controlling Block 2 with 1:
CP1 = 1, CP2 = 1
CP2 = 0
Normal working mode:
CP2 = 0
CP1 = 1, CP2 = 1
CP1 = 0, CP2 = 1
4
Website for this image
Consider i- Corporation for your
quality custom test fixtures.
Bed of Nails ...
icorporation.biz
http://www.youtube.com/watch?v=EH
sZQ1WiojE
5
Boundary Scan Standard
http://www.youtube.com/watch?v=0YOBZ122vI0
6
Scan-Path Design
IN
OUT
Combinational
circuit
Scan-IN
q’
T = 0 - normal working mode
T = 1 - Test mode (scan mode)
q
R
Scan-Path design allows to
control and observe internal flipflops, which means that the task
of sequential testing has been
transformed to the task of testing
a combinational circuit
Normal mode : flip-flops are
connected to the combinational
circuit
Scan-OUT
q’
&
Scan-IN
&
1
T
D T
q
C
Scan-OUT
Test mode: flip-flops are
disconnected from the
combinational circuit and
connected to each other to form a
shift register
=> scan-chain
7
Scan-Path Design and Testability
Two possibilities for improving
controllability/ observability
SCAN
OUT
MUX
IN
OUT
DMUX
SCAN
IN
8
Parallel Scan-Path
IN
Combinational
circuit
Scan-IN 1
R1
Scan-OUT 1
Scan-IN 2
OUT
In parallel scan
path flip-flops
can be
organized in
more than one
scan chain
R2
Scan-OUT 2
9
10
Texas Instruments SCOPE™ Family of Testability
SCOPE™ Instruction Set:
– IEEE Standard 1149.1-1990 Required
Instructions,
– Optional INTEST, CLAMP and HIGHZ
– Parallel-Signature Analysis at Inputs
– Pseudo-Random Pattern Generation
From Outputs
– Sample Inputs/Toggle Outputs
– 4-wire test access port (TAP) interface
11
Boundary Scan Register
12
Mandatory features
• Test Access Port (4 Signale, TAP):
– TCK (Test Clock), TMS (Test Mode Selection),
– TDI (Test Data In), and TDO (Test Data Out)
•
•
•
•
TAP Controller (FSM)
Instruction Register (2 Bit or more)
Bypass Register (1 Bit)
Boundary Scan Register (1 Bit or more)
13
14
15
Boundary Scan Standard 1149.1-1990
Serial-test information is
conveyed by means of a 4wire test bus, or test access
port (TAP), that conforms to
IEEE Standard 1149.1-1990
Test instructions, test data,
and test control signals all
are passed along this serialtest bus.
The TAP controller monitors
two signals from the test bus,
TCK (clock) and
TMS (mode select).
16
17
Instruction-Register Opcodes
18
19
20
TAP-controller state diagram
21
TAP-controller state diagram
22
Boundary Scan States
•To reach state “Pause-DR”
select state sequence:
•TMS=0 > Run-Test/Idle
•TMS=1 > Select-DR-Scan,
•TMS=0 > Capture-DR,
•TMS=0 > Shift-DR, and
•TMS=1> Exit1-DR
•TMS=0 > Pause-DR
23
STEP0: After Switch on
• Scan Chain in off
• BS cells are inactive
•Goal:
•Testing connection between
Pin AB2 of U1 and Pin 15 of U2
24
STEP1: SAMPLE/PRELOAD
• Testing connection between
Pin AB2 of U1 and Pin 15 of U2
4
• Preload
5
45
46
6
47
• FF 5 U1: control
7
48
• FF 6 U1: output
8
49
9
• FF 7 U1: input
50
• FF 5 =“1” => Driver at FF 6 active
• Pin AB2 = 1
25
STEP2: SAMPLE/PRELOAD
• Driving AB2 of U1 with “1”
4
• Scan chain is activated
5
45
46
6
47
7
48
8
49
9
50
• Scan cells are inactive (x)
26
STEP3: EXTEST
• Test vector loaded
• Scan cells active
• FF 6 U1 drives “1”
• Pin 15 U2: tri state (inactive)
• Measuring
• U1: at FF 7
• U2 at FF 48
27
STEP4: SCAN DR
•Read AB2 at Pin 15
• result in FF cell 48 and 7
• Shift (new test vector)
• Drive new values
28
Calculation
•
•
•
•
•
500 BS-cells
TCK frequency: 10 MHz
Shift operation: 50 μs = 1 signal change
2 edges = 2 shifts
What is the frequency for changing the value at a
pin?
• 500 cells a 2 shifts => 1000 shifts until next value
• => frequency 10 kHz
• => Bottleneck
29
Boundary Scan Applet
30
Boundary Scan Diagnosis
31
References
• Books:
• Boundary Scan Handbook, 3rd Edition, Ken P. Parker,
Kluwer Academic Publishers, ISBN 1-4020-7496-4
• Analog and Mixed-Signal Boundary-Scan, Adam Osseiran,
Kluwer Academic Publishers, ISBN 0-7923-8686-8
• Digital Systems Testing and Testable Design, Miron
Abramovici et.al., IEEE Press, Wiley Interscience, ISBN 07803-1093-4
• Websites:
•
•
•
•
www.goepelusa.com
www.freeDFT.info
www.DFTdigest.com
www.smta.org
32
ERADOS-project (2009-2011):
Experimental Research for Adaptive Diagnostics based On
Structural multi-core emulation test
ROBSY-project (2011-2013
Re-konfigurierbares On Board Selbsttest-SYstem
Integrated Communication Systems Group
www.tu-ilmenau.de/ics
Architecture of an Adaptive Test System Built on FPGAs
Page 33
ERADOSExperimental Research for Adaptive
failure Diagnostics based On Structural
multi-core emulation test
H.-D. Wuttke, S. Ostendorff, J. Sachße, Jorge-H. Meza-Escobar
Prof. Dr.-Ing. habil. Andreas Mitschele-Thiel
Integrated HW/SW Systems Group
Page 34
Self-Organization
19 February 2014
34
1. Einführung
Page 35
Self-Organization
19 February 2014
35
1. Einführung: Motivation
• Testprobleme steigen mit
zunehmender Komplexität
– Längere Testzeiten
– Geringere Fehlerabdeckung:
ungetestete high-speed Module
• ERADOS Ziele
– Verfügbare FPGAs zur
Beschleunigung des Testens
– Algorithmenbeschleunigung durch
Verteilung
– Verbesserung von Testzeit und
Fehlerabdeckung
Board with FPGA
Page 36
Self-Organization
19 February 2014
36
1. Einführung: Stand der Technik
• BScan: klassisch
– Alle Testfunktionen auf dem PC
• Testalgorithmus
• Pattern Generation und Analyse
• Ansteuerfunktionen der zu testenden Leiterplatte (DUT)
– JTAG Interface zur Ein-/ Ausgabe von Testwerten
Page 37
Self-Organization
19 February 2014
37
2. Projektziele: ERADOS-Ansatz
• JTAG Emulation mit FPGAs
– Field Programmable Gate Arrays (FPGAs)
• Frei programmierbar
• Auf vielen Boards vorhanden
• wiederverwendbare Emulationsumgebung
– JTAG Interface zum PC zur Ein-/ Ausgabe von Testwerten
• Programmierumgebung bisheriger Produkte einbeziehen
– Automatische Generierung des FPGA- Programmierkodes aus
bisherigen Test- Quellen und Modellen der Leiterplatten
– JTAG Interface als Kommunikationskanal
– Beschleunigng des PC-basierten Testens durch FPGA- Emulation
(Teile des Testalgorithmus auf FPGA)
Page 38
Self-Organization
19 February 2014
38
2. Projektziel: ERADOS Ansatz
• BScan: Klassisch
– Alle Testfunktionen auf dem PC
• Testalgorithms
• Pattern Generation und Analyse
• Ansteuerfunktionen der zu testenden
Leiterplatte (DUT)
– JTAG interface zur Ein-/ Ausgabe
von Testwerten
• ERADOS test system
– Testteile implementiert innerhalb
eines FPGA
– JTAG Interface als
Kommunikationskanal
BScan test environment
Page 39
Self-Organization
19 February 2014
39
Basic concept
FPGA
DUT
device
FPGAfor
logic
test
resources
(DFT)
device under test
DUT interface
(DUT)
Basic concept
DUT interface
DUT
usual JTAG
Pins
FPGA logic resources
DFT
(FPGA)
Basic concept
DUT interface
DUT
usual JTAG
BScan cells
TAP Controller
TDI
DFT
(FPGA)
TDO
BScan chain
Basic concept
DUT interface
usual JTAG
1
TDI
1
TAP Controller
*
1
0
TDO
DUT
0
1
0
DFT
(FPGA)
Test system: layer model
• To manage the complexity of such PCB dependent test
system, its functionality is divided into layers
• Each layer implements dedicated functions
– Apply the pattern sequences
• Consider DUT timings
– Analyze responses
• Depends on the DUT’s test algorithms
– Decide according to the test strategy
• Based on the DUT’s test algorithm
 Concept of 5 layers
Page 44
• L5: controls the whole test
Test Program
L5
Main Control
procedure
Test Analysis
L4
• L4: analyzes the test results
Test
L3
and decides the next
Comparator
test step
DUT TestL2
Primitives
• L3: compares the result
DUT AccessL1
Primitives
patterns with their
Layer Stack
expected values
• L2: dependent on the used test algorithm (shift-, countrotate- or other special operations)
• L1: basic functions to access the device under test (read,
write operation)
Page 45
• Each of these layers can be implemented:
– In software running at the embedded test processor
– Directly in HW as a co-processing units
– In software running at the Test-PC
Optimization concerning available resources and needed
performance
Bachelor, Master, PhD- Themes
Page 46
Basic concept
DUT interface
ERADOS layer 1
1
TDI
TAP Controller
1
*0
DUT
1
0
1
0
DFT
(FPGA)
TDO
Basic concept
DUT interface
DUT
ERADOS layer 2
TDI
TAP Controller
0
*1
DFT
(FPGA)
TDO
Basic concept
DUT interface
ERADOS layer 2
DUT
1
TAP Controller
TDI
1
0
1
0 1
DFT
(FPGA)
0
1
*
TDO
Basic concept
DUT interface
DUT
ERADOS higher layers
TAP Controller
TDI
impl. of layers 1 - 3
diagnostic processor
(layer 4 – 5)
TDO
DFT
(FPGA)
Test system architecture
Automation
• Why?
– A must for real industrial test applications
– Adaptability to unknown environment
• How?
– Based on DUT-M, FPGA constraints, PCB and test cases
– HW/SW partitioning
– Layers implemented in hardware are transformed to their
hardware descriptions
– Layers realized in software are transformed to object code
Page 51
4. Ergebnisse: Algorithmen-Integration
• Eingaben
– IP Blöcke
– Ein-/ Ausgangs Information
– DUT Modell
• Übersetzung
– Informationsextraktion
– Code Generierung
• Ergebnis
– FPGA Programmierungs-Datei
Automatic test system generation flow
Page 52
Self-Organization
19 February 2014
52
Test System Architecture
DUT Models
• Device model (DUT-M)
– Access functionality
– Test algorithms
– Parameters
• Bus width, package, pins, timing
information, …
• L1 based on the DUT-M access
functions and parameters
• L2-L5 functions based on the test
algorithms and parameters
RAM DUT‐M
ADDRESS
(PIN A0, A1, A2, .., A7)
DATA
(PIN DQ0, DQ1, DQ2, .., DQ7)
CONTROL
(PIN OE, WE, CE)
ACCESS FUNCTIONS
(CYCLE WRITE [110], [100], [110])
(CYCLE READ [110], [010], [110])
(CYCLE OFF [111])
TEST1
( ..... )
TEST2
( ..... )
END DUT‐M
DUT-M example
Page 53
Implementation
Test scenario
Prototype implementation
Page 54
4. Ergebnisse:
• SRAM
 Verbindungstest Algorithmus
 Daten- und Adressbus Verbindungstest
• LCD Display
 Funktionstest Algorithmus
 Pixelgenerierung
DUT
Classic BSCAN
Test Time (s)
Processor based Test System
Speed-up
Prog. Time (s)
Test Time (s)
Total (s)
SRAM
2
0.65
0.1
0.75
2.7
LCD Display
120
0.65
7
7.65
15.6
Comparison table
Page 55
Self-Organization
19 February 2014
55
ROBSY-project (2011-2013
Re-konfigurierbares On Board Selbsttest-SYstem
Page 56
Test system: concept
• Use programmable HW of the electronic system (FPGA)
• Use standard JTAG as communication link to the Test-PC
(Test-SW)
• Use a specialized, high configurable test processor
– run parts of the test algorithm
– communicate between test system and Test-PC
• Accelerate testing process by co-processors (permit at speed
testing)
• Split up test functionality by introduction of layers
– Reduce complexity
– Flexibility for realizing functionality in HW or SW
Page 57
Test system: concept
• Interfaces
JTAG
– IEEE 1149.1
– Peripherals (DUTs)
FPGA
• Processor
– Communication with host PC
and co-processors
– In charge of the execution flow
– Boolean/integer arithmetic
– Interrupt handling
Processor
Co-proc Co-proc
...
Co-proc
• Co-processors
– Accelerate test execution
DUT1
DUT2
Page 58
DUTn
Test system: modeling language
• Hardware related, test oriented modeling language (DSL) to
describe the DUT’s:
MODULE mod1 (...)
– Interface
• Data, address, control bus
– Timing (L1)
– Device functions (L1)
• Read, write cycle
– Test algorithm(s)
• L2 .. L4: procedures
• L5: main program
INTERFACE (
DATA (...)
ADDRESS (...)
CONTROL (...)
)
TIMING (...)
CYCLE write
BEGIN
...
END
VAR i1, i2, xyz;
L2: PROCEDURE proc1 (...)
BEGIN
...
END
...
PROGRAM prog (...)
BEGIN
...
END.
Page 59
Test system: generation
• HW/SW partitioning
– Based on the DUT model’s timing section, test algorithm, and
PCB properties
– Depends on the required performance and available resources
• Layers realized in SW
– Model transformation to test processor object code
– Model transformation to SW code executed at the Test-PC
• Layers implemented in HW
– Model transformation to a hardware description (VHDL)
Page 60
Test system: architecture
• Control and Debug IF
JTAG
– Communication port to the
host PC
– Load/change program code
– Read/write internal registers
Control-Debug IF
FPGA
Processor
• Processor
– Run complex algorithms
IRQ
• Bus system
Bus
– Processor co-processor link
Co-proc
Co-proc
• Co-processors
– HW accelerators
– Meet timing constraints
...
Co-proc
...
DUT1
DUT2
Page 61
DUTn
Test system: test processor
• Specialized, high configurable test processor as part of the
test system
• SW implementation of complex algorithms
– Flexibility to implement test algorithms
– Algorithms running on the FPGA
– Low communication load between PC and Board
• JTAG based communication mechanism through the
processor’s debug and control interface
Page 62
Test system: test processor
Program Memory: 4kx18
Stack Memory: 1kx18
Data Memory: 2kx8
External bus: 31kx8
(Wishbone)
Program
Memory
Stack
Memory
Data
Memory
Stack
Interface
Data
Multiplexer
CPU
Jump
Target
State
Machine
ALU
Page 63
Int/Exc
Modules
Wishbone IF
•
•
•
•
Control and Debug IF
Processor
• Harvard architecture
• Single instruction
single data (SISD)
• Reduced instruction
set computer (RISC)
Test system: test processor configuration
• Why configurable?
– Unknown PCB properties
• FPGA resources and performance
• DUT properties (bus width, timing)
– Optimization based on the application
• Fit processor to the test application
– Performance
– HW resources
 optimal HW/SW partitioning
– Optimization of ISA concerning the test algorithms
Page 64
Test system: test processor configuration
• Configuration of the pre-defined architecture
– Memory sizes
• Program, data, stack memory
–
–
–
–
Number of registers
Data path width
External bus parameters (Wishbone bus)
Enable/disable instructions
• Extend the processor
– Addition of special instructions
Page 65
ROBSY: Testsystem auf FPGA
Possible test environment
Page 66
Self-Organization
19 February 2014
66
Conclusion
• Test system supplies the benefits known from emulators to all
PCBs containing an FPGA
• Adaptability due to DUT models
• Co-processors permit at speed testing
• Technology independent concept
– Test system can be implemented on FPGAs of different vendors
and families
• Maintaining the standard JTAG interface as communication
link
– Seamless integration in existing test tools
– No additional HW required for testing
Page 67

test - TU Ilmenau

Transcription

Similar documents

The Thank You Report - International Charter School

Product Brief HIRes

project action plan

IPO Process and Listing Recent Experience from the Baltic States

Digital Stamps of Companies

Web Crawling

Comenius Regio project „Extrakey“ Schools´ extra

Personalising a smartcard

Semiconductor - Ect

The Art Of Engineering - Custom Powder Systems

Estonian Films 2014-2015

mewsletter 135 - Independent Cat Society

Issue 57: XtremeDSP Solutions