744 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO.

3, MARCH 2016

Development Flow for On-Line Core

Self-Test of Automotive Microcontrollers
Paolo Bernardi, Member, IEEE, Riccardo Cantoro, Student Member, IEEE, Sergio De Luca,
nchez, Senior Member, IEEE, and Alessandro Sansonetti
Ernesto Sa

Abstract—Software-Based Self-Test is an effective methodology for devising the online testing of Systems-on-Chip. In the automotive
field, a set of test programs to be run during mission mode is also called Core Self-Test library. This paper introduces many new
contributions: (1) it illustrates the several issues that need to be taken into account when generating test programs for on-line
execution; (2) it proposed an overall development flow based on ordered generation of test programs that is minimizing the
computational efforts; (3) it is providing guidelines for allowing the coexistence of the Core Self-Test library with the mission application
while guaranteeing execution robustness. The proposed methodology has been experimented on a large industrial case study. The
coverage level reached after one year of team work is over 87 percent of stuck-at fault coverage, and execution time is compliant with
the ISO26262 specification. Experimental results suggest that alternative approaches may request excessive evaluation time thus
making the generation flow unfeasible for large designs.

Index Terms—Microprocessors and microcomputers, reliability and testing, software-based self-test

1 INTRODUCTION

T HE diffusion of electronic systems in the automotive

field is increasing at a fast pace. Car makers constantly
demand from electronic manufacturers for faster, less
been addressed for a long time by different teams in the
research community [1], [2], [3]. SBST techniques basically
consist in letting the CPU running a sequence of code words
expensive, less power-consuming, and more reliable devi- to excite and propagate errors affecting the circuit [4]. Com-
ces. Microprocessor-based systems are employed in cars for pared to traditional hardware-based test solutions, such as
a great variety of applications, ranging from infotainment to Built-In Self-Test (BIST), it presents many advantages, such
engine and vehicle dynamics control, including safety- as: the possibility of autonomously testing [5] and diagnos-
related systems such as airbag and braking control. ing [6] both the microprocessor and the controllable periph-
The use of microprocessor systems in safety- and mis- erals; working in normal mode of operation; not requiring
sion-critical applications, calls for total system dependabil- any hardware modifications; allowing at-speed test applica-
ity. This requirement translates in a series of system audit tion (i.e., at the circuit nominal frequency). Nevertheless,
processes to be applied throughout the product lifecycle. SBST methodologies have their applicability in industry
Nowadays, some of these processes are common in indus- limited by the difficulty to write efficient and effective test
trial design and manufacturing flows. These include risk programs and to devise suitable methodologies for test
analysis, design verification and validation, performed application.
since the early phases of product development, as well as While in the manufacturing test arena, BIST solution are
various test operations both during and at the end of chosen because these solutions achieve high coverage in a
manufacturing or assembly steps. Increasingly often, addi- short time and with a simple development flow, regarding
tional test operations need to be applied during the online test application, SBST is the preferred solution for
product’s mission life, such as periodic online testing and periodically monitoring the system health without interfer-
concurrent error detection. The reliability requirements are ing with the normal mission behavior [7], [8]. A standard
met by trading off fault coverage capabilities with admissi- solution adopted by the industry is the periodic application
ble implementation costs of the selected solutions. of test from a Core Self-Test (CST) library composed of
Within the scope of microprocessor-based integrated sys- SBST programs. In such an approach, the microprocessor is
tems, the Software-Based Self-Test (SBST) approach has periodically forced to execute a self-test code able to detect
the possible occurrence of permanent faults in the processor
core itself and the peripherals connected to it (Fig. 1). Such

P. Bernardi, R. Cantoro, and E. S anchez are with the Politecnico di Torino, procedures are designed to activate possible faults, then
Dipartimento di Automatica e Informatica, Torino, Italy. compress and store the self-test results in an available mem-
E-mail: {paolo.bernardi, riccardo.cantoro, ernesto.sanchez}@polito.it.

S. De Luca and A. Sansonetti are with STMicroelectronics, Agrate ory space, or raising a signal when the test has not ended
Brianza, Italy. E-mail: {sergio.deluca, alessandro.sansonetti}@st.com. correctly.
Manuscript received 1 Feb. 2015; revised 29 July 2015; accepted 17 Sept. 2015. As far as test program generation is concerned, many
Date of publication 5 Nov. 2015; date of current version 10 Feb. 2016. approaches can be found in the literature, employing man-
Recommended for acceptance by C. Bolchini, S. Kundu, and S. Pontarelli. ual or automated approaches, which are suited to target dif-
For information on obtaining reprints of this article, please send e-mail to:
[email protected], and reference the Digital Object Identifier below. ferent processor architectures and fault models as described
Digital Object Identifier no. 10.1109/TC.2015.2498546 in [4]. However, setting up an efficient CST development
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
0018-9340 ß 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
BERNARDI ET AL.: DEVELOPMENT FLOW FOR ON-LINE CORE SELF-TEST OF AUTOMOTIVE MICROCONTROLLERS 745

program runs and eventually detects misbehavior by sim-

