bitstream secrecy

Sébastien Bourdeauducq sebastien.bourdeauducq at
Tue Sep 7 18:16:08 EDT 2010


On Tuesday 07 September 2010 23:42:56 David Kuehling wrote:
> 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.

$ speedprint 6slx45
Loading device for application Rf_Device from file '6slx45.nph' in environment 
Family spartan6, Device xc6slx45

Block delay report for device: 6slx45,  speed grade: -3

                          Fast Corner                          Slow Corner
                          Min/Max, Min/Max(when applicable)     Min/Max, 
Min/Max(when applicable)


Tgi0o                     (59/63)                               (197/209)


Tgi0o                     (59/63)                               (197/209)
Tgi0s                     (-21/-21, -15/-15)                    (-47/-47, 
Tgi1o                     (59/63)                               (197/209)
Tgi1s                     (-21/-21, -15/-15)                    (-47/-47, 

Other timing parameters (if any) can also be easily found using the "Delay" 
option in FPGA editor.

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

There will be little or no reverse engineering involved in this step if 
targeting real Xilinx FPGAs.

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

There are already a couple of academic FPGA synthesizers targeting virtual 
FPGAs; most of them are unusable crap. There is often good theory, but the 
coding is horrible, and in the uncommon case where the tool compiles at all*, 
bugs are prevalent and functions that would enable any practical use of the 
tool are absent.

* you'll routinely come across trivial C coding errors like functions with two 
parameters having the same name, inconsistent static and non-static 
declarations, etc. Obviously they did not test their program and it makes me 
wonder how they obtain the results in their papers.

The bottom line is: read the papers, understand the ideas, but make your own 
opinion and do your own coding.

> 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
> software?

Usually, yes. FPGA synthesis tools aren't easy to write.

>  - schematic entry

Forget about this, no serious FPGA design uses schematic entry nowadays.

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

GHDL is based on GCC (iirc) so please don't. Maybe my standards are high, but 
I think you'd be much better off writing your own parser from scratch.
Also, Verilog is simpler to parse and synthesize than VHDL so it's probably a 
better thing to start with (and it also enables you to use Milkymist SoC as a 
test case ;).

The basic strategy is (let's focus on synchronous designs, which covers most 
FPGA designs):
* determine the clock signals
* for each clock:
** determine where the registers are
** determine logic equations between them and reduce them to a mix of BDDs, 
arithmetic operators, etc. (see below)

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

Here is some:

A common error that all academic synthesizers fall for (afaik) is to reduce 
everything to a BDD and then try to optimize the resulting soup, often with 
results of dubious practical relevance. This is why we must throw away 
intermediate formats like Berkeley Logic Interchange Format (BLIF) and the 
VHDL subset that Alliance VLSI uses and develop our own - those are flawed by 
design and stifle the use of dedicated FPGA circuitry (carry chains, hardware 
multipliers, hardwired muxes, shift registers, RAMs, etc.) resulting in poorly 
performing circuits. A good intermediate reprentation would strike a 
compromise between the super-low-level BDDs and the high-level Verilog/VHDL. 
For example, we can imagine a format that allows mixing BDDs (to be mapped on 
pure LUTs) and arithmetic operators (to be mapped using carry chains or 
dedicated multipliers).

(You also have particular cases like FSMs, RAMs, shift registers, etc. that 
can benefit from specific synthesis and/or mapping treatment as well)

> * place and route
>   - just an optimization problem :)

Yeah, "just" an optimization problem :p
This tool looks interesting:

> * timing analysis
>   - no-brainer?

This one is relatively simple, basically just measure the post place and route 
combinatorial and net delays on all data paths between the registers.
Timing analysis must be built into the P&R tool, too (so it knows what to 

> * generate bitstream
>   - depends on reverse engineering

Indeed, and I think this is the only part that does. It probably won't be 
hardcore reverse engineering too. See

> Naive?  Completely undoable?  What do you think?

Good approach, but quite a lot of work that puts off most open source 


More information about the discussion mailing list