3.3 Development Flow
3.4.3 Cumulative Results
In the frame of a collaboration with STMicroelectronics, during the recent years the proposed development flow has been applied to several industrial devices for safety-critical automotive applications. The fault coverage level of the resulting suite of SBST programs concurs to the overall functional safety regulated by the ISO 26262 standard [89].
The cumulative results gathered in these years are reported in Table 3.8. The e200 processor family is a set of CPU cores that implement low-cost versions of the Power Architecture™ Book E architecture. A brief description of the processors is given in the following:
e200z0h is a single-issue 32-bit CPU embedded in a single-core 90nm SoC for auto-motive targeting chassis market segment, specifically the Electrical Hydraulic Power Steering (EHPS) and the lower end of Electrical Power Steering (EPS), and the airbag application segment.
e200z448 is the case study processor of Section 3.4.1. It is embedded into a 90-nm single-core SoC for safety-critical automotive applications.
e200z215 is a single-issue 32-bit CPU operating up to 80 MHz. It is embedded into a 40-nm single-core SoC that targets automotive vehicle body and gateway applications, such as standalone gateway, simple body control module, and satellite body application like door or lighting module.
e200z420 is a dual-issue five-stage pipeline 32-bit CPU operating up to 180 MHz.
It is embedded into a 40-nm multi-core SoC (including two symmetrical z420 CPUs and a third processor running at 100 MHz) that targets automotive
Table 3.8 Cumulative experimental results on industrial processors
Processor #Faults SA FC% Duration [cc] Code size [kB]
e200z0h 198,622 82.55 45,091 76
e200z448 756,789 87.23 116,102 119
e200z215 282,370 80.40 156,363 86
e200z420 422,419 82.64 205,003 113
e200z425 792,647 81.04 222,855 139
vehicle body and gateway applications, such as central body controller, smart junction box, and mid-end and high-end gateway.
e200z425 is a dual-issue five-stage pipeline 32-bit CPU operating up to 180 MHz.
It is embedded in a 40-nm multi-core SoC that targets any safety-critical application requiring a very high level of safety integrity, such as automotive powertrain controllers, steering, breaking, and others.
In order to comply with the overall functional safety, the required fault coverage level on the CPU module of a given device was equal to 80%. As shown in Table 3.8, this level was reached in all the considered case studies. However, the final fault coverage reached on the processors is not very high and in same cases is quite near to 80%. The reason for this is partially due to the maturity level of the test suite, that is still in development for some processors. Moreover, stringent on-line requirements were limiting the effectiveness of some test procedures, as well as functionally untestable faults which are hard to identify and quantify.
Finally, cumulative results have been gathered on a set of academic processors and reported in Table 3.8. The RT-level descriptions of such processors have been synthesized using Synopsys Design Compiler targeting different open-source tech-nology libraries. No Design-for-Testability features have been included in the final gate-level netlists, thus the fraction of functionally untestable faults in these proces-sors is significantly lower than in industrial ones, whose netlist are post-layout. Also, the reason why the final fault coverage on academic processors is considerably higher is due the less complexity and size of the fault lists. Finally, on-line constraints have not been considered in the test program generation for these processors.
Table 3.9 Cumulative experimental results on academic processors
Processor #Faults SA FC% Duration [cc] Code size [kB]
miniMIPS 110,024 95.02 17,162 45
Cortex-M0 75,936 90.47 205,765 153
OpenRISC 1200 112,144 85.60 32,516 54
OpenMSP 430 29,424 94.87 118,450 48
3.5 Chapter Summary
This chapter described an effective development flow for the SBST generation of a library of test programs to be integrated in the mission operating system. The automotive domain was used as reference in the discussion.
In details, the chapter discussed about:
1. identification of on-line constraints and implemented solutions;
2. resources distribution and generation order for a most efficient and fast test program generation along the various sub-modules of the device under test;
3. robust execution and management of SBST programs.
As case of studies, the chapter presented results related to the development flow for an industrial 32-bit processor core and a floating-point unit (FPU) included in automotive SoCs manufactured by STMicroelectronics.
The fault coverage obtained on the case study processor is more than 87% over around 750k stuck-at faults, while 90% is the FPU coverage. Cumulative results on several academic and industrial processors demonstrated that the development flow can be systematically applied to reach the target fault coverage level with reduced generation time.
Summary of Part I
This part of the thesis presented SBST techniques for microprocessor based systems.
Within this work, a set of systematic techniques for hard-to-test modules in modern microprocessors has been presented: decode unit, register forwarding and pipeline interlocking unit, special modules that implement dual-issue execution, and floating-point unit.
Although this subject has been studied for years, its practical adoption by the industry is still not mature. An effective development flow has been presented and actually implemented for a family of industrial processors manufactured by STMicroelecronics. Previous approaches found in the literature mainly target SBST generation for academic processors, without stringent on-line requirements due to the integration of SBST into mission operating systems. Such requirements are not only related to time and memory budgets, which challenge the possibility by the test engineer to reach high levels of fault coverage, but also concern the robustness of the testing environment, meaning that SBST programs must not corrupt resources used by the mission application.
Referring to the industrial domain, testing of microprocessor cores is tradition-ally afforded using automatic techniques that are highly supported by commercial EDA tools. This is the case of scan testing, which relies on ATPG and retarget-ing techniques for embeddretarget-ing patterns into built-in self-test modules. Conversely, SBST generation is mainly implemented with manual effort, by recurring to deter-ministic algorithms or feedback-based techniques, which in most cases are highly
time-consuming tasks. The usage of commercial EDA tools by the test engineer is restricted to fault simulations, used for the fault grading or withing the test program refinement loops, and (mainly combinational) ATPG for sub-modules that can be easily controlled by means of software routines. This thesis has tried to go in the direction of collecting some state-of-the art SBST techniques and new proposed ones, with the purpose of creating a repeatable generation flow for complex designs.
Nevertheless, the proposed flow is based on manual effort, but is trying to maximize the generation efficiency, compared to non-organized alternative approaches.
Test and Diagnosis of Reconfigurable
Scan Networks
Background
Due to the complexity of new electronic devices, several features are embedded in such systems beside the core functional logic. Examples of such features are Built-In Self-Test (BIST) included for test and diagnostic sake, interfaces to core testing (e.g., based on the IEEE Std 1500), analog components (e.g., temperature sensors) accessed during the chip calibration, or debug related components (e.g., trace buffers).
These features are hereinafter called instruments. Creating a mechanism to access instruments has led to many different legacy solutions, facing the complex task of integrating all of them in the system, especially when they come from different designers. In order to mitigate these issues, new standards have been created.
The traditional boundary scan chains are not efficient solutions for connecting the considerable number of instruments present in next generation designs for dif-ferent reasons. Some of the instruments may need to be accessed only in particular situations, e.g., for security-related issues. This chapter introduces the basic concepts of Reconfigurable Scan Networks (RSN in Fig. 5.1), which extend the concept of reconfigurable scan chains and are extensively used in the IEEE Std 1687.
The rest of this chapter is structured as follows: Section 5.1 presents the main structures characterizing RSNs, in particular introduced by IEEE Std 1149.1-2013 (cf. Section 5.1.1) and IEEE Std 1687 (cf. Section 5.1.2). Section 5.2 discusses about the related work. Finally, Section 5.3 introduces a suite of benchmarks used in the experimental results of this thesis.
Parts of this chapter have been derived from published works [90, 13, 14].
T A P
T D R SI
RSN
SOInstrument
Fig. 5.1 Concept of Reconfigurable Scan Network (RSN)
5.1 Network Constructs
IEEE Std 1149.1-2013 and IEEE Std 1687 have introduced the concept of reconfig-urable scan chains. This kind of chains are segmented in several parts, hereinafter referred to as segments, which are interleaved with special elements, hereinafter referred to as reconfigurable modules. Each segment can include one or more instru-ments. The interface with an instrument is the test data register (TDR), which can include capture logic (in case of reading capability) and update logic (in the case when writing is allowed). According to the configuration of reconfigurable modules, certain segments are connected together in the so called active path, i.e., the path connected between the scan input and scan output pins of the reconfigurable scan chain. Since the complexity of these reconfigurable scan chains can be high (i.e., many possible active paths may exist), the standards refer to them as networks.