ply exercising the processor functionalities. This process
intrinsically respects power constraints, since the test pro-
grams are executed under the same conditions of the mis-
sion mode. SBST does not ask for additional test circuitries,
and is quite cheap in terms of features and commodities
required to the test equipment.
When dealing with a (CST), which has to be applied
online, the test programs have to share processor resources
with the mission application, i.e., the OS which is managing
Fig. 1. On-Line Self-Test application example. mission’s tasks; this coexistence introduces very strong limi-
tations compared to manufacturing tests:
flow requires solving a number of additional issues regard-
1. CST programs need to be compliant with a standard
ing test program generation, organization, and grading [9].
interface, enabling the OS to handle them as normal
Coping with such online requirements means both to intro-
processes. This interface must guarantee processor
duce additional rules to be respected along test program
status preservation and restoration, even in case of
generation, and to include additional code parts that may
higher priority requests (e.g., preemption).
impact on the CST development time.
2. The CST programs need to be generated following
This paper presents an innovative and comprehensive
execution time constraints, due to the resources
approach for the development of a CST library for micro-
occupation that can be afforded by the mission envi-
processors in safety-critical automotive embedded systems.
ronment. In particular, this is strictly required when
Such a CST library can be integrated in the Operating Sys-
a test cannot be interrupted because using critical
tem installed on-chip (it will be referred to as OS), i.e.,
resources (e.g., special purpose registers).
which is responsible for running the mission application.
3. There is a strong limitation in terms of memory
The pursued goal is to satisfy all reliability requirements
resources, due to the mission code and data charac-
imposed by emerging standards such as ISO 26262 [10],
terizing the OS. To face this issue, it is usually recom-
which require a constant monitoring for the possible occur-
mended to:
rence of permanent faults in the circuit along its mission life.
- provide the CST as a set of precompiled pro-
The technical content of the paper deals with the most
grams stored in binary images to be run along
relevant aspects of on-line test programs characteristics and
mission mode, possibly scheduled and loaded
their development flow. Specifically, the paper progresses
by the operating system;
the state-of-the-art by describing and discussing:
- not to refer to any absolute addresses when
1. the constraints to be taken into account when gener- branching, as a result, the test code can be stored
ating self-test programs to be run on-line; in the memory, copied, and launched from any
2. the requirement for a robust on-line execution of location without any functional or coverage
self-test programs in coexistence with an embedded drawback;
operating systems; - not to refer to absolute addresses when accessing
3. an effective development flow organization aiming the data memory;
at minimizing the computational efforts. - identify possible memory constraints from the
Moreover, the paper shows the results that have been col- point of view of the OS restrictions, and indispens-
lected on an industrial case study during one year. The impact able locations to be reserved for test purposes.
of online requirements is evaluated on a large 32-bit micro- Moreover, targeting effort reduction, the test should be
processors embedded in an automotive System-on-Chip created also taking into account the characteristics of the
(SoC) manufactured by STMicrolectronics. Code overheads general processor family, in order to reduce code modifica-
and adaptation toward on-line of the generation strategies are tions when transferring the CST library to another processor
reported; experimental results also demonstrate that the core belonging to the same family architecture. The next
development of a CST becomes unfeasible on processors with paragraphs face these questions and provide some guide-
a significant dimension, without careful planning for proper lines for easily taking early decisions.
resource partitioning and order in the CST creation. On-line execution constraints may in same cases limit the
The rest of the paper is organized as following: Section 2 effectiveness of the usual methodologies for writing test pro-
describes the on-line constraints that are encountered while grams, which has to be rethought to fit to the real system.
generating test programs. Section 3 details the characteris-
tics required to guarantee robustness and full compliancy 3 CORE SELF-TEST EXECUTION MANAGEMENT
with the OS. Section 4 illustrates an effective development As briefly described in the introduction, the inclusion of
flow suitable for large microcontrollers. Section 5 reports SBST routines in the mission environment is a critical issue.
experimental results, and Section 6 concludes the paper. To face the problematic aspects of this integration, after the
generation, we consider three major points related to test
2 CORE SELF-TEST GENERATION CONSTRAINTS program execution:
SBST is widely perceived as a proper method for accurate
cooperation with other software modules, usually
and non-invasive autonomous test. In a few words, a test related to the mission environment such as the OS;
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
746 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO. 3, MARCH 2016

Fig. 2. Test program encapsulation and loading for execution phase.

context switching and result monitoring;
memory protection setup;

robustness in case of faulty behavior, which is
test duration.
strictly related to interruption management. Metadata are used by the test program during different
phases, some at the setup:
3.1 Test Encapsulation
1) duration time (i.e., watchdog setup);
Considering the cooperation with other software modules,
2) stack frame size (i.e., space available for mission con-
such as the threads launched by the OS, the test program
suite needs to be constructed by including key features figurations to be saved and local variables of the test
enabling the test to be launched, monitored and eventually program);
interrupted by higher priority processes of the mission man- 3) processor setup (i.e., special purpose register ad-hoc
agement system. values);
The test program has to be carefully structured, in order 4) memory configuration (i.e., virtual memory
to configure memory areas and peripheral resources for test initialization);
purposes, as also graphically depicted in Fig. 2. All the test 5) memory protection (i.e., to manage wrong memory
programs are normally stored and executed in the flash accesses through exceptions); and others at the exe-
memory. cution end:
First of all, in order to be compliant with the mission soft- 6) signature (i.e., test results check).
ware environment, a viable and strongly suggested solution Such a memory structure can be also stored in the mass
for the development of the OS and software modules for auto- memory until it is loaded to be run from any portion of
motive embedded microcontrollers is the adoption of the the available memory, according to the features already
Embedded-Application Binary Interface (EABI). Widely used described in Section 2 (i.e., relocation).
EABIs include PowerPC [11], ARM EABI2 [12], and MIPS
EABI [13]. EABIs specify standard conventions for file for-
3.2 Context Switching to Test Procedure
mats, data types, register usage, stack frame organization,
Test programs structured as described Section 3.1 can be
and function parameter passing of a software program. Thus,
every test program includes an EABI prologue and epilogue integrated into any mission OS as normal system tasks.
(Fig. 2), in charge of saving and restoring the mission status. Proper context switching is managed by the EABI interface;
The EABI frame is created by the test code as soon as it additional setup may be required, according to the charac-
begins. Thus, any scheduler can launch the test execution, teristics of the test program, and it is managed internally by
e.g., the scheduler available in the OS hosting the test rou- the test programs themselves, by means of the additional
tine. Moreover, we propose the inclusion of extra informa- metadata.
tion which can allow a test scheduler to perform a proper We identify three general cases, each one demanding for
running environment setup. proper metadata to be used in setup procedures:
Such additional information, or metadata, encompasses:

run-time tests: can be interrupted by mission

stack frame size; requests; usually used to cover computational mod-

special purpose register setup; ules such as arithmetic modules;
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
BERNARDI ET AL.: DEVELOPMENT FLOW FOR ON-LINE CORE SELF-TEST OF AUTOMOTIVE MICROCONTROLLERS 747

Fig. 3. Expected and unexpected exception management scenario.

non-exceptive tests: require the manipulation of SPR
the current status and control registers of the used
register, such as for testing the Register File; peripheral modules, such as the interrupt controller

