A validation engineer’s core task is to develop the measurements required for the device. When developing a typical measurement, they often hardcode the input parameters within the measurement code. When another engineer or team validates a similar device, they must copy the code and customize the measurement code to fit the new device. This involves a lot of code change and requires complete code testing, adding time, effort, and cost.
Ideally, the framework would abstract the measurement IP development with input parameters and sweep parameters for reuse, whether in another device in the same family or a different device with the same silicon IP. Then, other engineers can use the reusable measurement IPs in the automation to run multiple measurements on the same device and sweep over different test conditions such as temperature and input supply. Reusable measurement IP reduces measurement development/debug time for a similar device or family, saving time and cost and accelerating time to market.
Sweeping and Looping Conditions
A comprehensive device validation requires making measurements over many conditions to ensure that the device functions within specifications. So, the validation engineer should run measurements across many process, voltage, and temperature (PVT) conditions, requiring a flexible, robust automation framework. The validation engineer should be able to configure, change sweeping conditions on the fly, and run the automation effectively without any measurement IP code change. Within the framework, you should be able to configure the parameters over which the measurements must be swept:
- Easily configure the range of values for each sweep parameter both individually and comprehensively in a nested sweep
- Quickly generate sweep values based on a distribution and visualize the conditions
- Automatically log the sweep conditions along with the measurement data
When the sweep parameters are abstracted from the measurement module, you can develop reusable measurement IP and promote collaboration between teams.
The test sequencer is the core part of automation and data collection. The validation engineer’s objective is to string together the measurement (from the Measurement IP Library) developed for the DUT and run the measurements over PVT test conditions. The validation engineer should be able to do this quickly without a lot of software development. The framework’s test sequencer is an easy-to-use tool with a low training barrier. Use the test sequencing environment to:
- Sequence tests using drag-and-drop actions and quickly configure input.
- Create instrument and device configurations in the debug/ interactive environment.
- Configure and save all PVT conditions in the integrated sweep condition manager.
- Quickly run tests and get to data in the default .csv integrated data log module.
- Accelerate data collection over multiple DUTs in parallel with multisite testing.
- Customize development with advanced programming language features such as loops and statements.
With NI TestStand test and measurement management software, you can develop, debug, and deploy measurement sequences in one standard off-the-shelf solution—develop multithreaded sequences, support any programming language, generate reports, and log to a database. Industry-leading validation organizations don’t waste valuable time and engineering resources developing and maintaining software solutions that don’t add value back to their product designs. Instead, working with a software expert like NI empowers teams to spend more time on measurement IP, analyzing device performance and providing design feedback with a turnkey test sequencer.
Hardware Abstraction and Measurement Abstraction
Often, validation labs use different instrument models at different sites or benches. In these cases, the measurement code developed at one bench cannot be reused in another. Each bench has its own measurement code; hence, test measurements are fragmented and not reusable. A hardware abstraction layer (HAL) solves this problem by abstracting the instrument information from the measurement code.
For example, Bench A might use an NI SMU to power up the DUT. But Bench B uses a benchtop power supply. Without HAL, each bench requires custom measurement code to power up the DUT, and the power-up sequence is nonreusable. With HAL, though, the measurement author just calls the top-level parent APIs in their implementation. The choice of hardware rests in an interactive configuration on the Instrument Pin Mapping screen.
Figure 3. Test Sequence Abstraction Layers
Reuse Measurement IP
Developing measurement modules over HAL and digital communication modularizes the specific dependency. These abstractions promote modular and reusable measurement IP development, reducing development and testing effort.