
Reverse-engineering FPGAs [video] - anfilt
https://media.ccc.de/v/34c3-9237-reverse_engineering_fpgas
======
userbinator
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.

~~~
moring
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)...

~~~
adwn
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.

------
lnsru
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.

~~~
pjc50
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.

~~~
adwn
> _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.

~~~
moring
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.

~~~
ChickeNES
I'm curious to know more about your HDL, as I'm also working on an HDL of my
own.

~~~
moring
The code is at [https://github.com/MartinGeisse/mahdl-
plugin](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.)

------
vinchuco
What tool is he using to show the circuit layout?

------
pankajdoharey
Really quite impressive work.

------
callesgg
He kind of looks like Christopher Walken.

