FPGA / BOARD BRING-UP

FPGA shows 7f after programming? Rebuild the baseline.

For an FPGA that was visible to the host before a bitstream change, or never appears reliably at boot.

THE SHORT ANSWER

After FPGA reprogramming, unknown header type 7f can accompany loss of the PCIe endpoint the host previously enumerated. Compare the exact board’s reference design, configuration timing and reset sequence before debugging your application registers. A rescan alone cannot guarantee recovery of a missing or unready PCIe endpoint.

1. Separate programming success from PCIe readiness

A successful JTAG operation establishes that programming completed; it does not demonstrate a working host PCIe connection. Record four checkpoints separately: configuration completes, the endpoint reaches link-up, the host enumerates the expected function, and software can access the intended interface.

AMD’s 7 Series PCIe guide explains that endpoints must be ready to respond during enumeration. If the device is not ready, the root complex may not discover it. Use the guide for your actual FPGA and PCIe IP version rather than copying timing assumptions from another family. AMD PG054: FPGA configuration and PCIe enumeration timing.

When a previously enumerated endpoint is replaced by a different design, the host’s old view may no longer match the hardware. Record whether PCI IDs, BAR layout, link configuration or reset behavior changed.

2. Prove one board-specific reference path

Choose the board manufacturer’s reference design matching your exact board revision. For NiteFury or LiteFury, start with the RHS Research repository and its sample-project instructions. Its existence is a baseline to investigate; Header7F has not tested those boards in a lab. RHS Research: NiteFury and LiteFury reference projects.

  1. Record board revision, FPGA part, host platform, tool release and reference-project revision.
  2. Build or use the documented matching reference artifact.
  3. Follow the vendor’s programming and host-startup order.
  4. Save a working PCIe view before introducing your changes.
  5. Reintroduce one design change and repeat the same sequence.

If the reference path also fails, investigate the platform, connection and programming sequence before blaming custom RTL. If only the new build fails, compare constraints, reference clock, reset, PCIe IP configuration and timing results.

3. Understand the warm-restart experiment

For the PG055 Gen2 bridge, AMD describes using a warm system restart after JTAG configuration to rerun enumeration while retaining power. Recovery with that sequence points toward configuration timing. This is a scoped diagnostic technique; another board may clear its FPGA on reset or use a different startup sequence. AMD PG055: configuration-time debug and a warm restart.

Check the board manual before testing. Save work and stop DMA and host applications before reconfiguration. A full shutdown can erase a volatile design, making the next startup a different experiment. Write down which reset preserves your image.

4. Capture the host view and design evidence

uname -r
lspci -Dnn
lspci -t
# Replace this example with the FPGA endpoint address.
sudo lspci -s 0000:03:00.0 -vv
sudo journalctl -k -b --no-pager

Keep matching pre-change and failed-state output, the bitstream build identifier and a timeline of programming and resets. Where your design exposes them, capture link-up, LTSSM state, user reset and clock status with the FPGA tool’s debug facilities.

Linux rescan is a discovery operation. Do not repeatedly remove/rescan or reset an upstream bridge without understanding every device below it. The kernel documents these operations separately. Linux kernel: PCI sysfs, remove, rescan and reset interfaces.

Once enumeration is stable, test application registers and DMA. An AXI-Lite verification kit addresses a later internal-interface problem; it does not repair a host-to-FPGA PCIe link by itself.

Common FPGA questions

Could a valid bitstream still fail PCIe enumeration?

Yes. Programming success and timely, correct PCIe operation are different checkpoints. Check the generated design’s actual reset, clock and configuration behavior.

Should I change the PCI header value in software?

No. The reported invalid layout is evidence to investigate. Editing bytes does not repair an endpoint that is no longer responding.

What would a useful bring-up kit contain?

A tested board/tool/host combination, reproducible reference build, scripted evidence collection, explicit programming/reset sequence and a small host smoke test. That is a product direction we are researching, not a package currently for sale.

Sources and scope

This is a source-based diagnostic guide, published by Header7F. We have not reproduced every scenario or validated these steps across all devices. Vendor-specific advice is identified above; examples use placeholder PCI addresses. A suggested comparison is not a guaranteed fix.

Published 18 October 2026. For corrections or a case this guide misses, send a short description.

KEEP TROUBLESHOOTING

Message us