sebastien.bourdeauducq at lekernel.net
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,
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
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
* 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
(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 http://www.ulogic.org
> 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