Reverse-engineering FPGAs [video]

https://media.ccc.de/v/34c3-9237-reverse_engineering_fpgas

by anfilt • 9 years ago

152 41 9 years ago

media.ccc.de

lnsru2• 9 years ago

Reverse engineering FPGAs is like stealing a train. It might be fun, but the overall benefit is rather limited.

Vidado isn't most comfortable tool, it does the job and handles all the primitives (memory controllers, clocking, transceivers, etc) very well. I wish somebody could design comfortable IP version control system.

egg_head12• 9 years ago

You do realize an open source tool chain was made off this guys work of reverse engineering the ICE series of FPGAs. Also what about real time alteration or reconfiguration of an FPGA? Pretty hard to do without some documentation. Although, that's kinda like self modifying code kinda hard to design something useful with, but not impossible.

black_puppydog2• 9 years ago

that's nothing like self-modifying code. It would probably be much more like CUDA kernels being uploaded to the GPU. More complex than "single cpu with global memory" but hardly "mr president, the virus is a self-mutating hydra" level.

pjc50• 9 years ago

The fact that digital logic design is constrained to one of two ancient languages by the proprietary toolsets is a serious problem.

There are ways round this by compiling to Verilog (eg Chisel) but it's an uncomfortable halfway house.

anfilt6• 9 years ago

There is SystemC, and that's not exactly ancient. It's handy when working at the architectural level.

Also what's wrong with old languages? Looks at C for instance which is much older than VHDL or Verilog.

adwn3• 9 years ago

The fact that digital logic design is constrained to one of two ancient languages by the proprietary toolsets is a serious problem.

Not really. You can compile any high-level language to a netlist and use that as input for place&route. Even if the proprietary toolchain didn't support EDIF netlists, you could still compile to a purely structural VHDL/Verilog file with the instantiated FPGA logic primitives (LUTs, nets, etc.), which is basically

The main (but not the only) reason why VHDL and Verilog have not been replaced yet, is that nearly all supposedly "better" alternatives fail to address the actual pain points in FPGA design. The most likely cause for this is that the overlap between professional FPGA designers and people capable and willing of designing and implementing a language is very, very small. The result is that you get a lot of languages designed by people who have never programmed larger FPGAs in a professional setting and consequently don't have a good understanding of the problems involved.

pjmlp• 9 years ago

Well, I kind of prefer VHDL.

anfilt6• 9 years ago

IPs can be nice when working with FPGAs, but when it comes to ASICs unless its very detailed piece IP block also works with your fabs process/cell library. You either design your own IP for the fab or find a suitable replacement.

Or are you talking about managing blocks that you or team have designed? That's annoying especially when you have all these blocks with certain performance characteristics such as power use, propagation delay, area ect... So you spend time simulating a design with each of these blocks till you get the one that meets the specs for the larger design, but saves the most space so you can put more things else where. It's nice though that some of this stuff is getting automated, but it's still a pain with analog designs.

lnsru2• 9 years ago

These are blocks designed by us. I put now basic configuration of the block as separate Vivado project to git. That’s the pain...

meuk• 9 years ago

Reverse engineering the format is necessary to make an open source toolchain, so I disagree. But you are right that an open source toolchain probably won't handle the primitives very well, so we're stuck with the vendor-specific tools, at least for now.

lvoudour2• 9 years ago

Yes vendor tools are free and pretty good at their job, but it doesn't mean there shouldn't be another (or better) way.

Imagine being stuck with Intel issued compilers and 2 programming languages max when dealing with x86 processors.

I wish somebody could design comfortable IP version control system.

That's true, vivado generates a ton of intermediate files and binary blobs which make source control a frustrating. Another reason to have a nice clean toolchain

black_puppydog2• 9 years ago

I am amazed that apparently, a lot of bigger project formats are not VCS friendly, even in domains where everyone should (?) know how to use git. For electronics, I liked this talk, also from 34C3:

https://media.ccc.de/v/34c3-8818-designing_pcbs_with_code

Shikadi• 9 years ago

If you export everything as tcl scripts, it actually plays very nice with vcs. Just a bit hard to set up initially, but you can even use make files to generate projects and such

moring4• 9 years ago

To add why an open-source toolchain would be useful:

It lowers the barrier to entry for FPGA development significantly. The Papilio project, for example, tries to build an "Arduino for FPGA" and runs into the problem that a full ISE or Vivado installation and corresponding license is needed. This aggravates the primary problem that the Arduino has solved for microcontrollers, easy entry.

