An Integrated Logic Analyzer (ILA) is a soft-IP debug core instantiated inside an FPGA that captures internal signal activity into on-chip memory and streams the results to a host PC for inspection, without requiring physical probe access to internal nets. It is functionally similar to an external logic analyzer but operates entirely within the fabric, making otherwise inaccessible internal signals visible during real hardware operation.
In practice
ILA cores are most commonly inserted into a design using vendor-supplied IP: Xilinx/AMD provides the ILA core (ChipScope Pro was an older predecessor suite; the current ILA core is integrated into Vivado Hardware Manager), and Intel/Altera provides Signal Tap Logic Analyzer in Quartus. Both typically connect to the host over JTAG, so in most cases no additional hardware beyond a standard JTAG cable is needed, though some boards use onboard USB-JTAG adapters or other debug links. The captured waveforms are displayed in the vendor IDE much like a bench logic analyzer.
A typical workflow involves selecting the internal signals to probe, setting a sample depth (limited by available block RAM), configuring trigger conditions, running the design, and then uploading the capture buffer over JTAG. Because sample depth competes directly with block RAM available for the rest of the design, choosing what to capture and how many samples to retain is a real resource trade-off. On a small device such as a Spartan-6 or Spartan-7, a deep capture on many signals can consume a significant fraction of available BRAM, though the exact impact varies with probe width, capture depth, and the specific device density.
Trigger flexibility is one of the ILA's main strengths. Many implementations support edge, level, and multi-condition triggers across any combination of probed signals, though the exact trigger features available vary by vendor, device family, and tool version. This generally makes it practical to catch rare or intermittent fault conditions that would be difficult to reproduce reliably with an external analyzer. Some flows also support comparison against a counter or sequence, enabling protocol-level triggering without writing RTL.
A common pitfall is that synthesis and place-and-route tools may optimize away or rename signals that are not connected to outputs or used in logic cones. Marking probed signals as debug nets (using attributes such as KEEP or MARK_DEBUG in Xilinx flows) prevents the optimizer from removing them before the ILA core can tap them. Designs described in blog posts such as "Designing a FPGA Micro Pt2 - Clock and Counter build and test." and "The Spartans" illustrate how FPGA-internal signals can be observed during live hardware testing using exactly this approach.
Frequently asked
How does an ILA differ from a traditional external logic analyzer?
An external logic analyzer probes physical pins on a PCB; it can only observe signals that have been routed to device outputs. An ILA taps nets inside the
FPGA fabric directly, so any routed signal, including internal state machines, bus arbitration signals, and pipeline registers, can be observed without dedicating I/O pins or adding PCB test points. The trade-off is that the ILA consumes on-chip
BRAM and
LUT resources and the sample depth is typically far smaller than a benchtop instrument's acquisition memory.
What resources does an ILA core consume?
Resource cost depends on the number of probed signals and the sample depth.
BRAM is the dominant cost: a 1024-sample capture of 64 signals uses 64K bits of storage, which maps to several 18K or 36K BRAM primitives depending on the device family.
LUT and routing overhead for the trigger logic and capture control is usually modest but not zero. On resource-constrained devices like a Spartan-6 XC6SLX9 or a low-density MAX 10, ILA insertion can noticeably affect fit and timing closure.
Can an ILA affect the timing behavior of the design under test?
Potentially, yes. Inserting probe taps adds fanout to the observed signals, which can slightly increase routing delay and affect timing closure. In most cases the impact is small, but on paths that are already near the timing margin the added load can cause failures that did not exist before instrumentation. This is an embedded form of the observer effect. It is good practice to run timing analysis with the ILA in place and verify that all paths still meet setup and hold requirements.
How deep a capture buffer is typically practical?
This varies by device and the competing
BRAM demands of the rest of the design. A few hundred to a few thousand samples is common in practice on mid-range devices. Xilinx ILA cores support a range of depths configurable in powers of two, but the exact supported range depends on the core version and device family, and large depths on wide probe buses can quickly exhaust available BRAM. Intel Signal Tap offers similar configurability. If deeper captures are needed, options include reducing probe width, enabling data compression, or using a dedicated external memory interface for trace storage (a feature available in some high-end debug environments).
Is an ILA useful for debugging soft-core processors running inside an FPGA?
Yes, and it is frequently used for exactly this purpose. A soft-core such as PicoBlaze or a custom RISC core exposes its internal buses, program counter, and register file as ordinary
RTL signals, all of which can be tapped by an ILA. This makes it possible to observe instruction fetch sequences, memory transactions, and control flow without a software debugger attached. The blog post 'PicoBlaze - Program RAM Access for an Interactive Monitor' discusses observing and interacting with PicoBlaze internals, a scenario where an ILA capture of the address and data buses provides direct visibility into program execution.
Differentiators vs similar concepts
An ILA is sometimes conflated with a virtual I/O (VIO) core. A VIO core drives or reads signals in real time from the host PC without a trigger-and-capture mechanism; it is more like a register interface than a waveform recorder. An ILA captures time-ordered samples relative to a trigger, producing a waveform view. The two cores are often instantiated together: the VIO stimulates inputs while the ILA records the response. ILA is also distinct from boundary-scan (
JTAG BSCAN), which probes device pin states rather than internal fabric signals.
