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.
"(…) 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.
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.
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.
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.