critical tests: intentionally raise interrupts and make configuration and the MMU.
use of peripheral cores, such as a procedure for test-
ing modules managing software exceptions. 3.3 Interruption Management and Robustness
Run-time tests are the easiest to manage. They only
Interrupt mechanisms, which are managing synchronous
require creating a stack frame according to EABI compli-
and asynchronous exceptions, need to be handled with
ancy; stack frame size is minimal. It is suggested to execute
extreme care, because they are not only intentionally raised
this kind of tests with low privileges, i.e., user mode,
for testing purposes.
because they shall never request interruptions or privileged We discriminate three types of exception:
instruction execution in the fault-free scenario. No other
special setup is required. EABI compliancy can be satisfied
intentionally provoked exceptions, i.e., to test proces-
during the execution, and other OS threads can preempt the sor exceptions;
test execution.
unexpected, induced by an erroneous execution that
Non-exceptive tests are slightly less easy to manage is provoked by a faulty configurations;
because these require resources that are not allowed to be
mission mode interruptions.
directly used in the EABI context. For this category, addi- Intentionally provoked interruptions can be both syn-
tional test setup steps have to be executed before running: chronous or asynchronous. Situations like system calls, ille-
gal memory access, illegal instructions and privilege related

disable the external interrupts to avoid preemption; operations are synchronous, as they have to be forced by

save all special and general purpose registers in a the code itself. On the other hand, asynchronous interrup-
larger stack frame memory area; tions are raised by peripheral cores.

modify the content of special and general purpose To test exceptions it is therefore necessary to both rise
registers according to the processor setup information. and manage them (Fig. 3). If the circuitries managing the
Moreover, some closing operations are needed at the interrupt have not been corrupted by a fault, each single
conclusion of the test execution to restore the initial configu- forced exception is correctly managed, meaning that a test
ration. During the execution of these tests, no preemption is Interrupt Service Routine (ISR) is accessed. Such an ISR is
allowed because the compliancy with the EABI standard configured at the time when the scheduler prepares the
cannot be guaranteed. environment for the test program execution and replaces
When considering Critical tests, other than saving-restore the mission ISR with the test ISR.
all registers and disable external interrupt sources, more The code included in the test ISR is also used to add sig-
restrictive requests have to be accomplished: nificant contents into the signature, e.g., the processor’s sta-
tus registers. In presence of a fault, the execution flow may

the Interrupt Vector Table (IVT) and the related
be altered and an exception intentionally scheduled but is
registers in case an alternative IVT is required for
not raised. In this case, the signature is not updated by the
testing purposes;
test ISR, and the right signature value is not produced.
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
748 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO. 3, MARCH 2016

Fig. 4. Sub-module identification and visualization of the coverage figure evolution along the proposed generation steps.

Furthermore, the exception management is also crucial before achieving a good coverage. We propose a method-
for detecting faults producing execution flow deviations ology able to achieve a significant optimization of devel-
that lead to an unexpected processor’s internal status or opment time and resources based on the following
cause unexpected synchronous interruptions. Typical cases principles:
are a legal instruction wrongly decoded as an illegal instruc-
tion format, or an illegal memory access raising an interrup-
modularity: the embedded processor is not tackled as a
tion by the memory protection unit mechanism. If this unique module, but its sub-modules are considered
situation occurs during the execution of any test program, separately (e.g., ALU, CTRL Unit, etc.); this means
the test ISR should ideally be able to recover such an errone- that the processor’s fault universe is selectively
ous (due to the fault) execution flow and to record the divided into several smaller fault lists for being effec-
wrong behavior observed. Some countermeasure can be tively attacked while generating the test programs;
adopted to identify unexpected interrupt requests, such as
parallelization: by facing modules separately, it facili-
performing an assertion in the ISR prologue to check a pass- tates the distribution of the development process on
word stored into a GPR before the interrupt is intentionally the available workstations/test-engineers (see more
raised. A similar method is implemented for checking the details in 4.1);
correct return from interrupt, e.g., by completing the test
side-effect: by developing a test for a specific sub-
execution with an assertion. module, it is likely to have a side-effect that is the
This technique is making the test code quite robust, but coverage of faults belonging to other sub-modules.
more work is needed if the processor status become unsta- The strategy we propose is based on these principles and
ble, resulting in spurious and repeated exceptions or infinite consists on the iterated execution of two steps until all sub-
loops. In the latter case, an external mechanism have to be modules are considered:
implemented in order to bring the system into a safe status,
1. to generate, possibly in parallel, the test programs for
i.e., by watchdog timer.
a set of carefully selected sub-modules until these are
These cases are graphically shown in Fig. 3, where solid
sufficiently covered (more details in 4.2);
lines are showing expected interrupts while dashed are
2. to perform a synchronization among all the previ-
showing the effect in case the processor status is unstable.
ously generated test programs, to evaluate their
During the execution of run-time test programs, mission
effectiveness over a larger fault list; to synchronize
interrupts need to be identified and served as soon as possi-
means to fault grade test programs that are gener-
ble, i.e., passed to the mission OS. By following the EABI
ated for a specific sub-module over a different
standard, it permits to easily manage this case.
(larger) list of sub-modules.
In order to better explain the proposed flow, we can con-
4 CORE SELF-TEST DEVELOPMENT FLOW
sider a simple example of a microprocessor’s CPU, which is
The major cost in the development flow of a CST is the modularized into four sub-modules: s1, s2, s3, and s4 (Fig. 4a).
computational effort required to generate the test program In the first step (Fig. 4b), two modules (s3 and s4) are con-
suite: the fault grading process [9], which evaluates the effec- sidered in parallel and graded separately, i.e., during the
tiveness of a test program (by assessing the fault coverage), generation process for module s3 only its own faults are
represents a severe bottleneck. Moreover, the cost for devel- considered.
oping the test program infrastructure described in the previ- As soon as the coverage of these sub-modules is satisfac-
ous paragraphs and required by the on-line execution is not tory, the generated test programs are graded over the other
negligible. For instance, for a medium sized embedded pro- parts of the CPU (Fig. 4c); this synchronization step brings
cessor with about 200 k stuck-at faults, fault simulating 1ms to observe a positive side-effect on the coverage of modules
program may require some three days on a 2 GHz quad-core s1 and s2, as well as on s3 when grading the test program
workstation at the maximum parallelism allowed. for s4, and vice versa.
Such a cost becomes unsustainable if the generation A new generation step is then started on s1 and s2
process is iterative [18] and produces many programs (Fig. 4d); it is worth to mention that the previous steps were
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
BERNARDI ET AL.: DEVELOPMENT FLOW FOR ON-LINE CORE SELF-TEST OF AUTOMOTIVE MICROCONTROLLERS 749

