Lattice IC Unlock: Supported Parts and Feasibility

Short answer: Lattice IC unlock is realistic on older non-volatile CPLDs — the ispLSI, ispMACH 4000 and MACH 4/5 families — and on some early XP and MachXO parts, but it gets progressively harder on modern devices with hardened bitstream encryption. Feasibility depends on the exact die revision, not just the part number printed on the package. Send us the marking and we’ll tell you honestly whether it’s worth attempting.

If you’re here because a machine is down and the only copy of a JEDEC file left in the world is inside a 20-year-old PLCC44, keep reading. That’s the situation this page is written for.

What “unlocking” a Lattice device actually means

Lattice parts don’t hold firmware the way an MCU does. There’s no hex file with an interrupt vector table. What you’re recovering is configuration: the fuse map of a CPLD, or the bitstream of an FPGA. For a CPLD, that recovery target is normally a JEDEC (.jed) file. For an FPGA with internal flash, it’s a bitstream (.bit) or the programming file that generated it.

That difference matters for what you get back. A recovered JEDEC file will program blank parts and reproduce the original logic exactly. It will not hand you readable VHDL or Verilog source. Turning fuses back into human-readable equations is a separate, much slower job — sometimes possible on small ispLSI or 22V10-class devices, rarely practical on anything with thousands of macrocells.

So the honest framing is this: Lattice IC unlock gets your production line running again. It does not automatically give your engineering team something to edit.

Why the security bit is the whole story

Lattice CPLDs use a security fuse (sometimes called the verify-protect or security bit) that disables readback over the ISP/JTAG chain while leaving programming and functional operation intact. On older families, that bit sits in the same flash array as the configuration and behaves like a gate on the readback path rather than a cryptographic barrier. Newer devices — later MachXO2/XO3, ECP-class parts, anything with AES-based bitstream protection — are a different engineering problem entirely, and we say no to some of them.

Which Lattice families we can realistically work with

The table below is a feasibility guide, not a promise. Two chips with the same top marking can carry different die revisions with different lock behavior, which is exactly why we ask for photos before quoting.

One special case worth calling out: many iCE40 designs boot from an external SPI flash rather than internal one-time NVCM. If that’s your board, you may not need a Lattice IC unlock at all — you need the SPI flash read, which is a much simpler and cheaper job. We check for this first because it saves customers money often enough to be worth mentioning.

What determines whether your part comes back

Engineers ask for a percentage. We won’t give one, because the number would be meaningless across a family this wide. Here’s what actually moves the answer:

• Date code and die revision. A 1990s ispLSI and a late-run ispMACH 4000 are different animals. The fab revision on the die often matters more than the part number.
• Whether encryption was enabled. On FPGA-class Lattice parts with AES bitstream protection actually turned on, we usually decline rather than take your money on a long shot.
• Sample quantity. One irreplaceable chip is a much tighter constraint than five. With multiple identical parts we can work more aggressively and cross-verify the result.
• Whether the part is functional. A device that still runs in-circuit gives us behavioral reference data. A dead one gives us nothing to compare against.
• Package and prior rework. A clean PLCC or TQFP is straightforward. A part that’s been hot-air removed twice, or a BGA with cracked balls, adds risk before we even start.
• Whether decap is on the table. Some routes require exposing the die, which consumes the sample. If you have exactly one chip and no spares, that changes the plan.

Cases where we tell people not to bother

If your design uses a current-generation Lattice FPGA with encryption keys programmed and a secure boot chain, the practical path is usually redesign, not recovery. Same if the part is a modern MachXO3 with the security features fully engaged. We’d rather say that in the first email than three weeks and an invoice later.

We also decline when the ownership story doesn’t hold up. Legitimate work here means recovering configuration you have the rights to — a board your own company shipped, a legacy product line you acquired, equipment you maintain under contract, or authorized failure analysis. You’re responsible for holding those rights and complying with applicable IP law; every project runs under NDA on our side.

How the job actually runs, step by step

1. Identification. We read the full top marking under a scope — part number, speed grade, package, date code, and any fab suffix. This is the single biggest input to the feasibility call.
2. Non-invasive assessment. The chain is exercised electrically. We check the device ID, confirm the security bit state, and look at how the part responds to readback attempts. Some devices reveal a great deal here and never need to be opened.
3. Route selection. Based on what step 2 shows, the engineer picks a path. If a non-invasive route exists for that family and revision, we take it — it’s faster and leaves your sample intact.
4. Extraction. The configuration is pulled and assembled into a JEDEC or bitstream file. On CPLDs we also record the device signature and any user electronic signature field, since a lot of legacy production tests check it.
5. Verification. This is the part competitors skip describing. We program the recovered file into a blank part of the same type, then compare against the original: pin-level logic behavior on a bench fixture, and where the customer can supply a working board, functional test in the real socket. A file that programs cleanly but behaves differently is a failed job, not a delivered one.
6. Handover. You get the file, a note on the device signature, and any observations about programming settings the original tool chain would have needed.

Steps 2 and 5 are where the real time goes. Extraction on a well-understood ispLSI can be quick; the characterization work around it is what makes the result trustworthy.

What to send us for a feasibility answer

Give us these five things and you’ll get a straight yes, no, or “worth trying, here’s the risk” — usually without a long back-and-forth:

• Clear photos of the chip marking, in focus, all lines legible, taken on a dark background. Angle the light so laser marking reads clearly.
• Photos of both sides of the board, whole board in frame, dark background, plus the board’s overall dimensions.
• How many identical samples you have, and whether at least one is known-good and functional.
• What you need back — just a programmable JEDEC or bitstream file, or an attempt at logic-level recovery as well.
• Any context you have: the original tool chain, whether the part was factory-programmed or field-updated, whether other identical boards exist.

What comes back from us is a feasibility assessment, a realistic lead time, and a price. We don’t quote a figure on a page like this because the range across these families is too wide to be useful — device family, security state, sample count, package, and whether decapsulation is needed all move it. If you’re comparing manufacturers, our notes on Silicon Labs device recovery and Texas Instruments part feasibility follow the same honest structure.

Pairing Lattice recovery with board-level work

Most Lattice unlock requests we see arrive attached to a bigger problem: an obsolete controller board that has to keep running for another decade. In those projects the CPLD file is one deliverable among several — you also want the schematic, the Gerbers, and a BOM that reflects parts you can still buy.

That combination is common enough that we plan for it. The CPLD gets read while the board is being scanned and layer-separated, so the schematic and the recovered logic can be checked against each other. A net that the JEDEC file says should be an output, connected to something that only makes sense as an input, is a signal that one of the two recoveries is wrong. Cross-checking catches it.

Companion parts on the same board frequently need attention too — an older Motorola microcontroller or a m

Related reading

• Oct 2026Rohm IC Unlock | Which Families We Can Read
• Oct 2026Maxim IC Unlock | Families We Can Read & Recover
• Oct 2026Dialog IC Unlock | Families We Can Read & Recover