Hello,
I've been lurking here for awhile now, and have been waiting for the
conversation to turn in this direction....
I'm an fpga designer by day, and hobby computational linguist by
night, so I (perhaps egotistically) feel particularly qualified to
comment on this area.
While it is true that the open bitstream has gone the way of the
dinosaur, this should not be seen as much of a limiting factor. It
is the rare software engineer who delves into the microcode format of
the CPU, and the bitstream should be viewed in the same light. While
it is true that this means there will be a "proprietary bit of
software" performing the last step in your hardware compilations....
this is really no different from the "proprietary bit of hardware"
performing the last step in your software compilations. (machine
opcodes being translated into re-ordered microcode by the cpu)
Neither is something anyone has much occasion to delve into.
However, this is not to say that the situation is not ideal. For one
thing, this proprietary tool may be grossly inefficient for your
needs (the microcode systems in the cpu are rarely pointed to as a
bottleneck... much the opposite with vendor bitstream tools!) For
another, it is possible that your "host system" on which the
bitstream should be generated may not be a "supported" pc
configuration, or may not even be a pc at all! It is in these sorts
of situation that the vendor tool does become a hinderance...
I am consistently saddened by the fact that people point to "no open
bitstream format" as a reason for lack of progress on "fpga
computing" projects. For the majority of the research necessary in
these areas, the bitstream black box *shouldn't* be a show stopper.
And if it is... as mentioned in the xwt.org link you pasted, it is
indeed not very difficult to reverse engineer a bitstream. (at least
to the point where you can regenerate a "re-synthesizable" edif...)
Sadly, the majority of "experts" in this area are not sharing there
processes, as they are generally in the business of design theft. (I
was once emailed a bitstream and corresponding machine generated edif
for one of my own designs, which had been promptly "cloned" upon it's
commercial release. We have been reluctant to put any faith in
Xilinx "design security" since.)
Another option, aside from reverse engineering the bitstream, is to
simply engineer a new bitstream format. I regularly work with a
"meta-fpga" design where the design programmed onto the fpga fabric
in turn has it's own reprogrammable elements. Unfortunately, this
approach can have significant impact on performance, sometimes seeing
as much as a 70% overhead in resource consumption... eek! (this is
not to say it is always so inefficient, in many cases the overhead is
a negligible 1-2%) I have yet to take this approach to the next
step, an asic implementing the reprogrammable design (in essence, at
this point you have just made a new fpga) but I expect that this may
become common practice over the next 5 to 10 years, as we are seeing
more and more hardware pop up with "field programmable array"
elements. (Cell processor, GPUs, etc) Usually these are coarser-
grained then gate-level (actually "cell/tile/slice/other-vendor-term-
here level") programability of FPGAs, but this trend is shifting as
well.
What we really need is not an open bitstream format, as that is a
minor annoyance only. The *true* limiting factor in research towards
such concepts as on-the-fly reconfiguration, evolvable machines, and
other "runtime hardware" dreams is a problem of lack of
approachability of the problem. Today, even an amateur systems
engineer can delve into the world of GPU metaprogramming, in a
language as approachable as python. An engineer wishing to do the
same at a fine grained, gate level of an fpga is faced with a
daunting challenge of poor languages (vhdl/verilog/edif are not
pleasent to work in, by any means) poor debugging tools (trying to
find an unintentional race condition in a small subcomponent of your
circuit buried in a multi-million gate design is a nearly intractable
problem for most, even though it is something that could be handled
by the tools) and poor educational resources. (The background
knowledge required to succeed at any substantial approach to these
techniques generally requires years of specialized training, coupled
with years of practical experience in the field)
Perhaps we can start working together to resolve these real issues,
instead of just giving up at "welp, we can't delve into the
bitstream, so we must be screwed."
--Nathan
On Nov 27, 2007, at 12:31 PM, Toby Watson wrote:
Hi
Does anyone know if an open toolchain is available for any FPGA
series?
I think Xilinx's open bitstream experiments began and ended with
the 62* series, when they acquired the small firm Algotronix. 62*
series is rather old too. I believe some of their newer devices
offer "partial reconfiguration" : http://tinyurl.com/yqk6c4 . This
works a bit like memory overlays in certain machines.
Generally FPGA vendors are protective of their bitstream formats
and this precludes the possibility of open (and self-hosting)
software -> hardware translators.
Of course if you don't mind having a proprietary bit of software in
the loop then many experiments are possible. JBits is probably as
close as one can get for now: http://tinyurl.com/2fehf6
Open Cores project is a good place to track the open state of the
art: www.opencores.org
Closed Bitstream Sadness here
http://xwt.org/thoughts/bitstream.secrecy.html
http://www.tuxdeluxe.org/node/204
One day, hopefully one day...
Toby
On 27 Nov 2007, at 16:34, Antoine van Gelder wrote:
Ian Piumarta wrote:
Several of us here (at VPRI) are interested in the potential of
better synergy between hardware and software. Something we'd
love to see is the *OLA back-end generating netlists for FPGAs,
or better still reprogramming them on the fly (which I'm told is
possible, but I've yet to see an example). Just-in-time software
deserves just-in-time hardware, no? ;-)
Was looking at FPGA's a month or two ago asking questions about
reconfigurability and clockless computing and apparently the
Xilinx 62* series of FPGAs are not only capable of being rewritten
on the fly but - even better - you can reprogram only a subset of
the gates if you want!
Also looks intriguing: http://www.falvotech.com/blog/index.php?/
archives/200-Forth-Day-Report.html
- a
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
