fpga-signaltap

SignalTap II Auto-Generator

Auto-generate Quartus SignalTap II logic analyzer configurations for post-synthesis FPGA debugging.

When to Use

1. FPGA BIST reports FAIL but UART log doesn't show the root cause
2. Need to capture internal signal transitions at speed
3. Debugging timing-dependent issues that simulation doesn't reproduce
4. Verifying that actual DUT behavior matches expected waveforms

Requirements

• Quartus 23.1+ (SignalTap II is included in all editions)
• DE10-Nano target board (or any Intel/Altera FPGA with JTAG)
• USB-Blaster JTAG cable for signal capture

Tool: .stp generation (deterministic — MCP tool, not prose)

The .stp is generated deterministically by the MCP tool eda_rtl_signaltap_autogen — it scans the RTL for the DUT port list + timing-critical signals and emits the Quartus SignalTap XML (.stp) or Vivado ILA .tcl. Defaults: clock_signal=CLOCK_50, depth=2048, trigger on the BIST fail event. Pass extra_signals=[...] to add anything the heuristic misses.

eda_rtl_signaltap_autogen(rtl_dir=..., top_module=..., target="quartus",
                          clock_signal="CLOCK_50", depth=2048)
  -> <top_module>_debug.stp

⚠️ MEASURED 2026-08-03 (vibe-ic#693) — this tool does NOT yet satisfy the policy stated in the next section, and it reports status: "PASS" anyway. Driven for real against a published memory-mapped DUT's RTL directory it emitted one signal (a heuristic state match), no DUT ports, no BIST group, and an EMPTY self-closing <trigger_set …/>. signaltap_stp_completeness_check on that output: 4 × MISSING_BIST_SIGNAL + 8 × MISSING_PORT + NO_TRIGGER. Its signal selection is four name patterns (tx_start|rx_done|state|delimiter), not a port-list parse.

Until that is fixed: always validate the emitted .stp with signaltap_stp_completeness_check (step 2 of the workflow below) and add what is missing via extra_signals=[...], or use the other shipped producer tools/signaltap_gen.py --module <m> --sv <top.sv>, which parses the port list and emits the BIST group and a populated trigger, and PASSES the validator both with and without --sv. This split is why signaltap_stp_completeness_check is deliberately NOT wired as a blocking post-condition of the MCP tool: doing so today would break the declared generator 100% of the time.