beneficial because the starting fault lists of s1 and s2 have
fault coverage calculation for synchronizing the
been lightened before facing their generation process. results of multiple test programs among multiple
The main advantage of using this approach is a faster sub-modules should be allocated on many threads.
development of the test suite because:
4.2 Optimized Test Programs Generation Order

the fault lists to be considered are significantly
Based on the side effect principle described above, it is cru-
smaller than the complete fault list, resulting in a
cial to select the most promising order to proceed in the test
faster fault grading that usually takes in the order of
program generation. The decision needs to be tailored on
minutes to complete;
the specific architecture under analysis.

after each synchronization step, the number of active
In the following, we propose general guidelines for
faults in new sub-modules is reduced, again leading
to a speed-up of the fault simulation process. determining the generation order considering the most
common microprocessor architectures used in automotive.
4.1 Resources Partitioning In our development flow, we organize the generation order
As briefly stated in the previous paragraph, the processor is according to horizontal and vertical flow rules. Vertical
divided into sub-modules to consider independent fault lists flow rules demand to split the flow into consecutive levels,
in parallel, and their selection is the major issues in the pre- such that by testing all the modules into a given level, a
liminary phase preceding the generation effort. large positive side-effect in terms of fault coverage is
For being independent, fault lists need to be observed when moving to the next level.
We are currently proposing to divide the flow into levels

non-overlapping: one fault has to belong to only one according to the following rules:
fault list;

functionally orthogonal: faults in the same indepen- 1) to consider first those units that can be mapped on
dent fault list need to belong to modules related to specific assembly instructions or specific architec-
one specific functionality. tural programming mechanisms;
The non-overlapping criterion dictates that the same 2) to continue with memorization and control flow
fault must be considered only one time in the process; on resources;
the other hand, when dealing with orthogonality, a fault 3) to conclude with modules which functionalities are
must be included in the most relevant fault list from the transparent to the programmer.
point of view of the functionality of the related gate. According to the presented strategy, a synchronization
The process of selecting the set of fault lists is not trivial. step is needed after completion of the currently consid-
In our flow, this process relies on: ered level before moving to the next; this synchronization
step involves all sub-modules of the next level, i.e., to

manuals and documentation of the microcontroller reduce the size of the fault lists to be considered succes-
with specific indications about the micro-architecture; sively. By looking at the problem in a horizontal manner,

hierarchy of the microcontroller netlist; it is also possible to identify many parallel branches which

test engineer expertise. are still complying with vertical requirements. This hori-
To identify independent fault lists, it requires: zontal view consists in identifying branches, so that a

analysis of the processor functionalities; negligible side-effect crosses branches belonging to differ-

mapping of the functionalities over the microcontrol- ent horizontal views.
ler hierarchical netlist. Based on the previous rules, for a typical automotive-ori-
Most of the fault lists directly derive from a specific mod- ented architecture, we individuate a development flow
ule, but it is frequent that different sub-modules are based on three levels and two branches (Fig. 5). However,
squeezed into a single fault list if related to the same proc- additional branches can be added when considering micro-
essing functionality. As an example, the faults of a multipli- processors equipped with special features, e.g., caches [14],
cation unit usually constitute an independent fault list. On shared memory schemes [15], and Floating-Point unit [16].
the contrary, there are several multiplexers that seem to be We suggest considering two broad categories of sub-
independent netlist modules, but actually compose the module as first levels:
feed-forwarding logic in the processor’s pipeline; thus, level 1 – branch A) ALU: easy to test, sub-modules that ask
faults belonging to these multiplexers have to be grouped for the execution of specific arithmetic and logical instruc-
into the same fault list, which is functionally orthogonal tions. Side effect will be maximized towards the REGISTER
and non-overlapping with other modules. FILE by an accurate selection of registers to be used as oper-
Concerning computational resources allocation, once the ands and in the control flow management.
independent fault lists have been identified, the following level 1 - branch B) SPECIAL: sub-modules that encompass
rules aim at maximizing the number of fault lists to be con- Exceptions Management, Branch Prediction, and Virtual
sidered in parallel: Memory-related modules, e.g., the Memory Management
Unit (MMU) module. These sub-modules are hard to cover,

fault coverage calculation for sub-modules may be requiring specific instructions and sequences of instruc-
allocated on a single or many threads according to: tions. They will produce a very large positive side-effect on
- number of available threads per CPU; ADDRESS-related modules.
- number of EDA tool licenses; Once a sufficient coverage on these sub-modules is
- fault list size; reached, it is suggested to proceed in a synchronization
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
750 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO. 3, MARCH 2016

Fig. 5. Proposed test program development order organized in levels and branches, and synchronization steps.

process. The set of programs developed for 1A) are evalu- The microcontroller’s cost-efficient processor core is built
ated on the REGISTER FILE fault lists, while 1B) is graded on the Power Architecture technology and designed specifi-
on the ADDRESS-related modules. As a result, the number cally for embedded applications. The processor integrates a
of active faults to be then considered will be greatly pair of integer execution units, a branch control unit,
reduced. instruction fetch unit and load/store unit, and a multi-
level 2 – branch A) REGISTER FILE: the test of the register ported register file capable of sustaining six read and three
file module is straightforward, being many papers describ- write operations per clock cycle. Most integer instructions
ing effective sequences to test. In the proposed generation execute in a single clock cycle. Branch target prefetching is
method, it is suggested to reorder instructions and operands performed by the branch unit to allow single-cycle branches
in order to induce the usage of DATA DEPENDENCY in many cases. It contains a Memory Management Unit
structures in the PIPELINE. (MMU) and a Nexus Class 3 module is also integrated for
level 2 – branch B) ADDRESSING: by having completed external debug purposes.
1B), the most of the faults included in the ADDRESS-related The 32-bit processor utilizes an in-order dual-issue five-
modules, such as Branch unit, Effective Address calculation, stage pipeline for instruction execution. These stages are:
and Program Counter, will result as already covered. This

Instruction Fetch (stage 1)
step is therefore a completion of the previous one, which is

Instruction Decode/Register file Read/Effective
done mainly by adding memory operation and branches to
Address Calculation (stage 2)
specific addresses.

