Short answer: Xilinx IC unlock is realistic on older CPLDs and some early FPGA configuration paths, and generally not realistic on modern encrypted parts. XC9500 and XC9500XL CPLDs with the read-security bit set are the most commonly recoverable devices we see. XC2C CoolRunner-II is case-by-case. A Kintex or Artix design with an AES-encrypted bitstream and a burned key is a different problem entirely, and we’ll tell you that before you ship anything.
That distinction matters more with Xilinx than with almost any other vendor, because “Xilinx” covers everything from a 1990s 5V CPLD to a modern SoC with a hardware key store. The rest of this page explains where the line sits and why.
Why Xilinx is not one problem but four
Most microcontroller unlock work deals with a single flash array behind a lock bit or a protection level. Xilinx programmable logic doesn’t work that way. The configuration lives in different places depending on the device class, and that location is what determines whether recovery is possible.
CPLDs with internal non-volatile config. XC9500, XC9500XL, XC9500XV, XC2C CoolRunner-II and the older XC7300 series store their pattern in on-chip EEPROM or flash. There is a read-security feature that blocks JTAG readback. These are the parts where a JED file can often be recovered.
SRAM-based FPGAs with an external config source. Spartan-II, Spartan-3, Spartan-6, Virtex families and most of what came after load their bitstream at power-up from a separate PROM or SPI flash. In these cases the “chip” you want to read may not be the FPGA at all — it’s the XCF platform flash or the 25-series serial flash sitting next to it.
FPGAs with encrypted bitstreams. From Virtex-II onward, Xilinx offered AES bitstream encryption with the key held in battery-backed RAM or, later, in eFUSE. If the design was built this way and the key is gone, the encrypted bitstream on the PROM is readable but useless. We do not claim to break AES.
One-time-programmable and antifuse parts. Older XC17xx serial PROMs and the antifuse families each behave differently again. Some are trivially readable; some are physically hostile to any readback.
What a “successful” Xilinx unlock actually produces
On a CPLD, a good result is a JED or ISC file that programs a blank device and produces functionally identical behavior. On an SRAM FPGA fed from external flash, the result is a binary bitstream file plus the programming file format needed to reload it. What you almost never get from either is readable HDL. Recovering VHDL or Verilog source from a bitstream is a research-grade problem, not a service, and anyone promising you clean source code is overselling.
Family-by-family feasibility
The table below reflects how we triage incoming Xilinx jobs. Treat it as a starting point for conversation, not a guarantee — silicon revision, date code and how the part was configured all move the answer.
| Device family | Where the config lives | Typical feasibility |
|---|---|---|
| XC9500 / XC9500XL / XC9500XV | On-chip EEPROM, JTAG read-security bit | Frequently recoverable; our most common Xilinx job |
| XC7300 / XC7000 | On-chip EEPROM, 5V logic | Often recoverable, but sourcing blank replacements is the real bottleneck |
| XC2C CoolRunner-II | On-chip flash, read protection | Case-by-case, depends on device and protection state |
| Spartan-II / Spartan-3 with unencrypted config | External XCF PROM or SPI flash | Usually a memory read, not an FPGA attack |
| Spartan-6 / Virtex-5 with unencrypted config | External SPI or BPI flash | Readable as flash; verifying the load is the harder half |
| Any family with AES-encrypted bitstream and eFUSE key | Encrypted external flash + on-chip key | Not feasible; we decline these |
| Zynq / UltraScale with secure boot | Hardware root of trust | Not feasible |
What happens to your part in the lab
The order of operations matters, because the cheap non-destructive checks have to come first. Once a package is opened, the part is a sample, not a spare.
- Identification. We read the full top marking — device, speed grade, package, date code and the lot code. On Xilinx CPLDs the difference between an XC9572XL-10VQG44 and an XC9572-15PC84 changes the whole approach.
- JTAG chain survey. If you send the board, we check whether the part is reachable on the boundary-scan chain, whether IDCODE reads back cleanly, and what the security state reports. Sometimes the “locked” part turns out to be a broken connection or a held-low PROG pin.
- Look for the real target. On an SRAM FPGA design, we identify the configuration source and its mode pins. A serial flash read is faster, cheaper and less risky than anything done to the FPGA, so if that’s the path, we take it.
- Non-invasive evaluation. Electrical and timing-based approaches appropriate to that specific family, using known Xilinx JTAG behavior. This is where the go/no-go call usually gets made.
- Semi-invasive work, only if it’s justified. Some older CPLDs require die access to evaluate further. We only recommend this when you have spare units, because it consumes the part.
- Verification. The recovered pattern gets programmed into a blank device of the same part number and tested. For a CPLD we compare pin-level behavior against the original under the same stimulus. If the original board still powers up, we test the reprogrammed part in-circuit.
Step 6 is the one competitors skip in their marketing. A file that reads back is not the same as a file that works. Xilinx CPLD fitting is deterministic enough that a correct JED reproduces the original behavior, but user I/O configuration, pull-up defaults and unused-pin settings are exactly where a sloppy recovery bites you six months later.
Where Xilinx jobs go wrong — the honest list
- Encryption ends the conversation. If the bitstream is AES-encrypted with the key in eFUSE, there is no service-level answer. Redesign is your path.
- Replacement silicon is often the harder problem. XC9500 and XC7300 parts are long obsolete. Recovering the JED is pointless if you can’t buy trustworthy blanks, and the grey market for these is full of relabeled junk. Sometimes the better project is retargeting the recovered logic to a current CPLD.
- A single sample limits us. With one unit and no spares, we stay strictly non-invasive and the feasibility odds drop. Two or three units of the same part number materially improve the picture.
- Conformal coating and potting add time. Not fatal, but the part has to come off cleanly and coating removal is manual work.
- Damaged or reworked parts. A CPLD that’s been hot-air-removed twice, or one from a board that saw an overvoltage event, may have marginal I/O even if the config array is intact.
- Mixed-vendor confusion. Plenty of “Xilinx” jobs turn out to be Altera MAX or Lattice parts once we read the marking. We check rather than assume.
What to send us, and what you get back
To quote a Xilinx IC unlock job we need very little, but it has to be the right little. Vague inquiries get vague answers, so please include:
- Sharp photos of the chip marking. Every line of text, in focus. Angle the light — laser marking on plastic packages reads best with raking illumination.
- Photos of both sides of the whole board on a dark, matte background, entire board in frame. This lets us spot the configuration PROM, the JTAG header and whether there’s a battery for key retention.
- Board dimensions and rough layer count if you know it.
- How many units you have and whether any are sacrificial.
- One line on what you need: just the config file, a working reprogrammed part, or the file plus a board-level duplicate.
- The context. Legacy machine repair, obsolescence migration, failure analysis — this shapes the recommendation.
Back from us you get three things: a straight feasibility assessment for your specific device and protection state, a lead-time estimate, and a price. Pricing on Xilinx work is driven by family and vintage, whether the target is the CPLD itself or an adjacent memory, how many units you can supply, and whether verification includes in-circuit testing. A CoolRunner-II evaluation and an XC9536 read are not the same job and shouldn’t carry the same number.
If the answer is no, you’ll hear no with the reason attached. We’d rather lose a quote than take money for a project we can already see the end of. When the CPLD path closes, we often pivot to recovering the surrounding board design so you can retarget the logic to a current device — and past projects of that shape are the ones we’re happiest to talk about.
Legitimate use and confidentiality
Everything we do sits on the maintenance-and-obsolescence side of the line: recovering configuration for equipment you own, keeping out-of-production industrial and test gear running, migrating a dead Xilinx CPLD design onto a part you can still buy, failure analysis, and authorized security evaluation. You’re responsible for holding the rights to the design and for complying with applicable IP law in your jurisdiction; every project runs under NDA, and files go only to you.
Common questions
Can you read an XC9572XL that has
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote
Related reading
Working on a board like this?
Send the chip marking or two photos. You get feasibility, lead time and price within 24 hours, and the check costs nothing.
Get a free quote