What a firmware rebuild actually involves

A custom firmware order does not hand you a file that already existed. It starts a build. The build needs one input only you can supply: the identifier burned into the FPGA on your card. That is why the catalogue says a firmware line is prepared rather than issued. It is the one product here that cannot complete itself while you wait. Below is the sequence, written out, so an order sitting in the build window is legible instead of silent.

One image, one chip

Every Artix-7 FPGA carries a unique device DNA, a serial burned into the silicon. Custom firmware is generated against that value. The image will not configure a different chip. That single fact drives everything else. The build cannot start before the DNA is in the ticket. The file cannot be reused on a second card. A card swap means a new build rather than a copy. It also means the image is worth nothing to anybody else. That is the point of binding it in the first place.

What the ticket needs before anything starts

• The order ID, so the build attaches to a paid order rather than to a conversation
• The DNA ID, read from your own card on the second PC
• A photograph of the board including the silkscreen model and revision
• The FPGA marking, read off the chip rather than copied from the listing
• The game you intend to run, because the tier and the profile are chosen against it

None of that is paperwork. The silkscreen revision decides which USB bridge and which flash chip the image has to drive. Two boards that both say 75T on a listing can differ in both. The FPGA marking decides the part. The DNA decides the binding. A ticket carrying all five lines moves. A ticket carrying a game name and nothing else does not.

Choosing the donor profile

A DMA card answers the host's configuration reads from a writable overlay, not from values fixed at synthesis. So the identity the card presents is data. Selecting a donor means deciding which real device that data describes. That means the vendor and device IDs, the class code, the BAR layout, the capability list and the extended entries behind it. The work is consistency rather than obscurity. Say a profile's class code disagrees with its device ID, or its subsystem pair is blank. That is a contradiction anything reading those registers can notice. The tiers on the firmware page — Emulated, Slotted, Slotted v2, Signature and Sovereign — differ partly in which profiles a build can draw on. They also differ in the anti-cheat list and the length of replacement cover each one carries.

Building and flashing

With the inputs fixed, the profile is written into the design. The design is then synthesised into a bitstream for your part. That produces one file, named for your order and bound to your DNA. The window is the one the site already publishes: a firmware order is prepared typically inside 24 to 48 hours once payment is verified. The flash itself is yours to run. The image goes onto the card over its flashing port, while the card is powered in the game PC. A real write takes minutes rather than seconds. A flash that finishes instantly wrote nothing.

Verifying, in the only order that proves anything

1. 1Shut the game PC down fully — a restart leaves the slot powered and proves nothing
2. 2Move the cable from the flashing port to the data port on the card
3. 3Confirm the FTDI data device appears on the second PC with no warning triangle
4. 4Run the connection test issued with your order and confirm it reaches the card
5. 5Read the DNA ID back and check it matches the value the image was built against

Only the last step closes the loop, and it is the one most often skipped. The LEDs on the board are not evidence. They report power, not configuration, and they light happily with a corrupt image in flash. One thing this whole process does not do is change what happens inside a game. Firmware decides how the card's PCIe identity reads to whatever enumerates it. That is one exposure surface out of several. A profile that reads as ordinary hardware today is a statement about today.