Execute 0/Memory Access 0 (stage 3)
A synchronization step is then operated on the PIPELINE

Execute 1/Memory Access 1 (stage 4)
and CONTROL UNIT modules, followed by level 3 with no

Register Write-Back (stage 5)
more branches, which consists on an ad-hoc generation step
The stages operate in an overlapped fashion, allowing
for these level modules.
single clock instruction execution for most of the available
To complete the process, the entire test suite obtained
instructions.
along this process is evaluated on the whole processor fault
The integer execution unit consists of a 32-bit Arithmetic
universe, eventually by adding refinement programs to
Unit (AU), a Logic Unit (LU), a 32-bit Barrel shifter (Shifter),
cover corner cases and specific configurations not consid- a Mask-Insertion Unit (MIU), a Condition Register manipu-
ered along the previous steps. lation Unit (CRU), a Count-Leading-Zeros unit (CLZ), a 32
 32 Hardware Multiplier array, and result feed-forward
5 AN INDUSTRIAL CASE-STUDY hardware. Integer EU1 also supports hardware division.
The methodology herein introduced has been applied to a Most arithmetic and logical operations are executed in a sin-
SoC including a 32-bit pipelined microprocessor based on gle cycle with the exception of multiply, which is imple-
the Power Architecture. The SoC is employed in safety-criti- mented with a two-cycle pipelined hardware array, and the
cal automotive embedded systems, such as airbag, ABS, divide instructions. A Count-Leading-Zeros unit operates
and EPS controllers and is currently being manufactured by in a single clock cycle. Two execution units are provided to
STMicroelectronics. allow dual-issue of most instructions. Only a single load/
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
BERNARDI ET AL.: DEVELOPMENT FLOW FOR ON-LINE CORE SELF-TEST OF AUTOMOTIVE MICROCONTROLLERS 751

TABLE 1
fitness values used in the Evolutionary computation

SBST Strategies Used along the Generation Process experiments include program size and length mea-
surement; in such a way, the programs exceeding
Sub-module Technique References
the imposed limitations can be discarded;
Arithmetic adders Division Deterministic þ Constr. [18], [19], [20],
Deterministic and Manual require additional efforts
unit Logic unit Multiplica- ATPG þ Evolutionary [21]
tion unit Shifters
by the test engineer to fit the programs length and
Exceptions Manual [22] size; more easily, if too long, they can be split into
Branch Unit Deterministic [23] several shorter programs.
Timers Manual Code characteristics fitting on-line requirements were
Register bank Deterministic [24]
also considered in all cases, such as having relocatable code
Register ports Deterministic [24]
EA adder Load store unit Loop-based þ Evolutionary [25] (absolute branches and access by absolute address to mem-
program counter þ Manual ory locations were not allowed) and resorting to limited
Forward unit Deterministic [26] portion of memory space (1 kB) reserved for test.
Decode unit Status/control Deterministic [27] As described in Section 3, each generated program is
flags
encapsulated into the EABI standard frame and includes
Fetch unit Deterministic [28]
the additional code sequences that guarantee the test
robustness.
For the current case of study, the EABI compliant frame
store unit is provided, and only a single integer divide unit is accounting for very few instructions at the beginning of
is provided, thus a pair of divide instructions cannot issue procedures (e.g., three-five instructions); this number
simultaneously. increases whereas:

extra registers have to be saved before being used
5.2 Experimental Results and finally restored to their original values (e.g.,
During one year of team work, we collected results of a non-volatile registers, or special purpose registers,
wide number of modules. To test processor through soft- such as the Microprocessor Status Register);
ware is a deeply explored field; therefore, in many cases the
memory resources need to be protected (e.g., Mem-
technique utilized has been borrowed from the literature ory Protection Unit is exploited);
and adapted to cover the specific modules of the considered
peripheral microcontroller’s resources need to be
processor core. Table 1 reports the list of generation techni- programmed for test robustness (e.g., watchdog
ques employed to achieve the high fault coverage of each timers, performance counters).
processor sub-module. On selecting these techniques, we The number of additional instructions required to afford
resort to some of the most important proposals regarding robustness other than raw compliancy with EABI standards
test program generation available in today’s literature. are about 20 instructions. Additionally, to further enforce
Concerning automatic approaches, we resorted to both robustness, additional instructions were added when a con-
ATPG-based techniques, and optimization techniques based text switching is forced via exception. Concerning the devel-
on Evolutionary Algorithms [17]. Some other techniques opment flow, the fault list generation and the adopted
(labeled as Deterministic) refer to available solutions that generation order follows the generic indications provided
exploit the sub-module regularity in order to propose a in Section 4.
well-defined test algorithm. Finally, rows labeled as Manual The fault lists were generated mainly according to the
refer to pure manual strategies performed by the test engi- processor functionalities which are directly related to spe-
neer exploiting the processor user manual, the ISA, as well cific modules in the netlist hierarchy. There are some excep-
as the available HDL processor descriptions. tions, due to the fact that the considered microcontroller is
As stated in Section 2, both the duration and the size of dual-issue and replicated arithmetic modules, such as the
each test program is an online requirement that may vary adders, were grouped together in a single fault list; in a dif-
depending on the mission application and physical limits of ferent way, the data-forwarding unit is composed of several
the microcontroller (e.g., the memory space available). In multiplexers, which faults are jointly considered. Another
our case study, the limitations were given both in terms of interesting case of resource partitioning is related to the
duration of single programs, and of overall occupation of multi-port register file that is contributing with two fault
the complete test suite. In particular, the maximum duration lists, the register bank and the register ports (decoders and
of a single program labeled as run-time test should not multiplexers); this is due to both the fault list size that we
exceed 512 clock cycles, while the FLASH memory area need to split, and the different functionalities.
reserved for test purposes was limited to 256 kB. Table 2 shows the evolution of the coverage along the
To match these constraints, every method needs to be tai- development flow. The final fault coverage is 87.23 percent
lored opportunely: on the fault list that includes around 750 k stuck-at faults.
For different reasons, there are modules not well

ATPG-based generation methods can be constrained covered:
by asking the automatic engine for high compression
and limiting the generation to a maximum number
modules managing exceptions: because it is not pos-
of patterns; the generated patterns may be eventu- sible to purposely exercise all of them (e.g., it is not
ally transformed into many test programs compliant possible to force a bus error which asks the exception
with duration constraints; unit to intervene);
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
752 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO. 3, MARCH 2016

