Add-in Cores Simply the FPGA Debug Chore

VERSION 1
Created on: May 14, 2009 2:12 PM by Dustin "Dr Dtroit" Hamilton - Last Modified: May 14, 2009 2:12 PM by Dustin "Dr
Dtroit" Hamilton
by Jon Titus, Senior Technical Editor
Ecnmag.com - May 04, 2009
Design tools insert debug logic into FPGAs so engineers can focus on design problems and not on
debugging the debugger.

Engineers will find a variety of debugging tools among the design software offered by
FPGA vendors. The tools place debug logic into a design so a host PC can access the
FPGA's internal conditions, memory contents, register data, and so on. Engineers can set
the trigger conditions that initiate data capture and storage of data in internal RAM. The
PC, which communicates with the FPGA through a JTAG connection, also can configure
internal FPGA settings and force signals into known states.
"When engineers are up against a deadline and they must debug an FPGA chip, they don't
want to create their own debug logic to probe the chip," said Brian Caslis, software
marketing engineer at Lattice Semiconductor. "They need something they know will work
and that they can quickly insert into their circuit."

In addition, they must consider how the debug capabilities will affect their design flow. Must they modify their
application code to add debug capabilities, or can they simply invoke debug capabilities and have the design tools
automatically add them? And how much work does on-chip debugging entail? To find out, we talked with experts
at Actel, Altera, Lattice Semiconductor, and Xilinx.

Xilinx provides an integrated logic-analyzer (ILA) core within its ChipScope Pro tools and developers can use a
Core Inserter tool to place an ILA into a synthesized design. (Xilinx also offers other cores for debug and test
operations.) Once developers have an ILA in place, an FPGA editor lets them look at the actual routing of circuits
and low-level components, and connect them to the ILA core for trigger or data-capture use. "You can identify
the debug cores currently in a placed-and-routed design and quickly change the connections to those cores,"
explained Brad Fross, product engineering manager for the Xilinx ChipScope tools. "Assume you have an ILA
core connected to a state machine in your design. You can use the editor to change the signals you need to
observe. Within a few minutes you have changed the signals, re-route them, saved a new bit file, and gone back
to your PC to view new debug information. This operation mimics lifting a scope probe on a board and placing it
on another signal."

The Xilinx ChipScope Pro tool inserts logic-analyzer, bus-analyzer,

and virtual-I/O software cores into a design so developers can view internal signals at any node.
The Platform Cable USB pod performs device-programming and debugging
communications from a host PC to a target board. Courtesy of Xilinx.

The PC-based analysis software can change trigger conditions as needed. "You can set up an ILA core to trigger
on a specific bit pattern or value on the signals it monitors," noted Fross. "Or, you can trigger when a value goes
outside a range, or set up many other types of trigger conditions. You make these changes dynamically from your
PC through a JTAG connection so you don't have to recompile application code when you change trigger
settings. And you can set the trigger position anywhere in your capture window so you could record data after or
before a trigger event, or capture x data points before and y points after a trigger event."
Designers who use FPGAs treat on-chip RAM as a precious resource, so unlike a bench logic analyzer with
megabytes of storage, an FPGA debug core can save only relatively small amounts of information. "You can use
storage qualification, or filtering, to selectively save only data that meets preset conditions," said Fross. "So,
rather than capture a sample for every clock cycle, you might set conditions to capture data only when the trigger
sees signals in specific states or when a memory address comes within a preset range, for example. The debug
core won’t capture any data unless the trigger logic detects those conditions. If you need to change the address
range or a trigger pattern, you use the PC-based software. There are no recompile or re-implemention steps."

The Xilinx ILA core can route a trigger-output signal to an I/O pin to trigger an oscilloscope or logic analyzer.
And developers who need to perform system-level debug can insert an Agilent Trace Core (ATC2) in their
FPGA. This core connects the internal FPGA logic to an external Agilent Logic Analyzer that offers deep-trace
capabilities but uses only from four to 128 of the I/O pins on the FPGA. Pin use varies depending on the number
of internal probe points, clock-domain frequency, and trace depth.

Altera offers many triggering capabilities in its on-chip SignalTap II Embedded Logic Analyzer (ELA) that
comes as part of the company's Quartus II design tools. "We have the basic logic-state triggers that users establish
with a graphical interface," explained Phil Simpson, senior manager for software technical marketing at Altera.
"But engineers also can use a schematic-type tool that lets them create a diagram of their trigger conditions. For
more complicated trigger requirements, we have a state-machine utility that lets engineers easily describe trigger
states. That’s a powerful way to establish trigger conditions because you can put the ELA into a 'wait state' until
another condition occurs that moves the machine to a different state to initiate a trigger."

