Reverse-engineering FPGAs [video](media.ccc.de)
media.ccc.de
Reverse-engineering FPGAs [video]
https://media.ccc.de/v/34c3-9237-reverse_engineering_fpgas
43 comments
What tool is he using to show the circuit layout?
Really quite impressive work.
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.
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.
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
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
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
https://media.ccc.de/v/34c3-8818-designing_pcbs_with_code
When I used Vivado a couple years ago on the Zynq, I was shocked by this. It was supposed to replace ISE, but was equally bad at version control. Absolutely ridiculous.
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
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.
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.
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
Qflow 1.1: An Open-Source Digital Synthesis Flow
http://opencircuitdesign.com/qflow/
last release: Oct. 28, 2017
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.
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.
These are blocks designed by us. I put now basic configuration of the block as separate Vivado project to git. That’s the pain...
Not sure how much you have looked into it, but the tcl scripts can be quite handy for some things. You can also drive quite a few things from the command line. So depending on what your doing you could just have some text files instead of a whole project being pushed to a git repository.
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.
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.
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.
There are ways round this by compiling to Verilog (eg Chisel) but it's an uncomfortable halfway house.
> 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.
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.
Do you have any good source of what these problems are? The reason I am asking is because I too am designing my home-grown HDL at the moment because I grew tired of both Verilog and VHDL. Since I never programmed FPGAs professionally -- the whole thing is a pet project only -- I'm likely to repeat those mistakes because I don't even know about them.
Note that I don't expect problems in the basics of language design and building tools, but rather specific mistakes in the context of FPGAs.
Note that I don't expect problems in the basics of language design and building tools, but rather specific mistakes in the context of FPGAs.
I'm curious to know more about your HDL, as I'm also working on an HDL of my own.
The code is at https://github.com/MartinGeisse/mahdl-plugin
Feel free to open an issue on GitHub to start a discussion. (I'm hesitant to post my private email address here -- old habits.)
Feel free to open an issue on GitHub to start a discussion. (I'm hesitant to post my private email address here -- old habits.)
It's actually kinda funny you mentioned designed without understanding FPGA development. VHDL predates FPGAs. Further, there are a lot of features that exist that are un-synthesizable. Some belong to the analog world. Some can't even be really even be used to build a real device.
Don't get me wrong – VHDL is a terrible language for design and verification (just like Verilog). Some of those new high-level languages are actually better than VHDL and Verilog, but not sufficiently better to overcome the momentum of the old languages.
> VHDL predates FPGAs
I was using "FPGA design" as a placeholder for digital logic design in general, given that by far the most VHDL and Verilog is written for FPGAs today.
> VHDL predates FPGAs
I was using "FPGA design" as a placeholder for digital logic design in general, given that by far the most VHDL and Verilog is written for FPGAs today.
Well, I kind of prefer VHDL.
Same. My main reason is Verilog does not make a distinction between variables and other objects. Verilog treats almost everything as if it were an assignment type. Furthermore, variables in verilog are shared by default. VHDL shows how it should be done. There is a clear distinction between signals and variables. Additionally, variables are local by default.
My opinion of course. Although VHDL can be bit more wordy. However, that's least of my worries (wordiness) when designing something. I would rather have clear semantics for me and other people on what the heck is going on.
My opinion of course. Although VHDL can be bit more wordy. However, that's least of my worries (wordiness) when designing something. I would rather have clear semantics for me and other people on what the heck is going on.
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.
Also what's wrong with old languages? Looks at C for instance which is much older than VHDL or Verilog.
SystemC and every other high level synthesis language, has to be translated to VHDL/verilog first. That's a big difference with software land.
HDLs are not bad, but not having the option to explore better options is bad
HDLs are not bad, but not having the option to explore better options is bad
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.
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.
How does that even make sense? It's like saying intel cripples their processors so they can sell more.
No, it's like saying the only compiler for x86 is created by Intel (paid for by the sale of processors) and they therefore don't have an incentive to make the compiler particularly good at optimizing. If it does a better job at optimizing, people can get away with cheaper processors.
I'm not saying there is any intentional area bloating going on, just that there is little incentive to make Vivado better at optimizing.
Read https://www.bunniestudios.com/blog/?p=5018 to see where I'm coming from.
EDIT: It makes a lot of sense in my head, but perhaps I'm overlooking something important. I'd be interested to read in more detail why it doesn't make sense to you.
I'm not saying there is any intentional area bloating going on, just that there is little incentive to make Vivado better at optimizing.
Read https://www.bunniestudios.com/blog/?p=5018 to see where I'm coming from.
EDIT: It makes a lot of sense in my head, but perhaps I'm overlooking something important. I'd be interested to read in more detail why it doesn't make sense to you.
Quite a few groups of lower-end Xilinx FPGAs (e.g, XC7S6/15, or XC7A15T/35T/50T) are all physically the same silicon, but are sold under multiple SKUs with different chip IDs, with the synthesis software forced to leave some percentage of the area unused. Open-source synthesis tools would probably break this part of their business model. :)
Intel a disincentive to be more advanced than a sufficient margin over the current competition. You saw the stagnation after Haswell.
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.
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.
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.
> 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.
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.
> 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?
Any idea what these reasons might be? I mean, it's the vendor's format, why couldn't they reveal it?
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.
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.
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)...
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.
> 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.
Sorry to be offtopic but I think the sibling comment by @moring should be unflagged, don't know why it is…
He kind of looks like Christopher Walken.