The FPGA DNA ID, in detail
The factory-burned unique ID in Xilinx 7-series FPGAs. What it is at the silicon level, how to read it, why custom firmware is bound to it, and what it is not.
Short answer
The DNA ID is a 57-bit, read-only value burned into each Xilinx 7-series FPGA at the factory. Logic reads it through the DNA_PORT primitive. Custom firmware is built against that value, so the image runs on one board only. It is not a licence key, and it holds no information about you.
On this page10
What the DNA actually is
Every Xilinx 7-series device, Artix-7 included, leaves the factory with a unique identifier programmed into eFUSE. Internal logic reads it through a primitive called DNA_PORT. That primitive loads a shift register with the value and clocks it out one bit at a time. In 7-series parts the accessible width is 57 bits. The value is read-only. No command rewrites it, no tool spoofs it in silicon, and no procedure gives two chips the same value. That permanence is the whole reason it works as a binding key.
The DNA at a glance
The properties that matter when you are deciding whether to paste it in a ticket.
- Where it lives
- eFUSE inside the FPGA, programmed at manufacture
- Width
- 57 bits accessible to logic on 7-series parts, read through the DNA_PORT primitive
- Writable
- No. Read-only for the life of the chip
- Scope
- Identifies one FPGA die. Not the board, not the flash chip, not the PC
- Derived from you
- Nothing. It predates your purchase and knows nothing about you
- Secret
- Not cryptographically. Treat it as an identifier you do not publish, not as a password
Where the value appears
MemProcFS mounts a virtual drive and writes a status file into it. The DNA line in that file is the value support needs, copied exactly, with no added spaces.
MemProcFS.exe run as Administrator on the second PC
<mounted drive>\misc\pcileech_status.txt
look for the line beginning: DNA_IDReading it with MemProcFS
The reliable path, and the one the shipped DNA ID guide describes. Do this on the second PC with the card powered.
- Boot the game PC first and let it reach the desktop, so the card is powered and enumerated
- Connect the card to the second PC on the port your order instructions specify for a status read
- Run MemProcFS.exe as Administrator, using the build issued with your order
- Open the virtual drive it mounts
- Open misc\pcileech_status.txt
- Copy the DNA_ID value exactly, with no trailing space and no reformatting
Warning
Why the file is sometimes missing
A missing status file means the card is not talking, not that the DNA is gone. Check the port first. A status read and a flash use different sockets on the board, and the wrong socket is the single most common cause. Then the cable, then the USB bridge driver on the second PC, then a cold boot of the game PC. Do not invent a value. Do not reuse one from an older card to unblock yourself. A build against the wrong DNA is a build you will have to redo.
Why firmware is bound to it
A custom image is built for one board. Binding the bitstream to the DNA it was built against makes that mechanical rather than an honour system. The logic reads the DNA at run time and only proceeds on a match. Two consequences follow. The image cannot be copied to a second card and used, which is why one purchase is one board. And if you replace the card, the new FPGA has a different DNA. You need a new build, because nothing in the old file carries across.
Info
What the DNA does not do
Three things people assume it is, and it is none of them. It is not a licence key. It identifies hardware, and your entitlement lives on your order rather than in the chip. It is not personal data. It was burned at manufacture, it is not derived from anything about you, and it cannot be turned back into an identity. And it is not a detection vector in itself. An anti-cheat reading the card's configuration space sees the donor profile, not the FPGA's internal DNA.
What to put in the ticket
Everything in one message. A ticket that has to be asked three follow-up questions is a ticket that waits three times.
- The order ID
- The DNA ID, copied exactly from the file you actually opened
- The card model and FPGA class as marked on the board, plus a photo of the silkscreen
- Which tool produced the value, and the full output rather than a retyped fragment
- The game and anti-cheat you intend to use it with
- Whether this is a first build or a replacement for a card you have changed
DNA questions
Can the DNA ID be changed or spoofed?
Not in the silicon. It is factory eFUSE and read-only. Logic in a bitstream can of course report whatever it likes to a tool. But the value the chip holds does not change.
Is it safe to send my DNA ID to support?
Yes, in the order ticket. It is a hardware identifier with no personal information in it. Do not post it in a public channel, for the same reason you would not post a serial number.
Two cards, do I need two builds?
Yes. Each FPGA has its own DNA, and a build bound to one will not run on the other. One ID, one board, one image.
I replaced my card under warranty. Can I keep my firmware file?
The file is bound to the old DNA, so no. Read the new card's DNA and ask in the same order ticket for a rebuild against it.
Does the DNA ID identify me to an anti-cheat?
No. It is internal to the FPGA and is not part of what the card exposes on the PCIe bus. What is exposed is configuration space, which is the donor profile.
Sources
How we bind a build to one card is our own policy. What belongs in a ticket comes from our own tickets.
- 01AMD/Xilinx DS180, 7 Series FPGAs Data Sheet: Overview
the factory-programmed device DNA in Xilinx 7 series parts, and the Artix-7 parts these cards use
docs.amd.com
- 02MemProcFS (Ulf Frisk), AGPL-3.0
the tool that mounts the virtual drive holding the status file where the DNA line appears
github.com
Read next
Still stuck? Open a ticket on Discord
All guides