State-machine trigger conditions in the Altera SignalTap II Embedded Logic Analyzer

let developers use if, else, else-if and other statements to handle complex trigger conditions.
This technique helps isolate events that involve several trigger conditions that must occur in sequence. Courtesy of Altera.

The Altera ELA provides for both non-segmented and segmented memories, or buffers, that let engineers control
how the ELA saves data. A non-segmented buffer acts like a large first-in first-out (FIFO) memory. On the other
hand, a segmented buffer breaks the storage space into smaller FIFO segments that make it easier to debug
systems that contain relatively infrequent recurring events. Each segment can have its own trigger conditions.

"Typically, when a trigger event occurs, the ELA capture as large amount of data and puts it into a buffer,"
explained Simpson. "When this type of capture occurs many times, the buffer fills quickly. So, you can say,
'Store the data only on the fifth occurrence of a particular type of cycle or trigger condition.' In addition, the ELA
can update only the parts of the data that change. If you have a 16-bit bus on which 12 bits remain constant you
can update the buffer with only the four changing bits and log when the changes took place."
Developers add SignalTap ELA blocks to their design as needed, using either the Quartus II software, which
automatically adds the ELA to the design, or by manually adding SignalTAP to their RTL, just as they would add
any other IP or circuit "component." If they change trigger conditions or data lines, they only have to recompile
the SignalTap block. "When someone says, 'Wait a second, I want to trigger on ABC not XYZ,' they can do an
incremental compile with the new trigger information," said Simpson.

When engineers debug or test a design in an Actel flash-based FPGA they use Identify Actel Edition (AE)
Instrumentor to insert debug-logic into their RTL before synthesis. This "instrumentation" step creates a
debuggable hardware description language (HDL) version of the design. Then engineers can set the sample
signals, trigger points for conditional sampling, and trigger breakpoints for event-driven sampling of the signals
within the design. After they program an FPGA, the engineers use the Identify AE Debugger to communicate
with the debuggable design and capture data.

As needs change, the engineers can modify the RTL code to accommodate new trigger conditions and data-
capture signals. "Each time you change the particular points you probe, you change the RTL code, recompile the
code, and layout and route the new design," said Wendy Lockhart, senior manager for design solutions marketing
and training at Actel. "So the physical implementation changes because the debug circuits become part of the
overall architecture. You don't intend to change things, but you might observe some slight changes in timing, for
example, even though the tools confirm the proper functionality of your design."

Of course, the IP for any debug core take some "space" in the FPGA. "If your design already takes 98 percent of
an FPGA's logic elements, you can't add a debug core at the last minute," stressed Lockhart. "We encourage
engineers to think about debug requirements when they start a project. If they plan to use, say, a ProASIC3
A3P250 250k-gate FPGA, they might start with a larger device such as the A3P600 with 600K gates. That device
gives them plenty of space for the debug circuits. Then they can validate their design, remove the debug cores,
and transfer the circuit into a smaller FPGA." According to Hughes, many customers include the Identify AE
core or cores in a design right from the start because it comes as part of the Libero Gold software package.

Simulation of a circuit can only take you so far before you have to jump into debug mode. "Suppose you run a
simulator and have to wait for 1000 cycles of event A and then wait for 1500 cycles of event B before you
examine the relationship of three other signals, X, Y, and Z," said Lockhart. "You want to know if X comes on
for five clock ticks and then if Y goes off for six clock ticks before Z comes on for another seven ticks. That's a
complex relationship to look for and it can take a long time to obtain and analyze the simulation results."

"But you can use conditional triggers in Identify AE to wait until events occurs in sequence," said Lockhart.
"Then you can acquire just the information you need so you minimized the amount of data you must examine to
ensure your circuit operates as it should. Think of the debug core as a logic-analyzer with a wide range of
conditional statements engineers can put into their RTL code to analyze on-chip events."

The debug data from an Identify AE core goes into a PC that will display the data in several ways. "The PC-based
software can highlight pieces of your RTL codes to indicate where a problem might occur," said Hughes. "Then a
user can back annotate the RTL code to fix the problem or try something different. Also users can display values
for signal groups, such as data and address buses, so they can better interpret what happens over a given time.
And they can look at computer-generated waveforms that present the debug information in graphical form."
 The Reveal Analyzer software captures and displays information from internal FPGA signals.
Users can dynamically change the trigger options set in Reveal Inserter and immediately capture new data
without re-implementing an FPGA design. Courtesy of Lattice Semiconductor.

