Vivado ILA never fires — probes show constant 0 in Hardware Manager after adding mark_debug

There's a useful two-step split here. Before touching trigger settings at all, verify the probes are actually connected to your signals — because if they're not, no trigger configuration will ever work.

Run Trigger Immediately first

In Hardware Manager, right-click the ILA → "Run Trigger Immediately" (or the lightning bolt button). This bypasses trigger conditions and captures whatever is on the probe buses right now.

Look at the captured waveforms. If tx_busy, spi_clk_en, and state all show constant 0 — even while you're running SPI transfers — the probes are not connected to live signals. The ILA core exists in the bitstream but the synthesis tool removed the nets it was supposed to observe.

If free-run capture shows the signals moving, skip to the trigger section.

---

Root cause: mark_debug without keep

This is where the HDL attribute model trips people up. (* mark_debug = "true" *) tells the synthesis tool to expose the net to the debug infrastructure. It does not instruct the tool to preserve the net as a physical wire.

Synthesis is free to absorb a net that has no downstream fanout beyond the ILA probe — absorbing it into an adjacent LUT, renaming it during hierarchy flattening, or removing it if it considers the signal to be a redundant copy of something else. The ILA probe port then ends up tied to a constant, and Hardware Manager dutifully shows you that constant.

The fix is to add keep alongside mark_debug:

(* mark_debug = "true", keep = "true" *) reg [2:0] state;
(* mark_debug = "true", keep = "true" *) wire spi_clk_en;
(* mark_debug = "true", keep = "true" *) reg tx_busy;

keep is a synthesis directive that preserves the net as a named, observable point regardless of optimisation. Alternatively, add both properties in your XDC:

set_property MARK_DEBUG true [get_nets {spi_clk_en}]
set_property KEEP        true [get_nets {spi_clk_en}]

After adding keep, re-run synthesis, re-run Set Up Debug, re-run implementation, generate a new bitstream, and re-program. Then test free-run again.

Verify using the Tcl console after synthesis

Before going all the way to bitstream, open the synthesised design and run:

get_nets -hierarchical -filter {MARK_DEBUG == 1}

If your three nets are missing from the output, the attributes didn't attach — either because they were optimised away before the property could be preserved, or because the XDC net name doesn't match the post-synthesis flattened name (hierarchy flattening renames nets — spi_ctrl/spi_clk_en may become spi_clk_en_0 or similar in the flat netlist). If you see the nets listed, the marks are in place and the issue is purely the missing keep.

---

If free-run works but the trigger never fires

Once you've confirmed the probes are live, the trigger configuration is the next thing to look at.

The default trigger operator is == (EQUAL), which fires when the probe equals a constant value on every sampled clock edge. This works well for a signal that holds for many cycles. But tx_busy sounds like it's a pulse — high for the duration of a transfer, then back to 0. At 50 MHz, a 16-bit SPI transfer (assuming one bit per clock) lasts about 320 ns — 16 clock cycles. Whether the ILA catches that depends on how long the trigger evaluation window is and where you're sampling.

Change the trigger operator to (R) — rising edge — so the ILA fires on the 0→1 transition of tx_busy rather than checking for a static 1:

• Click the operator dropdown next to tx_busy in the trigger setup panel
• Select (R) (rising edge transition, 0 → 1)

Also check the trigger position. The default is 512 out of 1024 samples (50%), meaning the trigger event lands in the middle of the capture buffer — you see half the buffer before the trigger and half after. Move it to around 10% so you capture the full SPI transfer after the rising edge of tx_busy.

One more check: make sure the ILA clock (clk_50 in your case) matches the clock domain your SPI signals are in. If the state register is in a different clock domain than the ILA clock port, the probes will sample at the wrong rate and may show aliased or constant values. The complete synthesis → implementation → programming pipeline is covered in the FPGA development flow guide — ILA insertion sits between synthesis and implementation, so changes to probe assignments always require re-running both.