

BORPH: An Operating System for FPGA-Based Reconfigurable Computers - Cieplak
https://casper.berkeley.edu/wiki/BORPH

======
ChuckMcM
Ok, this is insanely cool. This is the kind of thing I could get lost in just
sitting around week after week figuring out new ways to utilize this sort of
technology. About 8 - 10 years ago when I talked with the Stretch guys (they
did dynamic compilation into FPGA "hard" logic and computational "soft" logic)
I was wondering if anyone was thinking about a general purpose approach. An
argument I've had off and on with various Intel and AMD account managers has
been "What if my app doesn't use the FPU, can I turn it off entirely? Then
what is my TDP? Could you give me a switch so that I could add another compute
core if I didn't use the FPU? Or GPU?" Their response was Larrabe and the APU
stuff that AMD/ATI has done, "lightweight" reconfigurable cores for either
graphic type operations or integer operations.

------
vasco
If someone who is more knowledgeable can answer, how would this compare to
existing soft processor cores such as MicroBlaze?

~~~
alecdibble
Here is a better description of Borph:
<http://bee2.eecs.berkeley.edu/wiki/Bee2OperatingSystem.html>

Here is also a much clearer explanation taken from that link:

    
    
      BORPH is an extended Linux kernel that treats FPGA resources as native computational resources on reconfigurable computers such as BEE2. As such, it is more than just a way to configure an FPGA. It also provides integral operating system supports for FPGA designs, such as the ability for an FPGA design to read/write to the standard Linux file system.
    

If it supports partial-reconfiguration (which it looks like it does), then it
could be a very handy tool. Why? Hardware is significantly faster than
software. While Linux is running, the ability to spawn hardware at will would
be great for many applications.

At UCSB, some of the research I did related to this very problem. What I was
trying to do was have a Linux web server running on an FPGA that could
dynamically reconfigure itself for different experiments. I ended up choosing
a board that has an FPGA that communicates with a ARM processor. Decent size
FPGAs were (and still are) expensive. For all the Linux overhead and my
budget, a hybrid FPGA-processor platform turned out to be the better solution.
If anyone is interested, here is the problem we were solving:
[http://ece.ucsb.edu/academics/undergrad/capstone/presentatio...](http://ece.ucsb.edu/academics/undergrad/capstone/presentations/flexSD-
poster.pdf)

------
Cieplak
<https://github.com/brandonhamilton/BORPH>

[http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-92...](http://www.eecs.berkeley.edu/Pubs/TechRpts/2007/EECS-2007-92.html)

------
andrewcooke
how do these compare to gpus? a kind-of client is considering using this or
something similar to process radio data (calculating correlatins i assume) and
i'm curious what chance i have of selling him a gpu based solution instead.

~~~
Cieplak
_In fact, initially JP Morgan looked at GPUs for acceleration. They ported one
of their models to the graphics architecture and were able to get a 14- to
15-fold performance boost. But they thought they could do even better with
FPGAs. The problem was that it was going to take about 6 months for an initial
port. That's when they went to Maxeler and initiated a proof-of-concept
engagement with them._

[http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_int...](http://www.hpcwire.com/hpcwire/2011-07-13/jp_morgan_buys_into_fpga_supercomputing.html)

~~~
groby_b
Color me skeptical. The FPGA version was basically a rewrite, removing all
kinds of OO overhead (objects/classes, templates, etc.)

I would not at all be surprised that if that cleaned up code was ported to a
GPU, you'd see a much bigger speedup.

And if they did this for the GPU code, I'm not quite sure why they needed a
consultant to do the same thing before starting to work on FPGA code.

I'm not saying the numbers are wrong, but this is certainly insufficient data
for any decision :)

~~~
marshray
_GPUs [...] were able to get a 14- to 15-fold performance boost [...] Their
Monte Carlo model, for example, was able to realize a 260- to 280-fold speedup
using FPGA acceleration._

These numbers are consistent with other computations I've seen that were well-
suited for FPGAs.

~~~
groby_b
14x seemed awfully small. Looking at e.g. <http://mcx.sourceforge.net/cgi-
bin/index.cgi>, they see a ~300x speedup for a monte carlo simulation on the
GPU.

(Note - it might well be that the FPGA version of that particular problem
would be even faster. I merely posted the GP to point out that there was
_significantly_ more effort to tailor the model towards the FPGA than towards
the GPU, which seemed to be merely a "compile for GPU" without a restructuring
to make the data model fit.)

~~~
marshray
I've also heard that financial companies needed good double precision support,
which was not always fully performant on GPUs.

