Mało kto zastanawia się, jak przebiega proces produkcji układów mikroelektronicznych z punktu widzenia zapewnienia jakości finalnego produktu. Coraz większe projekty wymuszają ciągły i bardzo dynamiczny rozwój dziedziny znanej jako DFT (design for testability), ale i narzędzi wspomagających cały proces testowy. W ramach prezentacji przedstawione zostaną podstawowe koncepty wykorzystywane przez największe firmy produkujące układy mikroelektroniczne, jak i problemy, z którymi należy się zmierzyć, by zapewnić wysoką jakość komercyjnego oprogramowania. Specyfika oprogramowania tworzonego do testowania układów mikroelektoronicznych wykorzystywanych w urządzeniach powszechnego użytku różni się od klasycznych aplikacji desktopowych, jak i mobilnych. Bardzo duża dynamika rynku, zgodna z prawem Moore’a powoduje, że z roku na rok wymagania stawiane przed narzędziami wspomagającymi proces implementacji ciągle się zmienia. Wszystko to warunkuje sposób, w jaki należy podejść do testowania tego typu programów, jak rozwijać w pełni zautomatyzowaną infrastrukturę testową, pozwalającą zarządzać dziesiątkami tysięcy testów regresyjnych analizowanymi codziennie.

1. Okiem testera -
tam gdzie hardware
łączy się z softwarem
November 2017
Lukasz Rybak
QA/Test Manager, D2S Tessent R&D
Poland

2. Hardware testing
What is wrong with EDA tools?
How to test “testing tools”?
Case study
Conclusions and Q&A

3. • Design verification
• Emulation
• Prototype
Design
• Silicon debug/bring-upFirst silicon
•Manufacturing test (structural test)
•Wafer test
•Device test
•Package test
Mass production
• Functional testCharacterization
• In-Field test
Maintenance
Reliability
• Design verification
• Emulation
• Prototype
Design
• Silicon debug/bring-upFirst silicon
•Manufacturing test (structural test)
•Wafer test
•Device test
•Package test
Mass production
• Functional testCharacterization
• In-Field test
Maintenance
Reliability
Hardware testing

4. Structural test
 More disciplined and rigorous
approaches than in software
 Can be automated
(EDA tools)
 Concept of fault models
 Cannot be eliminated
 Mistakes are costly
 customer returns
 harder to fix silicon Source: techcet.com

5. ‘82 ‘85 ‘88 ‘91 ‘94 ‘97 ‘00 ‘03
10-9
10-8
10-7
10-6
10-5
10-4
$/transistor
‘06
10-3
10-2
Production cost
Test
cost
 The largest single
component of IC cost
(25%-40%)
 Testing devices (ATE)
– a few millions of $
 Time-to-market
pressure
 Test tools must keep
pace with design
technologies and test
methodologies
Cost of test

6.  The largest single
component of IC cost
(25%-40%)
 Testing devices (ATE)
– a few millions of $
 Time-to-market
pressure
 Test tools must keep
pace with design
technologies and test
methodologies
Cost of test

7. Design for testability
 Requires design
modification
 Fully automated test
pattern generation
(ATPG)
 Embedded compression
to reduce test cost
 Different technologies:
 Logic test
 Memory test
 Automated diagnosis
Source: Mentor, A Siemens Business

8. Intel core
Your laptop
How small this world is?
Source: V.Singh, DAC 2015
Grain of rice
Red Blood Cell
Transistor
Human hair
Influenza virus
1X
40X
90X
1900X
50000X
2700000X
7000000X

9. Source: Intel; www.silfex.com/cnfolio.com
Technology basics

10. Parametric
Defects
Random

11. How dynamic this world is?
Source: Wilson Research Group and Mentor Graphics, 2016 Functional Verification Study
Source: Gartner

12. What is wrong with
EDA tools?
20%
60%
20%
Better interoperability New features Quality
Source: EE Times, 03/27/2003

13. 2014 2015 2016
0
50
100
150
200
250
CDNS
SNPS
MGC
What is wrong with
EDA tools?
Source: EE Times, 03/27/2003

14. Source: Mentor, A Siemens Business
How to test “testing tools”?
Few uncommon
things
User Interface
Input data
Users

15.  Starting from scratch:
 Build well organized
team with dedicated
knowledge
 Build necessary
infrastructure
 Build in-house tools if
needed
 Automate if possible
Source: Mentor, A Siemens Business
How to test “testing tools”?

16. CC
How to test “testing tools”?
 Various programing
languages (C++, TCL,
custom preprocessor)
 Code size
 3,082 KLOC
 6,001,408 branches
 Automation including:
 Full daily test coverage analysis
 More than 300k tests run daily
(interoperability with 3rd party
tools)
 415 tests for performance
measurements
 Address sanitizer tools
License
framework
Caching
system
On the fly
modification
Smart
filtering
Code
Coverage
Custom
plugins
Option
Coverage
DOC
regression
GUI
automation
Valgrind
(ASAN)
License
framework
Caching
system
On the fly
modification
Smart
filtering
Code
Coverage
Custom
plugins
Option
Coverage
DOC
regression
GUI
automation
Valgrind
(ASAN)
License
framework
Caching
system
On the fly
modification
Smart
filtering
Code
Coverage
Custom
plugins
Option
Coverage
DOC
regression
GUI
automation
Valgrind
(ASAN)

17. Case study
A
B B
HDL View Gate level view Layout
 Input data:
 Design
 Build-in tool commands
 Purpose – design editing

18. Case study
A
B B
HDL View Gate level view Layout
 What if
 design is represented as HDL: Verilog, SystemVerilog,
VHDL (mix is allowed)?
 there are multiple version for each?
 module can be parametrized?

19. Case study
memory
Instance 1
Instance 2
editing
 Data out
 Transcript
 Edited design
 Hard to validate
 In-house scripts or simulation
 Third party tools

20. Questions?
lukasz_rybak@mentor.com
lukasz.rybak@wsb.poznan.pl
lukasz_rybak@onet.pl