91–100 of 161 posts
That's a really narrow market. Telecom equipment and lab equipment, basically.
If I need volume, I need at least an ASIC. If I need to manage power, I need a full custom design.
Earlier quoted context omitted.
I feel you completely. The Vivado IDE/toolchain is absolutely atrocious and the designers should be shamed for the horrifying bloatware they push as the STANDARD. Sometimes I have better luck doing everything in tcl/commandline there.
Vivado is amazing compared with the ASIC counterparts: Design compiler is for RTL synthesis only and you need years of experience to get any decent qor out of it. In ASIC land you have separate tools for every step, synthesis, STAs, PnR, simulation, floor planning, power analysis, etc. Vivado does all that in one seamless tool, and allows you to cross probe from a routed net right back to the RTL code it came from. T…
It froze the IDE for 45 minutes before I could do anything else.
This was on a beefy machine at AWS too, not some cheap home desktop thing.
That wasn't compiling, no synthesis, P&R, nothing.
There was no giant netlist I'd been working on either. Most of the FPGA was empty.
That was literally just adding a small source file which the IDE auto-indexed so you could browse the contents.
In Verilator, an open source Verilog simulator, that same source file loaded, completed its simulation and checked test results in less than a second. So it wasn't that hard to compile and expand its contents.
Vivado is excellent for some things. But the excellence is not uniform unfortunately. On that project, I had to do most of the Verilog development outside Vivado because it was vastly faster outside Only importing modules when they were pretty much ready to use and behaviorally validated.
As a bit of a counterpoint: One of my prior projects involved working with a lot of ex-FPGA developers. This is obviously a rather biased group of people, but I saw a lot of feedback around that was very negative about FPGAs. One comment that's telling is that since the 90s, FPGAs were seen as the obvious "next big technology" for HPC market... and then Nvidia came out and pushed CUDA hard, and now GPGPUs have corner…
See it's funny, I (software guy) have recently started doing a bunch of FPGA stuff on the side for "fun" and I find the programming model to not be the biggest challenge. The tools, yes, because it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs with half the features that us software developers have, and with a crapload of vendor lock-in... but I digress. I find working…
Earlier quoted context omitted.
> HLS as a first-class design paradigm is always a decade away. What about Chisel?
Chisel is not a HSL. Chisel is much closer to VHDL and Verilog, since the hardware is directly described.
I'm a casual in that space but I thought Chisel was an HDL that could be used to support HLS.
Earlier quoted context omitted.
Very much this. (Also, in general, FPGA tools are just some of the lowest quality garbage out there... and that is saying something. They're that bad . This is a completely unnecessary speedbump.) The rebuttal to your objection is always tools like "HLS" (High-Level Synthesis), or in English it's "C to HDL" (FPGAs are 'programmed' in the two Hardware Definition Languages VHDL (bad) or Verilog (worse, but manageable i…
> The rebuttal to your objection is always tools like "HLS" Yup. I know HLS has gotten a lot better recently but my impression is that, somewhat like fusion, HLS as a first-class design paradigm is always a decade away. > FPGA tools are just some of the lowest quality garbage out there Absolutely. I think the problem is vendors see FPGA tooling as a cost center and a necessary evil in order to use their real products…
Earlier quoted context omitted.
There is another traditional FPGA use case where you need real time data capture or signal generation. That seems to be getting eaten from the bottom now that there are really high speed MCUs that are easier to program. It's less efficient, but easier to develop for.
The other problem with using an FPGA here is that microcontrollers are cheap and have great cheap dev boards. FPGAs, not so much. I've wanted to just "drop in" a small FPGA in several designs, the way you can drop in a microcontroller, but there's no available FPGA that's not a massive headache in that use case. Trust me, I've looked. The iCE40 series is almost there but not quite. It's a bit pricey (this is sometime…
As a bit of a counterpoint: One of my prior projects involved working with a lot of ex-FPGA developers. This is obviously a rather biased group of people, but I saw a lot of feedback around that was very negative about FPGAs. One comment that's telling is that since the 90s, FPGAs were seen as the obvious "next big technology" for HPC market... and then Nvidia came out and pushed CUDA hard, and now GPGPUs have corner…
See it's funny, I (software guy) have recently started doing a bunch of FPGA stuff on the side for "fun" and I find the programming model to not be the biggest challenge. The tools, yes, because it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs with half the features that us software developers have, and with a crapload of vendor lock-in... but I digress. I find working…
The main challenge I had was compilation time. It can sometimes take overnight to compile a simple application if there's a lot of nested looping, only to have it run out of gates. This can be a royal pain.
I'd expect most HPC scenarios would have lots of nested looping, and probably memory accesses, and thus have to spend a lot of time writing state machines to get around gate count limitations and wait for memory responses, at which point you're basically designing a 200 MHz CPU.
So I don't see it as being very useful for general purpose acceleration, but could be a good CPU offload for some very specific use cases that are more bit-banging than computing. Azure accelerates all its networking via FPGA, which seems like the ideal use case.
I wonder if it is possible to add a (small) FPGA to a personal computer that could accelerate any specific software tasks (video/audio encoding, ML algorithms, compression, extra FPU capabilities) on user demand .
So it's unlikely ever to gain broad acceptance because the software vendors would have to support such a high number of permutations and the return can be questionable. This is why you see far more accelerators based on ASICs that have higher clock speeds and baked-in circuitry for specific tasks, with standardized APIs.
But sure, there's nothing preventing you from buying an FPGA board, hooking it up to your PC, creating a few images that do the accelerations you want, and writing software that uses them, swapping the image in when your program loads. You could even write a smart driver that swaps the image only if it's not in use by another app, or whatever. It's just unlikely you'll ever find a bunch of third-party software that supports it.
Earlier quoted context omitted.
Vivado is amazing compared with the ASIC counterparts: Design compiler is for RTL synthesis only and you need years of experience to get any decent qor out of it. In ASIC land you have separate tools for every step, synthesis, STAs, PnR, simulation, floor planning, power analysis, etc. Vivado does all that in one seamless tool, and allows you to cross probe from a routed net right back to the RTL code it came from. T…
I added one small Verilog file to a Vivado project. It froze the IDE for 45 minutes before I could do anything else. This was on a beefy machine at AWS too, not some cheap home desktop thing. That wasn't compiling, no synthesis, P&R, nothing. There was no giant netlist I'd been working on either. Most of the FPGA was empty. That was literally just adding a small source file which the IDE auto-indexed so you could bro…
Earlier quoted context omitted.
GPUs work great for accelerating many applications, and it's true that that reduces interest in FPGAs. For applications that map well to GPUs, you're absolutely correct that the higher clock speeds (and greater effective logic area) make GPUs superior as accelerators. However, some applications do not map well to GPUs. Particularly those applications with a great deal of bit-level parallelism can achieve enormous spe…
Another big advantage of FPGAs is low latency and the ability to hit precise timing deadlines. When working with radio hardware, you still need an FPGA for automatic gain control calculations and recording/playing out samples. Similarly, you need to do your CRC and other calculations in an FPGA if you need to immediately respond to incoming signals, such as the CTS->RTS->DATA->ACK exchange in 802.11.
Okay, bit-banging is another advantage of FPGA that GPU doesn't do as well. There are a few things.