2492
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 49, NO. 5, OCTOBER 2002
The Digital Front-End Electronics for the Space-Borne INTEGRAL-SPI Experiment: ASIC Design, Design for Test Strategies and Self-Test Facilities Michel Mur, B. Cordier, M. Donati, R. Duc, J. L. Fallou, T. Larqué, F. Louis, S. Schanne, and E. Zonca
Abstract—The flight model of the digital front-end electronics (DFEE) of the gamma-ray spectrometer SPI has been recently integrated on the INTEGRAL satellite spacecraft. The processing core of the DFEE is based on a dedicated application specific integrated circuit (ASIC). We report on the unified design and test methodology that was deployed to cover the entire life cycle of this subsystem, from initial design simulation to operational self-test and diagnosis operations after launch. Strong emphasis is put on the ASIC design-for-test strategies, from very-high speed integrated circuit description language IEEE 1076 (VHDL) simulation and test bench validation to full scan fabrication test coverage and inflight self-test capability. Index Terms—Application specific integrated circuit (ASIC) design, built-in-self-test, design-for-test.
I. INTRODUCTION
T
HE SPI spectrometer is one of the gamma-ray astronomy instruments of the INTEGRAL satellite [1], to be launched in 2002 by the European Space Agency. The flight model of the digital front-end electronics (DFEE) for SPI has been recently delivered for integration on the spacecraft [2]. The processing core of the DFEE is based on a dedicated application specific integrated circuit (ASIC). The original specification and environment of this circuit were already described elsewhere [3]. After completion of the project, we now report on the unified design and test methodology that was deployed to cover the entire life cycle of this subsystem, from initial design simulation to operational self-test and diagnosis operations after launch. Strong emphasis is put on the ASIC design-for-test strategies, from VHDL simulation and test bench Manuscript received November 22, 2001; revised March 19, 2002. The Space-Borne INTEGRAL-SPI experiment is an international collaboration of the following research institutes: Centre d’Etude Spatiale des Rayonnements (CESR) Toulouse, France; Max-Planck-Institut für extraterrestrische Physik (MPE), Garching, Germany; Commissariat à l’Énergie Atomique (CEA) Saclay, France; University of Valencia, Spain; Goddard Space Flight Center (GSFC) Greenbelt, MD; Istituto per ricerche in Fisica Cosmica (IFC)/Consiglio Nazionale delle Ricerche, Italy (CNR) Milano, Italy; Space Sciences Laboratory (SSL), University of California, Berkeley; Center for Astrophysics and Space Sciences (CASS), University of California San Diego; University of Louvain, Belgium; University of Birmingham, U.K.; Centrum Badan’ Kosmicznych (CBK) Warsaw, Poland. The SPI project is managed by the Centre National d’Etudes Spatiales (CNES) Toulouse, France. The authors are with the Commissariat à l’Energie Atomique (CEA) Saclay, DSM/DAPNIA/SEDI, F-91191, Gif sur Yvette Cedex, France (e-mail:
[email protected]). Digital Object Identifier 10.1109/TNS.2002.803855
Fig. 1.
DFEE system interfaces.
validation to full scan fabrication test coverage and in-flight self-test capability. II. DFEE ARCHITECTURE This section briefly recalls the architecture of the DFEE subsystem. The DFEE analyzes and correlates the real time activity of the SPI front-end electronics, and regularly produces a formatted list of classified and time stamped events to the DPE flight computer [Fig. 1]. Gamma-ray time and energy are obtained from the Germanium (Ge) detector analog front-end electronics (AFEEi), and background rejection is provided by the bismuth germanate (BGO) anti-coincidence veto shield and the pulse-shape discriminator (PSD) unit. The processing core of the DFEE is implemented in a dedicated ASIC, in charge of detector signal alignment, multiple event gathering, energy acquisition, event classification, counting and dead time monitoring. This digital ASIC first takes care of the real time high-speed event building and classification, and then builds event and energy lists that are made available to the DPE flight computer on a dedicated scientific serial link (high-speed link). The high-speed link is activated eight times per second, thus, defining a series of scientific measurement packets corresponding to 125-ms Time Frames. Complete photon per photon information—detector address, event time, energy, multiplicity—is produced for nonvetoed
0018-9499/02$17.00 © 2002 IEEE
MUR et al.: DIGITAL FRONT-END ELECTRONICS FOR THE SPACE-BORNE INTEGRAL-SPI EXPERIMENT
2493
Fig. 2. DFEE Block Diagram.
events and will eventually be transmitted to the ground support station. Energy lists are produced separately for each detector, and are accumulated by the DPE to form individual energy spectra. Monitoring statistics—signal counts, veto rejection fraction, ACS and AFEE dead time—are requested by the DPE for each second of operation. These parameters are built up in the ASIC for 1-s accumulation intervals, and are then made available to an intermediate software programmable microcontroller unit in the DFEE. The microcontroller unit handles the low-speed communication with the DPE flight computer on a dedicated serial link (low-speed link), and is also used to initialize, configure, supervise, and test the ASIC.
III. ASIC BLOCKS This section briefly recalls the function of the ASIC internal blocks, as sketched in Fig. 2. The Front-End block (Front) takes care of input signal detection, glitch filtering and relative detector delay alignment. In the following stage, the Association block (Asso) implements the core event association and classification, and creates the intermediate Primary Object table (Pobj). The
Acquisition block (Acq) collects the corresponding AFEE energies and PSD event identifier, builds separate event classes for single events (SE), multiple events (ME) and PSD events (PE), and creates formatted records in the external Output Tables, where they are maintained for intermediate storage. After a pipeline delay matched to the high-speed link 125 ms periodic acquisition interval, the Dialogue block (Dial) takes data records from intermediate storage and passes them to the DPE according to the HSL packet protocol. The Dead Time and Count block (Cnt) maintains signal activity counts and various monitoring statistics, and accumulates them for 1-s intervals, to match the DPE periodic acquisition interval on the low-speed link. The Configuration, Control, Status and Test block (Ccst) encompasses the supervising tasks implied by its name, and controls the circuit clock selection TimeBase block (TimeB). The use of the CCST block as a system test driver will be addressed specifically in this paper. IV. CLOCK DOMAINS The ASIC circuitry is fully synchronous (no asynchronous signal path), and assembles three distinct synchronous clock domains. All domains are fully static and can run from very slow (even DC) clocks.
2494
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 49, NO. 5, OCTOBER 2002
A. CcstClk Domain The CCST domain runs synchronously to a variable-frequency clock provided by the microcontroller (CcstClk). CcstClk transitions are triggered by specific microcontroller instructions. CcstClk cycles and operations are, thus, driven and synchronised by software execution. B. SysClk Domain The main event processing tasks run under control of a central system clock (SysClk). All delay adjustments, event association operations and event time stamp marks use SysClk as the reference time unit. In normal operation, SysClk is provided by a free running 20-MHz quartz oscillator. Under special CCST-initiated test modes, the SysClk domain may be driven from an externally provided external clock (ExtClk), or from the software-driven clock (CcstClk). C. HslClk Domain The HSL output transfer runs synchronous to a separate clock (HslClk). In normal operation, HslClk is a 5-MHz clock signal provided by the DPE. Under special CCST-initiated test modes, the HslClk domain may also be driven from the software-driven clock (CcstClk). D. Single Step Actions Due to the TimeBase clock selection facility, single step actions on either SysClk, HslClk or both domains can be achieved by software from CCST. As will be described later, this powerful feature is the major tool for circuit test and self-test operations. V. CCST TEST FUNCTIONS The CCST block is accessed by software and provides serial access to the uniform internal resources required to reset, initialize, configure, start and stop the ASIC blocks. In operation, channel dead time and signal counting statistics are retrieved by the microcontroller from the CCST port, and then transmitted to the DPE on the low-speed link. Additional features of the CCST provide global and sampled (8 Hz) status, test facilities and system clock selection. For test purposes, the CCST can provide single-step system clocking in all clock domains. This feature is used to test the counting units, the embedded Primary Objects FIFO memory (Pobj) and achieve self-test operations. VI. GENERIC BLOCK STRUCTURE To support the above described CCST access method, each block follows the generic architecture sketched in Fig. 3. The processing core of the block (finite state machine and/or data path elements) normally runs in the SysClk domain. A notable exception is the Dialogue block processing core, which runs partly synchronous with SysClk (sequential extraction of data from the output tables) and partly synchronous with the independent high-speed link clock (HslClk). The generic block wrapping “envelope” is accessed in the CCST domain and provides independent configuration, reset, control and status registers for the block. Configuration registers are driven by CcstClk only, and may not be changed while run-
Fig. 3.
Generic block structure.
ning in operational mode. Reset and Command registers are synchronised to SysClk, to allow for precise state machine initialization and run activation in the very same clock period across several blocks. Separate Reset registers for each block allow for chip-level block isolation, and are useful for partial test procedures. Status registers are either in the “global” class: progression or error status bits build up on their own and never fade off until explicitly reset, or in the “sampled” class: progression or error status bits are regularly sampled by the CCST software and accumulate in between. Corresponding registers from different blocks are connected together to form long chip-level serial access registers. These registers show a parallel–serial behavior: All bits in a particular register are updated and observed at the same time, but they are prepared and extracted in sequence from the CCST serial port. VII. DESIGN VALIDATION A. Functional Validation The DFEE ASIC circuitry was described and simulated in VHDL, it was then created by automatic gate synthesis, optimized by iterative floorplanning and wire delay estimation tools, and finally laid out by foundry proprietary tools. Functional tests were designed at the I/O boundaries to exercise the circuit in its nominal operating mode and were applied on both the VHDL register transfer level (RTL) and gate level descriptions. After circuit layout, the same simulations were run again using the extracted wire delays in the standard delay file (SDF) format and the corresponding VHDL initiative toward ASIC libraries (VITAL) cell libraries. Test vector sequences were automatically derived from the VHDL functional test bench to prepare test-oriented simulations. These test vectors were then used for design sign off with the foundry design center, and were later run on the manufactured parts as part of the acceptance test.
MUR et al.: DIGITAL FRONT-END ELECTRONICS FOR THE SPACE-BORNE INTEGRAL-SPI EXPERIMENT
B. Static Analysis Due to the fully synchronous nature of the circuit, post layout performance could be fully assessed by static analysis, after parasitic delay extraction. Maximum operation frequency for the circuit could be determined for each domain independently, and showed sufficient slack for all three domains. For the most demanding SysClk domain, we obtained a guaranteed operation frequency of 40 MHz (for a 20-MHz target) on the selected Atmel-0.6 m CMOS radiation tolerant gate array technology. C. FPGA Prototype To further enforce design strength in our goal to obtain first good silicon on the ASIC development plan, we developed a source compatible field programmable gate array (FPGA) prototype circuit. When this approach was considered, FPGA circuits were not dense enough to accommodate the full design. We could however implement a fully functional circuit, with only five out of the 19 AFEE channels installed. To guarantee FPGA and ASIC equivalence, the unique VHDL source was made flexible enough to automatically support any number of AFEE channels and generate the appropriate structures accordingly. The FPGA device was extensively tested and characterized, and was used in the early DFEE engineering model (EM) delivery. VIII. DESIGN FOR TEST In addition to the general CCST test access port features, we had to install dedicated test structures to make sure that the test coverage for fabricated circuits would exceed 95%, as was required by the French space agency (Centre National d’Etudes Spatiales, CNES). In designing these special structures, we also specified them to be controllable by the CCST “software” port, to prepare a seamless transition from ground test to flight self-test conditions. A. Dedicated Test Structures Due to the limited number of possible test vectors 200,000 , functional tests applied to external I/Os were impractical to test buried structures (such as embedded memory blocks) or highly sequential units (such as large range counters). Specific CCST test registers and functions were added at design time to support the validation of those units. The foundry design center provided the embedded Primary Object memory as a precompiled dual-port random access memory hard block, but did not provide a guaranteed built in self test module for it. To reach the expected test coverage, we could not rely on circuit functional tests to indirectly exercise the internal memory in all possible word and access pattern combinations. It was then absolutely necessary to include a direct read/write test of the embedded memory (128 26-b words) from CCST. This was accomplished by inserting serial input and output access registers, and providing special functions to write and read the memory. To speed up the test, multiple writes were allowed and an exclusive-or accumulated signature was provided on the output. In the DFEE ASIC, approximately half of the circuit is devoted to the dead time and activity monitoring counters (21 24-b
2495
counters, and 63 16-b counters). Validating the full progression and saturation of any -b signal counter by signal activation functional vectors. Functional testing would have required for this circuit section was, thus, precluded. To make it testable even during flight mission self-test phases, we included CCST registers to initialize and extract the counters, and special functions to repeatedly and collectively increment them. B. Full Scan Test Strategy The full scan test methodology is a powerful tool to reach very high-test coverage rates, and is very efficient in fully synchronous designs. After scan path insertion, all sequential flip-flop nodes in the design are connected together in a series of dedicated serial register chains. Using a special scan control pin, these chains can be shifted in and out to install a particular initial state in the circuit, apply a functional clock edge and then observe the resulting state. Automatic test pattern generation (ATPG) tools are used to create the optimal test vector sequence required to validate the random logic circuitry connecting the outputs and inputs of the sequential nodes installed in the scan path. Checking the output state of each vector guarantees coverage of any stuck-at-1 or stuck-at-0 fault in the random logic paths, and also inherently checks the sequential nodes. On the DFEE ASIC, full scan was applied concurrently on the three clock domains, simultaneously flooding all three clock trees from CcstClk. This was made possible across the strongly interlaced SysClk and CcstClk domains by careful clock tree balancing of these two domains. The much smaller HslClk tree was not balanced. Due to that, a small number of domain interface flip-flops had to be excluded, and their function was specifically checked by functional testing. The embedded memory precompiled block could not be included in the scan path. However, we already obtained 95% coverage of the full circuit after 120 000-scan path test vectors. IX. CIRCUIT VALIDATION AND SCREENING Circuits were tested with a set of two distinct functional simulations, followed by the scan test vectors. The functional simulations ran the circuit in different configurations, with different sources for SysClk, and exercised the dedicated test structures. Altogether, global test coverage was estimated to be higher than 98%. The DFEE ASIC was mapped on a 200 000 gate Atmel MG-RT sea-of-gates array in a 256-pin ceramic quad flat pack package. Engineering and qualification parts were found satisfactory on the first production run. Flight parts were manufactured according to Hi-Rel standard ESA SCC9000 Level C, including Lot Acceptance Test level 3 and life test procedures. X. IN FLIGHT SELF TEST A. Flight Operation During flight mission, the DFEE cyclically runs setup and operation phases where it is successively powered up, configured and then put into operational mode. The DFEE software drives the system through specific states corresponding to each of these phases. During actual operation, the software continuously monitors the installed configuration, checking the ASIC
2496
IEEE TRANSACTIONS ON NUCLEAR SCIENCE, VOL. 49, NO. 5, OCTOBER 2002
CCST configuration registers against the expected configuration obtained from ground telecommands. In addition to the normal signal count and dead time values, produced for each second of operation, the DFEE software also compiles the global and sampled status for each ASIC block into a status summary showing the health of the system, recorded for each following second. B. Self-Test Procedure When powered up, the DFEE software runs a comprehensive self-test procedure. After microsystem health checks, the self-test procedure places the ASIC in a mode where the detector and DPE interface port pins are disabled, and replaced by CCST-accessed boundary registers. A sequence of tests is then launched, starting with the counters, continuing with the embedded memory and ending with a simulated operational run. During this simulated run, which makes extensive use of the single step clocking facility, several following virtual time frames are created; for each time frame, input detector signals are injected on the boundary registers, and HSL and LSL outputs are recorded. The outputs are checked for identity against reference records that were prestored in read only memory.
XII. CONCLUSION By careful anticipation of the various validation stages that would occur throughout the system life cycle, we could use the same test suite across all stages of design development, and follow a secure path that led us to successful ASIC circuits in the first fabrication run. The initial VHDL simulation test bench was used to validate the ASIC circuit function, but was also used to produce the functional test vectors for foundry test. Circuit foundry fabrication test coverage was insured by full scan methodology and by special built-in self test structures. The stimuli and result files of the VHDL test bench were made compatible with the real world test bench that was used to validate the prototype FPGA and ASIC physical parts. The same test environment could later be supported by the DFEE software itself, owing to the inclusion of an advanced single step clocking mechanism and to regular ASIC block isolation and scheduling functions. During satellite mission life, the DFEE flight software will still regularly apply self-test operations based on this mechanism, and will provide in-depth status and error diagnostic to help system-level diagnosis. ACKNOWLEDGMENT
XI. IN FLIGHT DIAGNOSIS A. Error Analysis and Recovery While in operational mode, the DFEE ASIC gives detailed information on its behavior for each 125-ms time frame. External events such as detector or HSL signal exchange protocol errors, or internal unexpected events such as internal buffer overflows are detected and reported. Unexpected finite state machine progression errors or Output table record parity errors are also reported. On the INTEGRAL orbit, the expected radiation induced Single Event Upsets in the DFEE ASIC are not expected to exceed ten events per year, and most of them will not affect durably the circuit behavior. In the event where the ASIC gets locked due to such an error and stops providing valid HSL output, the DFEE software may be configured to automatically recover by selectively restoring the offended ASIC subsystem. In most cases, signal counts and dead time monitoring will not have been interrupted.
The authors wish to thank their colleagues from the Service d’Astrophysique (CEA/DSM/DAPNIA/SAP) for their fruitful discussion and advice during the design and development of the DFEE electronic architecture and their support in the ASIC technology selection and quality surveys. They also wish to thank their colleagues from the Service d’Electronique et d’Informatique (CEA/DSM/DAPNIA/SEI) for their support in the design of the sophisticated ASIC test fixtures and support software. They also wish to thank their colleagues from the Service d’Instrumentation Générale (CEA/DSM/DAPNIA/SIG) for their support in the design of the event stimuli generator that was used to validate and commission the DFEE. The DFEE was designed and developed under supervision of the French space agency (CNES, Centre National d’Etudes Spatiales, Toulouse, France). The authors wish to thank the CNES SPI project team for their support, and the CNES Component and Quality Division for their advice in the ASIC development procedures.
B. Diagnostic Registers In case of problem, the SPI ground segment may elect to place the DFEE in diagnostic mode. The DFEE will work as in normal (operational) mode, but additional, detailed diagnostic snapshots of the internal ASIC activity will reach ground. Based on these records, diagnostic analysis will be conducted and may conclude on the problem source and corrective actions, including redundant circuit activation.
REFERENCES [1] C. Winkler, “INTEGRAL: Overview and mission concept,” Astrophys. J., June 1994. [2] S. Schanne, B. Cordier, M. Gros, M. Mur, S. Crespin, and S. Joly, “The space-borne INTEGRAL-SPI gamma ray telescope: Test and calibration campaigns,” IEEE Trans. Nucl. Sci., to be published. [3] E. Lafond, M. Mur, and S. Schanne, “The digital ASIC for the digital front end electronics of the SPI astrophysics gamma-ray experiment,” IEEE Trans. Nucl. Sci., vol. 45, pp. 1836–1839, Aug. 1998.
