-2
\$\begingroup\$

I am looking to determine the plausibility of reverse engineering a design from an FPGA. Suppose a company fabricates their revolutionary design on FPGAs and I have managed to acquire one. My goal is to remove the configuration from the chip and rebuild the Netlist, preferably in EDIF. I know that FPGA design security is a major concern so that leads me to believe that the design has been successfully removed from an FPGA in the past...? I figure there is no 'standard' way to achieve this but is there a known/documented way I haven't come across yet?

What I know so far is that there are three primary types of FPGAs: SRAM, Flash and anti-fuse.

  • Anti-fuse chips have their design seared into them permanently with high-voltage; the complexity of re-engineering the design seems far too large so we'll just forget about them for now.
  • Flash chips have the design stored non-volatiley inside the FPGA. Though considered 'live at power-up' the design is loaded from the internal flash memory to the FPGA. If this flash can be accessed it seems that we can remove the configuration data and build the netlist from there.
  • SRAM chips store the design in some external memory (such as an EEPROM or some RAM). It seems this memory is generally configured with a JTAG interface which tells me that it shouldn't be too difficult to remove the configuration.

I am aware that these days most FPGAs have their configuration data encrypted on the device. This is a separate problem and for the moment let's ignore it.

Once the plain-text configuration is acquired there seems to be the issue of format. It seems that most CAD tools have their own bit-stream formats. So far I have come across

  1. SVF - Serial Vector Format
  2. XSVF - Improved Serial Vector Format
  3. STAPL - Altera
  4. JAM
  5. JIC - JTAG Indirect Configuration
  6. SOF - SRAM Object File
  7. POF - Program Object File
  8. RBF - Raw Binary File
  9. TTF - Tabular Text File
  10. BIN
  11. BIT - Xilinx
  12. PDB - Actel

The goal is to end with a netlist in EDIF format, I have heard that there are translators in most common tools but I can't seem to find which, if any of the above formats are what are used to convert to EDIF. Are these configuration files what CAD tools use to represent a Netlist or must they first be converted into something else? If so do each of the respective tools provide means of doing so?

\$\endgroup\$

closed as too broad by Chris Stratton, PeterJ, uint128_t, Tom Carpenter, Peter Smith Mar 13 '16 at 14:44

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • \$\begingroup\$ Before trying to readback configurations, you should read about how they are configured. ... Then you'll see that configuration streams are not encrypted by default and that bit files can be converted to a human readable format. Many research groups are doing FPGA readback operations. ... \$\endgroup\$ – Paebbels Mar 12 '16 at 12:45
3
\$\begingroup\$

These files are not representations of netlists. They are binary configuration instructions for the FPGA, containing instructions to set the routing switches and IO banks and load RAMs, LUTs, flip-flops, latches, PLLs, DCMs, and transceivers with initial configurations. You would need to know what parts of the configuration instructions correspond to which internal components, and how these internal components are connected. Then you could piece together the mapped, placed, and routed netlist. However, unravelling the construction of the configuration bitstream is not so easy as the structure and specific commands are usually not publicly documented. This makes this sort of reverse-engineering more difficult, but certainly not impossible. It really only provides security through obscurity. There are some various projects to build open-source FPGA toolchains that have reverse engineered the bitstream formats for a couple of different FPGAs, namely the iCE40 series from Lattice.

However, you have totally skipped over the part of getting the configuration information out of the FPGA in the first place. This is non-trivial. The JTAG interface can be disabled internal to the FPGA when required by the design, making readout of the design far more complicated. With FPGAs with internal flash memory, code protection bits will prevent readout through any debug interfaces. I'm not sure if there are any ways around that that do not involve decapping the chip. SRAM based FPGAs will load a configuration from an external memory of some sort. Snooping this with a logic analyzer will trivially allow a design to be recovered. However, if the design is sensitive, then higher end FPGAs will usually support some form of bitstream encryption. This can either use a key that is burned into OTP cells on the FPGA, at the same time permanently disabling the JTAG interface, or at least debugging via JTAG, or stored in battery backed SRAM. In this case it is also not possible to access the unencrypted bitstream without physically modifying or probing the FPGA die.

\$\endgroup\$
1
\$\begingroup\$

When I used to make FPGAs, I used VPR to route my graphs. The EDIF format is an intermediate in the tool chain, and I then push the EDIF to the "target". I then take the bit stream and output it into the EDIF format to a program that has my complete switch matrix for verification. I would then compare the EDIF files. We had the situation where 1/2 the team did the graph routing and tools, and 1/2 did the circuits, so the program was mainly there to be sure our fuse maps match.

I know the Toronto guys have a VPR to Vertex II router, so the bit stream formats are out there somewhere. The Song team out of Georgia Tech also have an Altera router. I think that you just need to dig into the VPR documentation.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.