When engineers use the ispLEVER software suite to develop designs for FPGAs from Lattice Semiconductor
they use a Reveal Inserter tool to place debug cores in their circuitry. "Reveal Inserter shows you all the signals in
a design so you can select the ones you want to look at," explained Brian Caslis of Lattice. "Then you select the
signals you want to observe, or trace, the signals to use as triggers, and the various trigger conditions. Instead of
having to design a debug logic circuit or modify RTL code, you click a button and the software handles the
details in the background." Within the debug logic, Reveal hard wires the signals you want to capture, but you
can go back and change them from the software and reinsert the debug logic in a design. Users can dynamically
change the trigger conditions, however, during a debugging session with the Reveal Analyzer software.

"A complaint with early core-based debug techniques centered on the extra effort it took to build a core, put it in
a design, and set it up," said Caslis. "People said, 'Now I want to look at another signal over here.' So they went
back to their source code with the debug logic and fiddled with it to modify the original signal and trigger
choices. That approach made it difficult to keep track of the many changes. In Reveal, you pop up the screen,
change your signals and trigger conditions and click on 'Insert Debug' again." The process appears transparent to
users because they do not modify their code in any way and they can turn the debug core on or off.
Adding a debug core does extract a small penalty, but according to Caslis, the key is whether the penalty matters.
"A debug core or cores do take up some space," said Caslis, "but the big concern is the amount of RAM storage
needed to hold the captured signals. The trace buffer takes up by far the largest amount of logic in a debug core."
So, if you have used most of the memory for other functions, you have limited space for debug information.
That's a tradeoff engineers should know about right at the start. Debug cores do need memory and the more
memory available, the more debug information they can store.

"In some cases, adding a debug core will affect timing and in others it won't," noted Caslis. "The debug logic
itself adds only one load to whatever signal you look at. But the logic takes space, and routing can affect timing
to a small extent. We’ve seen designs where it does have an impact on timing, but we’ve also seen designs where
even though the debug logic has an impact, it doesn’t have enough of an impact to affect performance."

Like other debug logic, the Reveal debug cores offer many types of triggers and trigger conditions. "We have
trigger units that compare signals to a value, say a rising edge on signal ADDR and a specific value on an 8-bit
counter," said Caslis. "A trigger expression combines trigger units in combinatorial, sequential, and mixed
combinatorial/sequential patterns. Each debug core can accommodate as many as 16 trigger expressions that
users dynamically enabled or disabled in the Reveal Logic Analyzer software."

When you define the triggering logic you can specify a trigger-out signal and route this signal to an I/O pin for an
external logic analyzer or scope. Likewise, you can access an input signal. "Any signal in an FPGA is visible,"
said Caslis. "It looks like just another signal and you can use it as an input to the debug core."
 This display from the Actel Identify Debugger shows instrumentation code added
(bottom window) to a design. The floating window shows the acquired signals and their waveforms. Courtesy of Actel.

Leave It In or Take It Out?

After you debug a design should you remove the debug cores or leave them in the circuit? It depends. "If
designers don't have a strict power and layout budget, often they leave a debug core in the FPGA," noted Altera's
Simpson. "They might choose to upgrade the design later on, so it's helpful to still have the debug core available.
Also they can use remote debug capabilities to extract information in the field via the JTAG port and the System
Console software. We put in a SPI interface to System Console as well, because we’ve seen FPGAs connected to
coprocessors that use SPI as a communication channel."
Brad Fross at Xilinx said when customers remove debug cores they have to go back and re-implement the design.
"When you probe something inside an FPGA with one of our debug cores, you inherently change the design, add
loads to signals, and perhaps change how the place-and-route algorithms handle the design. In other words, you
perturb the design."

"Suppose you have a basic functional problem where your logic was just incorrect," continued Fross. "In that
case, taking the cores out will not hurt your design. But let’s say you have a timing problem. Often adding the
debug core causes the problem to disappear because the FPGA tools moved things around and all of sudden the
circuit behaves properly. In that case it behooves you to go back and understand how the timing changed so you
can properly constrain your design. Then you can safely remove the debug cores."

If you decide to remove Lattice debug cores it doesn't take much work. After you use the Reveal Inserter to add a
debug core, a Reveal .rvl source file appears in the ispLEVER Project Navigator. If you decide to remove debug
from your design, you just delete that .rvl file from your source list. "Conversely, if you change the functionality
of your source code, the Project Navigator will automatically reinsert the debug cores as long as the .rvl Reveal
file exists," said Caslis of Lattice Semiconductor.

Click here for more helpful information from ECNmag.com