Here are some quick FPGA pointers

• Be very clear on what sort of reset, asynchronous/synchronous you want. An asynchronous reset in clocked logic can result in your whole design becoming one big metastable input
• Often a reset is not required. Most FPGAs upon start up can have their initial contents specified for signals (i.e. signal bla : std_logic:='1';). Doing this removes one signal form almost every LUT in your design, removes the net with the biggest fanout and removes other reset timing problems. Don't feel as though you NEED to have a system reset pin. This can be done through the FPGA programming interface if really required (A well designed system and FPGA should not really need a reset).
• Understand metastability (That is where a changing asynchronous input is sampled and its result can stay in an undetermined state). The undetermined state is an obvious problem, however the instance where due to logic structure the 'same' signal actually resolves differently in two different places in the design on the same clock edge can cause all manner of problems. This is easy to accidentally do as in:

• Specify timing constraints: Especially on clocks and any timing critical IO. If you don't your system may not meet timing and you'll not realise and spend a long time tracking down odd behaviour.
• If you don't care what a signal is, then say so. The implementation tools can take advantage of this and specify what would result in the fastest or the smallest implementation. i.e. if b='1' then a <= X"01"; elseif c='1' then a <= X"10"; else a <= "XXXXXXXX"; end if; end if;

• Count to a predefined number, initialize to a arbitrary one. Often this means counting down to zero. This results in a smaller fan in on the comparison and thus lower propagation delay, and higher speed.
• Clock as slow as you can. This makes your life easier and reduces power consumption.
• Pipeline. Pipelining improves thruput. Its harder to think about, and does have complications, but can make higher clock speeds easier.
• Plan your pinout BEFORE committing to a layout. Too often the FPGA firmware developer is badgered into picking a pinout so the hardware can be built. RESIST! There is nothing more annoying than trying to make a design work with pins, clocks in the wrong place on the package so the propagation delay is increased. Pay particular care with VREF, VRN and VRP pins. Realizing you've missed these can ruin your day. Ideally generate a design with a proposed pinout to check for any problems.
• Where you can allow the PCB layout guys to swap pins. It is equally annoying for the PCB layout engineer to fan out a mess of an FPGA pinout which when all is said and done is arbitrary. You'll have better tracking, better decoupling, better signal integrity.
• Reduce the number of signals contributing to any other signal. This reduces fan in, fan out. Thus reducing propagation delay and power consumption.

In preparation for manufacturing a large number of Snapper CL15 modules, we have been developing an automated test system for quickly and accurately finding assembly faults in Snapper CL15 modules.  The test system will be sent to the manufacturer so that the modules can be tested and, if necessary, repaired at the point of assembly. In the past we have used our Autotester software, combined with a Rig 200 baseboard for testing Snapper modules.  While this approach works reasonably well, it has a number of limitations which make in unsuitable for this task:

• It is too interactive.  Many of the tests require user interaction or confirmation. For example, the audio test requires the user to confirm that a sound was played correctly, and the USB tests require the user to insert and remove a USB device.  For large builds this interaction becomes both tedious and error prone.
• It cannot accurately find faults.  A failed test in the Autotester only tells the user which sub-system is faulty, but not where the specific problem is. For example, the video sub-system of the Snapper CL15 comprises of more than 20 pins, but a failed video test in the Autotester does not give any information about which of these may be faulty.
• The Rig 200 baseboard does not expose all of the features of the Snapper CL15 in an easy to test way.  While the major features of the Snapper CL15 are accessible on the Rig 200 baseboard, many of them require some additional hardware to actually test the functionality.

To solve these problems, we have developed the Snapper CL15 test jig.  The test jig is a standard Snapper CL15 baseboard which has been designed to fully automate the testing of all of the Snapper CL15 features. In the event of a failure, very specific information about the nature of the fault, often referencing a single pin, is given. The problem of requiring external hardware for testing some peripherals is solved by having an FPGA which can monitor and drive pins on the Snapper CL15. The FPGA enables tests which previously required user interaction, such as video test, to be fully automated. For the video testing, the Snapper CL15 runs an application which configures a video mode and displays a test pattern.  The FPGA has registers which contain information such as the number of clocks per line and the sum of the pixel data in the frame. The software running on the Snapper CL15 can verify that this information is correct. Many of the test procedures use loop-backs so that no user interaction is required. For example, the audio tests, which in the Autotester setup required a user confirmation that sound played correctly, loop the line-out to the line-in via an analogue switch. After initially testing that the left and right capture channels are working correctly by feeding a 1kHz (generated by the baseboard) to them, the line-out and high-power out are tested by looping them back to the line-in and comparing the captured audio with what was played. The test jig system will be able to fully test a Snapper CL15 module in around 2-3 minutes, with no user interaction other than insterting the Snapper CL15 module and checking the result of the test. Because the information about failures is highly specific, it enables the manufacturer to quickly find and correct any assembly faults with the modules.