What this guy is doing is amazing, and shows the very sad state of the FPGA scene today.
To give a picture on how important is this, imagine if Intel CPUs were delivered with only the most sparce documentation: it told you how many registers it had and what the instructions could do, but wouldn't tell you anything about register addresses, switches, meaning of each bit or even the individual OPCODES. You would know that there's a floating point unit with divider, but didn't know how to access it, or how to set the register for the division, or even which OPCODE you should use to set it up.
Moreover, the only compiler would be the one send to you by Intel, and the whole compilation process is also pretty much undocumented. Compiler errors would be cryptic and support wouldn't do more than point you in general what kind of problem your code may have triggered - they simply would refuse to tell you specifically what has gone wrong to avoid telling you the details from the compiler processor.
And the compiled code would always have an enormous size and change almost randomly from one compilation to another, making reverse engineering a very difficult and frustrating task.
This is not a perfect analogy (it would still be easier to reverse engineer software in the analogy), but I hope this give an idea of the size of the task this guy has performed. Even if the FPGA is a quite simple and small one, from a second-tier vendor, and only one part number, all my praise to Mathias Lasser and Clifford Wolf.
This is the sad state of FPGA tools nowadays. This has recently been debated in HN (more than once)[1][2], but to contextualize how difficult and important it is. Imagine how GCC, or CLang, or even Microsoft and other compilers would be if this was the case. I highly doubt there would be any Linux or BSD to tell the story if this was the case.
it would still be easier to reverse engineer software in the analogy
Actually, thanks to FPGAs having a very regular structure to them, figuring out their bitstream format is not all that difficult and I can say that it has been done in the past countless times by different people, although not for the same goals as this project. The hurdles are more political/legal than technical; the threat of EULAs, DMCA, etc. is what keeps almost all the work that's done from becoming public. (I would instinctively suggest that their site be mirrored, in case something does happen.)
That said, I agree more open-source FPGA tools are always a good thing, and this project still deserves praise for doing it!
OTOH, at least there are second-tier vendors. I haven't been following FPGA development, and I thought there's just ALTERA and Xilinx. Do you know any others?
Also Atmel, although they're either so new to the market or the volume that they ship is so small compared to other manufacturers that they don't appear in any lists that I've seen.
Atmel have had FPGA devices for a very long time, they also have military specification FPGAs that are probably sat in lots of hardware that would need a constant flow of replacement modules for repair.
I seem to remember that they had some early 8051 and possibly even AVR devices that had some programmable logic blocks on board too.
in a somewhat related field, you find LUTs in PSOC devices from cypress. I was hopping that would be the gateway drug to FPGA. (for now it's mostly an introduction to shitty electronics vendor CAD tools)
To give a picture on how important is this, imagine if Intel CPUs were delivered with only the most sparce documentation: it told you how many registers it had and what the instructions could do, but wouldn't tell you anything about register addresses, switches, meaning of each bit or even the individual OPCODES. You would know that there's a floating point unit with divider, but didn't know how to access it, or how to set the register for the division, or even which OPCODE you should use to set it up.
Moreover, the only compiler would be the one send to you by Intel, and the whole compilation process is also pretty much undocumented. Compiler errors would be cryptic and support wouldn't do more than point you in general what kind of problem your code may have triggered - they simply would refuse to tell you specifically what has gone wrong to avoid telling you the details from the compiler processor.
And the compiled code would always have an enormous size and change almost randomly from one compilation to another, making reverse engineering a very difficult and frustrating task.
This is not a perfect analogy (it would still be easier to reverse engineer software in the analogy), but I hope this give an idea of the size of the task this guy has performed. Even if the FPGA is a quite simple and small one, from a second-tier vendor, and only one part number, all my praise to Mathias Lasser and Clifford Wolf.
This is the sad state of FPGA tools nowadays. This has recently been debated in HN (more than once)[1][2], but to contextualize how difficult and important it is. Imagine how GCC, or CLang, or even Microsoft and other compilers would be if this was the case. I highly doubt there would be any Linux or BSD to tell the story if this was the case.
[1] https://news.ycombinator.com/item?id=5895672 [2] https://news.ycombinator.com/item?id=9408881