bitstream secrecy

David Kuehling dvdkhlng at
Tue Sep 7 17:42:56 EDT 2010

>>>>> "Wolfgang" == Wolfgang Spraul <wolfgang at> writes:


> For the bitstream, there is an open slot in the hall of hacking fame
> for someone to reverse-engineer the bitstream format of one of the
> major FPGA makers, for example the Xilinx bitstream format. We could
> learn a lot from such reverse engineering, and eventually it could
> also help in gaining the knowledge needed to develop a free
> synthesizer, free FPGA, and effective copyleft license.  If you are up
> to it, get a cheap Xilinx board and start hacking :-) If you google
> you can find starting points...

Reverse engineering FPGA internals to the point of making open source
synthesis possible, might require more than just understanding the
bitstream.  One also needs to find out timing constants and constraints
of the (macro)blocks, interconnects etc. and how much these constants
vary for one type of FPGA.  Chasing vendors who bring out new designs
every few years also might get frustrating for developers.

What I find much more interesting than FPGA design reversing, would be
to spend some time to build a (probably minimalistic) generic HDL
synthesis system with a generic and configurable back-end.  At first
maybe only verifying the stuff using simulations with made-up
(i.e. non-existing) FPGAs, without wasting too much time on reverse
engineering (at first).

> I found one quote from 2007 (source seems offline)
> " In the world of software
> running on microprocessors, device vendors generally publish their
> product’s bit-stream format in an architecture manual for use by
> third-party compiler writers. The roles of chip designer and compiler
> writer are effectively decoupled.

> In the world of FPGAs, the situation is quite different. Since the
> discontinuation of the XC6200 series in 1998, the trend has been
> overwhelmingly in the direction of bitstream secrecy. Currently no
> major vendor discloses the bitstream format of their device. This has
> had the effect of stunting research in several areas, including
> partial reconfiguration, evolvable hardware, and fault recovery.
> Additionally, alternative design methodologies such as self-timed
> circuitry or pausible clocks become difficult to implement properly if
> the manufacturer’s tools do not support them."  "

If this is true, then an open-source synthesis system might find some
use in research, even if incomplete or lacking support for real
hardware.  Not too bad conditions for such a project.

Also, when chinese companies can design their own (MIPS) CPUs, then what
keeps them from doing their own FPGAs?  Is this also just the lack of

Just to get an idea.  What would one need for the minimal working
synthesis system that's generic enough to be adapted to current
main-stream FPGAs?  From my memory and a little googeling I'd start the
list with:

* design entry 
  - schematic entry: can use gschem with a library of corresponding
    components and just need to code a (simple?) EDIF export filter?

  - HDL is more difficult: need to write a HDL -> EDIF compiler from
    scratch?  Could reuse the VHDL parser frondend of ghdl.

* map to device resources
  - no clue  (optimization of boolean equations done here?)

* place and route
  - just an optimization problem :) AFAICS there are no high-quality
    open source optimization frameworks around.  Can this be reduced to
    just a few general but powerful solvers?  convex relaxation and SDP
    or geometric optimization?  maybe much more difficult than i can

* timing analysis
  - no-brainer?

* generate bitstream
  - depends on reverse engineering

Naive?  Completely undoable?  What do you think?

GnuPG public key:
Fingerprint: B17A DC95 D293 657B 4205  D016 7DEF 5323 C174 7D40
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the discussion mailing list