C# and IronPython accelerate test development

When the user selects a spec file, the GUI will dynamically populate the window with the "clickable" controls specific to the file loaded. Clickable controls include the tabs labelled PLL, TX_LVDS, etc. The spec file defines the names of the variables that hold settings for the DUT. For example, spec_SD43_v2.xls contains the names of data variables and the register addresses where they reside. LS_HSEN, for example, uses two bits, 0 and 1. LS_EN uses bit 4 only. Note that LS_SEN uses bits 0, 1, and 2. Those bits reside in a different address and thus don't conflict with the LS-HSEN bits.

Once a "spec" file is loaded, a user can manually enter values into the GUI, which allows for debug or for wringing out details of a test. To begin a new test, a user can power-on reset the DUT, then load a "default registers" file to get the DUT to a known starting point. The "default register" file is another Excel file that adds the register values to the fields in the right column of Figure 2. Each test has at least one default register file. Finally, a user can execute the IronPython test script using the loaded register values.

Scripting/IronPython domain
The entry point into the scripting domain is through a dedicated text box (multi-line) on the GUI. Commands are typed (or pasted) into the text box. When the user presses the enter key, the commands are pre-processed by the C# code. Commands are then either executed directly in C# or passed to the interpreter. A user can enter a path and filename for script files, a path and filename for default register files, individual IronPython commands, or individual DUT commands (register write, register read, etc.).

The C# project has objects instantiated for VISA, serial port, communication device (FPGA board), etc., as well as an instantiation of the IronPython interpreter. All scripts in the IronPython domain have access to the public C# objects (VISA, serial port, FPGA board or communication device, etc.). All scripts have full access to the .NET libraries, and the IronPython interpreter accepts (and interacts with) objects created in the C# domain.

Validation framework scripts
In addition to the system described above, we developed a scripting framework that handles all the loops and features needed to fully automate tests. This framework includes looping through register settings, temperature cases, supply cases, addresses of equipment, errors, status, and the like. Through the framework, scripts can be rapidly developed as the developer only needs to focus on the steps necessary for executing the test. The framework also provides IronPython objects for most of the commonly used equipment (usually just wrappers around SCPI commands, but includes error processing as well).

Each individual test consists of a user test (usually just a single file) and the included framework files (included in a user test with one line of code). After including the framework code, a developer of a test is only required to instantiate several methods (procedures) that the framework will call. This would include code to execute before and after a test (setup and cleanup), as well as the actual test for each temperature, power supply, register setting, etc.

Conclusion
The system is easy and quick to configure. That makes bringing up a new test faster and easier that with the previous system, which has increased the TAEC lab's throughput. The automation capability, coupled with the interactive debug capability, has even brought designers into the lab for heated debug and redesign efforts. Lastly, the validation framework has greatly cut test development time through its ability to re-use code across projects.

About the author
Daniel Galaba contributed this article.

   1 • 2