C# and IronPython speed test development

C# and IronPython speed test development

Technology News |
By eeNews Europe

Engineers in our lab validate individual IP blocks and perform some spec testing to industry standards such as PCIe (PCI Express), SAS (Serial-Attached SCSI), SATA (Serial ATA), and DP (DisplayPort). When the time came to update our validation software, we decided to develop a new application in house rather than hire a third-party developer.

The lab automation software we previously used National Instruments LabVIEW. The application software consisted of a GUI, LabVIEW code, and a Microsoft Excel file used for register descriptions. Several problems were inherent in this system:

  • The whole system was developed by an outside vendor.
  • The GUI was project specific, so a new GUI would need to be developed for each project.
  • Re-development was expensive in both cost and time.
  • There was no ability to run custom scripts.

The old system worked well for manual debugging and "twiddling" of registers or settings, but we needed more. Once the decision was made to pull the development in-house, the team developed a rough sketch of requirements:

  • The new system must be generic enough to account for the majority of the division’s products.
  • It must be able to handle small to large projects – device under test (DUT) register sets from 100 to several thousand.
  • Maintain the ability to perform manual debug.
  • Add the capability to run custom scripts.
  • Ensure capability to generate scripts rapidly.

After a bit of research, we chose the architecture shown in Figure 1. This involved creating a C# GUI and infrastructure (C# Domain), instantiating an IronPython script interpreter (IronPython/scripting Domain), standardizing the hardware interface, and developing a test framework (Validation Framework).

Figure 1. The new software architecture uses C# for the user interface and IronPython for running test scripts.

Hardware and equipment
The lab is set up so that each test bench is independent and self-contained. This means each bench has a networked PC with all necessary software installed. All instruments are connected to the PC via GPIB, RS232, or USB. Although LAN connections have been avoided thus far, they can easily be accommodated through VISA (Virtual Instrument Software Architecture). The system also supports a non-internet-connected network should it become necessary.

The connection from the PC to the DUT (known as the register space) is accomplished in one of two ways: through an FPGA communications board, or an off-the-shelf communications board. The custom FPGA board we developed can communicate through I2C, SPI, or a custom parallel interface. Sometimes, our parent company requests a specific device to accomplish the PC to DUT connection, and this would be used in place of the FPGA communications board.

GUI/C# domain
The GUI (Figure 2) is a fairly simple C# winforms project. There are two main features to the GUI:

  • The script interface which is a portal into the IronPython scripting domain (discussed in the next section),
  • The "clickable" controls (i.e., text boxes, labels, etc.).

On starting the GUI, the user is presented with a (mostly) blank window. From the File menu, a user can choose to load a register definition file (a "spec" file), which is an Excel file with a simple structure defining register addresses, names, bit locations, etc. In this example, we’ve selected "spec_SD43_v2.xls."

Figure 2. The user interface gets configuration data from a "spec" file, then it gets specifics on a DUT and its test from a register file, both of which are Excel spreadsheets.

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 labeled 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.

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.

If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :    eeNews on Google News


Linked Articles