Also: Incremental builds, partial reconfiguration, porting to macOS. I'm not sure which of these Vivado has solved. With an open-source toolchain, those interested in these features at least have a chance of building them themselves.

blacksqr• 9 years ago

The site http://opencircuitdesign.com is ancient, but it appears the tools are still getting updated. For example:

Qflow 1.1: An Open-Source Digital Synthesis Flow

http://opencircuitdesign.com/qflow/

last release: Oct. 28, 2017

andars2• 9 years ago

Xilinx has a pretty clear disincentive to optimizing Vivado for minimum area. If it does a bad job optimizing, the user is forced to switch to a larger FPGA -> more $ for Xilinx.

gruez• 9 years ago

How does that even make sense? It's like saying intel cripples their processors so they can sell more.

tails4e• 9 years ago

That's definitely not true. There is strong market competition, so the tools are highly optimized. In fact if you have written logic that vivado detemines is impossible to reach it removes it, and everything connected to it, and so on. I've seen it do really amazing optimizations this way and it's all to save area. So while being inefficient it may seem like a sensible thing to do in a monopoly situation, there is a healthy duopoly, the tools squeeze every last bit of performance out of the device. Tool performance is a selling point.

userbinator• 9 years ago

It seems every few years someone does this publicly, and then either gets DMCA'd or forgotten. Nonetheless, the extremely regular structure of FPGAs, along with the availability of official documentation (which basically explains everything but stops short of mentioning which bits control what) mean that it's not all that difficult of a problem to "connect the dots".

As I've mentioned before, the bitstream formats are one of the worst-kept secrets in the industry. The only reason they aren't revealed more often is for legal, not technical reasons. I'd almost bet that a considerable number of those who work with FPGAs have figured out at least part of the structure and kept it to themselves.

moring4• 9 years ago

That makes me wonder whether it would be more DMCA-safe / lawsuit-safe to not reveal the format itself but rather the exact process to discover it (avoiding endless hours of dead-end experiments because of a wrong assumption about the format)...

adwn3• 9 years ago

I'm replying here to a different comment of yours, which has been flagged for some reason.

Do you have any good source of what these problems are?

A quick list:

* Bad verification support. Serious verification takes at least as much effort as the implementation. Improving that is a hard problem, and you won't know if you've improved it unless you have experience with real-world designs.

* Bad support for sequential code. Contrary to what is taught at college, there is a lot of sequentialism in non-trivial designs (except if you design a CPU, but hardly anybody does that). Basically every protocol is sequential. Even most of the smaller external devices, like ADCs or DACs, typically have a sequential interface. VHDL and Verilog require you to explicitly code a state machine, which is needlessly verbose and error-prone.

* Lack of transparency. If the route tool can't meet timing, you have to be able to map the tool's report of the critical path to your high-level design, or you'll have a big problem at the most inconvenient time.

* Lack of a convenient VHDL/Verilog interface. If you can't easily instantiate VHDL/Verilog IP cores, your language will be an academic exercise, at most.

navaati• 9 years ago

Sorry to be offtopic but I think the sibling comment by @moring should be unflagged, don't know why it is…

loup-vaillant• 9 years ago

The only reason [bitstream formats] aren't revealed more often is for legal, not technical reasons

Any idea what these reasons might be? I mean, it's the vendor's format, why couldn't they reveal it?

monocasa• 9 years ago

I think he's saying that the vendors will sue you.

All of that being said, what bits are what mux and what LUT in the bitstream is only a small piece. All of the information needed for timing is the hard part.

datenwolf• 9 years ago

It seems every few years someone does this publicly, and then either gets DMCA'd or forgotten.

Luckily the guys who do this do not live or work in the USA, but in Austria, so Austrian and European Law applies:

http://eur-lex.europa.eu/legal-content/EN/TXT/?qid=143505754...

"(…) It has therefore to be considered that, in these limited circumstances only, performance of the acts of reproduction and translation by or on behalf of a person having a right to use a copy of the program is legitimate and compatible with fair practice and must therefore be deemed not to require the authorisation of the rightholder. An objective of this exception is to make it possible to connect all components of a computer system, including those of different manufacturers, so that they can work together. (…)"

Essentially this means, that reverse engineering with the intent of creating a cleanroom implementation of a compatibility layer or independent toolchain is perfectly legal.

callesgg• 9 years ago

He kind of looks like Christopher Walken.

vinchuco• 9 years ago

What tool is he using to show the circuit layout?

pankajdoharey• 9 years ago

Really quite impressive work.

Reverse-engineering FPGAs [video]

Related Stories