Home>Characterization Test Center>Test How-To
The underlying test code
By Staff- June 1, 2006
Norman Kirchner recently joined Texas Instruments’ Wireless Terminals Business Unit (Dallas, TX) as a software infrastructure engineer. He supports and writes infrastructure software that characterization engineers around the world use to evaluate new products utilizing LabView and TestStand. He has extensive LabView programming experience, having previously worked at Engineering Specialists (Brookfield, WI), a test-system integrator. While at Engineering Specialists, Kirchner participated in a T&MW-sponsored panel discussion on the topic of test-system planning; we covered the discussion in our February 2005 issue (“Test-system development: Do everything first,” p. 33.)
Q: How do you support characterization engineering?
A: Software engineers are an integral part of the characterization team. We write software that characterization engineers use to take measurements on ICs for wireless consumer products. The parts use a variety of technologies including Bluetooth, 3G cellular, and wireless LAN. The functions of those devices range from single-chip analog-to-digital converters (ADCs) to full-level SOCs. I work with TI engineers around the world to develop the software that will be used by a global characterization team.
Q: What's the procedure for developing code?
A: We work with design and characterization engineers to learn which measurements they need for a specific part. The characterization engineers take the part's specifications from design engineering and define the high-level measurements. Next, we look through a library of existing measurement routines and try to use prewritten and validated code wherever possible. We may also modify prewritten code and adapt it to a specific task.
The code modules do more than just control instruments and collect data. They perform data manipulation and post processing, producing measurements such as group delay and digital-to-analog-converter (DAC) linearity. Software engineers write code at their desktops and upload the software to a central source-code control server, making the new software available to test systems located around the world. We can remotely control any test system from our desks, so we can test the code on the system where it needs to run.
Q: How do you know if you have code that's appropriate to reuse in a test?
A: We keep a log of measurements taken by each code module. We also keep a list of supported instruments and the measurements they make. Experience helps in finding the best code module. We are looking toward automating the selection process to decrease the time and experience needed to design a test sequence.
Q: Do you write the entire test code, or does the characterization engineer get involved?
A: We write the software modules that make the measurements and compile the test results. We've also developed what we call "universal instruments." These are generic software modules for controlling generation and capturing instruments. A characterization engineer configures the universal instrument and it calls the underlying test code, which executes the necessary instrument drivers. The universal instrument software allows the measurement software to not care which instrument is behind it. Characterization engineers then use TestStand to define the sequence and configuration of the measurements.
Q: What challenges do you face in writing test code?
A: The biggest challenge is in designing software modules that fit a wide variety of requirements so we don't end up writing unique code for every part. For example, a module that calculates frequency response should work with a variety of instruments at frequencies from audio through RF.