TABLE 2
Coverage Evolution along the Development Flow

Single 1A Synchro 1A Single 1B Synchro 1B Single 2A Single 2B Synchro 2Aþ2B Single 3 Synchro 3
Sub-module #faults
FC [%] FC [%] FC [%] FC [%] FC [%] FC [%] FC [%] FC [%] FC [%]
Arithmetic adders 5,996 95.03 97.93 – – – – 98.27 – 98.52
Divider 19,018 83.98 83.98 – – – – 83.99 – 84.82
Logic instructions 22,294 76.32 78.57 – – – – 78.70 – 83.34
Multiplier 78,094 91.18 92.62 – – – – 92.62 – 95.90
Shifters 14,172 87.95 92.96 – – – – 93.97 – 96.32
Exceptions 40,718 – – 66.08 67.17 – – 68.16 – 72.48
Branch prediction 24,489 – – 70.91 70.95 – – 72.67 – 72.67
Timers 7,683 – – 88.21 88.43 – – 88.46 – 89.70
Register bank 83,764 – 71.21 – – 84.15 – 89.38 – 92.66
Register ports 126,329 – 69.17 – – 94.93 – 97.67 – 98.09
Program counter 26,060 – – – 66.07 – 68.66 69.42 – 70.09
EA adder 5,228 – – – 66.51 – 92.02 93.75 – 94.57
Fetch unit 71,582 – – – – – – 69.45 82.39 83.54
Forward unit 84,758 – – – – – – 70.95 84.29 84.82
Status flags 33,277 – – – – – – 59.31 78.08 78.61
Control flags 10,328 – – – – – – 64.21 66.83 69.83
Decode unit 62,876 – – – – – – 50.12 92.46 93.08
Load/Store unit 15,971 – – – – – – 73.50 75.42 76.73
Glue logic 19,425 – – – – – – – – 63.36
TOTAL 756,789 – 36.07 – 9.74 – – 76.87 – 87.23

branch prediction, program counter, and load/store maximizing the cascade effect. As an example of effective-
units: due to the memory mapping configuration of ness, by adopting the proposed order, the generated test
the specific SoC, not all bits in the addressing regis- programs over the 139,574 faults of arithmetic modules
ters can be functionally touched; included in 1A (level 1 – branch A) led to a positive side

processor status and control flags: since many of effects on 2A consisting in 147,029 over 210,093 faults (corre-
these flags cannot be used because controlling cir- sponding to about 70 percent), i.e., these faults are already
cuitries outside the processor core. covered without any specific generation effort for 2A. In
As a complement to the fault coverage measurements, other words, the fault simulation experiments carried on
the dimension and duration and coverage of the test along level 2A need to consider only 63,064 faults.
the entire development flow are included in Table 3. Having To the sake of completeness, we also computed the
a frequency of working of 150 MHz, the overall time results obtained by implementing an alternative generation
required for executing all 73 tests is about 0.8 ms. order, considering by first the modules of 2Aand then the
It is interesting to note, how the synchronization phases ones of 1A. We tackled the 210,093 faults of register bank
produce a very strong positive cascade effect over the mod- and ports by obtaining a fault coverage comparable with
ules not yet considered; at least the half of the faults of the results in Table 2, and evaluated the side effect of such pro-
modules that are going to be considered during the next grams over 1A: only 10,318 faults (or 7.4 percent) were
generation steps were pruned from the list without any already covered over the total amount of 139,574 faults of
additional effort. Table 2 also permits to remark that the the arithmetic modules.
synchronization steps cause coverage improvement also for The reduction in the fault list cardinality, achieved by
modules of the current and previous levels of the same properly ordering sub-modules and synchronizing fault
branch, as described in Section 4.2. lists, induces a great time gain due to a large reduction of
A significant advantage in terms of grading time reduc- fault simulation efforts. The effect is not limited to succes-
tion is achieved by a proper development order which is sive synchronization, but it permits faster generation itera-
tions as required by evolutionary algorithm.
TABLE 3 Table 4 shows the elapsed time for fault simulation in
Number of Test Programs, Duration and Code Size two cases:

Development Number of test Duration Code size 1)a raw development flow not using synchronization
Flow Step programs [Clock Cycles] [kB] but simply considering sub-modules separately;
Single 1A 29 8,840 23 2) a development flow following the proposed order
Synchro 1A and implementing synchronization between levels.
Single 1B 8 19,716 11 All the experiments were executed on a single core of a
Synchro 1B 2 GHz processor; the resulting times would be reduced by
Single 2A 10 32,634 36 running multi-process fault-simulations.
Single 2B 8 28,212 17 It is worth to notice that the fault simulation time
Synchro 2Aþ2B 55 89,402 87
Single 3 18 26,700 32 becomes excessive if not implementing synchronization. As
Synchro 3 73 116,102 119 well, the development order is important to minimize the
fault simulation efforts. Supposing again that level 2 branch
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
BERNARDI ET AL.: DEVELOPMENT FLOW FOR ON-LINE CORE SELF-TEST OF AUTOMOTIVE MICROCONTROLLERS 753

TABLE 4 that all the available processor functionalities can be exclu-

CPU Time Comparison for Approaches without sively accessed for testing purposes; on the contrary, CST
and with Synchronization
Library has more restrictive requirements.
Fault simulation time [hours] For validation sakes, we finally conducted two kinds of
1) without 2) with Saved experiments emulating the in-field behavior of the system:
synchro synchro time 1) to verify the fault-free behavior, a sample OS was con-
Level 1 Branch A 37 - sidered that was intensively triggering mission inter-
Level 1 Branch B 122 - rupts while self-test executed at regular intervals as
Level 2 Branch A 217 55 74.7% described above; a physical target was programmed
Level 2 Branch B 72 23 68.1%
Level 3 630 195 69.0% with such a complete software environment and left
running for several hours, tracing the correctness of
the test responses and liveness of the system;
A has been considered before level 1 branch A, the saved
2) to investigate on the robustness in case of faults, a
CPU time for fault simulation is decreased from about 37 to
specific fault injection campaign was performed by
34 hours, which is a negligible gain if compared to those
means of complete simulation (i.e., without fault
obtained by the proper ordering.
dropping) in order to classify erroneous behaviors,
5.3 Test Deployment during Mission as previously introduced in Section 3.3:
The suite of test programs resulting from the development a) self-test ends with a wrong signature;
phases described above is integrated in an industrial demo b) self-test is not ending due to deadlock
project for STMicroelectronics. The project handles the configuration;
whole test set of programs by means of two software mod- c) self-test ends with unattended exception man-
ules, and provides the project integrator with a software agement, due to:
Application Programming Interface (API), in order to i) illegal instruction execution;
include them in the mission application: ii) wrong branches in memory areas pro-
tected by MPU configuration.

