A few seconds in the real world can bring more insight than days, weeks, months, or even years of simulation. However, FPGA reprogrammability is not a panacea. Without the right amount of upfront FPGA validation planning, reprogrammability can be a liability instead of an asset.

Systems employing FPGA technologies follow an iterative design methodology for ensuring a design operates as intended. Turns require no NRE fees and if all goes well, finding and fixing a problem can be done in less than a day. Reprogrammability fuels the tight iterative link between the virtual design world and real world. Experienced design teams wield the power of determining what circuit behavior can best be checked in simulation, and what behavior can be best checked in the real world.

With the knowledge that FPGA designs can be rapidly changed and recompiled, designers sometimes falsely assume that the reprogrammable nature of FPGAs, in and of itself, will allow for efficient debug. This thinking can lead to significant guesswork, weeks of lost time, and hundreds of design iterations.

While recompiling an FPGA can be done rapidly, finding design errors between large and fast FPGAs and the surrounding system can be daunting without proper upfront planning. I recently talked to an ASIC designer developing his first FPGA. He did not follow the rigors of putting hooks into the design to allow for easier debug. Rather, with easily changeable FPGA technology, he expected to be able to use his intuition to quickly find and fix design problems.

Complex internal interactions that didn't behave as anticipated surpassed this engineer's instinct. The design team went through numerous iterations without any progress on finding the root of the problem. Intuition was not sufficient.

In the early development stage, designs must incorporate a methodology that will ensure a debuggable design. A little debug forethought can shave weeks or months off of development time. Early in the design phase is where teams determine how debuggable the design will be. Here are some key questions that affect how debuggable the design will be.

1. What size FPGA will I use? A rule of thumb for new designs is to use an FPGA twice as big as you think you will need. FPGAs with extra resources will make recompilation faster with less effort required to meet timing objectives. This can speed the iterative design and validation process. As well, they have extra resources to implement on-chip debug IP if needed. Forward-looking the extra size allows for feature additions and defect fixes.

2. How many pins will I dedicate for debug? Ensuring adequate internal visibility can significantly reduce guesswork. At a minimum, the number of pins should be the width of the widest bus that will need measurement. Having dedicated debug pins is a bonus for future generations of the design. The dedicated debug pins over time can be used for feature additions.

3. What types of measurements will I need to make? While simulation generally uncovers most synchronous problems specific to the FPGA design itself, simulation falls short at testing unexpected corner cases, defects resulting from interaction with the rest of the system, and parametric signal issues.

Oscilloscopes and logic analyzers make ideal tools for most in-circuit measurements. The tools vary greatly in acquisition capability and the types of visualization capabilities available. For example, you might determine that you need to be able to trigger on corrupt protocol packets and view the resulting measurement in a protocol context. Selection of a logic analyzer with this capability can save days to weeks of time per project. Thinking about what types of measurements may be needed and having the right equipment to make these measurements can go a long way.

4. How am I going to connect my design to measurement tools? While the best anesthesiologist would be useless without a needle to deliver vital drugs, the best test equipment is useless without reliable, accurate, and usable probing. However, designing for probing connectivity must be forethought and not afterthought. For example, without adjustment to the board layout, probing a soldered BGA package is impossible. With a little board layout planning, a set of vias can be put on the board to connect with innovative connectorless probing like Agilent's soft touch technology.

5. Do I want to instrument my design to make debug easier? This may be as simple as implementing a user-defined mux to allow selection of signals to the debug pins. Or, it could take the form of an of-the shelf core such as logic analysis or stimulus. There are several EDA tools that allow instrumentation of the design in a way that small buffers of information can be collected at a wide number of nodes in the design.

Because additional circuitry is created internal to the FPGA, this circuitry essentially becomes part of the design itself. For this reason understanding the tradeoffs and designing with these debug technologies in mind will increase the probability of efficient debug.

Like a scratched record that repeats itself, the iterative nature of FPGA debug can result in speculative guesswork without proper planning. Planning for proper visibility and debug insight during the design phase helps ensure quality designs have timely releases.

Steve Warntjes is R&D Manager for the Design Verification Division at Agilent Technologies.