Reverse-engineering FPGAs [video]
media.ccc.de
media.ccc.de
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.
> 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.
Any idea what these reasons might be? I mean, it's the vendor's format, why couldn't they reveal it?
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.
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.
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.
There are ways round this by compiling to Verilog (eg Chisel) but it's an uncomfortable halfway house.
Also what's wrong with old languages? Looks at C for instance which is much older than VHDL or Verilog.
HDLs are not bad, but not having the option to explore better options is bad
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.
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.
Feel free to open an issue on GitHub to start a discussion. (I'm hesitant to post my private email address here -- old habits.)
> 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.
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.
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.
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
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.
Qflow 1.1: An Open-Source Digital Synthesis Flow
http://opencircuitdesign.com/qflow/
last release: Oct. 28, 2017
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.