tests for power-on: 44 test program, including Non-
exceptive and Critical tests, scheduled by an ad-hoc 6 CONCLUSIONS
software module named Boot Time Self-Test Module
This work proposes a development flow for the effective SBST
(BTSTM);
generation of a library of test programs, also referred as CST,

tests for Run-time: 29 Run-Time test programs han-
to be run online during the mission of automotive systems.
dled by an AUTOSAR 4.0 Complex Driver [29]
The paper includes:
named CST Library.
Both CST Library and BTSTM provide configuration
identification of online constraints and implemented
capabilities at compile time, in such a way that the project solutions;
integrator can selectively activate all programs or a subset
resources distribution and generation order for a
of the entire suite. It is up to the user of the API to choose most efficient and fast test program generation along
suitable test combinations and a scheduled execution order the various sub-modules of the entire processor;
to fulfill the safety requirements of the system.
execution management of the CST library and
In the devised demo, after the execution of the tests for robustness of its execution.
power-on that takes about 0.7 ms, the run-time tests were As a case of study, the paper reports the final results
scheduled according to some specific requirements for mis- related to a CST library generated for an industrial 32-bit
sion integration: processor core included in an automotive SoC manufac-
tured by STMicroelectronics; the fault coverage obtained in

self-test chunks must be less than 5 ms long; one year team working is more than 87 percent over around

self-test interrupts the mission application every 750 k stuck-at faults.
500 ms.
Along mission, using the proposed demo setup, the over- ACKNOWLEDGMENTS
all self-test length does not exceed 100 ms and a complete
self-test is performed in less than 2 ms. Availability of the The authors would like to thank for the useful discussion
mission application is reduced by around 1 percent even and contributions to this work Thomas Zsurmant, Renato
though that self-test can be preempted at any time. Meregalli, and Giovanni Di Sirio from STMicroelectronics,
Along development, the demo test suite was encom- Matteo Sonza Reorda, Michelangelo Grosso, Lyl Ciganda,
passing several verification and validation stages towards and Giovanni Squillero from Politecnico di Torino, Oscar
software maturity, which were including embedded docu- Ballan previously working with STMicroelectronics.
mentation of the code by means of special comments (e.g.,
Doxygen tags [30]) that are parsed by external tool for REFERENCES
automatically generating user manuals. [1] S. M. Thatte and J. A. Abraham, “Test generation for microproc-
Test programs also provide services for returning test essors,” IEEE Trans. Comput., vol. C-29, no. 6, pp. 429–441, Jun. 1980.
results, i.e., error codes such as AUTOSAR DEM errors and [2] A. Paschalis, D. Gizopoulos, N. Kranitis, M. Psarakis, and Y. Zor-
ian, “Deterministic software-based self-testing of embedded pro-
malfunctioning signatures computed by the test programs cessor cores,” in Proc. Des. Autom. Test Eur. Conf. Exhib., 2001,
for successive inspection of failing chips. BTSTM assumes pp. 92–96.
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.
754 IEEE TRANSACTIONS ON COMPUTERS, VOL. 65, NO. 3, MARCH 2016

