C# and IronPython accelerate test development

The MSD/SLG division of Toshiba America Electronic Components (TAEC) is primarily focused on the design of IP (intellectual property) for custom and standard SoC products. We design and test a wide variety of products, mostly SERDES, but we also design video ICs, audio ICs, DC converters, and memory interfaces. 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.

Our previous automation software was written in 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), standardising the hardware interface, and developing a test framework (Validation Framework).

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.

Software domains
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."