As FPGAs grow faster and more powerful, our natural inclination is to scrape more and more functionality off our boards and cram it into our new, bigger FPGAs. It’s a strategy that makes good sense. Not only do we save board real estate, increase reliability, and cut bill of materials (BOM) cost, but we also usually improve our performance and, paradoxically, reduce our FPGA’s I/O requirements. In addition, we put more of our circuit into the “soft” arena, allowing future upgrades, patches, and variants to be made with only an FPGA bitstream change on the same hardware. We can even upgrade our customers’ systems in the field.
Of course, every silver lining has a cloud, and the cloud of increased integration is decreased debug visibility. That beautiful new state-of-the-art logic analyzer we bought a couple of years ago (going out on a limb with management in the process), isn’t much use to us if it can’t see signals inside our FPGA and correlate those to the more visible activity on the rest of our board. With that lack of visibility, nobody is happy – we can’t see what’s going on to debug our design, our FPGA vendor can’t sell us large volumes of chips until we get our design working, and our favorite test and measurement company can’t convince us to buy high-end logic analyzer gear that’s unable to see into the one place where most of our logic problems are located.
Tektronix, First Silicon Solutions (FS2), and Altera have seen that problem of course, and now they’ve worked together to make the debugging world a slightly safer place with their recent announcement of FS2’s FPGAView. FPGAView is a software application that bridges the gap between Tektronix TLA logic analyzers and Altera FPGAs, allowing you to trace your problems with your Tek TLA all the way from the board to the bug.
This is one of those rare cases when companies listened to us (their customers), rolled up their sleeves, and did some worthwhile cooperating to bring a very high-value capability to the table. Even though no piece of the puzzle involves radical or revolutionary technology, the three-way collaborative effort brings us a seamless solution to a very difficult emerging engineering problem.
“Lots of Altera customers were hand-building big muxes inside their designs to allow them to debug with a logic analyzer,” explains Phil Simpson – Senior Manager for Software Planning at Altera. “That was a very difficult and error-prone process. We developed the logic analyzer interface to simplify and standardize that approach, and to help handle tedious tasks like entering all the signal names into the logic analyzer interface.”
Tektronix TLA series Logic Analyzers are among the most popular and capable units on the market today. With up to 8GHz operation in timing mode, and 800MHz in state mode, you can isolate and debug timing and logic problems anywhere on your board, even in very high speed circuits. Until now, however, if some of those problems traced back to logic inside your Altera FPGA, your TLA’s fabulous capabilities ended at the FPGA’s pins, and you had to slip your sleuthing project into embedded FPGA debugging with something like Altera’s SignalTap.
The advantages of FPGAView extend far beyond unifying your debug environment in your logic analyzer, however. “Using FPGAView combined with Altera’s logic analyzer interface in timing mode, you can bring internal signals of the FPGA directly to the output pins,” says Mike Juliana, Product Marketing Manager for Tektronix Logic Analyzers. “This allows you to view signals at the full resolution of the TLA – up to 8GHz.” This provides a significant advantage over embedded logic analyzers which are typically state mode only, making it difficult to debug timing problems that don’t show up in static timing reports.
FS2 has long specialized in bringing the insides of your FPGA to the outside world. Several FPGA vendors use and resell their software and hardware solutions for embedded debug and embedded logic analysis. “FS2 had expertise and technology that were a perfect fit for this problem,” notes Rick Leatherman, Vice President and General Manager of FS2 (now a MIPS subsidiary). “We could apply our expertise in embedded logic analyzers for FPGA to create a very clean software-only solution.” In this case, FS2 provided the missing link between Tek’s primarily board-based logic analyzer world and Altera’s FPGA-based land of LUTs. FPGAView is a software application that is loaded into a Tek logic analyzer. FPGAView connects Tek’s TLA-series logic analyzers to Altera’s logic analyzer interface which was introduced in Quartus II version 5.1.
In order to use the system, you tell Quartus II that you want to insert one or more logic analyzer interfaces into your design at compile time. For each interface, you use the Altera’s Logic Analyzer Interface Editor to specify what signals you might want to monitor, whether you want timing mode or state mode, and what I/O pins you want to dedicate to communication with the logic analyzer. You’ll want to analyze your logic paths and think about the widest thing you might want to observe at one time, then use that number to determine the number of pins to allocate. Beyond that, you can mux-in any signals you want to watch at runtime without having to recompile your design. The logic analyzer block in the FPGA can be configured with up to 256 input banks of signals at the output width you specify from the I/O pins you select.
There are several advantages to this approach over the typical “embedded in the FPGA” debugging systems. First, in most of those systems you’d need to recompile your design each time you wanted to change the signals you were monitoring. Unfortunately, each recompile changes the placement and routing. With different placement, you get different timing and so the problem you were chasing might have shifted somewhere else. If your bug is timing related, you could end up chasing your own tail through a few iterations of recompiling for debug. Even if your problem isn’t timing related, the iteration time for each debug loop is much higher with a recompile involved.
Second, most “embedded in the FPGA” approaches use on-chip resources (like memory) for storing results. If you don’t have a lot of embedded memory left over after your design, you can be pretty limited in the depth of tracing you can store. Often, a problem only manifests itself after a long chain of events, so it can be difficult to store enough history to allow you to walk back from the symptom to the actual problem. Also, by using more on-chip resources you increase the overhead on your design for debug. You may then end up needing to pull the debug out for final production – a step which can make your design much harder to support in the field or in final pre-production testing.
Third, as we mentioned above, the logic analyzer approach allows full-resolution visibility of timing problems. Since most embedded logic analyzers offer state mode only, having the full-speed resolution of a high-end logic analyzer gives a big boost to your bug-seeking goggles. Most embedded solutions use only the JTAG port on the FPGA to move data back and forth. The ability to use normal I/O pins to communicate dramatically increases the speed of the debugging data transfer. Even though most FPGA designers seem to think they should be able to debug their designs with a couple of homemade bailing-wire probes, a roll of duct tape, and some WD-40, it really does save a lot of engineering time when you do your job with the proper equipment. Real logic analyzers may seem expensive, but that price is peanuts compared to the cost of talented engineers and days or weeks of time-to-market advantage.
Fourth, most bugs first show themselves somewhere outside your FPGA. Your system will be acting up, and you’ll go in and start debugging with your logic analyzer. If the symptom is complex, you’ll probably also invest some serious time setting up triggering events to help you catch the circuit in the act (like with your dog, it’s the only way you can teach them to behave). Since FPGAView allows you to continue your logic analyzer-based debug right into the FPGA, you can continue to use triggers on external signals and monitor activity inside the FPGA concurrent with the outside world. Otherwise, you’d have to figure out and set up completely new triggering conditions once you switched to your FPGA-based embedded logic analyzer.
Finally, (and it certainly doesn’t sound like rocket science, but it is extremely useful) FPGAView works with both the logic analyzer and the on-chip logic analyzer interface to automatically (and accurately) transfer the signal names from the design into the logic analyzer interface. Of course, you could type 500 or 1000 signal names in by hand (or buy your favorite intern a jelly donut and let them do it), but the process is tedious and error-prone. Besides eliminating a few hours of thankless work, this feature can save significant debug time by eliminating those embarrassing situations where you spend two days trying to find out why a signal isn’t triggering, only to realize that you were monitoring the wrong signal in the first place. (Don’t look so cocky, we know you’ve done it too.)
So far, Tektronix is the only logic analyzer supplier to announce support for Altera’s new interface, and FS2’s FPGAView is the only commercially-available way to hook them up. With the power this combo brings to bear, however, we wouldn’t be surprised to see more equipment vendors follow suit.
