The cost of implementing fixes increases as the development progresses, so you need to think about how you will test your hardware from day one.
One of the most exciting stages of an engineering project is when the hardware arrives in the lab for the first time -- ready for commissioning before integration testing. The downside is that this typically involves long hours for all of the engineers on the project, so how can we try and reduce this time and minimize the issues that may arise? Here are three suggestions:
1. Think about how you will test your hardware from day one. All engineers know that the cost of implementing fixes increases as the development progresses. For example, it is far more expensive to fix a pin-out error once the design has been fixed and manufactured than it would be during an early design review. This is exactly the same when it comes to testing -- thinking about how you will test the hardware from day one and what test equipment you might need will save you a lot of time and effort later on.
2. Think about what you need to include in the design. During the design of the hardware, several design features and functions may need to be included to allow testing of the board with greater ease. Perhaps the simplest and most often implemented test provision is placing test points on all voltage rails. Being able to monitor the outputs of clocks and resets is also important.
For this reason, it is good practice to place test points on the reset line, correctly terminate any unused clock buffers, and add test points allowing the clock(s) to be probed with ease. Many modern high-performance devices also have on-die temperature diodes that can be used during testing to determine if the junction temperature of the die is acceptable (provided you can access these points, of course).
3. Use simplified code. If you have a design that is complicated at both the board and the processor/FPGA levels, it may be best to develop a more simplified, cut-down version of the code to aid in the testing of the board and the interface between the processor/FPGA and the peripherals. This is especially true if you are designing high-speed interfaces. This cut-down code can be used in conjunction with a virtual logic analyzer like ChipScope to capture data.
Also, on-chip Block RAMs can be pre-loaded with data patterns to act as stimulus. When analog-to-digital converters (ADCs) and digital-to-analog converters (DACs) are connected to a processor/FPGA, the reprogrammable nature of these devices should be utilized to the maximum to develop designs which will allow parametric testing of the ADCs and DACs to facilitate things like NPR (noise power ratio), SFDR (spurious free dynamic range), and ENOB (effective number of bit) calculations. You should also aim to capitalize on the resources provided by any FPGAs, such as the system monitor and XADC in Xilinx FPGAs, which can be very useful for monitoring the voltage rails on die and hence helping verify the power integrity of the design.
What if the initial testing does not go to plan? The first thing is to not panic. Oftentimes you will not be the first person to face a particular issue (although it may feel like you are). Revisit the design schematics, layout, and read the data sheets and any erratas again. Also have a look on some of the very helpful websites like the EE Times DesignLine.