Is it possible to "read out" whatever logic the FPGA was previously programmed with? If the speculation that it came from the Bing accelerator is correct, you might end up with some interesting code...
The bitstream that's loaded into the FPGA is very, very far from anything that would look like normal code. Additionally, all major commercial FPGAs have complex facilities for encrypting the bitstream that completely hides it's contents.
So it may be possible, but the architecture of the FPGA is not documented, so you'd have to completely reverse engineer the bitstream format, and if the protection is enabled, that'd still get you nowhere.
And aside from the encryption there's been a lot of work on FPGA bitstream reverse engineering tools, so the output wouldn't be meaningless—it would just take some effort to figure out what it's doing.
In fact there is a very nice tool for visualizing and analyzing a netlist taken from an FPGA called HAL[0]. In school we used this tool to e.g. modify S-Box output to retrieve an AES key when encryption was implemented within the netlist.
The bitstream isn't always secured, and when it is it's not the deepest security, but unless you either have a lot of time or a brilliant insight you probably aren't going to get too far with a raw bitstream.
Useless. The drivers are horrible and the state of the tooling is insanely bad. The vendors have no clue, Intel personnel have no clue as they don't care about OpenCL 2.0 but will still gladly charge $10,000 in licenses if you really want to go that route. Verilog/VHDL is wtf, and you still need to redo your drivers.
So much potential.
I talked to a couple companies that use these in production, they reveal that they wrote their own drivers and still have issues.
You pretty much have to be a Microsoft doing sci-fi tech to get the benefits out of these, and it doesn't have to be that way.
oh its not, I've heard the exact same thing from Xilinx users. The whole space is ridiculously bad and undermaintained while simultaneously having come a long way. I'm probably not the first person over the last 35 years to say this, but they are right at the cusp of a big breakthrough in utility.
OpenCL was a nice try but everyone did their own thing with it and are now going back to their own vendor specific frameworks. No leadership, irreconcilable business decisions, unnecessarily crippling an open source community, software licenses are too expensive probably because they can't mass monetize the FPGAs. Its just really bad, it doesn't seem like it belongs in this century.
The tooling is bad because it is a Katamari Damacy of 3rd party libraries held together with wheat paste and boogers. The majority of the software was not developed in house, and they pass the savings on to the customer.
The FPGA vendors see themselves as ASIC replacements so from their perspective they are "killing it" across all metrics. We know where this needs to go.
Doing new drivers is not a huge deal. At least you are programming them in C with sane tooling against a sane API. Getting up a simple setup with a bit of DMA and a few registers is not that hard. It pales compared to the amount of pain you will go through working with the FPGA tooling. The insanity begins with the fact that they are very GUI centric with comparatively little guidance on batch processing capabilities. This is despite the fact that you usually run these tools on ~80 core servers, so you have nicely lagging X11 windows all day
If you don't already have the sort of corporate hookup that the author has (R&S test gear on an ESD mat smells pretty telltale), then plan on throwing down at least another US$3K for a Quartus Prime Standard[1][2] license to PNR this target for shits and grins.
This is a pretty awesome FPGA for the price but the tool licenses are a few $K if you want to stay strictly legal. For Xilinx you can actually rent a full Vivado tool AMI on AWS, but I'm not aware of any similar offering for Quartus.
What is the purpose of this card? I'm familiar with using GPUs and even TPUs for some task specific acceleration but what's the point of a chip like this? Does this speed up arbitrary C code? I understand that an FPGA is in the middle of the CPU - ASIC spectrum, but what are the potential speedups for various types of code?
E.g. for FPGAs in general: multiplexing I/O, such as audio hardware managing hundreds of channels of digital audio for a theme park parade PA system over several different busses including Ethernet.
An FPGA can be thought of as programmable hardware. An FPGA chip has many many thousands of very flexible logic blocks, and a matrix of interconnects to connect those logic blocks together arbitrarily. Software tools allow you to describe a complex digital circuit, and the design is compiled down into a bitstream that configures the FPGA's blocks and interconnects to implement the circuit. In addition to internal connections, the circuits can be connected to external IO pins.
The logic blocks and interconnects are relatively slow compared to a tailor made ASIC, but they're still generally capable of propagating signals approaching GHz clock rates.
As an example, with a really nice CPU you might be able to run billions of instructions per second, but you are limited to what those instructions can do. If you want to sum a bunch of integers, you need to do it sequentially by implementing a loop. Maybe you can sum 1 billion integers per second. With an FPGA, you could instead use the available blocks to implement a thousand adders in a logarithmic pyramid, able to sum 500 numbers at once at say 100Mhz, and the circuitry to speak to a CPU and its memory directly over PCI-E. Now, you can sum 50 billion integers per second, assuming the RAM can even keep up.
I can't imagine there's any automatic speed up of C code with this specific card, unless the card maker implemented a really fancy compiler. More likely, there's a specific algorithm that the card was designed to do in parallel faster than a CPU can. Someone had to implement that algorithm in a language that could be compiled down to the FPGA bitstream. On top of that, it's possible the card wasn't even meant to be tightly coupled to a traditional CPU. It's possible that the FPGA was meant to participate directly on a data center network and respond to requests directly. The whole "program" could be implemented as state machines in digital logic, including the TCP/IP stack. Also, "soft" CPUs can be implemented inside an FPGA, making it possible to run traditional programs too.
You can generally use an FPGA to implement any algorithm that's parallelizable to some degree. As a master's project 11 years ago, my team accelerated stereo disparity calculations with an FPGA. The idea is that you match similar pixels between two spatially separated images in order to generate a depth map. It's an expensive calculation. At the time, a CPU could manage a few frames per second from 480p webcam streams. The FPGA version could handle hundreds of frames per second. We couldn't feed it in video fast enough. Of course, nowdays a modern GPU running a shader program might be faster.
I was just about to say: when to use an FPGA over a gpu? There are a few GPU gems books that describe what kind of code runs best on GPUs, and you can buy 30TFlops for $700 these days.
I know gpu is not so good beyond single precision. Is that the application? Do you recommend a similar FPGA gems book/website?
I see there is: designing with xilinx fpgas, design warriors guide to fpgas
It really comes down to how well a GPU's capabilities align with the problem you're trying to solve. A modern GPU is basically thousands of really simple CPUs that all
run the exact same program but on different input data. Communication between those CPUs while the program is running is incredibly bad for performance. If your problem is solvable within those limitations, then a GPU is a good choice.
An FPGA gives you more flexibility because you can dedicate hardware exactly where you need it. You don't even need to stick with common data widths. If you only need 11 bits, then there's no need to do 32 bit math, for example.
An ASIC with custom circuitry will generally be the fastest, lowest power way to solve a problem, with the lowest per-unit cost, but it has absurdly high development and initial tooling cost. An FPGA gives you the benefits of custom circuitry with significantly lower development cost (than an ASIC), but it's less power efficient and the unit cost is relatively high for what you're getting. A GPU gives you good power efficiency, good development cost, and good unit cost if your problem maps well to what GPUs can do. A CPU gives you the lowest development cost, but sets a mediocre baseline for power efficiency and unit cost.
middle of the CPU-ASIC spectrum? Not sure that's true, bitcoin miners started out on CPU, moved to GPU, and during that period also did some mining with FPGAs before quickly moving to custom ASICs.
I now understand what is a source of cheap high end FPGAs on AliExpress. Though buying complete board does not make much sense, because it lacks the Golden Top project with all pin assignments and clocking constraints. This particular Stratix V has tons of logic elements and on chip memory, but applications are still rather limited for it. I did this before too, was curious how chip for $20k looks like :-)
My advice: get some board from Digilent, they have examples and active support forum. It will be more useful on the long run.
There are tons of old FPGA boards on eBay for cheap, but they're basically unusable. Even if it was a popular dev kit at the time, chances are all documentation has 404ed.
27 comments
[ 3.0 ms ] story [ 72.4 ms ] threadSo it may be possible, but the architecture of the FPGA is not documented, so you'd have to completely reverse engineer the bitstream format, and if the protection is enabled, that'd still get you nowhere.
Stratix II: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.58...
There's been a little work on vulnerabilities in the Stratix V, though AFAICT no break on the encryption: http://www.ecs.umass.edu/ece/tessier/ramesh-fccm18.pdf
And aside from the encryption there's been a lot of work on FPGA bitstream reverse engineering tools, so the output wouldn't be meaningless—it would just take some effort to figure out what it's doing.
[0] https://github.com/emsec/hal
Useless. The drivers are horrible and the state of the tooling is insanely bad. The vendors have no clue, Intel personnel have no clue as they don't care about OpenCL 2.0 but will still gladly charge $10,000 in licenses if you really want to go that route. Verilog/VHDL is wtf, and you still need to redo your drivers.
So much potential.
I talked to a couple companies that use these in production, they reveal that they wrote their own drivers and still have issues.
You pretty much have to be a Microsoft doing sci-fi tech to get the benefits out of these, and it doesn't have to be that way.
OpenCL was a nice try but everyone did their own thing with it and are now going back to their own vendor specific frameworks. No leadership, irreconcilable business decisions, unnecessarily crippling an open source community, software licenses are too expensive probably because they can't mass monetize the FPGAs. Its just really bad, it doesn't seem like it belongs in this century.
[1] https://symbiflow.github.io/
[2] https://www.chisel-lang.org/chisel3/
The FPGA vendors see themselves as ASIC replacements so from their perspective they are "killing it" across all metrics. We know where this needs to go.
https://www.microsoft.com/en-us/research/uploads/prod/2014/0...
https://j-marjanovic.io/stratix-v-accelerator-card-from-ebay...
https://j-marjanovic.io/stratix-v-accelerator-card-from-ebay...
https://j-marjanovic.io/stratix-v-accelerator-card-from-ebay...
Most QSFP DAC cables are passive and do not use power for anything other than their ID EEPROM.
[1] https://www.intel.com/content/dam/www/programmable/us/en/pdf...
[2] https://www.intel.com/content/www/us/en/programmable/buy/des...
The logic blocks and interconnects are relatively slow compared to a tailor made ASIC, but they're still generally capable of propagating signals approaching GHz clock rates.
As an example, with a really nice CPU you might be able to run billions of instructions per second, but you are limited to what those instructions can do. If you want to sum a bunch of integers, you need to do it sequentially by implementing a loop. Maybe you can sum 1 billion integers per second. With an FPGA, you could instead use the available blocks to implement a thousand adders in a logarithmic pyramid, able to sum 500 numbers at once at say 100Mhz, and the circuitry to speak to a CPU and its memory directly over PCI-E. Now, you can sum 50 billion integers per second, assuming the RAM can even keep up.
I can't imagine there's any automatic speed up of C code with this specific card, unless the card maker implemented a really fancy compiler. More likely, there's a specific algorithm that the card was designed to do in parallel faster than a CPU can. Someone had to implement that algorithm in a language that could be compiled down to the FPGA bitstream. On top of that, it's possible the card wasn't even meant to be tightly coupled to a traditional CPU. It's possible that the FPGA was meant to participate directly on a data center network and respond to requests directly. The whole "program" could be implemented as state machines in digital logic, including the TCP/IP stack. Also, "soft" CPUs can be implemented inside an FPGA, making it possible to run traditional programs too.
You can generally use an FPGA to implement any algorithm that's parallelizable to some degree. As a master's project 11 years ago, my team accelerated stereo disparity calculations with an FPGA. The idea is that you match similar pixels between two spatially separated images in order to generate a depth map. It's an expensive calculation. At the time, a CPU could manage a few frames per second from 480p webcam streams. The FPGA version could handle hundreds of frames per second. We couldn't feed it in video fast enough. Of course, nowdays a modern GPU running a shader program might be faster.
I was just about to say: when to use an FPGA over a gpu? There are a few GPU gems books that describe what kind of code runs best on GPUs, and you can buy 30TFlops for $700 these days.
I know gpu is not so good beyond single precision. Is that the application? Do you recommend a similar FPGA gems book/website?
I see there is: designing with xilinx fpgas, design warriors guide to fpgas
An FPGA gives you more flexibility because you can dedicate hardware exactly where you need it. You don't even need to stick with common data widths. If you only need 11 bits, then there's no need to do 32 bit math, for example.
An ASIC with custom circuitry will generally be the fastest, lowest power way to solve a problem, with the lowest per-unit cost, but it has absurdly high development and initial tooling cost. An FPGA gives you the benefits of custom circuitry with significantly lower development cost (than an ASIC), but it's less power efficient and the unit cost is relatively high for what you're getting. A GPU gives you good power efficiency, good development cost, and good unit cost if your problem maps well to what GPUs can do. A CPU gives you the lowest development cost, but sets a mediocre baseline for power efficiency and unit cost.
My advice: get some board from Digilent, they have examples and active support forum. It will be more useful on the long run.