[3] C. H. P. Wen, Li. C. Wang, and K.-T. Cheng, “Simulation-based [26] P. Bernardi, R. Cantoro, L. Ciganda, B. Du, E. Sanchez, M. Sonza
functional test generation for embedded processors,” IEEE Trans. Reorda, M. Grosso, and O. Ballan, “On the functional test of the
Comput., vol. 55, no. 11, pp. 1335–1343, Nov. 2006. register forwarding and pipeline interlocking unit in pipelined
[4] M. A. Skitsas, C. A. Nicopoulos, and M. K. Michael, processors,” in Proc. IEEE Int. Workshop Microprocessor Test Verifi-
“DaemonGuard: OS-assisted selective software-based self-testing cation, Dec. 2013, pp. 52–57.
for multi-core systems,” in Proc. IEEE Int. Symp. Defect Fault Toler- [27] P. Bernardi, R. Cantoro, L. Ciganda, E. Sanchez, M. Sonza Reorda,
ance VLSI Nanotechnol. Syst., Oct. 2013, pp. 45–51. S. de Luca, R. Meregalli, and A. Sansonetti, “On the in-field func-
[5] M. Psarakis, D. Gizopoulos, E. Sanchez, and M. Sonza Reorda, tional testing of decode units in pipelined RISC processors,” in
“Microprocessor software-based self-testing,” IEEE Des. Test Com- Proc. IEEE Int. Symp. Defect Fault Tolerance Nanotechnol. Syst., Oct.
put., vol. 27, no. 3, pp. 4–19, May/Jun. 2010. 2014, pp. 299–304.
[6] F. Reimann, M. Glass, A. Cook, L. Rodrıguez G omez, J. Teich, D. [28] P. Bernardi, C. Bovi, R. Cantoro, S. De Luca, R. Meregalli, D. Piu-
Ull, H. J. Wunderlich, U. Abelein, and P. Engelke, “Advanced diag- matti, E. Sanchez, and A. Sansonetti, “Software-based self-test
nosis: SBST and BIST integration in automotive E/E architectures,” techniques of computational modules in dual issue embedded
in Proc. ACM/EDAC/IEEE Des. Autom. Conf., Jun. 2014, pp. 1–6. processors,” in Proc. IEEE Eur. Test Symp., May 2015, pp. 1–2.
[7] K. Constantinides, O. Mutlu, T. Austin, and V. Bertacco, “A flexible [29] (2014). AUTOSAR web-site: [Online]. Available: http://www.
software-based framework for online detection of hardware autosar.org/
defects,” IEEE Trans. Comput., vol. 58, no. 8, pp. 1063–1079, Aug. 2009. [30] (2015). Doxygen web-site: [Online]. Available: http://www.stack.
[8] A. Paschalis and D. Gizopoulos, “Effective software-based self- nl/dimitri/doxygen/
test strategies for on-line periodic testing of embedded process-
ors,” IEEE Trans. Comput.-Aided Des. Integr. Circuits Syst., vol. 24, Paolo Bernardi (S’03-M’06) received the MS
no. 1, pp. 88–99, Jan. 2005. and PhD degrees in computer science from Poli-
[9] P. Bernardi, M. Grosso, E. Sanchez, and O. Ballan, “Fault grading tecnico di Torino, Torino, Italy, in 2002 and 2006,
of software-based self-test procedures for dependable automotive respectively. Since 2001, he has been with the
applications,” in Proc. Des. Autom. Test Eur. Conf. Exhib., Mar. Department of Computer Engineering, Politec-
2011, pp. 1–2. nico di Torino, where he is currently an associate
[10] Road vehicles – functional safety, ISO/DIS26262, 2009. professor. His interests cover the areas of testing
[11] S. Sobek and K. Burke. (2004). PowerPC Embedded Application of electronic circuits and systems and the design
Binary Interface (EABI): 32-Bit Implementation [Online]. Avail- of fault-tolerant electronic systems. He is a mem-
able: http://www.freescale.com/files/32bit/doc/app_note/ ber of the IEEE Computer Society and IEEE.
PPCEABI.pdf
[12] ARM. (2008). Application Binary Interface for the ARM Architec- Riccardo Cantoro received the MSc degree in
ture v2.09 available at ARM Information Center web-site: computer engineering from Politecnico di Torino,
[Online]. Available: http://infocenter.arm.com/help/index.jsp? Torino, Italy in 2013. Since 2014, he has been
topic¼/com.arm.doc.ihi0036b/index.html working toward the PhD degree in the Depart-
[13] E. Christopher. (2003). mips eabi documentation available at Cyg- ment of Computer Engineering, Politecnico di
win web-site: [Online]. Available: http://www.cygwin.com/ml/ Torino. His main research topic is microprocessor
binutils/2003-06/msg00436.html testing. He is a student member of the IEEE.
[14] S. Di Carlo, P. Prinetto, and A. Savino, “Software-based self-test of
set-associative cache memories,” IEEE Trans. Comput., vol. 60,
no. 7, pp. 1030–1044, Jul. 2011.
[15] A. Apostolakis, D. Gizopoulos, M. Psarakis, and A. Paschalis,
“Software-based self-testing of symmetric shared-memory multi-
processors,” IEEE Trans. Comput., vol. 58, no. 12, pp. 1682–1694, Sergio De Luca is a team leader, project
Dec. 2009. leader, and Functional Safety expert at STMi-
[16] G. Xenoulis, D. Gizopoulos, M. Psarakis, and A. Paschalis, croelectronics; embedded software develop-
“Instruction-based online periodic self-testing of microprocessors ment for automotive system-on-chip and real-
with floating-point units,” IEEE Trans. Dependable Secure Comput., time applications.
vol. 6, no. 2, pp. 124–134, Apr.–Jun. 2009.
[17] G. Squillero, “Artificial evolution in computer aided design: from
the optimization of parameters to the creation of assembly pro-
grams,” Computing, vol. 93, nos. 2–4, pp. 103–120, Oct. 2011.
[18] F. Corno, E. Sanchez, M. Sonza Reorda, and G. Squillero,
“Automatic test program generation: A case study,” IEEE Des.
Test Comput., vol. 21, no. 2, pp. 102–109, Mar./Apr. 2004. Ernesto Sa nchez received the degree in elec-
[19] N. Kranitis, A. Paschalis, D. Gizopoulos, and G. Xenoulis, tronic engineering from Universidad Javeriana,
“Software-based self-testing of embedded processors,” IEEE Bogota, Colombia, in 2000. In 2006, he received
Trans. Comput., vol. 54, no. 4, pp. 461–475, Apr. 2005. the PhD degree in computer engineering from
[20] N. Kranitis, A. Merentitis, G. Theodorou, A. Paschalis, and D. the Politecnico di Torino, where he is currently an
Gizopoulos, “Hybrid-SBST methodology for efficient testing of associate professor with the Dipartimento di
processor cores,” IEEE Des. Test Comput., vol. 25, no. 1, pp. 64–75, Automatica e Informatica. His main research
Jan./Feb. 2008. interests include microprocessor testing and evo-
[21] M. Scholzel, T. Koal, and H. T. Vierhaus, “Systematic generation lutionary computation. He is a senior member of
of diagnostic software-based self-test routines for processor the IEEE.
components,” in Proc. IEEE Eur. Test Symp., May 2014, pp. 1–6.
[22] P. Singh, D. L. Landis, and V. Narayanan, “Test generation for
Alessandro Sansonetti graduated in computer
precise interrupts on out-of-order microprocessors,” in Proc. IEEE
science from the University of Milan. He manages
Int. Workshop Microprocessor Test Verification, Dec. 2009, pp. 79–82.
ST’s Automotive Product Group software design
[23] E. Sanchez and M. Sonza Reorda, “On the functional test of branch
teams based in Italy (Agrate B.za, Naples and
prediction units,” IEEE Trans. Very Large Scale Integration Syst.,
Catania) and in France (Le Mans). He has partici-
vol.23, no. 9, pp. 1675–1688, Sep. 2015.
pated as an active member of the AUTOSAR
[24] D. Sabena, M. Sonza Reorda, and L. Sterpone, “A new SBST algo-
consortium as SPI document owner. He has
rithm for testing the register file of VLIW processors,” in Proc.
been with ST since 1996.
Des. Autom. Test Eur Conf. Exhib., Mar. 2012, pp. 412–417.
[25] P. Bernardi, L. Ciganda, M. De Carvalho, M. Grosso, J. Lagos-Ben-
ites, E. Sanchez, M. Sonza Reorda, and O. Ballan, “On-line soft-
ware-based self-test of the address calculation unit in RISC
processors,” in Proc. IEEE Eur. Test Symp., May 2012, pp. 1–6. " For more information on this or any other computing topic,
please visit our Digital Library at www.computer.org/publications/dlib.
Authorized licensed use limited to: CHONGQING UNIVERSITY. Downloaded on May 26,2025 at 09:02:24 UTC from IEEE Xplore. Restrictions apply.