Managing Multiple Types of DSP Processors Using NI TestStand

Author(s):
Sambit Panigrahi - Viking Interworks/ Sanmina-SCI
Roland Canson - Sanmina-SCI

Industry:
Semiconductor, Electronics

Products:
PXI-2567, PXI-4110, LabVIEW, PXI-1044, PXI-8105, TestStand

The Challenge:
Developing a test solution that combines structural and functional tests and delivers high throughput, real-time test results, and data upload into MfG/PRO/Oracle to support multiple families of DSP processor modules.

The Solution:
Using the NI TestStand test management environment and the NI LabVIEW graphical programming environment with PXI and CompactPCI hardware, we created a solution that seamlessly combines a variety of tests to provide required throughputs. Viking Interworks, the module division of Sanmina-SCI, develops processor modules used in telecommunication and media applications such as WiMAX, WiFi, and VOIP. These processor modules contain high-end network/DSP processors from vendors including Intel, Mindspeed, Samsung, and ATMEL. They encompass components including SDRAM, FLASH, CPLDs, USB controllers, and PHYs, which typically are on a 200-pin SODIMM or 244-pin mini-DIMM card-edge module.

Using the NI TestStand test management environment and the NI LabVIEW graphical programming environment with PXI and CompactPCI hardware, we created a solution that seamlessly combines a variety of tests to provide required throughputs.

Viking Interworks, the module division of Sanmina-SCI, develops processor modules used in telecommunication and media applications such as WiMAX, WiFi, and VOIP. These processor modules contain high-end network/DSP processors from vendors including Intel, Mindspeed, Samsung, and ATMEL. They encompass components including SDRAM, FLASH, CPLDs, USB controllers, and PHYs, which typically are on a 200-pin SODIMM or 244-pin mini-DIMM card-edge module.

Using National Instruments Hardware to Develop a Modular Test System
We selected the NI PXI-1044 chassis as the primary PXI chassis, because it can support 14 individual PXI slots providing us much needed scalability and versatility in switching between tests for different processor families. A PXI boundary scan controller with the QuadPOD transceiver, used for acquisition of boundary scan test results, connects to the PXI-1044 chassis through one of the slots. In addition to connecting the POD, we used the NI PXI-8105 embedded controller, the NI PXI-4110 triple-output programmable DC power supply, and the NI PXI-2567 external relay driver module in our solution.

Using the PXI-1044 chassis, we can easily add and remove PXI cards for different tests. We also have multiple tests integrated into a single chassis for a one-stop solution. The PXI-8105 embedded controller eliminates the need for a separate computer to drive our test software. The PXI-2567 module offers high-speed hardware switching between the various tests, and the-PXI-4110 power supply provides power to the functional test boards. We also intend to use the PXI-4110 power supply in the future for voltage and current measurements to detect possible overvoltage or overcurrent faults in modules under test or test boards.

Boundary Scan Testing
We perform structural tests to determine if all the signal nets are connected to the card-edge and if the signals on the module under test can be supported at operational speeds. The boundary scan tests also ensure that the memory component interconnects in the module. Boundary scan tests such as infrastructure, interconnect, SDRAM (memory cluster), FLASH, and CPLD programming are performed by tests generated using the production integration package (PIP) specifically designed for use with NI TestStand. The PIP was provided by the boundary scan programming solutions provider. These tests were developed by proprietary test generation software and then integrated into NI TestStand.

Functional Testing
After passing the structural tests, the modules undergo a functional-level test, which tests the components including SDRAM (at speed walking 1s, walking 0s, Fs, 0s, 5s, etc), GPIO, USB, Flash, and Ethernet ports. The functional-level test typically consists of embedded code installed on the embedded Linux® OS redboot.

Programming the Modules
Once the module has passed the structural and functional tests, we typically program the modules using custom images provided by the customer for their specific applications. A typical programming cycle consists of:
(i) Programming a bootloader
(ii) Transferring an OS Image
(iii) Setting module parameters such as IP/MAC address and OS settings
(iv) Copying flash images onto the system
(v) Transferring large files to the modules using a TFTP server
(vi) Performing final boot and login to the system
(vii) Verifying correct programming of parameters

We use macros specific to Signum Systems’s Chameleon software, in conjunction with their Signum JTAGJet ICE, for initial programming through the JTAG port. TFTP servers are used to transfer large files onto the modules. All of the above steps were called from NI TestStand using the command line and a serial link with the module.

Database Upload and Error Reporting
Each step above provides detailed error report such as:

(i) Boundary scan test vector table of net failures
(ii) Functional test details of a step failure
(iii) Boot process, parameter setup, and detail checks

All of the above reports are combined and saved in a central network location. The errors are saved and uploaded into the company-wide database for tracking the modules, errors, and yields on any particular processor module line.

Connecting Multiple Test Applications on the Factory Floor
NI TestStand provided many benefits while generating tests for implementation on the factory floor. NI TestStand is the modular sequencer that provides a common user interface for the multiple test applications with which our test operators are familiar. Using NI TestStand, it is easy to integrate code modules developed in LabVIEW software and in the C programming language. In this particular application, NI TestStand delivered a top-level interface through which we could execute low-level functional and structural tests. We used some of our previous codes developed in LabVIEW to connect to MFG/PRO database to upload results. It has also been easy to upgrade to newer versions of NI TestStand without having to redevelop previous tests. We routinely add and remove steps from our tests without spending weeks recoding the entire test procedure. NI TestStand also provides us an easy interface to include DLLs from the boundary scan solutions provider to integrate boundary scan tests developed in their proprietary software.

Advantages of the Test System
Before integrating the tests using NI TestStand, the tests were conducted separately and programming the modules was done manually. The entire test took approximately 35 minutes (approximately 30 minutes for manual programming and approximately two minutes for the boundary scan and removal and insertion of modules). This approach had a high margin for error because the operator had to manually enter about 20 commands in a specific order. Complete automation of the test process reduced the test time to less than 10 minutes. Additionally, operator input is now limited to the scanning of part numbers which permits the operator to perform other tasks.

Future Work
A complicated test process that included multiple tests involving constant operator interaction has been simplified into a basic pass/fail sequence for the operator. With this functionality, we have the capability to process large work orders. Operators can start the test and focus on other tasks as opposed to focusing completely on the test for 30 minutes or more. We also developed an architecture that supports multiple processor module families. In the future, test modification will be easy when we introduce new processor modules. A high percentage of the code is reusable for other processor families with minor only modifications.

Our future work will focus on increasing throughput and using the parallel testing and resource sharing capabilities of NI TestStand. Our final objective is to use the parallel feature of NI TestStand to test four modules in parallel and reduce test time to approximately 2.5 minutes per module. Present setup requires dedicated hardware, such as POD for boundary scan and Signum ICE for flash programming for each test instance. We plan to share a single POD and ICE for multiple parallel tests using the resource sharing capabilities of NI TestStand.

Author Information:
For more information on this Case Study, contact:
Sambit Panigrahi
Viking Interworks/ Sanmina-SCI
30200 Avenida De Las Banderas
Rancho Santa Margarita, CA 92688
US
Tel: 949-643-7255 ext 2271
Sambit.Panigrahi@sanmina-sci.com/ Sambit.Panigrahi@gmail.com

Browse All Case Studies »