Earlier quoted context omitted.
Cool, didn't know that. Is the boot time fairly slow compared to booting a normal PC?
No, we're talking about microseconds.
We're often talking about hundreds of milliseconds.
Why Use an FPGA Instead of a CPU or GPU?
111–120 of 130 posts
Re: Why Use an FPGA Instead of a CPU or GPU?
#112How long does it take to "program" a FPGA?
i.e. compared with typing a command, and having it load into memory.
What about a JIT that compiles hot code sections to FPGA? (Though compilation sounds too slow)
EDIT "one or two seconds or at least 100's of milliseconds." https://electronics.stackexchange.com/questions/212069/how-l...
Re: Why Use an FPGA Instead of a CPU or GPU?
#113Earlier quoted context omitted.
Experience seems to show that standardizing on a codec or instruction type is the most likely path. Apple iDevices have had hardware transcoding for video for a couple releases now. You really can't just have an FPGA that you recompile to a different architecture within a split second. They typically require compiling, downloading, and testing the the architecture you're deploying. Until someone comes up with a much…
But isn't that a one time expense? When a program installs it could compile the hardware acceleration for your platform and test it. Can you not, rather rapidly, directly activate that compiled designs every time you launch the program in the future? In that same vein, one time compilation for a hardware video decoder when a new codecs is released, and simply loading it when you want to play a video, seems infinitely…
You're correct that it's a one time expense, you can quickly load the bit file onto the FPGA (< 2 seconds) once it's been generated.
Re: Why Use an FPGA Instead of a CPU or GPU?
#114> The HPC community is already used to GPUs — getting people to switch from GPUs to FPGAs requires larger benefits. It's worth pointing out that some scientists haven't even made the leap to CPGPU computing yet and are still relying upon OpenMP / multithreading on general purpose CPUs, even when a GPU would be clearly superior. Anecdotally, I remember hearing that climate science simulations are particularly bad abou…
In my experience, it's true. And it's unlikely to change - the simulation code was largely written in FORTRAN and C over a period of 50 years. This is in fact what makes Intel Phi so appealing to some.
12 years ago I worked on High Level Synthesis at Xilinx converting atmospheric moisture simulations from FORTRAN...
Re: Why Use an FPGA Instead of a CPU or GPU?
#115I doubt that programming efficiency is what's holding back FPGA's for general compute. Why ? because we've seen decades of research in this area - so at least we have some tools(c for fpga isn't ideal, but still...), and a lot of the general mapping between what algorithms should be in FPGA. And Amazon FPGA's instance exist for over a year. So in that time, if there worth while services to offer with FPGA's, people w…
Disagree. I worked in this space for 15 years and watched CUDA win a market for NVidia that was ripe for the picking by Xilinx or Altera. The culture around hardware design prototyping dominates the FPGA field and all attempts at making it approachable by software development are stunted by the proprietary ecosystem. I also think that high level synthesis is largely misguided since sequential imperative style isn't the correct way to think about FPGAs and also doesn't really address the lack of a good low-level language with an abstraction mechanism, and fundamental need for an operating system for running processes on a reconfigurable computing system.
Re: Why Use an FPGA Instead of a CPU or GPU?
#116Why does the compilation take hours, is this an NP Hard problem?
Re: Why Use an FPGA Instead of a CPU or GPU?
#117For those wanting to play around with an FPGA, this looks quite interesting: https://www.sparkfun.com/products/14829
It's about half the price of the other FPGAs I've seen commonly used for hobbyist projects [1], doesn't need any separate programmer board to interface to your computer for programming, and has an open source tool chain available.
I've not played with it, as it just showed up in a mailing from Sparkfun about new products.
[1] such as https://www.sparkfun.com/products/11953
Re: Why Use an FPGA Instead of a CPU or GPU?
#118Why does the compilation take hours, is this an NP Hard problem?
If my memory of a Processor Design course is correct, arranging the desired functionality onto the finite resources of an actual FPGA chip, let alone in such a way as to get good performance (i.e. have critical paths be as short as possible), reduces to bin-packing.
Re: Why Use an FPGA Instead of a CPU or GPU?
#119Earlier quoted context omitted.
I feel like people are taking the hybrid approach of having a dedicated microcontroller on the same die as their CPU, like the PRU on TI's ARM chips: http://processors.wiki.ti.com/index.php/PRU-ICSS This by no means replaces an FPGA, but if you just want your pins to flip and code to run at a predictable interval, this gets you that. (As for reading pins, they have another peripheral on the die that will just timesta…
Yeah, the TI PRUs are what you get approaching this topic from a processor manufacturer standpoint, the XILINX Zynq is how a FPGA manufacturers would do it.
Just to add Microchip with "Configurable Logic Cell" and Cypress with "configurable blocks".
Re: Why Use an FPGA Instead of a CPU or GPU?
#120Earlier quoted context omitted.
Another thing is that you can pipeline, for example, multiplies. So in a CPU multiply you give the CPU inputs, wait a couple cycles, and then get the result. In an FPGA you can build a pipelined multiply. It's built such that you can feed it input every cycle and get an output every cycle. The only caveat is that the outputs are delayed relative to the inputs. i.e. you may give it (2, 3) to multiply on one cycle, but…
Thanks. Just to clarify whilst I have your attention: isn't it a common practice to pipeline frame buffers too? For instance, Android has three frame buffers. IIRC, one is with the user space handing off display lists, one used for composition, and one is used by driver for rasterization? In that case, how good, you reckon, would the perf be compared to FGPA?
by straight having a frame buffer vs having a couple lines buffered, I'd imagine it's still the fpga, except now the GPU needs even more memory to do the same task