Your board bring-up team is trying to verify the prototypes of a new product so it can move into manufacturing, but they’re stuck and it looks like the product’s going to be late to market. The team can’t perform its functional tests on the board’s serial interfaces like UART, SPI and I2C because the system’s functional software is not ready yet. It’s stuck in development.
Here’s are a few test methods that can un-stuck the board bring-up team. You can perform at-speed functional verification tests on the serial interfaces without – I repeat: without! – the system’s functional software.
With boundary-scan (JTAG) and an embedded instrument IP inserted into an on-board FPGA you don’t need the functional software to do your functional verification tests.
First, you might want to start with regular boundary-scan tests to eliminate problems with at the physical or structural level of the board. Boundary scan will let you know about any shorts and opens on the interfaces and interconnects, plus it will verify the electrical connectivity on the interfaces. Beyond the physical level, you’ll want to do at-speed functional tests. For these you’ll need the FPGA-inserted embedded instrument IP. Specifically, you’ll need a communications master for the interface you’re testing, like a UART master, for example.
Another benefit of using an embedded instrument IP in an FPGA is you’ll be able to re-use the IP on other designs that have the same FPGA. It helps tremendously if the instrument is compatible with the IEEE 1687P Internal JTAG (IJTAG) standard because then you’ll be able to insert other IJTAG-compatible instruments into the FPGA to do other sorts of tests too.
Once you have the serial port’s communications master IP inserted into the FPGA, you can control it through an IJTAG tool like ScanWorks. (See the figure below.)
At-speed testing of a UART interface from an embedded instrument in an FPGA
The last step involves establishing some sort of transmit/receive communications originating in the FPGA and directed to the UART or other serial interface. A simple thing to do is to query the target device for its identification data like serial number, manufactured date or software version. If you get this information and it’s correct, the serial interface is working fine.
Of course, there’s a little more to this than I’ve outlined here. If you’re interested, we’ve just published an eBook on the topic. Check it out.
