CC BY
39Contract Specification of Pipelined Designs: Application to Testbench Automation
Alexander Kamkin Software Engineering Department Institute for System Programming of Russian Academy of Sciences 25, B. Kommunisticheskaya, Moscow, 109004, Russia E-mail: [email protected]
Abstract—In this paper we introduce a novel approach to formal specification of pipelined designs. The approach is based on contract specifications of pipe stages extended by a mechanism of temporal binding. Contract specifications describe the pipeline behavior in the form of preconditions and postconditions of pipe stages, while temporal binding combines specifications of separated stages into a co-operative specification. Such specifications are suitable for automatic generation of test oracles which check design correctness. The approach was integrated into the CTESK test development tool from the UniTESK toolkit. The methodology was successfully applied to several modules of the industrial microprocessor.
I. Introduction
Modem world can not be imagined without huge variety of electronic devices. Mobile phones, digital cameras and briefcase computers have become the integral parts of human life. Special devices manage household appliances, control airplanes and space satellites, regulate medical systems of life support. Practically all of such systems are based on digital semiconductor hardware.
To make sure that hardware works correctly, i.e. meets all functional requirements stipulated in documentation, functional testing is usually used [1]. Requirements on thoroughness of hardware design testing are very strong. This is not only connected with the fact that hardware underlies all computer systems including safety-critical ones. Powerful influence on requirements is also exerted by economic forces.
In contrast to software, where an error correction (not error consequencies) does not cost anything, a post-silicon error in hardware can cause reproduction of all erroneous devices. The well-known FDIV bug in Pentium microprocessor consisted in incorrect division of some floating-point numbers cost Intel about $475 millions [2]. Time constraints of testing are also very strong. It is crucially important to develop system in time while it is much in demand.
Currently, the high-level hardware description languages (HDLs) are widely used in electronic design. The HDLs greatly speed up a development process by automated translation of the register-transfer-level (RTL) description into the gate-level netlist. However they can not guarantee that system developed is faultless. Thus, a testbench development does remain an acute and very important task.
State-of-the-art complexity of hardware designs does not allow to develop suitable test suites manually in reasonable
time. The need of automated testbench development technologies is widely recognized. Development of such technologies and supporting tools has separated to a special branch of electronic design automation (EDA) industry which is known as testbench automation.
The main task of testing is to verify correspondence between design under test (DUT) behavior and requirements. To have the ability to do it automatically requirements should be represented in machine-readable form. Such form of requirements representation is usually called formal specifications or specifications for short.
The article focuses on specification and testing of pipelined designs. Pipelining is the key implementation technique used to make fast designs [3]. Generally, pipelining is the way of system organization whereby multiple operations are overlapped in execution. Each step in the pipeline, called pipe stage, completes a part of an operation; different steps are completing different parts of different operations in parallel.
Pipelining yields a reduction in the average execution time per operation, but it also introduces additional problems and new sources of errors. For example, two different operations can access the same resource on the same clock cycle. Such errors are called control logic bugs. According to statistics given in [4], 93.5% of MIPS R4000PC/SC errata (revision 2.2) [5] are control logic bugs.
We propose an approach applicable to complex industrial pipelined designs. The approach is based on contract specifications of pipe stages extended by a mechanism of temporal binding. Contract specifications describe the pipeline behavior in the form of preconditions and postconditions of pipe stages, while temporal binding combines specifications of separated stages into a co-operative specification.
The rest of the paper is organized as follows. The second section contains base definitions. In the third section contract specification of pipeline is considered. The fourth section comprises a short review of the UniTESK technology and the CTESK test development tool. In the fifth section related work is outlined. The sixth section is a case study. Finally, the seventh section concludes the paper.
II. Base Definitions
The classical model of finite state machine (FSM) extended with context variables, parameters, predicates, and functions
defined over context variables and parameters is known as extended automaton or extended finite state machine (EFSM), if automaton has a finite set of states and a finite transition relation [6]. Henceforward we will use the EFSM abbreviation even if a set of states or a transition relation are infinite.
The EFSM paradigm is widely used in computer science to model different kinds of software and hardware systems, such as real-time control systems, telecommunication protocols, etc. The FSM underlying an EFSM is said to model the control flow of a system, while context variables, parameters, and functions reflect its data flows. In this paper we use EFSM to model pipelined designs.
Hereinafter we will unify context variables and parameters of EFSM by general term variables. In the following definitions we suppose that each EFSM variable v is associated with a set of possible values Dv, which is called domain of variable v. If V is a set of variables, then DV denotes a set of possible valuations of variables from set V.
Definition 1: An EFSM is a 6-tuple {S, V,I U O, X, Y, T), where:
• S is a set of states;
• V is a set of context variables;
• IU O is a set of input and output parameters;
• X is a set of stimuli;
Each stimulus x e X is parameterized by input parameters inx C I; let Dx be a set of inx valuations.
• Y is a set of reactions;
Each reaction y e Y is parameterized by output parameters outy C O; let Dy be a set of outy valuations.
• T is a transition relation.
Two subsets of V are specified for each transition t e T:
— uset C V
is a set of context variables used by the transition;
— deft C V
is a set of context variables defined by the transition. Transition t is a 7-tuple (st, xt, yt, jt, Xt, St, s't), where:
— st e S
is an initial state of the transition;
— Yt : Dx x Duset ^ {true, false}
is a guard condition of the transition;
— Xt • Dx x Duset ^ Dy
is a reaction function of the transition;
— St • Dx x Duset ^ Ddeft
is a context update function of the transition;
— st e S
is a final state of the transition. ■
Definition 2: A context variables valuation v e DV is called a context of EFSM. ■
Definition 3: A pair (s, v) e S x DV is called a configuration of EFSM. ■
Definition 4: A predicate pres,x(p,v), which is defined
by the formula Ateit'er\st,=sAxt, =x} Yt(p,v), is called a precondition of stimulus x in state s. ■
Definition 5: A pair x(p), where x e X and p e Dx, is called an initialized stimulus of EFSM. ■
Definition 6: A pair y(r), where y e Y and r e Dy is called an initialized reaction of EFSM. ■
Definition 7: A triple t(p,r), where t e T, p e Dxt, and r e Dyt is called an initialized transition of EFSM. ■
Definition 8: An initialized transition t(p, r) is said to be enabled for configuration (s,v), if st = s, Yt(p,v) = true, and Xt(p, v) = r. ■
Denote the set of initialized stimuli, the set of initialized reactions, and the set of initialized transitions by X, Y, and T respectively.
The EFSM operates as follows. It receives an initialized stimulus and computes the set of enabled initialized transitions. A single transition nondeterministically chosen from the computed set fires. Executing this transition EFSM produces initialized reaction, updates context, and moves from the initial state of the transition to the final state. The EFSM usually starts from a designated configuration, which is called the initial configuration. A pair of an EFSM and an initial configuration is called an initialized EFSM.
III. Contract Specification of Pipeline
Intuitively, pipeline of length L is the way of system organization where execution of an operation consists of L successive stages, and it is possible to feed a next operation when the first stage of the previous one is complete. Let us formalize this idea.
Definition 9: A pair (x,l) e X x {l,...,L} is called a stimulus state. ■
Definition 10: A finite set of stimuli states {(x^,^)}n=i is called a control state; the empty set of stimuli states is called the initial control state. ■
Denote the set of stimuli processing states and the set of control states by XL and PL d= 2X L respectively.
Definition 11: A contract specification of pipeline of length L is 6-tuple {V, v0,I U O,X U {t}, Z U {e}, p), where:
• V is a set of context variables;
• v0 e DV is an initial context;
• IU O is a set of input and output parameters;
• X U {t} is a set of stimuli;
Each stimulus x e X U {t } is parameterized by input parameters inx C I; let Dx be a set of inx valuations. Besides the set of input parameters, the following attributes are specified for stimulus x:
— usex C V
is a set of context variables used by the stimulus;
— Yx : Pl ^ {true, false}
is a guard condition of the stimulus, such that:
i Yx(<2>) = true,
\ Yx(ni) ^ Yx(n2), if ^2 C ni;
— prex : Dx x Dusex ^ {true, false} is a precondition of the stimulus.
Set of stimuli includes special stimulus t, which is called
clock stimulus, such that:
— inT = 0;
— useT = 0;
— yt = true;
— preT = true.
• Z U {e} is a set of stages;
Each stage 2 is parameterized by output parameters outz C O; let Dz be a set of outz valuations.
Besides the set of output parameters, the following attributes are specified for stage 2:
— usez C V
is a set of context variables used by the stage;
— defz C V
is a set of context variables defined by the stage;
— Yz : Pl ^ {true, false}
is a guard condition of the stage, such that:
i Yz(0) = true,
\ Yz(ni) ^ Yz(^2), if n C ni;
— postz : Dusez x Dz x Ddefz ^ {true, false} is a postcondition of the stage.
Set of stages includes special stage e, which is called
empty stage, such that:
— oute = 0;
— usee = 0;
— defe = 0;
— Ye = true;
— poste = true.
• p : X U {t} ^ (Z U {e})L is a mapping of stimuli to stages, such that:
— P(t ) = (e,---,e); _
— Ypi(x)({(x, l)}) = true, for all (x,l) e Xl. ■ Definition 12: A pair z(r), where 2 e Z and r e Dz, is
called an initialized stage of contract specification. ■
def
If y C Z, outy = Uzey outz, and r e Douty, then y(r) = {z(r\outz ) \ 2 e y}.
A. Interpretation of Contract Specification
Contract specification of pipeline can be interpreted as a special case EFSM. States of the EFSM are control states of the contract specification; reactions of the EFSM are sets of the pipe stages executing simultaneously. Consider some definitions to begin with.
Definition 13: A stimulus x e X U{t} is said to be enabled on stage l e {1,..., L} in control state n e PL, if YPl(x)(n) = true; otherwise, it is said to be locked. ■
def
Definition 14: A set of stimuli states enabled(n) =
{(x,l) e n \ YPl(x)(n) = true} is called a set of enabled stimuli in control state n e PL. ■
def
Definition 15: A set of stimuli states locked(n) = n \ enabled(n) is called a set of locked stimuli in control state
n e Pl. ■
To interpret a contract specification of pipeline we use two special functions: a pipeline shift operator to calculate a next control state, and a temporal binding operator to calculate a set of executing stages.
Definition 16: The pipeline shift operator is a function
o : (X U {t}) x Pl ^ Pl
that for each pair (x, n) e (X U {t}) x PL possesses the value x o n which is a union of the following sets:
• locked(n);
• {(x, l + 1) \ (x, l) e enabled(n) A l < L};
• {(x, 1)}, if x = t. ■
Definition 17: The temporal binding operator is a function 9 : PL 2Z
def
that for each n e PL possesses the value 9(n) = {pi(x) \ (x, l) e enabled(n)} \ {e}. ■
Definition 18: A set of stages {z1,...,zn} is said to be conflict, if at least one of the following conditions is satisfied for some 1 < i = j < n:
• outz. n outz. = 0 — conflict of reactions;
• usez. n defzj = 0 — read/write conflict;
• defzi n defzj = 0 — write/write conflict.
Otherwise, it is said to be consistent. ■
Definition 19: A control state n is said to be consistent, if
pll (x1) = pl2 (x2), for all different (xli ,li) e n, such that
Pi(xH) = e, and 9(n) is consistent. ■
Definition 20: A stimulus x is said to be conflict for a set of stages {z1, ...,zn}, if usexndefzi = 0 for some 1 < i < n. ■
Definition 21: A stimulus x is said to be conflict for a control state n e PL, if x is conflict for 9(n). ■
Definition 22: A contract specification is said to be consistent, if for all x e X U {t } and n e PL the following conditions are satisfied:
• if x is conflict for n, then Yx(n) = false;
• if n is consistent and Yx(n) = true, then x o n is consistent. ■
Let T, = {V, v0,I U O,X U {t}, Z U {e}, p) be a consistent contract specification of pipeline, then it can be interpreted as the EFSM A = {S,V, (n0,v0),I U O,X U {t},Y U {e},T) with clock stimulus t and empty reaction e, which is organized as follows:
• S = Pl:
the states of A are the control states of T;
• no = 0:
the initial state is the initial control state;
• Y = 2Z:
the reactions of A are the sets of T stages;
• e = 0:
the empty reaction is the empty set of stages;
• For all n e S and x(p) e X U {t}, such that Yx(n) = true, transition relation T contains all initialized transitions t = (n, x, y, y, X, S, n') of the following kind:
— uset = usex U (Uzee(n') usez);
— deft = U zee(n') defz;
— n' = x(p) o n;
— y = 9(n');
— Y(p,v)= prex(p,v\usex);
— the value of reaction function X e D^zee(n') outz) and the value of context update function S e Ddeft for all v e DV, such that prex(p, v\usex) = true, satisfy the predicate:
*^rnx(v,X,S') /\ postz(v\usez , X\ Outz ,
S|deft ) ,
zeO(n')
which is called the test oracle of stimulus x in control state n.
B. Correspondence between Specification and Implementation
An important concept that is generally used in functional testing is a correspondence between specification and implementation. Consider the contract specification T =
{VS, vS, Is U Os, XS U {ts}, ZS U {eS}, pS) and the initialized EFSM A = {S1, V1, (s0, vI), 11 U O1, X1 U {t 1}, Y1 U
{eI },TI).
Definition 23: A surjective function yLX : Pl ^ SI, such
that yX (nS) = s0, is called a state correspondence function. ■ Definition 24: A function yX : XS U {ts} ^ X1 U {t 1}, such that yX(xS) = t 1, iff xS = ts, is called a stimulus correspondence function. ■
Definition 25: A bijective function yY : Y1 U {e1} ^ 2Z , such that yy (y1) = 0, iff y1 = e1, is called a reaction correspondence function. ■
Definition 26: A function y>y : DV ^ DL, such that Vv(vo) = vS, is called a context correspondence function. ■ Definition 27: An initial EFSM A is said to be corresponding to a contract specification T for a given set of correspondence functions {yX, ¥x, Vy , ¥v), if for all nS e PL, xS (pS) e XS U {ts } and v1 e DV if YxS (nS) = true, then x1 e init(sI), and if prexs (pS,vS) = true, then presi xi (p1 ,v1) = true, where s1 = yX(nS), x1 (p1) = yX(xS(pS)), vS = yV(v1). At that rate for each initialized transition t1 (p1 ,rI) e init(sI,xI), which is enabled in configuration (sI,vI), s'tI = yX (n'S), yY(yti (rI)) = 9(n'S)(rS), and $ns,xs(vS,rS,v'S) = true, where n'S = xS(pS) o nS and v'S = yY(Sti (vI)). ■
The definition above gives the following scheme for checking correspondence between specification and implementation during a testing:
(nS,vS) ^ (0,vi');
ifS = ¥s (nS) V vS = yy (v1)) Error(); while(-i isTestComplete()) { xS (pS) ^ getNextStimulus(); if((7zs (n‘S) A prexs (pS,vS)) { x1 (p1) ^ yx->■(xS (pS));
applyStimulus(x 1 (p1));
V1 (r1) ^ waitForReaction();
yS(rS) ^ yy(v!(r1));
v'S ^ yy(v1); nS ^ xS (pS) o nS; if(s 1 = y^(nS)) Error(); if(yS = 0(nS)) Error();
if(-$,s ,xs (vS ,rS ,v'S)) Error();
}
}
Sufficiently often the implementation state sI is hidden. Furthermore, the function of state correspondence yX is actually undefined. Thus, checks of kind sI = yX(nS) are usually omitted. The same is true for comparison yS = 9(nS), because one can consider reactions as the parts of the context. So, the only check that is generally done by testbench in each step of testing is $ns,xs (vS,rS,v'S) = true.
IV. UniTESK Technology
The UniTESK technology [7], [8] was developed at the Institute for System Programming of Russian Academy of Sciences [9]. The original purpose of the technology is the development of high-quality functional tests for software systems. The UniTESK technology and supporting tools have been successfully applied for testing different kinds of software (operating systems, telecommunication protocols, realtime systems, etc.). A key moment in the successful use of the UniTESK technology is the flexible and scalable test system architecture, which allows to adapt the technology to various classes of systems [8].
The main idea of UniTESK is separating the test sequence generation from the DUT behavior specification. on the one hand, it uses FSM traversal techniques to generate test sequences; on the other hand, it utilizes formal specifications in the form of preconditions and postconditions of operations to describe the DUT behavior. The approach has distinctive feature that it does not operate with explicit FSM models. In contrast, it works with implicit ones being described by means of FSM state calculation function and set of possible stimuli for each of the reachable states.
A. UniTESK Test System Architecture
UniTESK test system architecture has been developed as a result of many years experiments on specification-based testing of the industrial software from different fields and of different levels of complexity [8]. These experiments have allowed to create the flexible and scalable test system architecture based on the following division of the testing task into subtasks:
• Generation of a test sequence to achieve the functional coverage needed;
• Creation of a single stimulus within the test sequence;
• Building a connection between the test system and DUT;
• Verification of the DUT behavior in response to a single stimulus.
Special test system components are provided by UniTESK technology to solve these subtasks. Their interactions are shown on Fig. 1.
Test engine is a library component of the UniTESK test system. Test engine and test action iterator are intended for test sequence generation. Test engine is based on an FSM traversal algorithm.
Fig. 1. UniTESK test system architecture.
Test action iterator works under the test engine control. It calculates current FSM state, iterates corresponding stimuli, and applies them. Test action iterator is automatically generated from the high-level test scenario description.
Test oracle verifies the DUT behavior in response to a single stimulus. It is automatically generated from the formal specifications.
Mediator connects formal specifications and DUT implementation. It makes some transformations of the stimuli and reactions and also synchronizes the specification state with the implementation one.
Test trace shows the events happening during the testing. It is used by the UniTESK supporting tools to automatically generate different reports that help in the test results analysis.
B. CTESK Test Development Tool
CTESK test development tool is an implementation of the UniTESK conception for the C programming language. It uses SeC (specification extention of C) language to develop test system components. SeC language provides test developers with special functions:
• Specification functions - to specify DUT operations and to define functional coverage structure;
• Mediator functions - to connect specification functions with corresponding stimuli;
• Function of FSM state calculation - to calculate FSM state on the base of the specification state;
• Scenario functions - to define a set of stimuli to be applied in each of the reachable states.
CTESK tool has been used for testing Verilog HDL and SystemC designs of hardware. The detailed information on this subject is presented in [10] and [11].
C. Specification of Pipelined Designs
We have adapted the CTESK tool for contract specification of pipeline designs. To illustrate basic ideas of the suggested approach let us consider an example of a 3-stages floatingpoint adder. The adder is intended for adding two normalized single-precision floating-point numbers (zero values are also permitted) [12]. The pipeline of the unit consists of 3 stages: (1) alignment of exponents, (2) addition of fractions, and (3) normalization of result.
The first step of operation specification is the definition of so-called operation descriptor type that describes the current state of operation execution. This type usually contains operands of the operation and all kinds of temporal values calculated on one stage to be used on successive stages.
// Descriptor of ADD operation
specification typedef struct ADDDescriptorT {
// Operation operands bool op1_sign; uint8_t op1 .exponent; uint32_t op1 .fraction;
} ADDDescriptorT;
The specification function of the operation contains operation precondition.
// Specification function of ADD operation specification void ADD_spec(SingleT op1, SingleT op2) {
// Operation precondition pre {
return (isZero_SingleT(op1) || isNormalized_SingleT(op1)) && (isZero_SingleT(op2) || isNormalized_SingleT(op2));
}
}
For each stage of the operation a special function is developed to set forth stage requirements. Let us consider specification of the following requirement: ”If operands have different exponents, then fraction of the operand with the smaller exponent is shifted to the right (the number of positions that the bits in the fraction are to be shifted is the difference between exponents). If there is a unit among the shifted bits, then output inexactalign is set to high; otherwise, it is set to low.”
// Specification of the ALIGNMENT stage reaction ADDDescriptorT* ADD_align_spec(void) {
AdderUnitT *adder_unit = getAdderUnit();
ADDDescriptorT *add = ADD_align_spec; post {
if(add->op1 .exponent > add->op2_exponent) {
int shift = add->op1 .exponent - add->op2_exponent; return adder_unit->inexact_align ==
(add->op2_fraction & mask(shift)) != 0;
}
if(add->op1 .exponent < add->op2_exponent) {
int shift = add->op2_exponent - add->op1 .exponent; return adder_unit->inexact_align ==
(add->op1 fraction & mask(shift)) != 0;
}
}
}
In the code above adder unit denotes a variable that stores specification representation of the current DUT state.
V. Related Work
Functional testing of pipelined designs is mostly researched in the area of microprocessor design. The good many articles are dedicated to the methods of test generation for pipelined microprocessors. Many researchers come to a consensus that specification-based testing is the right direction for functional testing of hardware designs. The main question is which models and notations should be used.
The important step toward the specification-based testing of pipelined microprocessors was made by Ho et al. [4]. They suggest deriving pipeline control logic as FSM, analyzing reachable states of the FSM, and traversing the FSM to produce test vectors. Unfortunately, this methodology is not applicable to complex industrial designs [13].
Existing methods of test generation utilize explicit cycle-accurate specifications, e.g. Mishra et al. [14], [15], [16], [17] and Ur et al. [13] use explicit SMV specifications to describe DUT behavior and to generate test programs. Two modern directions of test generation are:
• test generation using FSM traversal techniques (Ho et al. [4], Ur et al. [13]);
• test generation using model checking techniques (Mishra et al. [14], [15], [16], [17]).
We suppose that model checking does not scale well on complex industrial designs. However some techniques, like bounded model checking (BMC) and properties decomposition, allow to achieve suitable efficiency of test generation [18], [19].
We use FSM models to generate test sequences, but in contrast to other methods we use implicit models being described by means of FSM state calculation function and set of possible stimuli for each of the reachable states. Transition relation of the FSM is built on-the-fly during the testing. We suppose that the use of the implicit models for specification and testing increases the scalability of the approach.
VI. Case Study
The suggested approach was applied to RTL model of translation lookaside buffer (TLB) of the industrial microprocessor withMIPS64™-compatible architecture [20], [21]. TLB is a buffer in a microprocessor that is used to increase the speed of address translation. TLB has a fixed number of entries containing part of the page table which translates virtual addresses into physical ones.
The memory of the TLB under test comprises three buffers: a 4-entries instruction micro TLB (ITLB), a 4-entries data micro TLB (DTLB), and a large 64-entries joint TLB (JTLB). The purpose of the micro TLBs is to allow two address translations to be performed simultaneously - one for an instruction fetch address (via the ITLB) and one for a data load/store address (via the DTLB).
TABLE I
TLB REQUIREMENTS PARTITIONING
Operation Multistage Requirements
Read No 7
Write No 9
Probe No 8
Data Address Translation Yes 38
Instruction Address Translation Yes 37
Total — 99
If a translation is not found in the corresponding micro TLB, then the JTLB is accessed. once the translation is retrieved, it is written back to the micro TLB. To refill micro TLBs the least-recently-used (LRU) algorithm is used - micro TLBs always replace the entry which has not been accessed for the longest amount of time. Thus, micro TLBs contain a subset of translations that are most-recently-used.
Address translation operations are organized as multistage pipelined operations. A micro TLB miss sequence has a penalty of one extra clock cycle. If we have simultaneous ITLB miss and DTLB miss, the DTLB gets first priority when accessing the JTLB, and the translation of instruction address stalls an additional cycle, giving a total penalty of two latency cycles.
Besides the address translation operations, the TLB under test implements operations for reading entry from the buffer, writing entry to the buffer, and probing if the entry exists in the buffer. The interface of the TLB under test contains about 30 inputs and as many outputs. The RTL model of the TLB is implemented in Verilog HDL. The source code of the model makes up to 8 KLoC.
The process of testbench development was organized as follows. Part of the requirements on the TLB under test were formulated by the developers, while the others were derived from the technical documentation. A total number of the requirements is about a hundred. TLB requirements partitioning is shown in Table 1.
Requirements on each operation were represented in the form of preconditions and postconditions of pipe stages. After that, pipeline shift operator and temporal binding operators were defined. It should be emphasized that all requirements were cheaply formalized. The volume of specifications makes up to 2.5 KLOC in SeC language.
We have found 9 errors in the TLB implementation including critical ones. Errors statistics is shown in Table 2. It should be noted that all errors were found in the multistage operations and the majority of errors (67%) are connected with the control logic. The total labor costs of the testbench development make up to about 2.5 man-months.
TABLE II
TLB errors statistics
Type of Errors Number Percent
Datapath Errors 3 33%
Control Logic Errors (Incorrect State) 5 56%
Control Logic Errors (Data Hazards) 1 11%
Total 9 100%
VII. Conclusion
The need of automated testbench development for complex pipelined designs is widely recognized. The paper described the novel approach to formal specification of pipelined designs, which is suitable for testbench automation. The approach is based on contract specifications of pipe stages extended by mechanism of temporal binding. Such specifications are suitable for automatic generation of test oracles which check DUT correctness. The approach was integrated into the CTESK test development tool from the UniTESK toolkit. The methodology was successfully applied to several modules of the industrial microprocessor.
The roots of the approach are Design-by-Contract (DbC) [22] and UniTESK [7]. As Ur et al. [23], we believe that close integration between the software testing and hardware validation communities can benefit both of them. Actually, many useful approaches that are developed and proven to be successful in one domain are rarely used in the other. Of course, this does not mean that all problems of one community can be solved by the other, but general problems are the same.
References
[1] J. Bergeron. Writing Testbenches: Functional Verification ofHDLModels. Kluwer Academic Publishers, 2000.
[2] B. Beizer. The Pentium Bug—An Industry Watershed. Testing Techniques Newsletter, TTN Online Edition, September 1995.
[3] D. Patterson and J. Henessy. Computer Organization and Design. 3rd Edition, Morgan Kaufmann, 2005.
[4] R. Ho, C. Yang, M. Horowitz, and D. Dill. Architecture Validation for Processors. ISCA’95: International Symposium on Computer Architecture, 1995.
[5] MIPSR4000PC/SC Errata, Processor Revision 2.2 and 3.0. MIPS Technologies Inc., May 10, 1994.
[6] A. Petrenko, S. Boroday, and R. Groz. Confirming Configurations in EFSM Testing. IEEE Transactions on Software Engineering, 2004.
[7] http://www.unitesk.com
[8] I. Bourdonov, A. Kossatchev, V. Kuliamin, and A. Petrenko. UniTESK Test Suite Architecture. FME’02: Formal Methods Europe. LNCS 2391, Springer-Verlag, 2002.
[9] http://www.ispras.ru
[10] V. Ivannikov, A. Kamkin, V. Kuliamin, and A. Petrenko. Application of the UniTESK Technology to Functional Testing of Hardware Designs. Preprint 8, Institute for System Programming of Russian Academy of Sciences, Moscow, 2005 (in Russian).
[11] A. Kamkin. The UniTESK Approach to Specification-Based Validation of Hardware Designs. ISoLA’06: The 2nd International Symposium on Leveraging Applications of Formal Methods, Verification and Validation, November 2006.
[12] IEEE 754-1985. IEEE Standard for Binary Floating-Point Arithmetic. NY: IEEE, 1985.
[13] S. Ur and Y. Yadin. Micro Architecture Coverage Directed Generation of Test Programs. DAC’99: Design and Automation Conference, 1999.
[14] P. Mishra and N. Dutt. Automatic Functional Test Program Generation for Pipelined Processors using Model Checking. HLDVT’02: The 7th IEEE International High-Level Design Validation and Test Workshop, 2002.
[15] P. Mishra and N. Dutt. Architecture Description Language Driven Functional Test Program Generation for Microprocessors using SMV. CECS Technical Report 02-26, September 13, 2002.
[16] P. Mishra and N. Dutt. Graph-Based Functional Test Program Generation for Pipelined Processors. DATE’04: Design, Automation and Test in Europe Conference and Exhibition, 2004.
[17] P. Mishra and N. Dutt. Functional Coverage Driven Test Generation for Validation of Pipelined Processors. DATE’05: Design, Automation and Test in Europe, 2005.
[18] H.M. Koo and P. Mishra. Test Generation using SAT-based Bounded Model Checking for Validation of Pipelined Processors. ACM Great Lakes Symposium on VLSI, 2006.
[19] H.M. Koo and P. Mishra. Functional Test Generation using Property Decomposition for Validation of Pipelined Processors. DATE’06: Design, Automation and Test in Europe, March 2006.
[20] http://www.mips.com/content/Products/Architecture/MIPS64
[21] MIPS64 Architecture For Programmers. Revision 2.0. MIPS Tecnologies Inc., June 9, 2003.
[22] B. Meyer. Applying ’Design by Contract’. IEEE Computer, vol. 25, #10, October 1992.
[23] S. Ur and A. Ziv. Cross-Fertilization between Hardware Verification and Software Testing. SEA’02: Software Engineering and Applications, ACTA Press, 2002.
