The process starts with the silicon vendor providing the test procedure and software API to the test vendor. Development then takes place to integrate the API with test equipment. The next stage is to verify solutions with DUTs. Iterative releases to the silicon vendor allow for qualification and test. The silicon vendor then verifies a final solution before the test vendor makes the release.

This process ensures that the test engineer can begin testing, safe in the knowledge that the tests are appropriately configured for the device and the test equipment setup. It also ensures that the individual test steps have been previously optimized for test speed, removing the need for end users to undertake this themselves. Figure 1 illustrates the automation core of the software.

Such a software solution differs from that of some test equipment vendors that provide the tools to complete the solution, but have no validation or endorsement from the silicon vendor. Indeed, some software is developed separately from, and against the recommendations of, the silicon vendor—introducing unnecessary risk into the success of the RF testing.

Such a software development route typically is aimed at obtaining fast test and is detrimental to compliance with recommended standards. A better RF testing strategy is to use qualified solutions, obtain relevant RF and test time data, and then use this information to refine the test plan to reduce test time.

Flexible Use Models

Given that the off-the-shelf software is intended to be the only tool developed by the test engineer, it is essential that the software be controllable and accessible, meeting a variety of test use models. Figure 2 shows an example of a chipset-specific solution offering a choice of two different automation use models.

For instance, the engineer may wish to begin with laboratory benchtop testing, characterizing a DUT and performing trial calibration tests. This can be achieved via a simple command line interface that allows for a basic runtime DUT configuration and test plan execution (Fig. 3).

Depending upon the engineer’s exact test requirements, a command line interface offering a degree of test automation is the goal for low-volume device testing. Figure 3 shows the final solution, where the test engineer directly accesses the command line interface tool within the supplied software.

Once benchtop testing or low-volume sampling is complete, the engineer may then choose to integrate the software into a test executive for full automation. This is a major consideration for contract manufacturers setting up product lines and seeking to test a high volume of devices.

Full automation is achieved by using the API model in Figure 3. The API model is essential for embedded devices like mobile phones that will require initial setup to be configured on the multi-functional device to enable the wireless part to be tested.

Looking at the high-level architecture of the software (Fig. 2, again), no matter what use model is chosen, the test plan automation still uses common optimized test steps. These are optimized for test speed, RF performance, and conformance to requirements, specifically designed for efficient communication between hardware and software.

Task-Oriented Programmable API

Most test engineers focus on automating the test software, requiring the use of a programmable API for integration into a test executive. It is important that an API provides:

• Maximum flexibility
• All available API calls for setup parameters, removing the need for any external files, e.g., text files
• Access to test points to control settings, limits, and sequences, while preserving the correct and optimized test algorithm
• A passing of test validation responsibility to the test engineer (given that core algorithms and tests are approved by the silicon vendor)
• Tasks oriented around the test of the specific chipset
• Testing of embedded devices
• Tailoring of tests and storing of results; Figure 4 shows a typical example of a log file that may be generated as well as how individual measurement results can be customized, exported, and displayed graphically
• Use in a range of programming environments
• Operating-system neutrality

Full Test Lifecycle Reuse

With software validated by silicon vendors and consisting of full test plan calibration and verification, R&D-type testing may also be performed. A well-designed API and software architecture with reusable libraries allows test engineers to use software with a variety of test equipment hardware.