Death, Taxes, and Debug
Dealing with Life's Certainties

They say that there are two things we can count on in this life. For chip designers, the list is just a little bit longer.

In the early days of FPGA design, you may have been able to “spin” your way around debug a bit – tempting fate with a devil-may-care attitude - burning and turning your design several times in one day and never slowing down to plan a “verification strategy”, but not any more. These days, your FPGA designs are too complex for that dance. You no longer create the bulk of your design from scratch, zooming through debug almost without looking at the HDL code you knew better than the back of your hand. Instead, you’re moving your system onto your chip, often in the form of large blocks of commercial IP, the contents of which may be a total mystery to you. Your FPGA is now officially a system-on-chip design, or FPSOC.

From a debug perspective, things just got a little trickier. On the hardware side, you’ve been dialed in for a while now, using a virtual logic analyzer to peek into your device and see what’s going on. Life’s been good. You’ve been able to easily and effectively locate and eradicate those pesky bugs. Those skills and tools will continue to be valuable, but now that you’re embedding complete systems in your FPGA design, you need to expand your debug strategy to consider the entire system, including (dare we say it?) software.

The design team for an FPSOC is usually larger and more diverse as well, with a mix of software and hardware experts working (not necessarily together) to complete the design. The software engineers – who probably outnumber the hardware engineers by about four to one – usually work in C code, using a software debugger, stepping through their design one line at a time to make sure that the system is operating properly. On the other side of the building, the hardware guys are using their HDL-based hardware tools and logic analyzers to perfect their part of the design. The only link between these two engineering camps may be a system architect, who is responsible for ensuring that the entire system is coming together and meeting the overall design goals. So, what happens when the system architect encounters a higher-level system problem and he can’t figure out whether the issue is in hardware or software? That’s when the fun starts. He has to bring together the software and hardware engineers to solve the problem, using different debug tools that aren’t connected to one another. Cue the finger pointing…

Two Worlds Colliding

Several FPGA and tool vendors have seen this problem, and have created embedded system debug solutions, and some of their solutions even connect the hardware and software worlds.

Xilinx offers the Xilinx Platform Studio. They took their ChipScopePro logic analyzer for hardware debugging, and a GNU-based software debugger, and created a way for them to speak to one another using cross triggering from one domain to the other. Their integrated hardware/software debug environment, called Platform Debug, creates a neutral zone where hardware and software engineers can access one another’s debugging capabilities to solve issues more efficiently. For example, if a hardware designer is experiencing a system hang-up at a certain bus cycle and can’t get past it, he can set a break point or a trigger event for that bus cycle, and then cross trigger the software debugger to turn on when it reaches that point in the hardware cycle. The software debugger turns on and shows you what the software is doing before and after that point. The software designer has the same flexibility. If his system goes off into the weeds at a certain point, he can cross trigger the hardware debugger to see what’s going on in the hardware.

The Platform Studio takes a wizard-based, menu-driven approach to lead you through the design, automating many of the otherwise manual tasks associated with embedded system design. “Our goal with the Xilinx Platform Studio was to create a comfortable environment for both the software and hardware guys, particularly for debug,” said Jay Gould, product marketing for embedded tools at Xilinx. “The software engineer may just want to change one line of code, and they don’t want to deal with HDL. Our platform domain provides that flexibility.”

The Xilinx solution uses one integrated JTAG probe to run the entire set of hardware and software downloads and facilitates debugging without having to swap out cables.

Altera’s offerings for hardware and software debug are not packaged together. On the hardware side, their SOPC Builder leverages the conventional JTAG approach, with a twist. If you want to engage, for example, in multiprocessor hardware debug with their Nios II embedded processors, the tool creates a “JTAG hub” inside the FPGA that allows you to talk to as many processors as you have in the device at the same time. When you run the Debug Module within SOPC Builder, you can choose from five different levels of debug depending on your needs: the first level is no debug; next, you can choose a basic JTAG connection to download software and have basic run control and some breakpoint functionality; the third choice gives you two more hardware breakpoints and two data triggers; the fourth adds instruction trace using on-chip trace; and the fifth choice adds to more hardware breakpoints (for example, if you want to debug some code stored away in ROM or FLASH), and two more triggers, plus data trace and off-chip trace. As you choose your level of debug, you are essentially making capability trade-offs that will use more or less logic in the system.

“A lot of customers will throw all of the bells and whistles in when they’re doing their development board, then when it comes time to ship the product, they pull it all out to conserve size,” said Bob Garrett, senior product marketing manager for the Nios II at Altera. “At that point, they may even be able to go recompile for a smaller device.”

On the software debug side, Altera’s Nios II Integrated Development Environment (IDE) provides a complete environment for editing, building and debugging. Altera also offers partnership connections with third-party vendors including Accelerated Technologies, First Silicon Solutions (FS2), and Lauterbach for some of the higher-end debugging capabilities.

FS2 is a company that was founded on the premise of providing solutions for embedded debug with a concept they call On Chip Instrumentation (OCI). Founder and CEO Rick Leatherman suggests thinking about debug at the beginning of your design process, not just for ASIC design, but also for FPGAs. He indicates that more than half of the designs they engage in have multiple processors, including cores such as Altera’s Nios, commercial or proprietary DSPs, and specialty processors.

FS2 OCI solutions integrate IP, hardware, and software to access and analyze designs. Their Configurable Logic Analyzer (also marketed by Actel as Logic Navigator) allows access to any embedded signal, and is the cornerstone of their system solution. The FS2 Processor In-System Analyzer (ISA) is like a debug block for processors. It knows how to start and stop the processor, single step, read/write memory, etc. It also has more advanced features for SOC design, including sophisticated triggering and trace capabilities. Their On-Chip Bus Analyzer provides access to embedded bus signals. Finally, their Multi-Core Embedded Debug allows system cross-triggering as well as trace synchronization.

FS2 sees the Processor ISA as a strong added value to a traditional debug environment. “If you’re doing an embedded processor core in an FPGA, and you plug in your software debugger, that debugger doesn’t know about real-time trace or triggering capabilities,” said Leatherman. “What we’ve done is develop windows that extend the designer’s debugging capabilities within the comfort of their familiar environment.”

Proving that there is indeed more than one way to skin this cat (begging forgiveness of cat lovers everywhere – including me…), Altium Limited takes an unconventional approach to this challenge with their LiveDesign methodology, which allows you to probe, analyze, and debug your design interactively using virtual tools, including an embedded logic analyzer. The embedded logic analyzer includes both external (hardware) and internal (software) triggering, enabling concurrent hardware and software debug. The LiveDesign-enabled FPGA-based development board, called the NanoBoard-NB1, provides engineers with a vendor-independent platform, supporting multiple target devices in the form of swappable FPGA daughter boards.

Debug is a reality for FPGA designers, and it packs an extra wallop when you add embedded systems to the mix. If you ignore the issue, thinking you can spin your way out of it, you’re going to have a big headache waiting for you at the end of the line. But with some planning early in your process, even the most complex FPSOC designs will be bug free.

Amy Malagamba , FPGA and Programmable Logic Journal

August 30, 2005

[back to top]

Comments on this article? Send them to comments@fpgajournal.com