All engineers know it is more expensive to fix a pinout error once the design has been finalised and manufactured than during an early design review. This is also true for testing and integration; the earlier the design engineer thinks about how they will test the hardware and write the specifications, the easier it becomes to include the necessary test points, hooks and functionality.
The aim of testing is to ensure a safe system is delivered that meets the specified requirements. Each requirement must therefore be demonstrated by test and functional test requirements should be flowed down and traceable to the design requirements.
It is good practice to compile a design verification matrix that details how each functional requirement is to be tested – for example, by test, by analysis or by read across (see table 1). This document may also show which tests are proof of design and which are to be used for the production run. Completing these documents early will ensure that system design and test equipment teams have a baseline.
However, before functional test, design engineers must be satisfied that the underlying hardware is correct. This will typically require a hardware level test specification including voltage rails, performance and basic hardware verification – with the latter performed before functional testing.
Decide what test equipment is needed and what performance is required? Do the pattern generator and logic analyser have sufficient storage depth and operating frequency? Will specialised test equipment – such as an arbitary wave generator – be required?
During hardware design, engineers may need to include features and functions to allow testing of the board with greater ease. The simplest approach is to place test points on all voltage rails. It is also good practice to place a pad connected to the ground return close to the voltage test point; protecting this with a high value resistor will limit the current that could flow if shorted during testing. Test pins could also be added to these pads to support automatic test.
Monitoring the outputs of clocks and resets is also important, so it is good practice to place test points on the reset line. Make sure you terminate an unused clock buffer correctly and add test points, allowing the clock to be probed. Then consider adding test ports to enable signal injection and extraction.
To aid with power budget closure, place low value resistors (10 or 100m?) in series with the output of the voltage regulators, if possible. This will enable accurate determination of the current drawn by a rail.
For the first build of a new product, a decision might be made to decouple the power supplies from the downstream electronics. In this way, the engineer can establish the power supplies and sequencing are functioning correctly, reducing the danger of overstressing or damaging downstream components.
Another early design stage is to ensure the JTAG port can not only be used for programming, but also for initial verification of the hardware; something useful in retiring hardware design risks early in the test phase. It does require the design to be optimised to ensure maximum coverage of boundary scan devices.
When the system arrives in the lab, the first thing to do is determine that the module underlying the hardware is acceptable to progress to further testing. Checks will include the initial power-on, which can be tense. Ensure that it has been manufactured correctly before applying power; all components in their correct positions, with pin 1 oriented in the proper position, and polarised components correctly placed.
Once the PCB's population has been checked, it's time to power the board. However, the test provisions made during the design phase will be of great assistance. The first step is to ensure the power output of point of load and other regulators is not shorted to return. Low impedances may be seen on rails which contain devices with a high-current demand. However, the impedances should be greater than 1?.
Provided no rails are shorted, the next task is to apply power, with a two stage approach favoured. The first stage applies 0.5V at a low current to ensure shorts have not been missed between planes or voltage rails. The next stage is to power up the design at the correct working voltages and with the current limit set appropriately – don't forget to account for inrush current.
Having applied power to the design, the next job is to see that the power rail sequencing, reset and clocks are working as intended. Remember to ensure the reset duration extends past all clocks and becomes stable prior to its release.
The next stages are to ensure the hardware can be seen via the JTAG chain. This can help with the quick test of interconnections between devices; test memories, to ensure they function correctly; and loop back inputs and outputs, provided loop back connectors are developed. JTAG and boundary scan testing can remove much of the risk from a design before progressing to more detailed testing.
If a design is complicated at the hardware and FPGA levels, it can be helpful to develop a simplified version of the RTL to aid in board test and the interface between the FPGA and the peripheral (see fig 2). This streamlined RTL could, for example, be used in conjunction with the Xilinx ChipScope tool to capture data, along with Block RAMs that have been preloaded with data patterns to act as stimulus. This tactic is especially helpful when using A/D and D/A converters connected to an FPGA. Here, the FPGA's reprogrammable nature should be used to develop designs that will allow parametric testing of the data converters.
On many occasions, using a simpler RTL design and the resources provided by the FPGA can help to pinpoint an area that is not functioning as intended.
Things might not function as intended or fail to meet the functional performance desired. Do not panic – there are a number of ways to determine the cause and the required corrective action.
Resist the temptation to change anything. Revisit the design – particularly the schematics, design information and data sheets. If it is an FPGA related issue, check whether the pin constraints file ties up with the design; it is possible the file may have lost synchronisation.
If nothing jumps out as obviously wrong, use web forums to see if other engineers have encountered the same problem – Programmable Planet and Xilinx forums provide support for FPGA based designs.
Commissioning hardware can be one of the more challenging aspects of engineering, but thinking about test early in the design stage – and including test facilities – can ease the commissioning process.
Adam Taylor is head of systems engineering with e2v.
