Hard
A th
Unive
dware BMet
M
hesis submit
P
Depart
ersity of
Based thodolo
Muham01-UET
tted in partia Degree of
Thes
rof. Dr. H
ment of
Enginee
P
J
White ogy for
By
mad IraTT/PhD-
al fulfillmenf Doctor of P
sis Super
Habibull
f Electric
ering and
Pakistan
July 2010
Box Vr IC Ch
am Baig-EE-06
nt of the reqPhilosophy
rvisor
lah Jama
cal Engin
d Techn
n
0
Verificahips
g
uirement for
al
neering
nology, T
ation
r the
Taxila,
ABSTRACT
This thesis presents a hardware based testing methodology for speeding up
process of verification. With advent of VLSI technology the gate densities on a
chip are increasing with rate predicted by Moor’s law. The designers are now
mapping complex applications in silicon for enhanced performance and
reduced cost. The testing of these designs is becoming more and more
challenging. The simulation based testing is very slow and for moderately
complex designs takes hours and even days to give decent coverage. The
thesis presents novel methodology to test the design by inserting test logic in
Hardware. The methodology best works for FPGA based verification. The
design is first mapped on FPGA for functional verification. The thesis presents
modules that are integrated with the DUTs and monitors the results for
correctness. The model also provides white box testing whereby internal
working of the design is exploited for exact location of a bug. The
methodology also provides assertions based testing and provides coverage
analysis of design for a set of test vectors. The thesis gives different examples
of circuits that are tested using the proposed methodology. In-silicon White
box verification with checkers and monitors holds a great potential in keeping
pace with the rapid growth in VLSI technology.
The basic idea of our proposed methodology can be termed as a hardware
(tester circuitry) testing another hardware (Design under Test). The concept of
an embedded layer of re-configurable/removable testing circuit or agent within
the hardware of the DUT is proposed and experimented. Starting from simple
combinational and sequential circuits to RISC processor and Medium Access
Control (MAC) layer found in the IEEE 802.11e standard are tested through
this methodology. Two main advantages have been observed:
1) The proposed methodology is found well suited for finding the root causes
of the errors in the design under real time.
2) A considerable time saving is observed. The design which takes days in
testing with simulation runs, gives equivalent results in minutes when it is
run on FPGA prototype along with embedded test agent proposed in this
thesis. When device is fully tested and ready for fabrication, this additional
tester circuitry can be removed.
3
Dedications………….
This dissertation is dedicated to my family and friends for their
love, deep understanding, endless patience and encouragement at
all times.
ACKNOWLEDGEMENTS
First of all, I thank Almighty ALLAH for his mercy, help and guidance, without
which this work would not have been possible.
I would like to express my heartiest gratitude to Prof. Dr. Habibullah Jamal,
who is my Supervisor, without his efforts and interest, this work could not
have been possible to complete. He, as Vice Chancellor, has always
emphasized on higher education and advance studies in the University. He
tried to promote a culture of research and technological development.
I am also grateful to the members of my Research Monitoring Committee: Dr.
Mohammad Saleem Mian, Dr. M. Khawar Islam and specially Dr. Shoab A.
Khan for his significant contribution to this research. He influenced and guided
me throughout as a member of the Research Monitoring Committee as well
as an expert in this field.
I highly appreciate the help of Dr. Muid ur Rehman Mufti for his technical
support, especially in testing related experimentation and preparation of
research paper for HEC approved journal.
I owe my parents for every success in my life. Their encouragement and
support is a key factor in every achievement that I have ever made. I am also
indebted to my wife, for her patience and understanding during the course of
my PhD. I would also like to thank my children, for their love for the happiness
and motivation that I always find from their smiles.
I would like to thank all the members of Faculty of Electronics and Electrical
Engineering and staff of Center of ASIC Design and DSP for their technical
support, especially the help of Mr. Hassan Bhatti is unforgettable.
I am grateful to all the people who had given me support during my research
and accomplishing this dissertation, especially Dr. Qaisar uz Zaman Khan
Director Advance Studies Research and Technological Development for his
cooperation and encouragement to realize this goal.
TABLE OF CONTENTS
ABSTRACT ....................................................................................................... 2
ACKNOWLEDGEMENTS ................................................................................. 4
LIST OF FIGURES ............................................................................................ 7
LIST OF TABLES ............................................................................................. 9
1 INTRODUCTION ....................................................................................... 10
1.1 TESTING APPROACHES 11
1.2 BLACK-BOX AND WHITE-BOX TESTING 12 1.2.1 Black-box Testing 12 1.2.2 White-box Testing 13 1.2.3 Comparison of Black-box and White-box Approaches 14 1.2.4 Hardware based White-box Testing 15 1.2.5 Hardware Testing Agent 15
1.3 TESTING TERMINOLOGIES 16
1.4 FAULT MODELS 17 1.4.1 Stuck-at Faults 18 1.4.2 Transistor Fault 18 1.4.3 Open and Short faults 18 1.4.4 Delay Faults and Crosstalk 19
1.5 OVERVIEW OF DISSERTATION 20
1.6 REFERENCES 21
2 TESTING: AN OVERVIEW AND PRESENT TRENDS ............................ 22
2.1 TECHNIQUES OF IC TESTING 22
2.2 AUTOMATIC TEST EQUIPMENT (ATE) 23 2.2.1 Automatic Test Pattern Generation (ATPG) 24 2.2.2 Digital Circuit Testing 25
2.3 DESIGN FOR TEST (DFT) 25
2.4 Boundary Scan testing 28
2.5 NEW TRENDS FOR IC TESTING 30 2.5.1 Design for Debug (DFD) 30 2.5.2 DFD Instruments 31 2.5.3 Hidden In-Circuit Emulator (HidICE) 32
2.6 ASSERTION BASED SILICON TESTING 33
2.7 SYSTEM VERILOG 35 2.7.1 Design Features 35 2.7.2 Verification Features 35
2.8 REFERENCES 37
3 HARDWARE REMOVABLE CHECKER CIRCUITS ................................ 40
3.1 BASIC IDEA 40
6
3.2 TESTING OF SIMPLE CIRCUITS 41 3.2.1 Accumulator Register 41 3.2.2 Finite State Machine 43
3.3 TESTING OF INTERFACE PROTOCOLS 44 3.3.1 Assume-Guarantee 44 3.3.2 Hierarchical Protocol Checker 46
3.4 TESTING OF RISC PROCESSOR 47
3.5 TIMING ANALYSIS 51
3.6 AUTOMATED HARWARE TESTING/VERIFICATION 51 3.6.1 White-Box Verification Tool for FPGAs 52
3.7 CONTEMPORARY ASSERTION CHECKER GENERATOR 55
3.8 REFERENCES 56
4 HARDWARE RECONFIGURABLE TEST AGENT .................................. 58
4.1 IEEE 802.11e MAC PROTOCOL 58
4.2 ARCHITECTURAL OVERVIEW OF THE TESTING AGENT 60 4.2.1 Test Agent Components 60 4.2.2 Test Agent Interfaces 62 4.2.3 Flexibility of Test Agent 63
4.3 AGENT DESIGN FOR IEEE 802.11e NETWORK STACK 63 4.3.1 Test Agent Implementation 64
4.4 TEST EXAMPLES ON IEEE 802.11e 64 4.4.1 RTS-CTS Test Example 66 4.4.2 AIFS Test Example 68
4.5 HARDWARE LOGGING AGENT (HLA) 68
4.6 REFERENCES 70
5 IMPLEMENTATION OF WHITE BOX TEST AGENT ON A RISC PROCESSOR CORE ................................................................................. 71
5.1 INSTRUCTION SET 72
5.2 ON-CHIP TEST AGENT 75
5.3 SYNTHESIS RESULTS 76 5.3.1 Processor Synthesis without Test Agent 76 5.3.2 Processor Synthesis with Test Agent 82
5.4 REFERENCES 84
6 CONCLUSIONS ........................................................................................ 85
APPENDICES ................................................................................................. 86
A. Complete Area Report of RISC Processor (with Test Agent) 86
LIST OF FIGURES
Figure 1.1 Transistor Count and Moore's Law............................................ 10
Figure 1.2 General Testing Mechanism...................................................... 11
Figure 2.1 Basic BIST Architecture ............................................................. 27
Figure 2.2 Hierarchical DFT Implementation .............................................. 29
Figure 2.3 Typical Functional Debug setup ................................................ 31
Figure 2.4 Principle of HidICE .................................................................... 33
Figure 3.1 Basic Idea (Si testing Si) ........................................................... 40
Figure 3.2 Tester Circuit Details ................................................................. 41
Figure 3.3 Accumulator Register with Tester Circuit .................................. 42
Figure 3.4 Waveform: Accumulator with Tester ......................................... 43
Figure 3.5 State Diagram of Moore Machine .............................................. 43
Figure 3.6 Simulation result of Moore type State Machine with Tester ...... 44
Figure 3.7 Block diagram of Assume-Guarantee ....................................... 45
Figure 3.8 Simulation result of Assume Guarantee .................................... 45
Figure 3.9 Block diagram: Hierarchical Protocol Checker .......................... 46
Figure 3.10 Waveform: Hierarchical Protocol Checker ................................ 46
Figure 3.11 Block diagram: RISC Processor ................................................ 47
Figure 3.12 Simulation results: ALU, Memory and RegisterFile ................... 49
Figure 3.13 Working Mechanism of Processor ............................................. 50
Figure 3.14 Factorial through RISC Processor: Simulation result ................ 50
Figure 3.15 AWB Verification Tool ................................................................ 52
Figure 3.16 Schematic flow: AWB tool ......................................................... 54
Figure 3.17 Boule’s Hardware Checker and debugging enhancements ...... 56
Figure 4.1 IEEE 802.11e, AIFS Based Prioritised Transmission ............... 59
Figure 4.2 Software Architecture of 802.11e MAC ..................................... 60
Figure 4.3 Architectural Design of 802.11e, integrated With Test Agent ... 61
Figure 4.4 Design of Testing Agent ............................................................ 62
Figure 4.5 AIFS Test, Under Different Traffic Conditions ........................... 68
Figure 4.6 Architecture of Hardware Logging Agent .................................. 69
Figure 4.7 Simulation result: Working of HLA ............................................. 70
Figure 5.1 RISC Processor: Block diagram ................................................ 74
8
Figure 5.2 ASMD of the RISC Processor ................................................... 75
Figure 5.3 Block Diagram: RISC Processor with Test Agent ..................... 76
Figure 5.4 Synthesized RISC Processor .................................................... 77
Figure 5.5 Control Unit: circuit diagram ...................................................... 78
Figure 5.6 Datapath: circuit diagram ........................................................... 79
Figure 5.7 Register File: circuit diagram ..................................................... 80
Figure 5.8 ALU: circuit diagram .................................................................. 81
Figure 5.9 Synthesized RISC Processor with Test Agent .......................... 82
Figure 5.10 Synthesized Test Agent (detailed) ............................................ 83
9
LIST OF TABLES
Table 3.1 Instruction set of RISC Processor 47
Table 3.2 Time Comparison 51
Table 4.1 Percentage Areas of Different Modules of DUT 64
Table 4.2 Trigger Logic of RTS-CTS Test 67
Table 5.1 Instruction Set of RISC Processor 73
C
1
T
b
m
tr
w
m
d
to
[1
T
o
CHAPTER
INT
The Moore’s
e true unti
million trans
ransistors o
which conta
million plus
evices hav
oday’s com
1].
This all is th
f microns to
R 1
TRODUC
s Law (196
il now. In
sistors, whic
on a single
ained more
transistors
ving two th
mputers and
Figure
e result of d
o ten’s of n
CTION
65), the sca
1980’s the
ch has cha
e chip now
e than one
were desig
housand m
d electronic
1.1 Tra
decrease in
nanometers
ale of ICs d
term VLS
nged to mi
w. In 1986 f
million tra
gned in ea
illions of tr
cs as show
nsistor Coun
n the featur
s, and with c
doubles eve
SI was used
llions and h
first megab
ansistors. M
rly nineties
ransistors a
wn in Figure
nt and Moore
re size of th
current sub
ery 18 mon
d for chips
hundreds o
bit RAM wa
Microproces
s. Processo
are commo
e 1.1, repro
e's Law
he transisto
bmicron tec
ths, looks t
s having 0.
of millions o
as launche
ssors with
ors and VLS
only used
oduced from
rs from ten
chnologies o
to
.1
of,
ed
3
SI
in
m
’s
of
le
p
re
d
st
a
re
o
a
le
A
p
b
1
C
p
c
o
st
p
u
re
c
a
d
ess than 10
apers wer
eduction in
esigning a
tructured a
t various
equired to e
of ten, whic
s we move
evel to syste
A verificatio
rioritizing v
lock will be
.1 TEST
Checking th
rocess [3].
an make
perating fr
tage to fin
roducts. In
nder test (C
esponses o
ircuit with n
re applied
etect a corr
00nm. In I
re present
n the featu
and manuf
approach fo
levels, thro
ensure the
ch says tha
e through e
em level an
n plan star
verification
e verified.
TING APP
e correctne
A very sm
the entire
requencies.
nal operatio
general te
CUT) and t
of a fault-fre
n inputs an
to the CU
rect or wron
Fig
EEE Desig
ted discus
ure size in
facturing p
or IC design
ough desig
fault free p
t the cost o
ach stage
nd finally to
rts first by
tasks and
PROACHE
ess is the m
mall numbe
chip to fa
. Therefore
on in the
sting consis
then compa
ee circuit. T
nd m outpu
UT and the
ng respons
ure 1.2 G
gn Automat
sing issue
ncreases t
phases. Th
ning becom
gn stage to
products. Th
of detecting
of manufac
system op
identifying
finally to d
ES
most crucia
er may be o
ail or not
e testing a
field, is re
sts of apply
aring the ou
The figure
ts. Set of i
e outputs o
se.
General Test
tion Confer
es regardin
he probab
herefore, a
mes a nece
o final ope
here is a ge
g a bug in t
cturing, from
peration in t
all the bloc
determine
l and difficu
only one, f
to function
at various
equired to
ying some t
utput respo
1.2 shows
nput patter
of the CUT
ting Mechan
rence (DAC
ng 22/20n
bility of def
a systemat
essity. More
eration in
eneral agre
the IC incre
m device le
he field.
cks to be v
when and
ult aspect o
faulty trans
n properly
levels, thro
ensure th
test inputs
nses with t
this test sc
rns, called
T are then
ism
C ’09) man
m [2]. Th
fects in th
ic and we
eover testin
the field,
eement, rul
eases by te
evel to boar
verified, the
how a sub
of the desig
sistor or wir
at require
ough desig
he fault fre
to the circu
the expecte
cenario for
test vectors
analyzed t
ny
he
he
ell
ng
is
le
en
rd
en
b-
gn
re
ed
gn
ee
uit
ed
a
rs,
to
12
In practice simulations are still the most oldest and common way of design
validation. Simulations are applied to verify circuits at various stages of the
design process. Error modeling, test vector generation and response
comparison are common with testing through simulation [3]. Test generation
methods can be classified into two categories: random or deterministic.
Random testing plays a dominant role in most of the simulation-based
verification methods. Deterministic methods like Automated Test Pattern
Generation (ATPG) address the issue of larger vector sets and to target a
particular fault, especially redundant faults, i.e. the faults that do not introduce
erroneous behavior and cannot be detected by any other test patterns. Now
with the growing circuit complexity, inadequate fault models (due to
impractical sizes of error lists) and too large vector sets simulations alone
might not be able to fully solve the problem of design verification.
Formal methods, which have been derived from software verification methods
developed some forty years ago, have also gained popularity in the hardware
verification. These methods normally target verification of sequential circuits,
particularly finite state machines (FSM). There are two major categories of
formal methods: Model-based and Proof-theoretical. Each of these categories
uses special languages and strict mathematical rules to verify certain
properties of a given circuit. Now a day’s designs in production are also too
large for formal methods [3]. Moreover complete formalization of the
implementation is intractable. Current trend is to use formal methods in
cooperation with simulations.
1.2 BLACK-BOX AND WHITE-BOX TESTING
Within the automated testing world there are two pre-dominating testing
methodologies: black-box Testing and white-box Testing. Here we compare
both of these approaches.
1.2.1 Black-box Testing
Black-box testing is also known as behavioral testing, functional testing and
input/output-driven testing. This testing methodology observes only outputs of
a certain design for some known input patterns. Functionality of the design is
completely specified in terms of its outputs and inputs. It is not concerned with
13
the inner workings of the circuit, the process that the application undertakes to
achieve a particular output or any other internal aspect of the design that may
be involved in the transformation of an input into an output. Black-box
(functional) testing has further two categories: Positive Functional Testing:
valid inputs are applied to get valid outputs and Negative Functional Testing:
invalid inputs are applied to observe un-expected operating conditions or out-
of-bound scenarios at outputs.
1.2.2 White-box Testing
White-box testing is also known as clear box testing, glass box testing,
transparent box testing, or structural testing (Beizer, 1995). White-box testing
is described in IEEE Standard 610.12-1990 as follows: “White-box testing
refers to testing that takes into account the internal mechanism of a system or
component”. The connotations of “clear box” and “glass box” appropriately
indicate that one have full visibility of the internal workings of the design/
product, specifically, the logic and the structure of the circuit [4].
There are various types of testing: unit, integration, function/system,
acceptance, regression, and beta etc. White-box testing can be used on three
of these types:
• Unit testing: is testing of individual hardware or software units or groups of
related units (IEEE, 1990). A unit is a software component that cannot be
subdivided into other components (IEEE, 1990). Engineers write white-box
test cases to examine whether the unit is coded correctly. Unit testing is
important for ensuring the code is solid before it is integrated with other
code. Once the code is integrated into the code base, the cause of an
observed failure is more difficult to find. Approximately 65% of all bugs can
be caught in unit testing (Beizer, 1990).
• Integration testing: is testing in which software components, hardware
components, or both are combined and tested to evaluate the interaction
between them (IEEE, 1990). Test cases are written which explicitly examine
the interfaces between the various units. These test cases can be black box
test cases, whereby the tester understands that a test case requires multiple
14
program units to interact. Alternatively, white-box test cases are written
which explicitly exercise the interfaces that are known to the tester [4].
• Regression testing: is a selective re-testing of a system or component to
verify that modifications have not caused unintended effects and that the
system or component still complies with its specified requirements (IEEE,
1990). Integration and regression testing can be done via black-box test
cases, white-box test cases, or a combination of the two. White-box unit and
integration test cases can be saved and re-run as a part of regression
testing [4].
1.2.3 Comparison of Black-box and White-box Approaches
White-box testing methodology looks under the covers and into the
subsystems of a circuit whereas black-box testing concerns itself exclusively
with the inputs and outputs of an application. White-box testing provides a
degree of sophistication, as the tester is able to refer to and interact with the
objects that comprise a circuit rather than only having access to the user
interface.
The main difference between black-box and white-box testing is the areas on
which they choose to focus. In simplest terms, black-box testing is focused on
results. If an action is taken and it produces the desired result then the
process that was actually used to achieve that outcome is irrelevant. White-
box testing, on the other hand, is concerned with the details. It focuses on the
internal workings of a system and only when all avenues have been tested
and the sum of an application’s parts can be shown to be contributing to the
whole is testing complete.
For black-box testing, the focus is on the user experience whereas white-box
testing focuses on the internal and making sure that the circuit works as
efficiently as possible (or at least as designed). Therefore, these two
methodologies can be seen as complimentary and for organizations that have
the budget and time available to take advantage of both, they should certainly
do so [5].
15
1.2.4 Hardware based White-box Testing
Based on the definitions of white box testing, presented above, the idea of
hardware based white box testing becomes possible by the help of field
programmable gate arrays (FPGAs) which permit significant reuse of design
tests in verification because of their regular structure and similarity between
different generations of products. It was observed that the design mapped
onto FPGA enriched with such code segments which can monitor the targeted
design during emulation and can halt the emulation if an unexpected or
undesired behaviour comes across are much beneficial for testing purposes.
This type of testing can be termed as “hardware based white box testing”
because design is running on the actual hardware with all real time
constraints and we can probe inside the circuit with the help of these
additional code segments. In this case the designers need not work extra for
verification of the target design. The size of the target design also does not
increase as the code for testing elements is included as comments in the
original design file. A special software tool was developed which translates
these comments into synthesizable RTL code segments and produces a new
design file. These monitoring entities are named as checkers or assertions
which instantiate, after synthesis of new design file, as hardware entities
along with the original design for testing purposes only. Detail of this type of
testing with experimental results is presented in chapter 3.
1.2.5 Hardware Testing Agent
Another key concept tested and presented in this thesis is of a “Hardware
Test Agent” within the DUT as an embedded layer. This agent can be
designed such that it can dynamically be configured to adapt according to the
changes and requirements of the design implemented. We observed that by
having such a flexible test agent, inside the DUT, functionality of the design
can be tested in real-time under real world environment. Such in-system
online testing gives better observability and more confidence on the reliability
of the system under test. This setup, with some extra circuitry for testing
agent, provides extensive tests at real time at the cost of approximately
5~10% additional chip area. With the help of this testing agent internal
sections of the design can be monitored during normal running of the device.
16
With the help captured data, within the test agent, faulty sections of the design
can be identified easily. Detail of this type of testing with experimental results
is presented in chapter 4.
1.3 TESTING TERMINOLOGIES
Fault is a representation of a defect reflecting a physical condition that causes
a circuit to fail to perform in a required manner.
Failure is a deviation in the working of a circuit or system from its specified
behavior, and it must to be repaired to provide intended design function.
An Error is a wrong output signal produced by a defective circuit. A circuit
defect may lead to a fault, a fault can cause a circuit error, and a circuit error
can result in a system failure.
On-Line and Off-Line Testing: The testing may be in the form of online,
which is performed concurrently with normal system operation in order to
detect failures as quickly as possible, or offline, which requires that the
system or a portion of the system be taken out of service in order to perform
the test, or a combination of both. Normally offline testing is performed
periodically, usually during low-demand periods of system operation. In many
cases, when online testing detects a failure, offline test techniques are then
used for diagnosis (location and identification) of the failing component to
improve the subsequent repair time. After the repair, system is retested using
offline techniques to verify that the repair was successful prior to placing the
system back in service for normal operation.
Structural testing is a practical approach to select specific test patterns
based on the circuit structural information and a set of fault models. Structural
testing saves time and improves test efficiency, as the total number of test
patterns is decreased.
Fault coverage provides a quantitative measure of the fault-detection
capabilities of a given set of test vectors for a targeted fault model. This
measure is expressed as follows:
Fault coverage = Number of detected faults/Total number of faults
17
Williams T. [6] has linked fault coverage to the yield and the defect level as
given in Eq. 1.
Defect level = 1−yield(1-fault coverage) (1)
As a result of above expression, improving fault coverage can be easier and
less expensive than improving manufacturing yield because making yield
enhancements can be costly. Therefore, generating test stimuli with high fault
coverage is very important. Moreover it is important to state here that it may
be impossible to obtain fault coverage of 100% because there always exist
some undetectable faults in the system. An undetectable fault means there is
no test to distinguish the fault-free circuit from a faulty circuit containing that
fault [7].
Test generation is a technique to find an efficient set of test vectors that
detects all faults considered for that circuit. Fault simulation is typically used to
evaluate the fault coverage obtained by that set of test vectors. As a result,
fault models are needed for fault simulation as well as for test generation.
Fault Simulation emulates the target faults in a circuit to determine which
faults are detected by a given set of test vectors. Fault simulation takes much
greater time with respect to the time required by the design verification. To
overcome this problem different techniques are used like: parallel fault
simulation uses parallelism of logical operations in a digital computer,
Deductive fault simulation deduces all signal values in each faulty circuit from
the fault-free circuit values and the circuit structure with some deductive
procedure, concurrent fault simulation is an event driven simulation to emulate
faults in a circuit in the most efficient way [7].
1.4 FAULT MODELS
Fault models are developed for generating and evaluating a set of test
vectors. In general, a good fault model is one that should satisfy two criteria:
first it should accurately reflect the behavior of the defects, and second it
should be computationally efficient in terms of fault simulation and test pattern
generation. Many fault models have been proposed by Miron A. [8], but
unfortunately, no single fault model accurately reflects the behavior of all
18
possible defects that can occur. As a result, a combination of different fault
models is often used in the generation and evaluation of test vectors and test
approaches. Fortunately, it has been shown that high fault coverage obtained
under the single-fault assumption (assuming that there can be only one fault
in the circuit) will result in high fault coverage for the multiple-fault model [9];
therefore, the single-fault assumption is typically used for test generation and
evaluation.
1.4.1 Stuck-at Faults
A stuck-at fault transforms the correct value on the faulty signal line to appear
to be stuck at a constant logic value, either at logic ‘0’ or logic ‘1’, referred to
as stuck-at-0 (SA0) or stuck-at-1 (SA1), respectively. A stuck-at fault affects
the state of logic signals on the lines in a logic circuit, including primary inputs,
primary outputs, internal gate inputs and outputs, fan-out stems (sources),
and fan-out branches. The stuck-at fault model is usually applied on
combinational circuits but can also be applied to sequential circuits; however,
high fault coverage test generation for sequential circuits is much more
difficult than for combinational circuits [7].
1.4.2 Transistor Fault
At the switch level, a transistor can be stuck-open or stuck-short, also referred
to as stuck-off or stuck-on, respectively. The stuck-at fault model cannot
accurately reflect the behavior of stuck-open and stuck-short faults in CMOS
logic circuits because of the multiple transistors used to construct CMOS logic
gates. A stuck-open fault in a CMOS combinational circuit requires a
sequence of two vectors for detection rather than a single test vector for a
stuck-at fault. Stuck-short faults will produce a conducting path between VDD
and VSS, therefore, stuck-short transistor faults can be detected by monitoring
the power supply current, IDDQ, during steady state. This technique to detect
transistor stuck-short faults is called IDDQ testing [7].
1.4.3 Open and Short faults
Defects in VLSI devices can include opens and shorts in the wires that
interconnect the transistors forming the circuit. Opens in wires tend to behave
like transistor stuck-open faults when the faulty wire segment is
19
interconnecting transistors to form gates. On the other hand, opens tend to
behave like stuck-at faults when the faulty wire segment is interconnecting
gates. Therefore, a set of test vectors that provide high stuck-at fault coverage
and high transistor fault coverage will also detect open faults; however, a
resistive open does not behave the same as a transistor or stuck-at fault but
instead affects the propagation delay of the signal path. A short between two
elements is commonly referred to as a bridging fault. These elements can be
transistor terminals or connections between transistors and gates. The case
of an element being shorted to power (VDD) or ground (VSS) is equivalent to
the stuck-at fault model; however, when two signal wires are shorted together,
bridging fault models are required [7].
1.4.4 Delay Faults and Crosstalk
A delay fault causes excessive delay along a path so that the total
propagation delay falls outside the specified limit. Delay faults have become
more prevalent with decreasing feature sizes. There are different delay fault
models: gate-delay fault, a delay fault occurs when the time interval taken for
a transition from the gate input to its output exceeds its specified range,
transition fault, simultaneous transitions at inputs of a gate may change the
gate delay significantly due to activation of multiple charge/discharge paths,
path-delay fault, which considers the cumulative (sum of all gate delays along
the path) propagation delay along a signal path through the CUT. Therefore,
the path-delay fault model is more practical for testing than the gate-delay
fault (or the transition fault) model [7].
Crosstalk is also an important consideration, cross-coupling capacitance and
inductance between interconnects increases, mainly due to nanometer
technologies, leading to severe crosstalk effects that may result in improper
functioning of a chip. There are two categories of crosstalk effects: crosstalk
glitches; a pulse that is provoked by coupling effects among interconnect
lines, and crosstalk delays; a signal delay that is provoked by the same
coupling effects among interconnect lines. Because crosstalk causes a delay,
in addition to normal gate and interconnect delay, it is difficult to estimate the
true circuit delay, which may lead to severe signal delay problems. Several
design techniques, including physical design and analysis tools, are being
20
developed to help design for margin and minimization of crosstalk problems.
However, it may be impossible to anticipate in advance the full range of
process variations and manufacturing defects that may significantly aggravate
the cross-coupling effects. Hence, there is a critical need to develop testing
techniques for manufacturing defects that produce crosstalk effects [3].
1.5 OVERVIEW OF DISSERTATION
The dissertation is organized as follows:
Chapter 1 has introduced importance of testing/verification, elaborated the
concept of black-box and white-box testing, introduced hardware checkers
and hardware testing agent; defined the necessary terminology and described
different type of fault models.
Chapter 2 describes the theoretical background of testing/verification of
circuits/ICs and a review of present trends and methodologies used in the
industry and by the scientists all over the world. Assertion Based testing:
SystemVerilog, a software language, which deals with assertions, is
described.
Chapter 3 gives detail of the idea/concept of removable hardware checkers/
testers and elaborates it with the help of different design examples; sequential
circuits, protocol checkers and a RISC processor. Time comparison between
simulation and design implemented on FPGA is also given. Hardware checker
generation with the help of White Box Verification Tool is explained.
Chapter 4 presents experimental results of an SoC, IEEE 802.11e MAC,
using the idea of an embedded Hardware Reconfigurable Test Agent present
inside the DUT. Design and working of this test agent along with some
experimental results for few test scenarios are described in this chapter. An
idea of system recovery with the help of Hardware Logging Agent is also
presented.
Chapter 5 is dedicated for detailed experimental results which were
performed on a RISC processor with our proposed testing agent
methodology. This design written in Verilog HDL is synthesized on Mentor
Graphics tools for ASIC design.
21
Chapter 6 concludes the dissertation and gives recommendations for future
work.
1.6 REFERENCES
[1] http://commons.wikimedia.org/wiki/User:Wgsimon
[2] Cong, J. et al., “Moore’s Law: Another Casualty of the Financial Meltdown?”, in
proc. of 46th IEEE Design Automation Conference (DAC’09), California USA,
pp. 202-203, July 26-31, 2009
[3] Radecka K. and Zilic Z., “Verification by error modeling: Using Testing
Techniques in Hardware Verification”, Kluwer Academic publisher, 2003
[4] Williams L., “White-Box testing”, www.agile.csc.ncsu.edu/SEMaterials/ , 2006
[5] “Black-Box vs White-Box Testing: Choosing the right approach to deliver
quality applications”, Redstone Software Inc. www.redstonesoftware.com, 2009
[6] Williams T.W. and Brown N.C., “Defect level as a function of fault coverage”,
IEEE Trans. on Computers, Vol. C-30, Issue 12, pp. 987–988, 1981
[7] Min Y. and Stroud C., “VLSI Test Principles and Architectures: Design for
Testability”, chapter 1, Morgan Kaufmann Publishers, Elsevier Inc., 2006
[8] Abramovici M., Breuer M.A. and Friedman A.D., “Digital Systems Testing and
Testable Design”, IEEE Press, Piscataway, NJ, 1994
[9] Bushnell M.L. and Agarwal V.D., ”Essentials of Electronic Testing for Digital,
Memory and Mixed-Signal VLSI Circuits”, Springer Science, New York, 2000
22
CHAPTER 2
2 TESTING: AN OVERVIEW AND PRESENT TRENDS The verification/testing of ICs is now no more a back-end issue, but it has
become a front-end burning issue of today. In this chapter a brief history of
testing methodologies is discussed. Moreover current challenges and trends
are presented with respect to test generation, testing times, testing speeds,
test scheduling, test access mechanism, controllability of inputs, observability
of outputs and testing cost, it is estimated that presently testing costs around
30-50% of the total product cost to an electronic manufacturer [1]. In spite of
huge efforts in design verification, errors are still found in about two thirds of
newly manufactured SoCs [12]. ITRS (International Technology Roadmap for
Semiconductors) states that time to locate the root cause of a problem grows
exponentially with the advancement in the process technology that produces
larger, denser and complex designs.
2.1 TECHNIQUES OF IC TESTING
A brief overview of IC testing approaches/techniques is presented in this
section.
Exhaustive approach: where all possible combinations of input test vectors
are generated and applied to the device under test (DUT), normally a
combinational circuit. A circuit with n number of inputs will have 2n input
combinations which can be generated by some type of counter. This
technique offers 100% of fault coverage with low computational cost [2].
However with inputs roughly greater than twenty test lengths become very
long.
Pseudo-exhaustive approach: DUT is logically partitioned into smaller parts
and then each part is tested exhaustively by much fewer test vectors.
Deterministic approach: allows DUT to be examined at the beginning of the
test and test vectors are generated using any suitable algorithm for
deterministic test pattern generation. This enables error signals to be
23
generated due to presence of faults and propagate them to some observable
output form.
Pseudo-random technique: generates a set of pseudo-random vectors from
all the possible input patterns. By this way a large number of tests can be
generated using smaller data storage. The low fault coverage of this approach
can be improved by the weighted random approach. It has a disadvantage
that a pre-processing is necessary to calculate the signal probabilities which is
not always very accurate. A combination of these techniques can be
incorporated as a mixed-mode approach. The above mentioned techniques
have different drawbacks like computational complexities, longer test times
are required, larger volume of data to be stored, have lack of flexibility etc. [3].
2.2 AUTOMATIC TEST EQUIPMENT (ATE)
In the 1960s, when ICs were first introduced, IC testers controlled by a
minicomputer were developed, and became the starting point of ATE industry
to establish. ATE is computer-controlled equipment used in the testing of ICs
which provides far greater test coverage (at the wafer level and in packaged
devices) and PCBs. Test patterns are applied to the DUT and the output
responses are compared to stored responses for the fault-free circuit. With
advances in the VLSI and computer technology, the ATE industry has
developed electronic subassemblies (PCBs and backplanes), test systems,
digital IC testers, analog testers, and SOC testers. A custom tester is often
developed for testing a particular product, but a general-purpose ATE is often
more flexible and enhances the productivity of high-volume manufacturing.
Generally, ATE consists of the following parts:
1. Computer: A powerful computer is the heart of any ATE for central control.
2. Pin electronics and fixtures: The pin electronics is responsible for formatting
test vectors to produce waveforms of the desired shape and timing and are
also responsible for sampling the DUT output responses at the desired time.
Current VLSI devices may have over 1000 pins and require a tester with as
many as 1024 pin channels. As a result, the pin electronics and fixtures
constitute the most expensive part of the ATE.
24
3. Test pattern generator and comparator: Test patterns are generated using
Automatic Test Pattern Generation (ATPG) algorithms. These test patterns
are applied to the inputs of the DUT and ATE captures primary output
responses, which are then translated to output vectors for comparison with
the fault-free responses. These translations and comparisons are controlled
by the central computer.
4. Digital Signal Processor (DSP): Powerful DSP techniques have also been
widely applied to analog testing for capturing analog characteristics at high
frequencies.
ATE based testing is slow, equipment costs are high and needs a huge
amount of data to be processed and makes cost of testing even greater than
the cost of making it [4]. Moreover, real-world, real-time corner cases cannot
be tested because the operating frequency of ATE is always less than the
actual production ICs. Ideally, the operational frequency of ATE should be
much higher than that of the ICs under test. Unfortunately, this is difficult
because the ATE itself is also constructed from the ICs and limited by their
maximum operating frequency [5].
2.2.1 Automatic Test Pattern Generation (ATPG)
A complete ATPG algorithm, called the D-algorithm, was first published by
Roth J. in 1966. The next landmark effort in ATPG was the PODEM algorithm
proposed by Goel P. in 1981. Since then many commercial ATPG tools have
appeared: for example, FAN by Fujiwara (1983) and SOCRATES by Schulz
(1988) were remarkable contributions to accelerating the ATPG process. A
common approach in ATPG tools is to start from a random set of test
patterns. Fault simulation then determines how many of the potential faults
are detected. With the fault simulation results used as guidance, additional
vectors are generated for hard-to-detect faults to obtain the desired or
reasonable fault coverage. The International Symposium on Circuits and
Systems (ISCAS) announced combinational logic benchmark circuits in 1985
and sequential logic benchmark circuits in 1989 by Brglez F. to assist in
ATPG R&D in the international test community. A major problem in large
combinational logic circuits with thousands of gates was the identification of
25
undetectable faults. In the 1990s, very fast ATPG systems were developed
using high-performance computers which provided 100% fault detection
efficiency. Therefore, ATPG for combinational logic is no longer a problem but
for sequential logic ATPG is still not fully workable.
2.2.2 Digital Circuit Testing
Digital testing is also improved by monitoring the quiescent power supply
current (IDDQ). Normally, the leakage current of CMOS circuits under a
quiescent state is very small and negligible. When a fault occurs, such as a
transistor stuck short or a bridging fault, it causes a conducting path from
power to ground, and may draw an excessive supply current. IDDQ testing
became an accepted test method for the IC industry in the 1980s but with
VLSI devices normal fault-free IDDQ has become quite large due to the
collective leakage currents of millions of transistors on a chip. Therefore, IDDQ
testing is becoming ineffective.
2.2.3 Analog and Mixed-Signal Circuit Testing
Analog circuits are used in various applications and due to the different types
of circuitry involved, several different schemes to test a mixed-signal chip are
usually required. Test methods for analog circuitry and converters have not
achieved maturity comparable to that for digital circuitry. Traditionally, the
analog circuitry is tested by explicit functional testing to directly measure
performance parameters, such as linearity, frequency response (phase and
gain), or signal-to-noise ratio. The measured parameters are compared
against the design specification tolerance ranges to determine if the device is
faulty or operational within the specified limits. Long test application times and
complicated test equipment are often required, making functional testing very
expensive. Recently, defect-oriented test approaches based on fault models,
similar to those used in digital testing, have been investigated for reducing the
cost for functional testing of the analog circuits [6].
2.3 DESIGN FOR TEST (DFT)
DFT is a philosophy of considering the testing of the circuit at the design
stage; this eases the burden of external testing. Test engineers usually
26
construct test vectors after the design is complete. This requires an excess
amount of time and effort that could be avoided if testing is considered early in
the design flow. The idea: design for testability (DFT), integration of design
and test simultaneously, was first proposed in 1970s. To structurally test
circuits, it is needed to control and observe logic values of internal lines.
Unfortunately, some nodes in sequential circuits can be very difficult to control
and observe. Testability measures of controllability and observability were first
defined by Goldstein in 1979, to help find those parts of a digital circuit that
will be most difficult to test and to assist in test pattern generation for fault
detection [7]. DFT techniques fall into following three categories: (1) Partition
method or Ad-hoc DFT techniques, (2) Level-Sensitive Scan Design (LSSD)
or simply Scan Design, and (3) Built-in Self-Test (BIST).
2.3.1 Ad-hoc DFT Technique
in this technique the circuit is partitioned and those portions of the circuit are
targeted that would be difficult to test and to add circuitry to improve the
controllability or observability. In this technique typically a test point is inserted
to access internal nodes directly.
2.3.2 Level Sensitive Scan Design (LSSD)
LSSD is a method for sequential circuits in which testability is improved by
adding extra logic to each flip-flop in the form of a shift register, or scan chain.
During the scan mode, the scan chain is used to shift in (or scan in) a test
vector to be applied to the combinational logic. During one clock cycle in the
system mode of operation, the test vector is applied to the combinational logic
and the output responses are clocked into the flip-flops. The scan chain is
then used in the scan mode to shift out (or scan out) the combinational logic
output response to the test vector while shifting in the next test vector to be
applied. As a result, LSSD reduces the problem of testing sequential logic to
that of testing combinational logic and thereby facilitates the use of ATPG
developed for combinational logic.
2.3.3 Built-in Self-Test (BIST)
BIST was proposed around 1980 by Bardell (1982) and Stroud (2002). In
BIST test circuitry is integrated inside the circuit in the form of Test-Pattern
27
Generator (TPG) and an Output Response Analyzer (ORA) to perform testing
internal to the IC, as shown in Figure 2.1. The TPG automatically generates
test patterns for application to the inputs of the DUT. The ORA automatically
compares the output responses of the DUT into a signature. Specific BIST
timing control signals, including scan enable signals and clocks, are
generated by the logic BIST controller for coordinating the BIST operation
among the TPG, CUT, and ORA [9].
Figure 2.1 Basic BIST Architecture
There are two general categories of BIST techniques for testing random logic:
(1) online BIST and (2) offline BIST [8]. Online BIST is performed when the
functional circuitry is in normal operational mode. It can be done either
concurrently or non-concurrently. In concurrent online BIST, testing is
conducted simultaneously during normal functional operation. The functional
circuitry is usually implemented with coding techniques or with duplication and
comparison [8]. When an intermittent or transient error is detected, the system
will correct the error on the spot, rollback to its previously stored system
states, and repeat the operation, or generate an interrupt signal for repeated
failures. In non-concurrent online BIST, testing is performed when the
functional circuitry is in idle mode. This is often accomplished by executing
diagnosis software routines (macrocode) or diagnosis firmware routines
(microcode) [8]. The test process can be interrupted at any time so that
normal operation can resume.
Offline BIST is performed when the functional circuitry is not in normal mode.
This technique does not detect any real-time errors but is widely used in the
BIST Mode
Primary I/Os
Pass/Fail
Device under Test (DUT)
Output Response Analyzer (ORA)
BIST LOGIC
Controller
Test Pattern Generator (TPG)
28
industry for testing the functional circuitry at the system, board, or chip level to
ensure product quality. Offline BIST is further categorized in Functional and
Structural techniques. In first case it performs a test based on the functional
specification of the functional circuitry and often employs a functional or high-
level fault model. Normally such a test is implemented as diagnostic software
or firmware. Structural offline BIST performs a test based on the structure of
the functional circuitry. The BIST schemes discussed here all assume that the
functional storage elements of the circuit are converted into a scan chain or
multiple scan chains for combinational circuit testing.
However, there are also disadvantages associated with this approach. More
stringent BIST-specific design rules are required to deal with unknown
sources originating from analog blocks, memories, non-scan storage
elements, asynchronous set/reset signals, tri-state buses, false paths, and
multiple-cycle paths etc. Also, because pseudo-random patterns are mostly
used for BIST pattern generation, additional test points (including control
points and observation points) may have to be added to improve the circuit’s
fault coverage [9]. DFT features are appropriate for internal unit tests of an
SoC but it lacks in the region of dynamic tests under real operating conditions
and this cannot be filled by software based self tests [10]. One way of
improving the testability of the system is to adopt a structured hierarchical
design methodology and a corresponding hierarchical test methodology. The
technique for hierarchical DFT implementation is presented in [11] as shown
in Figure 2.2.
2.4 Boundary Scan testing
In the mid-1980s, the Joint Test Action Group (JTAG) proposed a boundary
scan standard, approved in 1990 as IEEE Standard 1149.1. Boundary scan,
based on the basic idea of scan design, inserted logic to provide a scan path
through all I/O buffers of ICs to assist in testing the assembled PCB. The scan
chain provides the ability to shift in test vectors to be applied through the pad
to the pins and interconnections on the PCB. The output responses are
captured at the input buffers on other devices on the PCB and subsequently
shifted out for fault detection. Thus, boundary scan provides access to the
29
various signal nodes on a PCB without the need for physical probes. The Test
Access Port (TAP) provides access to the boundary scan chain through a
four-wire serial bus interface in conjunction with instructions transmitted over
the interface.
Figure 2.2 Hierarchical DFT Implementation
The boundary scan interface also provides access to DFT features, such as
LSSD or BIST, designed and implemented in the VLSI devices for board and
system-level testing. The boundary scan description language (BSDL)
provides a mechanism with which IC manufacturers can describe testability
features in a chip. In 1999, another boundary scan standard, IEEE 1149.4
was adopted for mixed-signal systems; it defines boundary scan cells as well
as a TAP for the analog portion of the device. In 2003, an extended boundary
scan standard for the I/O protocol of high-speed networks, namely 1149.6,
was approved. System-on-chip implementations face test challenges in
addition to those of normal VLSI devices. SOCs incorporate embedded cores
that may be difficult to access during testing. The IEEE P1500 working group
was approved in 1997 to develop a scalable wrapper architecture and access
mechanism similar to boundary scan for enabling test access to embedded
cores and the associated interconnect between embedded cores. This
System Testability Requirements
Subsystem Testability Requirements
Board Test Requirements
Component Test Requirements
Testability Requirement
DFT/BIT Implementation
30
proposed P1500 test method, approved as an IEEE 1500 standard in 2005, is
independent of the underlying functionality of the SOC or its individual
embedded cores and creates the necessary testability requirements for
detection and diagnosis of faults for debug and yield enhancement.
2.5 NEW TRENDS FOR IC TESTING
Scientists/researchers are working on different aspects of testing ICs and
designs for many years. A brief overview is presented in this section.
2.5.1 Design for Debug (DFD)
Design for Debug (DFD) is an act of adding debug support to a chip’s design
in the realization. DFD is considered good in the fast bring-up of prototype
silicon and in the analysis of field returns. Moreover it gives increased
observability of an embedded system’s internal operations. Vermeulen B. and
Goel provided a good overview of this technique in [12]. Designers use two
approaches of DFD, run-stop debug and real-time trace debug, to transport
valuable internal information [13]. To support run-stop debug three functions
are to be added to an embedded SoC: breakpoints, execution control and
internal-state access. In this technique execution control starts the system
and then stops it at a breakpoint to allow inspection of the system state.
Debugger can also be operated at single-step, to get some particular
granularity, or to restart or to resume. This debug functionality can be
controlled via a low speed serial debug interface. In real-time trace debug
internal signals are brought out of the chip, through some dedicated or shared
pins, to increase the internal observability of the system. One advantage of
this technique is that state of internal signals is observable for a long time to
detect timing related problems between signals. On the other hand this
method restricts the number of internal signals that can be observable. Many
different solutions scientists have developed to overcome this limitation:
Output multiplexers can be placed before output pins, an internal trace buffer
can be implemented to store the status of the system which can later be read
out through some debug interface. Figure 2.3 shows an example of typical
functional debug setup.
31
Figure 2.3 Typical Functional Debug setup
This setup includes a debugger tool running on some computer to control and
analyze the behavior of on-chip CPUs and other hardwired peripherals. Bart
Vermeulen, of NXP Semiconductors, presented functional debug techniques
for embedded systems with different experimental results in [14]. Test results
of audio and video devices like Co-Processor array, PNX8525 and Codec
were shown in the paper, which were tested by the debug engineers to locate
the root cause of erroneous behavior in early prototype Silicon.
2.5.2 DFD Instruments
Pre-Silicon verification techniques: simulation, emulation, FPGA Prototyping,
Timing Analysis and Formal verification do not address many deep submicron
problems that occur in the actual devices. Specially system-level verification
at or below 90 nm is not feasible pre-Silicon. Therefore Silicon Validation,
certifying that a chip works correctly under varying operating conditions, at-
speed and in-system becomes an essential step in design implementation
[15]. Miron A. et al., at DAFCA (Design Automation for Flexible Chip
Architectures), introduced a new approach to in-system Silicon Validation, in
the pre-Silicon stage, ‘DFD Instruments’: a reconfigurable infrastructure for
SoCs to support at-speed in-system functional verification [16]. They inserted
a distributed reconfigurable fabric in to the RTL model of the SoC and than
generated an instrumented RTL model to provide a debug platform that can
be operated post-Silicon via JTAG port. Standard synthesis-based design
flows can process these instrumented RTLs. There are several types of DFD
instruments, for example: Signal Probe Network (SPN) is a MUX network that
Embedded System
Debug Control
Debug Trace data
Debugger Tool
32
selects a sub-group of signals to bring to processing instrument, Debug
Monitor (DEMON) analyzes a group of signals, Wrapper which has a signal
analyzing features, Tracer contains a buffer memory to record input signals
etc. The ClearBlue solution [16], designed by DAFCA, offers different
validation and debug structures, like signal capture, logic analysis, on-chip
functional block test, assertion checkers, transaction identifiers, triggers, event
counters, fault injection and in-system scan dumps etc. In [16] test results of
above mentioned technique on four devices: Serial ATA controller, ARM9
SoC platform, ARM9 Processor and MIPS digital TV controller are given. It is
claimed that combination of embedded logic analysis, on-chip functional-block
test, at-speed assertion check and in-system scan dumps for complete
register observability creates a very powerful breakthrough solution for in-
system at-speed silicon validation and debug.
2.5.3 Hidden In-Circuit Emulator (HidICE)
Lange A. and Weiss A. patented a new methodology referred as hidICE
(hidden In-Circuit Emulator) for capturing trace data and to observe an SoC
with a facility that allows synchronization with an external emulator [17]. This
technology significantly increases the test coverage of an SoC, especially in
multi-core systems the interference between different sub-systems can be
tested under real operating conditions [10]. It is also claimed that the amount
of resources required for this hidICE IP are so small that almost any SoC can
implement it. The main principle of this concept is illustrated in Figure 2.4. All
related clocks, interrupts, data read from periphery, DMA requests, one or
more hash values of instructions and addresses are transferred to emulator.
Emulator is an exact replica of the microcontroller’s bus master cores, I/O
peripherals like ADC, UART or CAN etc. are not replicated. RAM and ROM in
emulator have the same or greater size than that of SoC.
At start same internal state is initialized to both, SoC and emulator, and after
applying reset signal both execute the same code. After recursive
computation and comparison if a divergence in hash values between SoC and
the emulator is found, it indicates a failure. At this point recording of trace
within the emulator is stopped and can be analyzed for finding the root cause
of the divergence.
33
Figure 2.4 Principle of HidICE
Tests can be repeated for different environmental and operational conditions
like temperature, clock frequencies and supply voltages etc. in comparison to
pure software based self tests the hidICE approach exposes more failures in
combination with the information of the exact time and a detailed trace. In
[10] test results of different demonstration systems from Actel and ARM are
presented. A detailed discussion covering several implications and
applications of mass produced SoCs with this extensive debug and trace
support can be found in [18].
2.6 ASSERTION BASED SILICON TESTING
Over the last decade Assertion Based Verification (ABV) is gaining wide
popularity for testing of designs in simulation. A software Electronic Design
Automation (EDA) company ‘0-In Design Automation’, founded in 1996 USA,
introduced the concept of assertions/checkers for functional verification of
multi-million gate ASICs and IC designs. Now this company has been
acquired by Mentor Graphics [19]. Several researchers developed different
techniques utilizing this concept for hardware verification. Riazati M. in [20]
SoC
hidICE IP (Sync TX)
hidICE (Sync RX)
Emulator
Development System
hidICE IP (Hash)
Interrupt Controller
Clock
hidICE IP (Hash)
Observable SoC region
Trace Data Interface
Comparator
DMA
DMA
CPU
CPU
RAM
ROM RAM
External bus interface
Periphery bus System
ROM
34
introduced a new automatable assertion-based on-line testing methodology in
which he showed that synthesized assertion into a chip can provide an
acceptable coverage for stuck-at-faults. Kakoee M.R., et al. in [21] presented
a methodology based on assertions for on-chip verification of NoCs. They
have designed a Local Assertion Processor (LAP) for each core and a Global
Assertion Processor (GAP) for the entire NoC. They offered a boundary scan
chain mechanism; LAP from different cores dispatches an error packet to
GAP after detecting an error, then GAP performs necessary actions to find
error and their severities. In [22] Kakoee M.R. proposed an efficient approach
for selecting and synthesizing OVL assertions to use them in online testing
domain. They merged similar assertions together and made a unified
hardware checker to obtain a reduced overhead. Geuzebroek J. and
Vermeulen B. of NXP Semiconductors has showed in [23] the results of
assertion based bus protocols (PSL-based AXI from ARM, MTL from NXP
and OCP 2.2) hardware checkers integrated for post-Silicon debug, which
provides better observability of internal properties within a system, with less
than 1% additional area cost. Hazra A. proposed a verification methodology
for inline assertions and compares them with the traditional approaches of
formal property verification and dynamic assertion based verification [24].
They used PCI Bridge and Ethernet examples as their case studies.
In the mean time many langu-ages are also developed which can be termed
as hardware verification languages such as PSL (Property Specification
Language), SVA (SystemVerilog Assertions) and OVL (Open Verification
Library). The Institute of Electrical and Electronic Engineers Inc., USA has
approved a standard for PSL, IEEE Std 1850™, which describes the design
behavior of electronic systems using properties, assertions and other
approaches in 2005. Similarly SystemVerilog has also been standardized,
IEEE Std 1800™ also in 2005.
SystemVerilog is widely used in the chip-design industry. The three largest
EDA vendors (Cadence, Mentor Graphics and Synopsys) have incorporated
SystemVerilog into their mixed-language HDL-simulators. In 2008, Cadence
and Mentor released the Open Verification Methodology, an open-source
class-library and usage-framework to facilitate the development of re-usable
35
test benches and canned verification-IP. Synopsys, which had been the first
to publish a SystemVerilog class-library (VMM), subsequently responded by
opening its proprietary VMM to the general-public. Many third-party providers
have announced or already released SystemVerilog verification IP.
2.7 SYSTEM VERILOG
In the semiconductor and electronic design industry, SystemVerilog is a
combined Hardware Description Language and Hardware Verification
Language based on extensions to Verilog.
2.7.1 Design Features
New data types: logic (Enhanced variable type), Multidimensional packed
arrays, Enumerated data types, New integer types: byte, shortint, int and
longint as two-state signed integral types having 8, 16, 32, and 64 bits
respectively, structures and unions. Moreover new type of procedural blocks
and interfaces are also available in SystemVerilog.
2.7.2 Verification Features
New data types: string and classes. Constrained random generation: Integer
quantities, defined either in a class definition or as stand-alone variables in
some lexical scope, can be assigned random values based on a set of
constraints. This feature is useful for creating randomized scenarios for
verification. Assertions: which are useful for verifying properties of a design
that manifest themselves over time. A SystemVerilog Assertion is a statement
of expected behavior (a design property). It is best suited to describe local
signal relationships (e.g., handshaking, state transitions and protocol rules).
SystemVerilog assertions are built from sequences and properties. A
sequence defines a pattern, typically over multiple clock cycles. A pattern can
be a collection of events (which could consist of Boolean expressions) that get
evaluated on the same clock edge, or it can be events that evaluate over a
period of time involving multiple clock cycles. A number of sequences can be
combined sequentially or logically to create more complex behaviors. These
complex sequential sequences are represented by a keyword known as a
"property". A property or a sequence does not do anything by itself in a
36
simulation unless they are asserted to take effect. An assert produces results
(reports, waveform, etc.) that are visible. An assert either succeeds or flags a
violation. The SystemVerilog language is built in such a way that every time
an assertion check fails, the simulator is expected to print out an error
message by default. By using the "action block" in the assert statement, an
error or a success message can also be printed.
Assertions are best used in synchronous designs. Assertions are only of value
if they are included with the design in some way. A substantial portion of the
typical verification process is spent validating designers' assumptions about
the environment in which the design will operate, and about the design
functional specification. How many times have designers said "it should work,"
only to realize that they had misread the specification (or at least interpreted it
differently from a colleague), or made some silly mistake in the HDL code
(such that the functionality described was subtly different from what was
intended)? It is therefore critically important to enable designers to capture
assumptions easily in a way that is familiar, and easily fits with the rest of the
design and verification methodology.
Unifying SystemVerilog assertions with the rest of the language that designers
already use allows designers to take advantage of this paradigm. This is
perhaps one of the biggest advantages that IEEE Std 1800 SystemVerilog
has over separate assertion languages. Because SystemVerilog assertions
can be embedded directly in the design code, the incremental effort of adding
assertions to the design is small. Designers may choose to write the
properties directly, either declaratively or procedurally, or they may instantiate
pre-verified properties from a library. Either way, the assertions become part
of the design, which makes designers more comfortable and more likely to
use them. Because assertions are unified, they can be encapsulated in
modules, programs or interfaces, which are all supported by the existing
library mechanisms already familiar to Verilog users.
Verification engineers often use different means and tools to ensure thorough
functionality checking. For this approach to be effective, results between
different verification tools must be consistent. Otherwise, much effort is spent
uncovering tool issues rather than design issues. The unification of assertions
37
in SystemVerilog also allows the test bench and assertions to work together,
which means that the test bench can recognize the existence of assertions
and react to their state. If assertions are described using a separate language,
then there is nothing to which the test bench can refer.
In addition to assertions, SystemVerilog supports assumptions and coverage
of properties. An assumption establishes a condition that a formal logic
proving tool must assume to be true. An assertion specifies a property that
must be proven true. In simulation, both assertions and assumptions are
verified against test stimulus. Property coverage allows the verification
engineer to verify that assertions are accurately monitoring the design.
Coverage as applied to hardware verification languages refers to the
collection of statistics based on sampling events within the simulation.
Coverage is used to determine when the device under test (DUT) has been
exposed to a sufficient variety of stimuli that there is a high confidence that
the DUT is functioning correctly. Note that this differs from code coverage
which instruments the design code to ensure that all lines of code in the
design have been executed. Functional coverage ensures that all desired
corner cases in the design space have been explored.
A SystemVerilog coverage group creates a database of "bins" that store a
histogram of values of an associated variable. Cross coverage can also be
defined, which creates a histogram representing the Cartesian cross-product
of multiple variables.
2.8 REFERENCES
[1] Guangyao L., Huang K., Chen J. and Gao F., “Intelligent Design Technology for
Testability of Complex Electronic Equipments”, Measurement and Control
Technique, Vol. 25, No. 8, pp. 71-72, 2006
[2] Stanion R.T., Bhattcharya D., Sechen C., “An Efficient method for Generating
Exhaustive Test Sets”, IEEE Trans. on Computer-Aided Design of Integrated
Circuits and Systems, Vol. 14, Issue 12, pp-1516-1525, Dec. 1995
[3] Ali, L., Sidek R., Aris, I., Suparjo, B.S. and Ali, M.A.M., “Challenges and
Directions for Testing IC”, Integration the VLSI Journal, Vol. 37, pp. 17-28,
Elsevier, 2004
38
[4] A.T.E. (Advanced Test Engg.) Solutions, Inc., http://www.bestetest.com/news.html
[5] Sunter S., “BIST vs ATE: Need a Different Vehicle?”, in proc. of International
Test Conference (ITC’1998), pp 1148, Oct. 18-23, 1998
[6] Stroud C.E., “A Designer’s Guide to Built-In Self-Test”, Kluwer Academic,
Norwell, MA, 2002
[7] Goldstein L.H., ”Controllability/observability analysis of digital circuits”, IEEE
Trans. on Circuits and Systems., Vol. CAS-26, Issue 9, pp. 685–693, 1979
[8] Abramovici M., Breuer M.A., and Friedman A.D., “Digital Systems Testing and
Testable Design”, IEEE Press, Piscataway, NJ, 1994
[9] Wang L.T., “Logic Built-in-Self-Test”, chapter 5 of ‘VLSI Test Principles and
Architectures: Design for Testability’, Morgan Kaufmann Publishers, Elsevier
Inc., 2006
[10] Weiss A. and Hochberger C., “A New Methodology for Test of SoCs and for
Analyzing Elusive Failures”, in proc. of 9th International Workshop on
Microprocessor Test and Verification, IEEE Computer Society, pp. 18-23, 2008
[11] Yansheng Z., Jianhui C. and Jianhui J, “Implementation of Hierarchical Design
for Testability Methodology”, in proc. of 9th International Conference on
Electronic Measurements and Instruments (ICEMI’09), pp. 1-369 to 1-373, 2009
[12] Vermeulen B, and Goel S.K., “Design for Debug: Catching Design Errors in
Digital Chips”, IEEE Design and Test, Vol. 19, Issue 3, pp. 35-43, 2002
[13] Hopkins A.B.D. and McDonald-Maier K.D., “Debug Support for Complex
Systems on- Chip: A Review”, IEE J. Computers and Digital Techniques, Vol.
153, Issue. 4, pp. 197-207, 2006
[14] Vermeulen, B., “Functional Debug Techniques for Embedded Systems”, Design
and Test of Computers, Vol. 25, Issue 3, pp. 208-215, IEEE Computer Society,
2008
[15] Abramovici, M., “In-System Silicon Validation and Debug”, Design and Test of
Computers, Volume 25, Issue 3, pp. 216-223, IEEE Computer Society, 2008.
[16] Abramovici, M., et al., “A Reconfigurable Design-for-Debug Infrastructure for
SoCs”, in proc. 43rd Design Automation Conference (DAC’06), ACM Press
California, pp. 7-12, Jul. 24-28, 2006
39
[17] Lange A. and Weiss A., “Procedure and Device For Emulating A Programmable
Unit”, European Patent EP1720100 B1, May 2005
[18] Hochberger C. and Weiss A., “Acquiring an Exhaustive, Continues and Real-
Time Trace from SoCs”, in proc. 26th IEEE International Conference on
Computer Design (ICCD’08), pp. 356-362, 2008
[19] http://venturebeatprofiles.com/company/profile/0-in-design-automation
[20] Rizati M., Mohammadi S., Afzali-Kusha A. and Navabi Z., “Improved Assertion
Lifetime via Assertion-Based Testing Methodology”, in proc. of 18th IEEE
International Conference on Microelectronics (ICM’06), pp. 48-51, 2006
[21] Kakoee M.R., Neishaburi M.H., Daneshtalab M., Safari S. and Navabi Z., “On-
Chip Verification of NoCs Using Assertion Processors”, in proc. of 10th IEEE
Euromicro Conference on Digital System Design Architectures, Methods and
Tools (DSD’2007), pp. 535-538, 2007
[22] Kakoee M.R., Riazati M. and Mohammdi S., “Enhancing the Testability of RTL
Designs Using Efficiently Synthesized Assertions”, in proc. 9th International
Symposium on Quality Electronic Design (ISQED’08), IEEE Computer Society,
pp. 230-235, 2008
[23] Geuzebroek J. and Vermeulin B., “Integration of Hardware Assertions in
System-on-Chip”, in proc. of International Test Conference (ITC’2008), IEEE
Computer Society, pp. 1-10, 2008
[24] Hazra A., Ghosh P., Dasgupta P. and Chakrabarti P.P., “Inline Assertions –
Embedding Formal Properties in a Test Bench”, in proc. of International
Conference on VLSI Design (VLSID’09), IEEE Computer Society, pp. 71-76,
2009
C
3
T
b
th
c
s
a
T
th
c
th
d
o
s
e
c
3
T
a
In
th
D
in
CHAPTER
3 HAR
The idea of
y us [1]. Th
he design
ircuits are
oftware co
ssertions is
Therefore ha
he literatu
omponents
he DUT du
ifferent inte
perating co
imilar idea
laborated b
ombination
3.1 BAS
The basic id
n FPGA. T
nputs are th
he DUT.
Details of th
nitialized w
R 3
RDWARE
hardware
he removab
under test
removed. T
ompany “0
s in simula
ardware ch
re. The t
s into the de
uring forma
ernal circu
onditions. P
as for diffe
by giving d
nal and seq
IC IDEA
dea is illustr
Therefore T
he test vect
Fi
he tester cir
with expecte
E REMO
removable
ble checker
(DUT). W
The idea st
0-In Desig
ation to ver
heckers are
theme of
esign unde
al verificatio
uits against
Presently m
erent appli
different exa
uential circ
rated in Fig
Tester Circu
tors that ful
igure 3.1
rcuit are giv
ed results
OVABLE
checker ci
r circuits ar
When the d
emmed fro
n Automa
rify the des
e also term
introductio
er test is to
on process
t unexpect
many resea
cations [2-
amples wit
uits; to a R
ure 3.1. DU
uit (Si) is te
ly cover all
Basic Idea
ven in Figu
before the
CHECK
rcuits was
re placed o
esign is fu
om 0-in ass
ation”. The
sign before
ed as synt
on of thes
probe the
s and to m
ed transitio
rchers hav
-5]. In this
h varying c
ISC proces
UT and the
esting the
possible c
(Si testing S
ure 3.2. Me
e testing st
KER CIR
first presen
on the FPGA
ully tested
ertions dev
e main ap
e it is ready
hesizable a
se hardwa
internal co
monitor the
ons or und
ve proposed
s chapter
complexity
ssor.
tester circu
design und
cases to com
Si)
mory of tes
tarts. When
RCUITS
nted in 200
A along wit
the checke
veloped by
pplication o
y for silicon
assertions
are checke
mponents o
behavior o
der differen
d/ presente
the idea
from simp
uit coexist o
der test (Si
mpletely tes
ster circuit
n inputs ar
02
th
er
a
of
n.
in
er
of
of
nt
ed
is
le
on
i).
st
is
re
41
applied, both DUT and tester circuit responds simultaneously. Outputs from
the DUT and memory are compared together and an error signal is generated
if there is a mismatch in the outputs. The error signal can be utilized to either
halt the testing at that point or can be routed as an interrupt signal to some
external pin or can be used to read and store the present state condition of
the DUT in memory. Later it can be examined for finding the reason/root of
the error. After successful testing, i.e. no error signal is encountered; the DUT
is ready for next production steps.
Figure 3.2 Tester Circuit Details
3.2 TESTING OF SIMPLE CIRCUITS
The concept was applied on numerous combinational circuits; simple logic
gates, multiplexers, adders circuits, decoders etc. The concept worked fine
and test results were available at hardware speed. Hardware test speed
cannot be compared with the time taken by simulation testing. In simulation
the results are computed while in hardware the outputs take only the
propagation delays to reach output nodes. Similarly some sequential circuits
were also tested. These included flip flops, counters, registers, accumulator
and Finite State Machine (FSM). Results of some circuits are given in the
following subsections.
3.2.1 Accumulator Register
In this example an eight bit accumulator register is designed and its operation
is verified with this proposed methodology. The experimental setup is shown
in figure 3.3. Tester circuit in this case resembles the one shown in figure 3.2.
Memory
DUT
Address Generator
Inputs
Comparator
Status
Tester Circuit
Error Signal
In
s
A
F
O
R
te
m
A
a
In
in
m
n_A and In_
elect.
Accumulato
1:
2:
3:
4:
5:
6:
7:
8:
For testing
Outputs of
Register wit
ester circui
memory. Te
Accumulato
ny. Simulat
n_A and I
nstructions
memory ad
_B are two
Figure 3.3
r register is
Parallel lo
Addition
Subtractio
Incremen
Decreme
Shift Left
Shift Righ
Reset
purpose s
all operat
h the help o
it, which in
ester circui
r register w
tion result o
n_B are h
(FS) are
dress. In t
o input data
3 Accum
s designed f
oad
on
nt
nt
ht
some data
tions are
of FS selec
n response
it then com
with this an
of Accumul
highlighted
the inputs
the figure
a buses of 8
mulator Regis
for the follo
Acc In_
Acc In_
Acc In_
Acc In_
Acc In_
Acc In_
Acc In_
Acc 0
elements
generated
ct lines. The
e reads al
mpares the
nd error is
lator with te
in the pa
s to the te
these app
8-bit each a
ster with Tes
owing instru
_A
_A + In_B
_A – In_B
_A + 1
_A – 1
_A << 1
_A >> 1
are selecte
one by o
ese FS sele
ready stor
e result of
generated
ester circuit
ane left to
ester circui
pear as /TB
and FS is 3
ster Circuit
uctions to be
ed for In_A
one from A
ect lines als
ed results
operation
according
t is shown i
o the wave
t correspo
B………./A
3-bit functio
e executed
A and In_B
Accumulato
so trigger th
from teste
available
ly if there
in figure 3.4
eforms. Th
nding to it
ddr. Just t
on
d.
B.
or
he
er
in
is
4.
he
ts
to
o
th
is
re
a
3
A
o
m
o
p
bserve the
he stored re
s evident by
esults and
rticle 3.5.
3.2.2 Fin
A Moore typ
utput, was
methodology
f Clk and
assed to th
correctnes
esults of te
y the gener
its timing
Figure 3
nite State M
pe state ma
s chosen a
y for seque
according
he tester cir
Figure
0
1
ss of the te
ester memo
ration of err
comparison
3.4 Wav
Machine
achine, as s
as a desig
ential circuit
to the exte
rcuit.
e 3.5 Sta
S0/0
S3/1
0
ester circuit
ory; encircle
ror signal, e
n with thes
veform: Accu
shown in fig
gn under t
ts. States o
ernal input.
ate Diagram
1
0
0
1
an error w
ed in yellow
encircled in
se simulate
umulator with
gure 3.5, w
test to ver
of the FSM c
. State val
of Moore Ma
1
0
was intentio
w. The resp
red. The h
ed results
h Tester
with four sta
rify the pr
changes on
ue of the F
achine
S1/0
S2/0
1
onally kept
ponse of th
ardware tes
are given
ates and on
roposed tes
n rising edg
FSM is als
in
is
st
in
ne
st
ge
so
If
c
in
o
st
re
a
/T
p
m
3
D
in
im
g
p
ve
p
s
3
A
in
f appropriat
ircuit signa
nitially load
f the teste
tored resul
esult is sho
nd present
TB…./state
osition. As
machine are
Figure
3.3 TEST
Different typ
ntegral part
mprove obs
enerally th
rotocols ar
erified thro
rotocols, A
ections.
3.3.1 Ass
Assume-gua
nterface sig
te output is
ls this fact o
ed with the
r circuit co
ts in memo
own in figure
t state; thi
, can be f
the stored
e same, the
e 3.6 Sim
TING OF I
pes of con
t of System
servability a
he main ta
re designed
ough hardw
ssume-Gua
sume-Gua
arantee is
gnals are us
s not produc
on its error
e state outp
ompares th
ory and ge
e 3.6. State
s evident
found from
d results fro
erefore no e
mulation resu
NTERFAC
ncurrent pr
mVerilog. T
and localiza
rget of ass
d in synthe
ware tester
arantee and
arantee
a formal
sed to verif
ced by the
line. For te
puts. When
e output o
enerates er
e transition
from the f
m left pane
om tester m
error is prod
ult of Moore
CE PROTO
roperties (a
hese prope
ation of des
sertion bas
esizable Ve
rs. The de
d Hierarchic
analysis
fy the block
state mach
esting purpo
n state mac
of the state
ror signal a
s are depe
figure. Cha
e of the di
memory an
duced.
type State M
OCOLS
assert, cov
erties provi
sign errors.
sed checke
erilog code
etail and re
cal, are giv
method in
k on one si
hine at that
ose memor
chine runs,
e machine w
accordingly
ndent on e
anges in /T
agram, ela
nd the outp
Machine with
ver, and a
de an effe
Interface p
ers [6]. A f
and their
esults of tw
ven in the fo
n which p
de of the in
t time, teste
ry of tester
comparato
with alread
y. Simulatio
xternal inpu
TB.…/In an
aborates th
puts of stat
Tester
assume) ar
ctive way t
protocols ar
few of suc
operation
wo of thes
ollowing sub
properties o
nterface an
er
is
or
dy
on
ut
nd
he
te
re
to
re
ch
is
se
b-
of
nd
a
e
b
W
a
te
v
T
o
c
e
e
c
s assumpti
xample for
lock B can
When verify
sserts the
ester circuit
iolated by b
Tester circu
f ‘INT’ sign
ount. If this
rror, otherw
rror but in
ondition wa
Inputs
ions to veri
r Assume-G
be asserte
Figure 3
ying block
interrupt s
t which che
block A. Si
it consists
nal and afte
s signal re
wise error is
second cy
as violated.
Figure 3.8
Block A
Clk
Int
fy the block
Guarantee;
ed no more
3.7 Bloc
A, this rule
ignal corre
ecks this p
mulation re
of a 3-bit c
er that test
emains low
s generated
cle there is
8 Simula
INT
≥
Interrupt
A
k on the oth
an interrup
frequently t
k diagram of
e is treate
ctly. The d
property an
esult of this
counter wh
ter circuit c
up to at le
d by the tes
s an error i
ation result o
5
t spacing ≥ 5
Tester
her side. Fi
pt signal ru
that every f
f Assume-Gu
d as a gu
diagram als
d issues a
experimen
ich starts c
checks the
east five c
ster circuit.
indicated, e
of Assume G
5
Block
igure 3.7 e
unning from
five clock c
uarantee
arantee tha
so includes
n error sig
nt is given i
counting at
status of ‘I
ounts then
In first cycl
encircled in
Guarantee
Error
k B Ou
laborates a
m block A t
ycles.
at the bloc
a hardwar
nal if rule
in figure 3.8
falling edg
INT’ at eac
there is n
e there is n
n red, as th
r
utputs
an
to
ck
re
is
8.
ge
ch
no
no
he
3
T
h
th
D
th
c
h
le
S
a
3.3.2 Hie
This is an e
andshaking
he block dia
F
Device Mas
hat point da
lock cycle,
igh until an
east for on
Simulation r
re transferr
Inputs
erarchical
example of
g signals. F
agram of th
Figure 3.9
ster asserts
ata is place
the duratio
nd including
ne cycle.
result of this
red accordi
Figure 3.10
MASTE
req
data
ack
Protocol
point to p
Figure 3.9 s
is setup inc
Block dia
‘req’ and h
ed by Slave
on of ‘ack’
g the ‘ack’ is
‘ack’ cann
s example
ng to this p
0 Wavefo
Byte
ack
req
H
ER
Checker
oint protoc
shows wave
cluding Tes
agram: Hiera
holds it unt
e on 8-bit da
. The ‘req’
s asserted,
not be ass
is shown in
protocol, en
orm: Hierarch
8-bit da
e1
Hierarchical
Tester
col, like par
eform of de
ster module
rchical Proto
til ‘ack’ is r
ata bus and
signal from
than ‘req’
serted unle
n Figure 3.1
circled in y
hical Protoco
ata
Protocol
SLAV
rallel data t
esired proto
e.
ocol Checker
received fro
d remains v
m Master m
must be de
ess ‘req’
10. Four da
ellow.
ol Checker
Erro
VE
Out
Byte2
transfer wit
ocol and als
r
om Slave. A
valid for on
must rema
e-asserted a
is asserted
ata element
or
tputs
th
so
At
ne
in
at
d.
ts
3
A
d
3.4 TEST
An 8-bit R
esigned. Fi
S#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
TING OF R
ISC proce
igure 3.11 e
Table 3
Inst
No o
Add
Sub
Mult
AND
Incr
Dec
Shif
Shif
Mov
Writ
Rea
Bran
Bran
Bran
Halt
Figur
RISC PRO
ssor with
elaborates
3.1 Ins
truction
operation
dition
btraction
tiplication
D Logical
rement
crement
ft Left
ft Right
ve
te to Memo
ad from Mem
nch Uncond
nch if Zero
nch if Less
t
re 3.11 Bl
OCESSOR
16 instruc
different se
truction Set
ory
mory
ditional
then
ock diagram
R
ctions, liste
ections/bloc
of RISC Proc
Action
None
Rd Rd
Rd Rd
Rd Rd
Rd Rd
Rd Rd
Rd Rd
Rd SH
Rd SH
Rd Rs
Mem [Ad
Rd Me
PC Ad
PC Ad
PC Ad
Halts and
m: RISC Proc
ed in Tabl
cks of the p
cessor
d + Rs
d - Rs
d x Rs
d && Rs
d + AMT (2-
d – AMT (2-
HL (Rd), AM
HR (Rd), AM
s
dr] Rs
em [Addr]
dd
dd (if flag Z
dd (if flag LT
d resumes o
essor
le 3.1, wa
processor.
-bit)
-bit)
MT
MT
= 1 )
T = 1)
on reset
as
P
re
e
th
a
In
p
p
d
In
m
c
T
R
a
T
e
s
A
a
o
y
Program ins
ead from
lements pr
hat it can in
s well as on
n offline m
rocessor a
atterns and
ata is helpf
n online m
monitors its
an be comm
The operat
RegisterFile
ppropriate
Test agent
xample m
imulation r
Agent, highl
ssigned to
utputs; me
ellow lines
structions a
memory a
resent in th
nteract with
nline.
mode, test
and its resp
d their resp
ful to evalua
mode, proc
different se
municated
tion of dif
were ve
test stimuli
has been d
odule num
results with
ighted with
o Memory.
emory teste
around the
re kept in m
and is dec
he cells of R
h different m
stimuli are
ponse is c
ponse is ma
ate the loca
cessor cont
ections. If s
outside the
fferent sec
erified thro
. Simulation
designed in
mber ‘0’ is
h same out
h yellow line
Figure 3.
ed directly
e outputs.
memory. Du
coded. Ope
RegisterFile
modules of
e applied
ompared w
aintained in
ation and ca
tinues to w
some error
e device by
ctions of
ugh this
n results of
nternally to
assigned
tputs; ALU
es around t
12(b) show
and throu
(a) ALU
uring fetch
erations ar
e. Tester c
the proces
to the diff
within the t
n the memo
ause of fau
work norm
occurs the
some seria
processor
tester circ
f each are g
select diffe
to ALU.
tested dire
the outputs
ws simulat
ugh Test A
U
operation i
re perform
circuit is de
ssor. It can
ferent sect
tester unit.
ory of test u
lt within the
mally and t
e state is re
al port with
: ALU, M
cuit with t
given in figu
erent test m
Figure 3.1
ectly and t
s. Module n
ion results
Agent, high
instruction
ed on dat
esigned suc
work offlin
tions of th
Log of tes
unit. This lo
e DUT.
tester circu
ecorded, tha
in the teste
Memory an
the help o
ure 3.12.
modules; fo
12(a) show
hrough Tes
number ‘1’
s with sam
hlighted wit
is
ta
ch
ne
he
st
og
uit
at
er.
nd
of
or
ws
st
is
me
th
M
b
s
W
fi
in
in
re
Fig
Module num
ack some
hows simul
Working me
gure 3.13.
nstruction,
nstruction is
esult is writ
gure 3.12
mber ‘2’ is a
data elem
lation resul
echanism of
During F
during Fe
s decoded
ten back.
(b
(c)
Simulation
assigned to
ments in fo
ts; highligh
f processor
Fetch_1 me
etch_2 imm
as well. A
b) Memo
Register
results: ALU
o RegisterF
ur register
ted with ye
r, through fe
emory is
mediate da
After instruc
ory
rFile
U, Memory an
File. Test a
rs of Regis
llow lines a
etch to writ
read to ge
ata from
ction is de
nd RegisterF
agent store
sterFile. Fig
around the o
te back is e
et the opc
memory is
coded it ex
File
s and read
gure 3.12(c
outputs.
elaborated
code of th
s read an
xecutes an
ds
c)
in
he
nd
nd
A
n
st
F
e
h
A program w
umber thro
tored in m
Factorial of
valuated b
ighlighted i
Fig
Figure
was develo
ough this pr
memory. Th
5 was ob
by ALU an
n the pane
ure 3.14 F
e 3.13 Wo
oped as a
rocessor. M
he simulati
btained thro
nd saved
left of the w
Factorial thr
orking Mecha
test exam
Machine cod
on result
ough this
in R0, fir
wave diagr
ough RISC P
anism of Pro
ple to gene
de of progra
of that is
processor
rst register
am.
Processor: S
cessor
erate the f
am was de
shown in
and the e
r of Regis
Simulation re
factorial of
veloped an
figure 3.14
end result
sterFile; Th
esult
a
nd
4.
is
he
51
3.5 TIMING ANALYSIS
One main advantages of this hardware testing methodology over simulation is
time saving. The designs mentioned above were written in Verilog HDL and
its functional simulation was performed by ModelSim (6.1i) as shown in
previous sections. The same designs were also synthesized on ISE (9.1i) and
targeted on Xilinx’s FPGA, SPARTEN xc3s1000 ft256. The same test stimuli
were applied in both scenarios. Time elapsed in both cases were observed
and summarized in table 3.2.
Table 3.2 Time Comparison
Design Simulation on ModelSim Xilinx FPGA
Assume Guarantee 9 S 5 mS
Hierarchical Protocol Checker 4.5 S 3 mS
Accumulator/Datapath 23 S 8.5 mS
Finite State Machine 20 S 11 mS
RISC Processor 85 S 38 mS
The above table shows that the proposed methodology of testing Design with
hardware testers provides a huge saving in time. Moreover testing the device
on hardware ensures its operation on real time operating conditions. This
methodology gives more possibilities to catch the hidden bugs and to catch
corner cases with respect to the simulation only.
3.6 AUTOMATED HARWARE TESTING/VERIFICATION
The FPGA based verification guarantees the correctness of the design;
because it is hardware and it works in real time i.e. all real world constraints
apply e.g. clock skews, fan-outs, path and routing delays etc.
ASIC design with HDLs is aided with a number of tools, used in verification
and debugging the design. Stimulus and test-benches are written in HDL.
Programming Language Interfaces (PLI’s) make it possible to interact with
higher-level languages like C/C++, to verify the complex design. There are
s
m
c
b
D
e
m
a
3
A
w
w
e
s
u
c
n
in
everal gra
monitoring.
overage too
eing emplo
During verif
merged w
monitoring
pproach.
3.6.1 Wh
A White-Box
was designe
which includ
mbed the
ource code
tility of the
ode and ge
ew code is
nto the desi
aphical use
These inclu
ols etc. Bla
oyed since l
fication of
which woul
the FPGA
hite-Box V
x Verificatio
ed. It com
des, code-g
checkers
e, which d
e tool trans
enerates co
s synthesiz
ign. This is
F
er interface
ude simula
ack-box app
long.
FPGA ma
ld provide
A mapped
Verification
on Tool (W
prises of a
generator a
in the form
describes t
slates the
ode for che
zed for FPG
elaborated
Figure 3.15
e (GUI) b
ators, wavef
proach and
apped ASIC
a sound
d hardwar
n Tool for
WBVT), bas
a checker
and monito
m of comm
he desired
checker co
cker library
GA, the che
d schematic
AWB Veri
based tool
form viewe
formal ver
C, idea to
d and con
re using
r FPGAs
sed on the
library and
oring softwa
ments, right
d behaviou
omments in
y componen
ecker circu
cally in Figu
ification Too
s for deb
ers, code-tra
rification tec
o develop
nfigurable
white-box
idea discu
d a softwar
are. The d
t into the V
r. The cod
nto synthe
nt instances
uits also ge
ure 3.15.
ol
bugging an
acers, code
chniques ar
a tool, wa
method fo
verificatio
ssed above
re tool-suite
designer ca
Verilog RT
de-generato
sizable RT
s. When th
et embedde
nd
e-
re
as
or
on
e,
e,
an
TL
or
TL
is
ed
53
These synthesized checker circuits present in the FPGA can make the
emulation halt on the basis of firing signal which was carried through PCI
interface and was communicated to the computer. A software application was
also built to make human-FPGA interaction easy as well as monitoring the
checkers, by using APIs available with the PCI driver. WBVT RTL library
contains a number of checker modules, which are instantiated by the code-
generator. The checker components can be categorized into following groups:
Timing and Sequence monitoring checkers.
Data-path components monitoring checkers.
Overflow saturation and empty status monitoring checkers.
The RTL coding of the checkers have a general construction with the
difference of algorithm implemented internally. The general features of RTL
coding are:
All checkers, RTL codes, comprise of a module, which has a definite set of
input and output interfaces.
The interfaces of the module are parameterized and hence reconfigurable
and reusable.
The behavioral specifications are provided by the designer in the form of
comments with options (switches). For example standard and required
arguments, firing result registers, clock etc.
An explicit reset signal is provided to clear/reset all the registers, counters
etc. Once a firing occurs, it is necessary to reset a checker for further
monitoring.
A checker module will be directly instantiated in the RTL where the
comment was placed.
The signals of the components to be monitored are connected to checker
module ports. Similarly, results are carried through output ports to the top-
level modules.
The code generator software comprises of two main modules: the parser and
the code generator as shown in figure 3.15. The main functions of parser are
id
m
in
W
a
in
st
A
a
d
w
p
c
th
a
dentification
missing info
nformation
When the pa
ssert com
nformation
tored in pro
After a part
ppended in
oes this, by
with this in
arameteriz
hecker is a
he parent m
nd are nec
n of assert
ormation, in
gathering o
arser modu
ment, toke
is then co
oper data st
ticular chec
n the mod
y instantiati
stantiation,
ation code
associated.
module. The
essary for i
Fig
tion comm
nvalid optio
of associat
ule is given
enizes it to
ompiled i.e.
tructure.
cker is iden
dule for its
ing the corr
, the logic
depends u
The code-
ese declara
its proper a
gure 3.16
ents, error
ons, wrong
ted variable
a file to ex
o arrange
. the inform
ntified, cert
hardware
responding
c for param
upon the si
-generator
ations depe
association
Schematic f
r checking
names of
e, like: var
xtract assert
parameter
mation gath
tain piece
implemen
library com
meterization
ze of the v
also decla
end upon th
with parent
flow: AWB to
of the com
f associatio
riable name
tion informa
rs and sw
hered is va
of RTL co
tation. Cod
mponent mo
n is also a
variable, wi
res certain
he instantia
t module.
ool
mments lik
ons etc. an
e, width etc
ation, it find
witches. Th
alidated an
ode must b
de-generato
odule. Alon
added. Th
th which th
variables
ated module
ke
nd
c.
ds
is
nd
be
or
ng
is
he
in
e,
55
The instantiated module contains some specific registers/variables, which are
to be read from or to be written to the FPGA, through PCI interface. These
variables or their copies must be brought to the top most FPGA wrapper, as
per requirement of the PCI. This requires modification in the port list of each
module, which comes in the hierarchy, starting from the module in which
checker is found and ending up to the top most module.The task next to the
code generation is to map that design on FPGA. When a design is mapped on
FPGA, a special module is written which wraps around the original design,
hence called the wrapper module. All the I/O pins available in the ASIC are
linked with the internal variables of the wrapper module. Some of these
internal variables are linked with the I/O pins of the wrapper module, which
comprises the physical connections of the PCI. It is a collection of data,
address and control signals. After finishing the mapping of addresses, hit
signals etc. the design is loaded into the FPGA (with a complete system built
on the PCI card).
The hardware thus mapped on FPGA has capabilities of halting the whole
device. This capability is necessary because in case of firing, the device must
freeze to the current status, which can be monitored for studying the behavior.
This is made possible by OR-ing all the firing-flags together and the result is
provided to the halt signal; so that whenever any firing asserts, the device
stops. This is being monitored all the time and whenever the device halts, and
is notified. Then we can check the values of associated variables. A separate
application can be written for this purpose.
The tool was used for the verification of devices with millions of gates and
significantly, it helped in detecting and eliminating tough hidden bugs. This is
certainly a novel idea and the research is being performed all over the world,
supervised by the electronics and computer societies and professionals. A
review is given article 2.6.
3.7 CONTEMPORARY ASSERTION CHECKER GENERATOR
Almost the same concept was proposed and presented later by Boule M. [2]
in 2005. They also developed a tool, named “MBAC”, to generate hardware
assertion checkers into efficient circuit emulation using PSL statements.
T
b
e
c
s
In
a
3
[1
[2
[3
[4
[5
These ass
ehaviorally
nhancemen
heckers [7]
hown in fig
Figure
n [8] differe
nd post-sili
3.8 REFE
1] Omar
Verific
Multito
2] Boule
Hardw
Comp
3] Foste
Acade
4] Cortez
Statis
Engin
(CIE’0
5] Kakoe
RTL
Intern
Socie
ertions ch
y correct
nts for inc
] in 2006. T
ure 3.17.
e 3.17 Bo
ent techniq
con debug
ERENCES
r M., Khan
cation Metho
opic Confere
e M. and Z
ware Emula
puter Design
r H., Kroln
emic Publish
z j. and Torr
tics”, in proc
eering (ICE
05), Mexico,
ee M.R., Ria
designs us
ational Sym
ty, pp. 230-2
heckers ar
circuits.
creased tra
The idea of
ule’s Hardwa
ues are di
scenarios.
S
S.A., Baig
odology for
ence (INMIC
Zilic Z., “In
ation”, in pr
(ICCD’05),
ik A. and
hers, 2nd Edit
res D.,” Des
c. of 2nd Inter
EEE’05) an
pp. 132-135
azati M. and
sing Efficien
mposium on
235, 2008
re resourc
Boule M
aceability a
f Boule M.
are Checker
scussed, b
M.I. and J
SOC Desig
C-02) Karach
ncorporating
roc. of 23rd
pp. 221-228
Kacey D.,
tion, 2004
sign and Ver
rnational Co
d 11th Con
5, 2005
d Mohamma
ntly Synthe
n Quality E
ce efficien
. present
and observa
is reproduc
and debugg
by using as
Jamal H., “F
gn”, in proc.
hi, pp. 297-3
Efficient A
IEEE Inter
8, 2005.
“Assertion
rification Bas
onference on
nference on
adi S., “Enh
esized Asse
Electronic D
nt, synthes
ed more
ability with
ced from hi
ing enhance
ssertions, i
FPGA Base
of 6th IEEE
00, Dec. 27-
Assertion C
rnational Co
Based Des
sed on Asse
n Electrical a
n Electrical
hancing the
ertions”, in
Design”, IEE
sizable an
debuggin
hin assertio
is paper an
ements
n pre-silico
ed White Bo
E Internation
-28, 2002.
Checkers int
onference o
sign”, Kluwe
ertions: Som
and Electron
Engineerin
Testability o
proc. of 9
EE Compute
nd
ng
on
nd
on
ox
al
to
on
er
me
nic
ng
of
9th
er
57
[6] Cerny E., Bergeron J., Thottasseri M.K., and Anderson T. (Synopsis), “Design
of SystemVerilog Assertion IP”, Design and Reuse, www.design-reuse.com,
2009
[7] Boule M., Chenard J.S. and Zilic Z., ”Adding Debug Enhancement to
Assertion Checkers for Hardware Emulation and Silicon Debug”, in proc. of
24th IEEE International Conference on Computer Design (ICCD’06), pp. 294-
299, 2006
[8] Boule M., Chenard J.-S. and Zilic Z., "Debug Enhancement in Assertion
Checker Generation”, IET J. Computers and Digital Techniques – Special
issue on Silicon Debug and diagnoses, vol. 1, No. 6, pp. 669-677, 2007
CHAPTER 4
4 HARDWARE RECONFIGURABLE TEST AGENT
The concept of reconfigurable testing agent within the hardware of the DUT
as an embedded layer has been recently presented by us [1]. The idea again
is of synthesizable assertions, used as Hardware Test Agent, to permanently
reside in the design up to the silicon stage. This agent is designed such that it
can dynamically be configured to adapt according to the changes and
requirements of the design to be implemented. Since application domains and
standards change rapidly, the design implemented on the SoC also changes.
With the help of this type of testing agent internal sections of the design can
be monitored during normal running of the device. Moreover captured data,
within the test agent, can provide better identification for faulty sections of the
design. We observed that by having a flexible test agent, inside the DUT,
design can be tested in real-time under real world environment. Moreover, in-
system testing gives a much higher degree of confidence on the reliability of
the system under test. This easy to use setup provides extensive tests at real
time at the cost of approximately 5~10% additional chip area, required to
implement this testing agent [1].
We have targeted Medium Access Control (MAC) layer found in the latest
IEEE 802.11e standard, Wireless LAN for Quality of Service, as DUT for
testing with this type of hardware testing. This device along with a testing
agent is implemented on an FPGA (Virtex-II platform). The detailed results of
this experimentation are presented in next sections of this chapter.
4.1 IEEE 802.11e MAC PROTOCOL
The 802.11e is a standard to support Quality of Service (QoS) in Wireless
Local Area Networks (WLANs). This standard is an enhancement of DCF
(Distributed Coordination Function) and PCF (Point Coordination Function)
with a new coordination function: the HCF (Hybrid Coordination Function).
There are two methods of channel access in HCF, (i) polling-based is known
as HCF controlled channel access (HCCA) and (ii) contention-based is known
59
as enhanced distributed channel access (EDCA). Both EDCA and HCCA
define Traffic Category (TC) [2]. For example emails could be assigned to a
low priority class, and Voice over Wireless LAN (VoWLAN) could be assigned
to a high priority class.
In EDCA high priority traffic gets a higher chance of being sent than low
priority traffic. In addition, each priority level is assigned a Transmit
Opportunity (TXOP) which refers to a bounded time interval during which a
station can send as many frames as possible (as long as the duration of the
transmission does not extend beyond the maximum duration of the TXOP). If
a frame is too large to be transmitted in a single TXOP, it should be
fragmented into smaller frames. The use of TXOPs can solve the problem of
unpredictable transmission time which a low rate station can gain [2].
The critical functionality to be tested in IEEE 802.11e is the prioritized
transmission opportunity based on variable AIFS. This is depicted in Figure
4.1 with slot duration 9µs, SIFS (Short Inter Frame Space) is 16µs, PIFS (PCF
inter frame space) is 25µs, DIFS is 34µs and AIFS is greater than or equal to
34µs [3].
The design of EDCA provides prioritized QoS by enhancing the contention-
based DCF. Each data packet, received from higher layer, is assigned a
specific user priority value before entering the MAC layer. EDCA introduces
four different FIFO queues called Access Categories (ACs).
Figure 4.1 IEEE 802.11e, AIFS Based Prioritised Transmission
ACK RTS
CTS
AIFS[TC]
Low priority TC backoff
High priority TC
Medium priority TC backoff
DATA
count down as long as medium is idle, backoff when medium gets busy again
Contention Window (counted in slots, 9µs)
Defer access
TIME
AIFS[TC]
SIFS SIFS
PIFS
AIFS[TC] (=DIFS)
SIFS
60
Different kinds of application traffics: voice, video, background, best effort can
be directed into different ACs. Each AC works as a single DCF contending
entity with its own contention parameters (CWmin, CWmax, AIFS and TXOPlimit)
[4]. Software architecture of 802.11e MAC with multiple priority queues (voice,
video, best effort) is shown in Figure 4.2.
Figure 4.2 Software Architecture of 802.11e MAC
4.2 ARCHITECTURAL OVERVIEW OF THE TESTING AGENT
The architecture of the testing agent is well suited for typical communication
SoCs such as network processors, wireless protocol controllers and
telecommunication nodes. A typical network controller along with the
debug/testing agent is shown in Figure 4.3. The figure shows this testing
agent, in gray, which is integrated with the device under test (DUT). This
agent is a reconfigurable unit which can be programmed externally according
to the system requirement. Internally it interacts with the DUT through event
triggers and data ports. The data ports are taps from input and output data
streams of device both at the upper layer and the lower layer. This testing
agent is a passive device, which means that it only interacts with the DUT by
receiving data only and it does not triggers or supplies any information to the
DUT.
4.2.1 Test Agent Components
The detail of the testing agent is shown in Figure 4.4. Its inputs are system
events and different data streams. The test agent consists of the following
components:
Priority Based Arbitration
Transmission
TXOP Manager
Multiple Priority Queues
Video
Voice Background (Best effort) . . .
61
Figure 4.3 Architectural Design of 802.11e, integrated With Test Agent
a) Test Agent Logic
This is a very simple logic entity which can be dynamically programmed
through external interface. Its operation can be viewed as a ladder logic
device that enables different triggers based upon the logic of input events.
b) Trap buffer
The trap buffer allows any one of the data steams to be routed through the
flexible interconnect and store in this memory. The trap buffer has a byte
count which sets before the data fill operation takes place. The byte count is
decremented with each byte that is stored in the trap buffer. As soon as the
byte count reaches zero, the trap operation stops. Data from the trap buffer
can be retrieved by an external device in an off-line manner.
c) Reference Buffer
In order to check the validity of incoming data, the reference buffer can be
filled by a known data so that the input data can be compared. This is done
automatically though a byte by byte comparator.
Data Path
Testing Agent
External Control Interface
DMA UNIT
CRC UNIT
ENCRIPTION
CONTROL PROCESSOR
FRAG/DEFRAG UNIT
REGISTER FILE
A L U
MEMORY MANAGMENT
EVENT HANDLER
DATA MEMORY
CODE MEMORY Instruction Decoder
Base band (External to DUT)
HOST PROCESSOR
62
Figure 4.4 Design of Testing Agent
d) Comparator
This comparator does a byte by byte comparison with the data in the
reference buffer and the data in the trap buffer and pass or fail output is given
to the test agent logic unit.
e) Flexible Interconnect
This unit dynamically streams data from the data port to either the trap buffer
or the data dump port based upon test agent logic and the triggers. It is an
extension of a synchronous multiplexer.
4.2.2 Test Agent Interfaces
The following are the test agent interfaces:
a) Trigger logic download port
This port is used to download the test agent logic to the test agents. Typically
an SPI port will serve this propose.
b) Reference data download buffer
This port is used to download data to the reference buffer. This is a high
speed serial port.
c) Agent output
This port has parallel output bits which are programmable to serve different
indications of the test being conducted.
Data Path
Test
Agent Logic
Flexible
Interconnect
System Events
Reference Buffer
Trap Buffer
Comparator
D U T
Trigger Logic Download Port
Reference Data Download Port
Agent Output
Data Dump Port
63
d) Data dump port
If the data from the DUT is to be monitored externally, the flexible interconnect
can route the data to the Data Dump Port. The external device should be
capable of assimilating the data at real time.
e) Data path input
This interface is not available externally. It is a parallel 8, 16, 32 bit bus which
collects data from the DUT and gives it to the flexible interconnect.
f) System events input
These are multiple single bit inputs which provide signals for different events
occurring in the DUT.
4.2.3 Flexibility of Test Agent
Although the interfaces of the test agent are static in the context of the
application of the SoC under test, the test agent is completely reconfigurable
by incorporating machine code which is downloaded at runtime. This machine
code acts like a ladder logic to flexibly configure the interconnections between
various data streams based on different triggers and events.
4.3 AGENT DESIGN FOR IEEE 802.11e NETWORK STACK
The agent based real time testing concept is applied on a hardware/software
implementation of IEEE 802.11e MAC layer. The software resides in the
control processor which holds the 802.11e protocol logic which interacts with
the data path. Since the device had two instances of the stack, these are
referred to as DUT1 and DUT2. The interfaces of the test agent are
configured in the following manner:
Data Stream 1: Data input from host to the MAC layer.
Data Stream 2: Data output from the MAC layer to the host.
Data Stream 3: Data output from the MAC layer to the Base band.
Data Stream 4: Data input from Base band to the MAC layer.
The System events are programmed as follows:
CRC Fail : End of CRC comparison with Fail status
64
CRC Pass : End of CRC comparison with Pass status
System Clock : used to measure timers by integrating it with a counter
Encr Status : Status of encryption unit
TxVV : Transmit vector ready
TxS : Start of transmit packet
TxE : End of transmit packet
RxS : Start of receive packet
RxE : End of receive packet
TxOP Start : Start of transmit opportunity
TxOP End : End of transmit opportunity
4.3.1 Test Agent Implementation
The proposed agent based implementation was developed in Verilog and
synthesized over a PCI based FPGA board (Virtex-II platform). The
percentage area on FPGA of different modules is given in Table 4.1. only
3.5% of the area was occupied by the Testing agent.
Table 4.1 Percentage Areas of Different Modules of DUT
S. No Module % area on FPGA
1 Data Path and Processing Elements 23.4%
2 RISC Processor Engine 43.1%
3 I/O Interfaces 2.4%
4 Testing Agent 3.5%
5 Free 27.6%
4.4 TEST EXAMPLES ON IEEE 802.11e
A number of typical tests, which were implemented, for the verification of
IEEE 802.11e MAC Protocol, Wireless LAN for Quality of Service, are
described below:
65
(i) MAC header control field test
Different types of management/data/control packets were sent. Connected
received sample stream with data dump port. It was verified that the received
MAC header and the one in the reference buffer are same.
(ii) Sequence control
Packets from different access categories were sent. It was verified that the
sequence control field is same as saved in the reference buffer.
(iii) QoS field test
Packets were sent from different access categories and the QoS field was
tested that it matches with the one saved in the reference buffer.
(iv) Data-acknowledgement sequence test
A loop back connection was configured between DUT1 and DUT2. It was
verified that a valid packet and acknowledgement is received. Also the SIFS
interval between end of data packet to the start of the ACK was verified.
(v) RTS-CTS sequence test
A loop back connection between DUT1 and DUT2 was configured. It was
tested that valid RTS-CTS sequence is followed. SIFS interval between RTS-
CTS data-acknowledgement was also verified.
(vi) Fragmented packet sequence
DUT1 and DUT2 were arranged in a loop back configuration and connected
both station’s receive stream to data dump port. Verified that packet received
at the receiver side is properly de-fragmented by comparing with the
reference buffer. SIFS interval between fragments was also verified.
(vii) AIFS (Arbitration Inter Frame Spacing) test
Different category packets were sent and it was verified that AIFS for
respective access category is followed between the packets.
(viii) Contention resolution
It was verified that, if the medium is busy, the packet is transmitted after AIFS
+ backoff.
66
(ix) Block acknowledgement sequence test
Verified that no acknowledgements were transmitted between a block
acknowledgement session. Verified the contents of the packets and block
acknowledgement related packets through receive dump port.
(x) NAV (Network Allocation Vector) test
It was verified that NAV was updated and followed properly before packet
transmissions.
(xi) Acknowledgement policy test
It was verified that acknowledgement policy is followed after every packet.
(xii) Beacon test
It was verified that the beacon was transmitted on every TBTT (Target
Beacon Transmission Time). Each beacon was compared with reference
buffer to verify its contents.
(xiii) Transmit opportunity operation test
Verified that the proper duration value was written in the ‘MAC header
duration fields’ to cater the transmit opportunity packet by comparing the MAC
header with the reference buffer. It was also verified that transmissions are
SIFS apart.
4.4.1 RTS-CTS Test Example
The test discussed here is to verify the correct sequence of RTS-CTS data-
acknowledgement packets. This test verifies that the correct packet exchange
sequence is followed, the SIFS is maintained and the packet contents are
correct along with CRC. The two instances of device, DUT1 and DUT2 are
configured internally in loop back mode. A packet with RTS enable is sent to
DUT1. This packet is also downloaded in the reference buffer. After proper
frame exchange, the packet should arrive at the data stream 2 of DUT2. This
is stored in the trap buffer and compared with the reference buffer. Table 4.2
describes the system events and the actions that the agent logic took at each
event. This test was performed without specialized external test equipment.
Similar tests can be performed using general purpose expensive test
67
equipment which also requires extensive post processing.
Table 4.2 Trigger Logic of RTS-CTS Test
Event ACTION
TxVV at DUT1 Configure Flexible Interconnect to connect Receive Port for
DUT2 to Dump Port for length of RTS packet.
TxE at DUT1 Start counter to measure SIFS.
RxE at DUT2 Disconnect Receive Port for DUT2.
TxVV at DUT2 Configure Flexible Interconnect to connect Receive Port for
DUT1 to Dump Port for length of CTS packet.
TxS at DUT2 Stop the counter and verify that clock ran for SIFS time only, by
comparing with the SIFS value stored in the memory with the
counter. Reset Counter.
TxE at DUT2 Start counter to measure SIFS.
RxE at DUT1 Disconnect Receive Port for DUT1.
TxVV at DUT1 Configure Flexible Interconnect to connect Receive Port for
DUT2 to Dump Port for length of Data packet.
TxS at DUT1 Stop the counter and verify that clock ran for SIFS time only, by
comparing with the SIFS value stored in the memory with the
counter. Reset Counter.
TxE at DUT1 Start counter to measure SIFS.
RxE at DUT2 Disconnect Receive Port for DUT2.
TxVV at DUT2 Configure Flexible Interconnect to connect Receive Port for
DUT1 to Dump Port for length of Acknowledgement packet.
TxS at DUT2 Stop the counter and verify that clock ran for SIFS time only, by
comparing with the SIFS value stored in the memory with the
counter. Reset Counter.
RxE at DUT1 Disconnect Receive Port for DUT1. Connect Host port for DUT2
for length of Data packet.
Data was saved in the Trap buffer in the order of transmission.
Compare the contents of Reference buffer and Trap Buffer to
verify that packets were transmitted in order.
68
4.4.2 AIFS Test Example
The AIFS test aimed at asserting the arbitration fairness of the implemented
QoS algorithm. The IEEE MAC unit is subjected to 100 packets, 20 bytes of
payload of each traffic category (voice, video, best effort).
The transmission was fixed to 1 Mb/s, the slot time was 9 µs. The debug
agent was configured in such a way that it counts the total number of packets
transmitted (TxE event). The debug logic was configured to trigger a TxS and
the debug logic enables the trap buffer to capture the nth byte (packet type in
MAC header). The test was stopped after 100ms. Trap buffer was then
offloaded to a PC and packet types were counted. This test was repeated
under different traffic conditions in the wireless space, starting from only one
station to 10 stations. The results are presented in Figure 4.5. It is seen from
this figure that as the number of simultaneous stations increases the
throughput in each of the category decreases. However the device been
tested performs satisfactorily as the probability of sending packets in voice
and video is higher than the best effort. Hence the number of packets
transmitted by the voice traffic category remains higher than the video and
best effort in spite of the congested wireless environment.
Figure 4.5 AIFS Test, Under Different Traffic Conditions
4.5 HARDWARE LOGGING AGENT (HLA)
The idea of Hardware Logging Agent is still being explored. The idea focuses
on some embedded hardware which keeps track of all fault instances in SoC.
These logs are then read by the companion Software Agents (SA). The
0
10
20
30
40
50
60
1 2 3 4 5 6 7 8 9 10
No.
of
pac
kets
sen
t in
10
0 m
s p
er
eac
h T
raff
ic C
ate
gor
y
No. of stations operating simultanuesly
Voice
Video
Best effort
c
in
is
c
o
in
a
s
s
T
fa
s
sy
im
T
L
tr
its
ompiler us
nstances. A
s establishe
ompilation
ccurred. A
nstruction in
nd logs of
hows the
eparate de
The proactiv
ailure rate w
imulation r
ystem after
mplementat
The working
ogPoints w
ransmitted o
s original s
es these S
After the sy
ed which ge
ensures a
A prediction
n SOC. Eac
each targe
architectur
cision on d
ve compilat
with respec
results hav
r a failure h
tion and the
Figure 4.6
g HLA on s
were record
outside thro
tate.
SA and tak
ntactical pa
enerate war
a pre-hand
n unit in co
ch unit has
et debug a
re of prop
ifferent par
tion also ge
ct to differen
ve shown a
has occurre
e developm
6 Archite
simulation is
ded in Log
ough serial
kes decisio
asses of co
rnings base
d testing m
ompiler ma
different v
agent are m
posed HLA
rtitions base
enerates sta
nt instructio
a reasonab
ed. Further
ment of a too
ecture of Har
s shown in
ging Regis
interface a
ons to avoi
ompiler are
ed on previo
mechanism
akes a list
irtual debug
maintained
A. The com
ed upon pre
atistical pro
ons for each
ble reductio
r experimen
ol is under
rdware Logg
Figure 4.7
ster Bank. T
and Logging
id collapse
finished, t
ous logs. T
before a
of target u
g agent run
separately
mpiler can
ediction uni
ofiles to giv
h partition o
on in retrie
ntation on
process.
ging Agent
7. During o
These Log
g Register
s on simila
he test pas
The proactiv
failure ha
unit of eac
nning in HL
y. Figure 4.
n also hav
t.
e the overa
of SOC. Th
eval time o
its hardwar
peration fiv
gPoints wer
Bank retain
ar
ss
ve
as
ch
LA
.6
ve
all
he
of
re
ve
re
ns
4
[1
[2
[3
[4
4.6 REFE
1] Baig M
Configu
Techno
2] Ni, Q.,
Network
27, July
3] Mangold
LAN for
39, Flor
4] Mangold
802.11e
Commu
Figure
ERENCES
M. I., Mufti M
urable Hard
logy, Mehra
“Performanc
ks”, Network
y/Aug 2005
d, S., Choi,
r Quality of S
rence, Italy,
d, S., Choi,
e for QoS S
unications So
4.7 Sim
S
M. and Jam
dware Age
an University
ce Analysis
k, IEEE Com
S., May, P.,
Service”, in
February 20
S., Hiertz, G
Support in W
ociety, Vol. 1
mulation resu
al H., “QoS
nt”, Resea
y, Jamshoro
and Enhan
mmunication
Klein, O. an
proc. of Eur
002
G.R., Klein,
Wireless LAN
10, Issue 6,
ult: Working
S Testing of
arch Journa
o, vol. 29, No
cements for
ns Society, V
nd Stibor, L.
ropean Wire
O. and Wal
Ns”, Wireless
pp. 40-50, D
of HLA
IEEE 802.
al of Engi
o. 1, pp. 1-10
r IEEE 802.
Vol. 19, Iss
, “IEEE 802
eless Confer
ke, B., “Ana
s Communic
December, 2
11e MAC v
ineering an
0, Jan. 2010
11e Wireles
ue 4, pp. 2
.11e Wireles
rence, pp. 32
alysis of IEE
cations, IEE
2003
via
nd
0
ss
1-
ss
2-
EE
EE
CHAPTER 5
5 IMPLEMENTATION OF WHITE BOX TEST AGENT
ON A RISC PROCESSOR CORE
The testing methodologies mentioned in the previous chapters are generally
based on resource testing for example registers status etc or are self test
methodologies. The dissertation focuses on modular white box testing
methodology. The test agent and its methodology resemble nature of
simulation in software. There are particular advantages to existing testing
mechanisms.
The assertions are not hardwired or burned into chip and can be applied
externally; this contributes to more generic assertions.
Each module is visible externally and any test patterns can be applied to
module individually. This allows flexibility testing and easier results
available for realization.
The assertions if fire can halt/freeze the system and internal state
conditions can be ported outside the chip through some serial port, so no
memory or comparison mechanism is required inside the chip. This can
save on chip area and avoids limitation of comparison mechanism.
The testing agent will take minimum effective area with folded agent
architect and minimum delay line without folding architecture.
The test agent does not contribute to the length of the critical path as it
works separately from the processor. To ensure the working policy the
processor can work in two separate modes i.e. test mode (off-line) where it
will not perform any job except for testing and the run mode (on-line)
where processor works normally and test agent just monitors the status.
Unlike the BIST architecture where the design requires additional cold
start time before it is available for the job.
The agent can be applied equally good to any architecture, but to ensure the
performance of the architecture, a relatively small design of RISC processor is
72
taken as the test reference. A RISC processor core which is presented by
Michael D. Ciletti in his book [1] is taken as base line for implementation of
white box testing agent. The design is enhanced to make it comparable for
test, a set of sixteen instructions in three different formats are selected for this
processor. These sixteen instructions contain all the ten instructions of Ciletti’s
design and six more instructions which are accommodated in 4-bit op-code
field.
5.1 INSTRUCTION SET
The instructions of RISC processor are categorized into three different
formats as shown below:
Format-1 (single byte instruction)
Op code Rd Rs
Format-2 (single byte instruction)
Op code Rd AMT
Format-3 (two byte instruction)
Op code Rd Rs
Address
In all above three formats, 4-bit op-code field selects one of the sixteen
instructions listed in Table 5.1. Rd (destination register) and Rs (source
register) are two 2-bit fields to select one of the 8-bit registers from the
register-file of four registers (R0 ~ R3). AMT is a two bit field for shift and
increment instructions. In Format-3 the second byte contains an 8-bit address
for memory read, write and branch instructions.
The processor has four main parts: ALU (Arithmetic Logic Unit), Register File,
Memory and a Controller. The block diagram of this processor is shown in
Figure 5.1. The operation of each instruction is described below:
73
Table 5.1 Instruction Set of RISC Processor
Op Code
Instr Operation Format Action
0000 NOP No Operation Format-1 None
0001 ADD Addition Format-1 Rd Rd + Rs
0010 SUB Subtraction Format-1 Rd Rd - Rs
0011 MUL Multiplication Format-1 Rd Rd x Rs
0100 AND AND Logical Format-1 Rd Rd && Rs
0101 INC Increment Format-2 Rd Rd + AMT (2-bit)
0110 DEC Decrement Format-2 Rd Rd – AMT (2-bit)
0111 SHL Shift Left Format-2 Rd SHL (Rd), AMT
1000 SHR Shift Right Format-2 Rd SHR (Rd), AMT
1001 MOV Move Format-1 Rd Rs
1010 WR Write to Memory
Format-3 Mem [Addr] Rs
1011 RD Read from Memory
Format-3 Rd Mem [Addr]
1100 BRN Branch Unconditional
Format-3 PC Add
1101 BRZ Branch if Zero Format-3 PC Add (if flag Z = 1 )
1110 BLT Branch if Less then
Format-3 PC Add (if flag LT = 1)
1111 HALT Halt Format-1 Halts and resumes on reset
NOP No operation is performed, all registers retain their values, Rd and Rs
fields are don’t cares and have no effect.
ADD Adds contents of two registers, Rd and Rs, and result is saved in Rd.
SUB Subtracts Rs from Rd and result is saved in Rd.
MUL Multiplies Rs to Rd (only lower nibbles) and product is saved in Rd.
AND A logical AND operation is performed between Rd and Rs.
INC, DEC Rd is incremented or decremented by two bit value in AMT,
S
M
W
R
B
B
B
T
C
a
M
SHL, SHR
MOV Conte
WR The c
byte o
RD The c
are re
BRN Branc
PC (p
BRZ Branc
zero f
BLT Branc
PC if
The ASMD
Control Unit
nd initially
ModelSim (v
Figur
Rd shifts le
ents of Rs c
contents of
of the instru
contents of
ead and co
ch uncondit
program co
ch if Zero,
flag is logic
ch if Less T
result of AL
of the cont
. The above
its functio
ver. 6.1f SE
re 5.1 RI
eft or right A
copies to R
Rs are writ
uction.
f memory a
pied to Rd.
tional, addr
unter regist
address in
c ‘1’.
Than, addre
LU is less t
trol unit is
e described
onality was
E) by writing
SC Processo
AMT times
Rd.
tten to mem
addressed
ress in 2nd
ter).
2nd byte of
ess in 2nd b
than the sou
given below
d RISC pro
s tested a
g some app
or: Block dia
and ‘0’ is in
mory at the
by the 2nd
byte of the
f the instru
byte of the
urce Regist
w which de
cessor is d
and verified
propriate tes
agram
nserted.
address re
byte of th
instruction
ction is cop
instruction
ter.
escribes the
esigned in
d in Mento
st benches
eferred in 2
e instructio
is loaded
pied to PC
is copied t
e working o
Verilog HD
or Graphic
.
nd
on
in
if
to
of
DL
c’s
5
A
c
c
th
to
F
fu
a
h
w
S
C
p
5.2 ON-C
A test circui
ircuit has
ircuit is des
he processo
o work in tw
First it can
unctionality
ll design m
elp of appr
were verified
Second it ca
Complete d
resented in
Figu
CHIP TEST
it is added
internal lin
signed suc
or: like me
wo ways.
internally
of differen
modules inc
ropriate stim
d. Results a
an monitor
design, com
n section 5.
ure 5.2 A
T AGENT
in the abo
ks with dif
ch that it is
mory, ALU
apply app
t sections o
cluding test
muli functio
are shown i
the activitie
mpiled and
3.2.
ASMD of the
ove design
fferent bloc
internally c
, controller
propriate te
of the proce
agent wer
onality of d
in section 3
es of the pr
synthesiz
RISC Proces
as shown
cks of the
connected
etc. this te
est pattern
essor in off
re written in
different sec
3.4.
rocessor w
ed, on Me
ssor
in figure 5
processor
to different
ester agent
ns and can
f-line mode
n Verilog H
ctions of th
orking in o
entor Grap
5.3. This tes
. The teste
t sections o
is designe
n verify th
. In our cas
DL and wit
he processo
n-line mode
hics Tool
st
er
of
ed
he
se
th
or
e.
is
5
T
ta
A
R
sy
re
s
5
C
Crdada
sl
F
5.3 SYNT
The complet
argeted on
Architect, El
RegisterFile
ynthesized
esults along
ub-sections
5.3.1 Pro
Critical Path
ritical paata requirata arriva
lack
igure 5.3
THESIS R
te design a
ASIC with
ldo and Ez
, Datapath
and then
g with sche
s.
ocessor S
h: (RISC Pro
ath #1, (pared time al time
Block Diag
RESULTS
along with te
Mentor Gr
wave. Thro
h, Controlle
complete
ematic des
Synthesis
ocessor)
ath slack
gram: RISC P
ester circui
raphics tool
ough these
er and Tes
processor.
signs of eac
without T
= 5.0): 5. 0. -----
5.
Processor wi
t was synth
l set: Leona
tools all m
ster Agent
The funct
ch module
Test Agent
.00
.00 ------
.00
ith Test Agen
hesized, op
ardo Spect
modules, AL
were first
tional, timin
are shown
t
nt
ptimized, an
trum, Desig
LU, Memory
t individual
ng and are
n in the nex
nd
gn
y,
ly
ea
xt
F
S
N N N To N N N N
F
S
N N N To N N N
C
Figure 5.4 s
Summary of
Number of Number of Number of
otal accumNumber of Number of Number of Number of
Figure 5.5 s
Summary of
Number of Number of Number of
otal accumNumber of Number of Number of
Clock Frequ
clk
hows synth
Figu
f area repor
ports : nets : instances
mulated arefake_gnd :fake_vcc :gates : accumulate
hows synth
f area repor
ports : nets : instances
mulated arefake_vcc :gates : accumulate
uency Repo
hesized RIS
ure 5.4 S
rt: (RISC P
:
ea : : : ed instanc
hesized Con
rt: (Control
:
ea : : ed instanc
ort: (Control
:
SC Process
Synthesized
rocessor)
1 1
156ces : 107
ntrol unit of
Unit)
2 1
2ces : 1
Unit)
341.5 M
sor without
RISC Proces
119 144 5
14 5 644 779
f the RISC
32 204 191
1 253 191
MHz
Test Agent
ssor
Processor.
t, top level.
C
Cr dada sl
S
ALMePCRe N N N To N N N
Critical Path
ritical pa
ata requirata arriva lack
Summary of
LU emory C egisterFil
Number of Number of Number of
otal accumNumber of Number of Number of
Figu
h Report: (C
ath #1, (
red time al time
f area repor
le
ports : nets : instances
mulated arefake_gnd :gates : accumulate
ure 5.5 C
Control Unit
(path slac
rt: (Datapat
:
ea : : ed instanc
Control Unit:
t)
ck = 2.1):
4. 2. ----- 2.
th)
1 x 7 1 x 115 1 x 1 1 x 1
3 2
128ces : 86
: circuit diag
:
.47
.40 ------ .07
734 734547 11547109 109196 196
63 312 230
4 878 656
gram
4 gates 7 gates 9 gates 6 gates
C
C
Cr dada sl
Clock Frequ
clk
Critical Path
ritical pa
ata requirata arriva lack
Fi
uency Repo
h Report: (D
ath #1, (pa
red time al time
gure 5.6
ort: (Datapa
: 2
Datapath)
ath slack
Datapath: c
ath)
22.3 MHz
= -39.7):
4.7 44.4 ------ -39.6
circuit diagra
79 48 ----- 69
am
S
N N NTo N N N
C
Cr dada sl
Summary of
Number of Number of Number of otal accumNumber of Number of Number of
Critical Path
ritical pa
ata arrivaata requir lack
Figu
f area repor
ports : nets : instances
mulated arefake_gnd :gates : accumulate
h Report: (R
ath #1, (pa
al time red time
ure 5.7 R
rt: (Registe
: ea : : ed instanc
RegisterFile
ath slack
Register File
rFile)
1 1
2ces : 1
e)
= 3.7):
1. 5. ----- 3.
: circuit diag
53 147 135
1 200 135
.30
.00 ------ .70
gram
S
N N N To N N
C
Cr d d s
Summary of
Number of Number of Number of
otal accumNumber of Number of
Critical Path
ritical pa
data requidata arriv slack
f Area Repo
ports : nets : instances
mulated aregates : accumulate
h Report: (A
ath #1, (pa
ired time val time
Figure 5.8
ort: (ALU)
:
ea : ed instanc
ALU)
ath slack
ALU: circ
5 4
6ces : 4
= -2.6):
5. 7. ------ -2.
cuit diagram
32 506 484
647 484
.00
.58 ----- .58
5
F
a
S
N N N N To N N N N
5.3.2 Pro
Figure 5.8 s
rea, freque
Summary of
Number of Number of Number of Number of
otal accumNumber of Number of Number of Number of
ocessor S
shows the
ency and cr
Figure 5.9
f Area Repo
ports : nets : instances references
mulated arefake_gnd :fake_vcc :gates : accumulate
Synthesis
RISC proc
itical path a
Synthesi
ort: (Test A
: s to this
ea : : : ed instanc
with Test
cessor alon
are as unde
zed RISC Pr
Agent)
1 1view :
141ces : 95
Agent
ng with Te
er.
rocessor with
86 186 109 1
8 2 120 590
est Agent. S
h Test Agent
Summary o
t
of
C
C
F
a
A
Clock Frequ
clk
Critical Path
Criticaldata reqdata arr slack
Figure 5.9 s
nd timing r
Appendix A.
uency Repo
h Report (Te
l path #1, quired timerival time
shows bloc
reports of R
.
Figure
ort: (Test Ag
: 1
est Agent)
(path slae
ck diagram
RISC proce
e 5.10 Syn
gent)
19.9 MHz
ack = -37.6 --- -
of synthes
essor along
nthesized Te
6): 5.00 42.59 -------- -37.58
sized Test
g with test
est Agent (de
Agent. Co
Agent can
etailed)
omplete are
n be seen
ea
in
84
5.4 REFERENCES
[1] Ciletti M.D., "Advance Digital Design with the Verilog HDL”, Pearson Education
Inc., Prentice Hall, 2005
CHAPTER 6
6 CONCLUSIONS
The thesis presented a review of testing of ICs in its first two chapters. The
differences between Black Box testing and White Box testing are highlighted.
Hardware checkers and Hardware test agents were introduced. Terminology
used in testing and fault models is described. Existing testing methods:
Formal techniques, Design for Test, Design for debug and Assertion based
testing are reviewed.
Removable hardware checker concept is explored. The concept is applied to
circuits of varying complexities. A large saving in testing time is observed and
full test coverage is easily possible using this new concept. The design which
takes days in testing with simulation runs, gives equivalent results in minutes
when it is run on FPGA prototype along with the proposed tester circuit.
Reconfigurable hardware test agent, which resides within the DUT, is used to
test communication devices. In particular the concept is applied to test
Medium Access Control (MAC) layer of Wireless LAN found in the IEEE
802.11e standard. It proved very efficient in saving time and cover corner
cases.
A RISC processor was fully tested using the proposed concepts.
The test agent ensures a modular testing behavior in the device. The
assertions can be applied to the chip dynamically from the external interface
and the results can be viewed externally. This makes the testing mechanism
more viable and generic. However the current methodology does not make
the design recoverable or correctable if a particular fault is traced at certain
assertion. Therefore efforts are underway in the direction of ‘fault recovery’ on
certain assertions traced by any silicon testing mechanism. A tool for
automated generation of test patterns and fault recovery is being developed.
Our proposed Proactive Logging Agent will be very useful for merging of fault
detection and recovery into a single architecture.
86
APPENDICES
A. Complete Area Report of RISC Processor (with Test Agent)
********************************************************** Cell: PC View: INTERFACE_unfold_1079_1 Library: work ********************************************************** Cell Library References Total Area buf04 tsmc035_typ 1 x 1 1 gates dff tsmc035_typ 10 x 5 48 gates inv01 tsmc035_typ 6 x 1 5 gates nand02 tsmc035_typ 11 x 1 11 gates nand03 tsmc035_typ 1 x 1 1 gates nand04 tsmc035_typ 1 x 1 1 gates nor02_2x tsmc035_typ 9 x 1 9 gates nor03_2x tsmc035_typ 3 x 1 4 gates nor04 tsmc035_typ 1 x 1 1 gates oai21 tsmc035_typ 11 x 1 14 gates oai22 tsmc035_typ 1 x 1 1 gates xnor2 tsmc035_typ 1 x 2 2 gates Number of ports : 19 Number of nets : 75 Number of instances : 56 Number of references to this view : 1 Total accumulated area : Number of gates : 99 Number of accumulated instances : 56 ************************************************************** Cell: Memory View: INTERFACE_unfold_1076_1 Library: work ************************************************************** Cell Library References Total Area Number of ports : 25 Number of nets : 1 Number of instances : 1 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of accumulated instances : 1 ****************************************************************** Cell: RegisterFile View: INTERFACE_unfold_1100 Library: work ****************************************************************** Cell Library References Total Area aoi33 tsmc035_typ 1 x 2 2 gates buf02 tsmc035_typ 17 x 1 17 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd inv01 tsmc035_typ 22 x 1 17 gates inv02 tsmc035_typ 13 x 1 10 gates
87
latch tsmc035_typ 24 x 2 60 gates latchr tsmc035_typ 16 x 3 43 gates nand02 tsmc035_typ 2 x 1 2 gates nand02_2x tsmc035_typ 1 x 1 1 gates nand03 tsmc035_typ 21 x 1 26 gates nor02_2x tsmc035_typ 16 x 1 16 gates nor03_2x tsmc035_typ 10 x 1 12 gates oai32 tsmc035_typ 1 x 2 2 gates Number of ports : 53 Number of nets : 157 Number of instances : 145 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of gates : 208 Number of accumulated instances : 145 ************************************************************** Cell: DataPath View: INTERFACE_unfold_1251 Library: work ************************************************************** Cell Library References Total Area ALU work 1 x 764 764 gates Memory work 1 x 1 1 fake_gnd PC work 1 x 99 99 gates RegisterFile work 1 x 208 208 gates ao221 tsmc035_typ 1 x 2 2 gates aoi22 tsmc035_typ 7 x 1 10 gates buf02 tsmc035_typ 19 x 1 19 gates buf04 tsmc035_typ 1 x 1 1 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd fake_vcc tsmc035_typ 1 x 1 1 fake_vcc inv01 tsmc035_typ 15 x 1 11 gates inv02 tsmc035_typ 8 x 1 6 gates latch tsmc035_typ 16 x 2 40 gates nand02 tsmc035_typ 32 x 1 32 gates nor02_2x tsmc035_typ 17 x 1 17 gates nor03_2x tsmc035_typ 1 x 1 1 gates oai22 tsmc035_typ 1 x 1 1 gates Number of ports : 63 Number of nets : 196 Number of instances : 124 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 4 Number of fake_vcc : 1 Number of gates : 1213 Number of accumulated instances : 938 ***************************************************************** Cell: ControlUnit View: INTERFACE_unfold_1255 Library: work ***************************************************************** Cell Library References Total Area and02 tsmc035_typ 2 x 1 3 gates and04 tsmc035_typ 1 x 2 2 gates
88
ao21 tsmc035_typ 1 x 2 2 gates aoi21 tsmc035_typ 3 x 1 4 gates aoi22 tsmc035_typ 2 x 1 3 gates aoi322 tsmc035_typ 1 x 2 2 gates aoi43 tsmc035_typ 1 x 2 2 gates aoi44 tsmc035_typ 1 x 3 3 gates buf02 tsmc035_typ 6 x 1 6 gates buf04 tsmc035_typ 6 x 1 7 gates buf16 tsmc035_typ 2 x 3 6 gates dffr tsmc035_typ 1 x 6 6 gates dffs_ni tsmc035_typ 3 x 6 17 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd fake_vcc tsmc035_typ 1 x 1 1 fake_vcc inv01 tsmc035_typ 32 x 1 24 gates inv02 tsmc035_typ 35 x 1 27 gates latch tsmc035_typ 17 x 2 42 gates nand02 tsmc035_typ 22 x 1 22 gates nand02_2x tsmc035_typ 1 x 1 1 gates nand03 tsmc035_typ 18 x 1 22 gates nand03_2x tsmc035_typ 5 x 1 6 gates nand04 tsmc035_typ 4 x 1 6 gates nand04_2x tsmc035_typ 1 x 2 2 gates nor02_2x tsmc035_typ 40 x 1 40 gates nor02ii tsmc035_typ 7 x 1 9 gates nor03_2x tsmc035_typ 13 x 1 16 gates oai21 tsmc035_typ 11 x 1 14 gates oai22 tsmc035_typ 6 x 1 9 gates oai221 tsmc035_typ 2 x 2 4 gates oai32 tsmc035_typ 2 x 2 3 gates xnor2 tsmc035_typ 1 x 2 2 gates Number of ports : 36 Number of nets : 261 Number of instances : 249 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of fake_vcc : 1 Number of gates : 311 Number of accumulated instances : 249 ************************************************************ Cell: Memory View: INTERFACE_unfold_1076 Library: work ************************************************************ Cell Library References Total Area inv02 tsmc035_typ 5 x 1 4 gates latch tsmc035_typ 16 x 2 40 gates Number of ports : 25 Number of nets : 30 Number of instances : 21 Number of references to this view : 1 Total accumulated area : Number of gates : 43 Number of accumulated instances : 21
89
******************************************************************** Cell: RegisterFile View: INTERFACE_unfold_1100_0 Library: work ******************************************************************** Cell Library References Total Area aoi21 tsmc035_typ 2 x 1 2 gates buf02 tsmc035_typ 15 x 1 15 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd inv01 tsmc035_typ 3 x 1 2 gates inv02 tsmc035_typ 13 x 1 10 gates latch tsmc035_typ 24 x 2 60 gates latchr tsmc035_typ 16 x 3 43 gates nand02 tsmc035_typ 3 x 1 3 gates nand02_2x tsmc035_typ 1 x 1 1 gates nand03 tsmc035_typ 21 x 1 26 gates nor02_2x tsmc035_typ 22 x 1 22 gates nor03_2x tsmc035_typ 7 x 1 9 gates oai22 tsmc035_typ 1 x 1 1 gates Number of ports : 53 Number of nets : 141 Number of instances : 129 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of gates : 195 Number of accumulated instances : 129 ************************************************************** Cell: DataPath View: INTERFACE_unfold_1189 Library: work ************************************************************** Cell Library References Total Area ALU work 1 x 764 764 gates Memory work 1 x 43 43 gates RegisterFile work 1 x 195 195 gates ao21 tsmc035_typ 1 x 2 2 gates buf02 tsmc035_typ 4 x 1 4 gates inv01 tsmc035_typ 18 x 1 14 gates inv02 tsmc035_typ 14 x 1 11 gates latch tsmc035_typ 16 x 2 40 gates nand02 tsmc035_typ 16 x 1 16 gates nand03 tsmc035_typ 23 x 1 29 gates nor02_2x tsmc035_typ 36 x 1 36 gates nor03_2x tsmc035_typ 7 x 1 9 gates oai21 tsmc035_typ 1 x 1 1 gates oai22 tsmc035_typ 8 x 1 12 gates Number of ports : 63 Number of nets : 187 Number of instances : 148 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 3 Number of gates : 1174 Number of accumulated instances : 911
90
******************************************************* Cell: ALU View: INTERFACE Library: work ******************************************************* Cell Library References Total Area and02 tsmc035_typ 3 x 1 4 gates ao22 tsmc035_typ 1 x 2 2 gates aoi21 tsmc035_typ 4 x 1 5 gates aoi22 tsmc035_typ 11 x 1 16 gates aoi222 tsmc035_typ 5 x 2 11 gates aoi32 tsmc035_typ 4 x 2 7 gates aoi321 tsmc035_typ 7 x 2 15 gates aoi322 tsmc035_typ 1 x 2 2 gates aoi422 tsmc035_typ 1 x 3 3 gates buf02 tsmc035_typ 9 x 1 9 gates buf04 tsmc035_typ 1 x 1 1 gates buf16 tsmc035_typ 2 x 3 6 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd inv01 tsmc035_typ 59 x 1 45 gates inv02 tsmc035_typ 101 x 1 77 gates latch tsmc035_typ 4 x 2 10 gates latchr tsmc035_typ 4 x 3 11 gates mux21 tsmc035_typ 21 x 2 38 gates nand02 tsmc035_typ 84 x 1 84 gates nand02_2x tsmc035_typ 7 x 1 7 gates nand03 tsmc035_typ 14 x 1 17 gates nand03_2x tsmc035_typ 1 x 1 1 gates nand04 tsmc035_typ 14 x 1 21 gates nand04_2x tsmc035_typ 2 x 2 4 gates nor02_2x tsmc035_typ 88 x 1 88 gates nor02ii tsmc035_typ 6 x 1 7 gates nor03_2x tsmc035_typ 23 x 1 29 gates nor04 tsmc035_typ 1 x 1 1 gates nor04_2x tsmc035_typ 1 x 2 2 gates oai21 tsmc035_typ 12 x 1 15 gates oai22 tsmc035_typ 24 x 1 36 gates oai221 tsmc035_typ 3 x 2 6 gates oai32 tsmc035_typ 2 x 2 3 gates or02 tsmc035_typ 3 x 1 4 gates xnor2 tsmc035_typ 92 x 2 176 gates Number of ports : 32 Number of nets : 638 Number of instances : 616 Number of references to this view : 3 Total accumulated area : Number of fake_gnd : 1 Number of gates : 764 Number of accumulated instances : 616 ***************************************************************** Cell: ControlUnit View: INTERFACE_unfold_1202 Library: work ***************************************************************** Cell Library References Total Area aoi21 tsmc035_typ 2 x 1 2 gates aoi22 tsmc035_typ 2 x 1 3 gates aoi221 tsmc035_typ 1 x 2 2 gates
91
aoi321 tsmc035_typ 1 x 2 2 gates aoi44 tsmc035_typ 1 x 3 3 gates dffr tsmc035_typ 1 x 6 6 gates dffs_ni tsmc035_typ 3 x 6 17 gates inv01 tsmc035_typ 10 x 1 8 gates inv02 tsmc035_typ 27 x 1 21 gates latch tsmc035_typ 16 x 2 40 gates mux21 tsmc035_typ 3 x 2 5 gates nand02 tsmc035_typ 15 x 1 15 gates nand03 tsmc035_typ 17 x 1 21 gates nand03_2x tsmc035_typ 1 x 1 1 gates nand04 tsmc035_typ 5 x 1 7 gates nor02_2x tsmc035_typ 39 x 1 39 gates nor02ii tsmc035_typ 4 x 1 5 gates nor03_2x tsmc035_typ 10 x 1 12 gates oai21 tsmc035_typ 8 x 1 10 gates oai22 tsmc035_typ 3 x 1 4 gates oai221 tsmc035_typ 1 x 2 2 gates oai32 tsmc035_typ 1 x 2 2 gates Number of ports : 36 Number of nets : 186 Number of instances : 173 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of fake_vcc : 1 Number of gates : 228 Number of accumulated instances : 173 ******************************************************* Cell: Memory View: INTERFACE Library: work ******************************************************* Cell Library References Total Area buf02 tsmc035_typ 1795 x 1 1831 gates inv01 tsmc035_typ 21 x 1 16 gates inv02 tsmc035_typ 963 x 1 732 gates inv04 tsmc035_typ 10 x 1 10 gates latch tsmc035_typ 264 x 2 655 gates latchr tsmc035_typ 1792 x 3 4838 gates nand02 tsmc035_typ 152 x 1 152 gates nand03 tsmc035_typ 313 x 1 388 gates nand04 tsmc035_typ 286 x 1 423 gates nor02_2x tsmc035_typ 1036 x 1 1036 gates nor03_2x tsmc035_typ 223 x 1 277 gates nor04 tsmc035_typ 128 x 1 190 gates oai22 tsmc035_typ 672 x 1 995 gates Number of ports : 25 Number of nets : 7673 Number of instances : 7656 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of gates : 11543 Number of accumulated instances : 7656
92
****************************************************************** Cell: RegisterFile View: INTERFACE_unfold_1185 Library: work ****************************************************************** Cell Library References Total Area buf02 tsmc035_typ 18 x 1 18 gates fake_gnd tsmc035_typ 1 x 1 1 fake_gnd inv01 tsmc035_typ 3 x 1 2 gates inv02 tsmc035_typ 10 x 1 8 gates latch tsmc035_typ 24 x 2 60 gates latchr tsmc035_typ 16 x 3 43 gates nand02 tsmc035_typ 4 x 1 4 gates nand03 tsmc035_typ 24 x 1 30 gates nor02_2x tsmc035_typ 22 x 1 22 gates nor03_2x tsmc035_typ 8 x 1 10 gates Number of ports : 53 Number of nets : 142 Number of instances : 130 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 1 Number of gates : 197 Number of accumulated instances : 130 *************************************************************** Cell: TestAgent View: INTERFACE_unfold_1252 Library: work *************************************************************** Cell Library References Total Area ALU work 1 x 764 764 gates ControlUnit work 1 x 228 228 gates DataPath work 1 x 1174 1174 gates Memory work 1 x 11543 11543 gates RegisterFile work 1 x 197 197 gates buf02 tsmc035_typ 2 x 1 2 gates inv01 tsmc035_typ 4 x 1 3 gates inv02 tsmc035_typ 10 x 1 8 gates latch tsmc035_typ 78 x 2 193 gates nand02 tsmc035_typ 1 x 1 1 gates nand03 tsmc035_typ 2 x 1 2 gates nor02_2x tsmc035_typ 2 x 1 2 gates nor03_2x tsmc035_typ 2 x 1 2 gates tri01 tsmc035_typ 1 x 1 1 gates Number of ports : 86 Number of nets : 186 Number of instances : 109 Number of references to this view : 1 Total accumulated area : Number of fake_gnd : 8 Number of fake_vcc : 2 Number of gates : 14120 Number of accumulated instances : 9590
93
******************************************************* Cell: Processor View: INTERFACE Library: work ******************************************************* Cell Library References Total Area ControlUnit work 1 x 311 311 gates DataPath work 1 x 1213 1213 gates TestAgent work 1 x 14120 14120 gates Number of ports : 119 Number of nets : 144 Number of instances : 5 Number of references to this view : 0 Total accumulated area : Number of fake_gnd : 14 Number of fake_vcc : 5 Number of gates : 15644 Number of accumulated instances : 10779
![Hearth Money Rolls [1663] for Co. Londonderry [T307 ...billmacafee.com/1660shearthmoneyrolls/1663hearth... · Hearth Money Rolls [1663] for Co. Londonderry [T307] [Sorted by Surname,](https://static.documents.pub/doc/80x56/602730d909222f5192711bd2/hearth-money-rolls-1663-for-co-londonderry-t307-hearth-money-rolls-1663.jpg)
![Hearth Money Rolls [1663] for Co ... - Adams Family DNAadamsfamilydna.com/wp-content/uploads/2013/02/1663-Hearth-Money...Hearth Money Rolls [1663] for Co. Londonderry [T307] [Sorted](https://static.documents.pub/doc/80x56/5b4b8a967f8b9a5c278ce123/hearth-money-rolls-1663-for-co-adams-family-money-rolls-1663-for-co-londonderry.jpg)
