AMICSA & DSP 2016

Scalable Sensor Data Processor: Testing and Validation

15 Jun 2016, 16:30

30m

Gothenburg, Sweden

DSP Day: Test, Verification and Qualification of DSP chips Session 2: Test, Verification and Qualification of DSP Chips

Speaker

Mr Ricardo Pinto (Thales Alenia Space)

Description

SSDP Architecture ================= The Scalable Sensor Data Processor (SSDP) is a heterogeneous multicore architecture for high-performance on-board data processing. Broadly, it embeds a Control block based on the well-known Cobham Gaisler LEON3 System-on-a-Chip (SoC) [1], with a LEON3FT general-purpose processor connected to several I/O interfaces via AMBA bus. The Processing block is based on Recore Systems multicore Digital Signal Processor (DSP) IP [2], containing two Xentium DSPs, connected to I/O interfaces and SDRAM memory via a Network-on-Chip (NoC). These blocks are connected via a bidirectional bridge, translating signalling and data transfers between block domains. The Control block provides several I/O interfaces, like SpaceWire (SpW), CAN, GPIO, SPI and I2C, among others. The Processing block has I/O interfaces more oriented towards data exchange and data conversion, with SpW interfaces for networked I/O and ADC/DAC interfacing with data conversion devices. Furthermore, the ADC/DAC interfaces can also be used as a high-throughput Parallel Interface for chip-to-chip communication. This interface possesses flow-control mechanisms, and can achieve a maximum throughput of 800 Mbps. Prototyping Support =================== The SSDP ASIC presents several challenges from a prototyping perspective: amount and quality of FPGA resources in order to accommodate all the logic needed by the control and processing blocks with reasonable performance; existence of mixed-signal (analogue and digital, e.g. ADCs) Intellectual Property (IP) blocks which may/can not be modelled nor prototyped. The SSDP ASIC design is being prototyped in a state-of-the-art Xilinx Kintex Ultrascale XCKU060 FPGA [3], mounted on a custom board designed in-house at TASE, named SSDP-PROB (SSDP Prototyping Board). This board provides all the needed I/O interfaces, together with SDRAM memory support. Mezzanine connectors have also been added in order to allow expanding the prototyping and validation activities, thus opening the possibility to either add more components, e.g. ADC and/or DAC devices, or probe internal FPGA signals directly. Testing and Validation ====================== Testing and validation is usually performed by providing the Unit Under Test (UUT) with stimuli, and then observe the outputs, whose correctness is assessed by comparison with a reference model. Applying this methodology to the SSDP requires the provision of Electrical Ground Support Equipment (EGSE), in order to provide the necessary stimuli (I/O activities), and capture the outputs for verification. The verification of output correctness is based either on specifications of I/O interfaces, or application output based on reference models. Setup ----- The test setup for SSDP requires an integrated and flexible EGSE platform, given the diversity of I/O interfaces. Such a platform is embodied by the National Instruments (NI) PXI product line [4], which offers the possibility to embed in a single chassis the controller cards and I/O interfaces. Such a platform is controlled with LabView, an industry standard software w.r.t. testing design and execution, and the testing activities can be modelled as LabView applications All the I/O interfaces of interest present on the board are connected to the test bench, using adequate EGSE I/O cards. Furthermore, an FPGA-based digital I/O module was used in order to control the SSDP, and at the same time offer the possibility to embed some of the testing activities directly into hardware. The EGSE interacts with the software layer on the SSDP via a set of pre-defined tele-commands (TCs). The TCs can be used to perform the following actions on the SSDP: setup interfaces; initialize memory areas and patterns; start and stop tests. Methodology ----------- SSDP testing activities can be divided in three classes, with increasing abstraction levels: **interface testing**, where one or more interfaces are tested, in order to assess their status of compliance to the (individual) specifications; **benchmark testing**, where an application is used to assess the performance of a given system or subsystem; **validation testing**, where an application is used to validate the overall system. In the case of **interface testing**, the philosophy followed is to delegate the testing activities almost solely to the EGSE, and add a minimal amount of software support to the SSDP in order to support the testing activities (drivers). The main advantage of this philosophy is to concentrate the bulk of test design and implementation on the EGSE application, thus easing the task of test design and execution. In **benchmark testing**, an application is executed and the time it takes to complete is evaluated. The results can be used to assess the performance of the tested system, and even compare it with others systems. An example of a benchmark is the amount of time needed to perform a give operation on a set of data, e.g. the FFT on a set of 1024 points of data. In the SSDP scope, the set of benchmarks defined for the NGDSP [5] will be used, in order to assess the performance figures of the processing block. Regarding **validation testing**, an application is executed in the SSDP, e.g., filtering, with the EGSE emulating the application’s expected environment, e.g. data acquisition from a sensor or data storage in a mass memory. The resulting output is then verified to be compliant with a reference model, e.g. output of the same application in a modelling tool like Matlab. Status ====== The testing and validation activities on the SSDP are currently at the interface testing level, with tests being developed for each I/O interface. These activities involve the development of specific software pieces in order to support the testing activities. The benchmark testing is envisaged to follow the NGDSP benchmark, making use of a normalized mark and enabling the comparison with other architectures. The results can also be used to make improvements to the architecture of the SSDP, or identify potential bottlenecks. The validation testing is envisaged to use the PXI EGSE as an emulator, providing stimuli and capture outputs to an application running on the SSDP. Envisaged applications include several representative use-cases, such as filtering, down-sampling or compression for the processing part, and sensor & actuator interface for the control part, via emulation. References ========== [1] Cobham Gaisler, GRLIB IP Core User's Manual, 2016. [2] Recore Systems, Xentium® VLIW DSP IP Core - Product Brief, 2012. [3] Xilinx Inc., UltraScale Architecture and Product Overview, 2016. [4] National Instruments, “PXI: The Industry Standard Platform for Instrumentation”, 2014. [5] TEC-EDP/2008.18/RT, “Next Generation Space Digital Signal Processor Software Benchmark”, ESA, 2008.

Summary

The Scalable Sensor Data Processor (SSDP) is a next-generation heterogeneous multicore mixed-signal ASIC for on-board data processing, embedding in the same chip resources both for high-performance data processing and general-purpose processing. These processing elements are connected to a diverse range of generic and specialized Input/Output (I/O) interfaces, including interfaces for data conversion from either external Analogue-to-Digital (ADC) and Digital-to-Analogue (DAC) converters.
The testing and validation of such a chip poses several challenges, stemming from its own nature: heterogeneous multicore; diversity of I/O interfaces; existence of analogue interfaces, etc. Tackling these challenges requires a robust prototyping platform, connected to flexible Electrical Ground Support Equipment (EGSE), capable of exercising all the I/O interfaces. These together with representative use-cases and applications are exploited in order to perform testing and validation.

Presentation materials

Paper

2_2_SSDP_Test_and_Validation_20160614.pdf

Slides

2_2_P_SSDP_Testing_&_Validation_20160614.pdf

summary

Conference_CV_R._Pinto.txt