Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The History, Status, and Future of FPGAs

queue.acm.org

Post reply on HN
Print view View original

141–150 of 161 posts

Re: The History, Status, and Future of FPGAs

#141

Post by imtringued »

IshKebab wrote: post #64
lnsru wrote: post #51

Earlier quoted context omitted.

Are these mature already? It took some time for KiCad to get to current usable state and I don’t want to be early adopter. In fact, I want to have my private hardware MVP next year with current tools. On the other hand I can’t imagine my slacker colleagues using anything else than Vivado. Learning Vivado for them was already mission impossible.

I wouldn't say KiCad is usable yet. I've made multiple attempts to use it and it just is fundamentally user hostile. Unfortunately the devs see any attempt to improve user friendliness as "dumbing down". Fortunately there is (finally!) an open source PCB design program that doesn't suck: Horizon EDA. I've only made one PCB with it but honestly it was pretty great and the author fixed every usability bug I reported in…

Last time I used KiCad the UX itself was fine although it was totally lacking polish but the parts management was absolutely atrocious.

Re: The History, Status, and Future of FPGAs

#142

Post by panpanna »

adwn wrote: post #139
roastsquirrel wrote: post #80

Earlier quoted context omitted.

Parts of VHDL leave a little to be desired but overall I find it to be a really great language. To the extent I bought Ada 2012 by John Barnes and I kind of like that too after coding in C/C++ etc, but maybe I'm now biased after many years of VHDL coding :) It's not uncommon to see "VHDL is bad" and such like, and I do wonder what the reasons are for those comments.

> It's not uncommon to see "VHDL is bad" and such like, and I do wonder what the reasons are for those comments. VHDL is bad because it's bad at prototyping and implementing digital hardware [1]. One reason why it's bad at that task is the mismatch between the hardware you want and the way you have to describe it in the language. For example: You want a 32-bit register x which is assigned the value of a plus b whenev…

Writing this with good intentions, not trying to start a fight...

---

There are some minor issues with your code that shows you are probably a verilog/SV guy and not an experienced VHDL guy.

Please read Andrew Rushtons "VHDL for Logic Synthesis". I also recommend you read on VHDLs 9-valued logic and why it was designed this way and how it differs from verilogs Bit.

Re: The History, Status, and Future of FPGAs

#143

Post by adwn »

panpanna wrote: post #142
adwn wrote: post #139

Earlier quoted context omitted.

> It's not uncommon to see "VHDL is bad" and such like, and I do wonder what the reasons are for those comments. VHDL is bad because it's bad at prototyping and implementing digital hardware [1]. One reason why it's bad at that task is the mismatch between the hardware you want and the way you have to describe it in the language. For example: You want a 32-bit register x which is assigned the value of a plus b whenev…

Writing this with good intentions, not trying to start a fight... --- There are some minor issues with your code that shows you are probably a verilog/SV guy and not an experienced VHDL guy. Please read Andrew Rushtons "VHDL for Logic Synthesis". I also recommend you read on VHDLs 9-valued logic and why it was designed this way and how it differs from verilogs Bit.

> you are probably a verilog/SV guy and not an experienced VHDL guy

Wrong on both counts.

Please, enlighten me, what's wrong with my code? Note that it's in VHDL-2008, and the async. reset is intentional.

> I also recommend you read on VHDLs 9-valued logic and why it was designed this way

My main issue with VHDL is not the IEEE 1164 std_(u)logic, although it really doesn't help that this de-facto standard type for bitvectors and numbers (via the signed/unsigned types) is just a second-class citizen in the language – as opposed to bit and integer, which are fully supported syntactically and semantically, but which have serious shortcomings.

Re: The History, Status, and Future of FPGAs

#144

Post by Unklejoe »

borramakot wrote: post #75
jcranmer wrote: post #16

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…

Just to throw in one more complication, I'll assert that the only benefits of FPGAs over ASICs are one time costs and time to market. Those are big benefits, but almost by definition, they aren't as important for workloads that are large scale and stable. So, if you do have a workload that's an excellent match for FPGAs, and if that workload will have lots of long term volume, you should make an ASIC for it. So, for…

> I'll assert that the only benefits of FPGAs over ASICs are one time costs and time to market.

There's one more big one: the ability to update the logic in the field.

Re: The History, Status, and Future of FPGAs

#145

Post by daxfohl »

inaccel wrote: post #128
daxfohl wrote: post #100

Earlier quoted context omitted.

I think that's the big advantage of FPGA. If you need acceleration to hit a 10 microsecond latency target, FPGA is what you need. If your latency target is like a millisecond or longer, then GPU can handle a lot more throughput. But GPU can't typically give you a 10-us guarantee. Okay, bit-banging is another advantage of FPGA that GPU doesn't do as well. There are a few things.

Regarding DNN inference FPGA can provide low latency AND higher throughput than GPUS. If you want to compare apples-to-apples, we have done a comparison with realistic (and not synthetic) data regarding the performance of GPUs and FPGAs. https://medium.com/@inaccel/faster-inference-real-benchmarks...

Ugh, ad spam taking over HN.

Re: The History, Status, and Future of FPGAs

#146

Post by daxfohl »

CamperBob2 wrote: post #117
daxfohl wrote: post #97

Earlier quoted context omitted.

Agreed. I never thought the mental leap to Verilog was a big hurdle. It's just C-like syntax with some new constructs around signaling and parallelism. I found this interesting rather than foreboding. 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 m…

There's no such thing as a "loop" on an FPGA. If you declare a loop in Verilog, the synthesizer allocates one set of gates per iteration. That's probably why your runs take all night. HLS notwithstanding, you don't use traditional control structures to tell an FPGA what to do. You use clocked FSMs and asynchronous expressions to tell it what to be.

Right. But for HPC, loops (in Verilog) will be the norm, to squeeze out as much from each clock tick as possible. Running everything as discrete steps in a FSM would defeat the purpose.

Re: The History, Status, and Future of FPGAs

#147

Post by jjoonathan »

imtringued wrote: post #137
jjoonathan wrote: post #81

Earlier quoted context omitted.

I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't: > it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In partic…

> the open source FPGA tooling pretty much completely ignored them, even though they're critical to commercial development. "ignored" as in the vendors aren't cooperating with the developers of the open source tools? What the opensource tools are doing is hard enough as is. When you consider how fragmented FPGA chips are it's difficult to support a wide variety of them even if you wanted.

I'm not blaming the open source devs at all. I admire them greatly. Unfortunately, it's one thing to admire someone greatly and quite another to believe they have a compelling offering.

Re: The History, Status, and Future of FPGAs

#148

Post by jjoonathan »

cmrdporcupine wrote: post #108
jjoonathan wrote: post #81

Earlier quoted context omitted.

I don't mean to belittle your exploration, but are you sure it's an apples-to-apples comparison? This suggests to me that it isn't: > it seems like hardware engineers have a fetish for all-encompassing painful vendor specific IDEs Hardware engineers feel pain just like you do. The reason why they put up with those awful software suites is because they have features they need that aren't available elsewhere. In partic…

Vivado ships all kinds of "IP" for those things, yes. And once you get past the GUI wizards, drag and drop boxes and lines, and Tcl scripts you find in the end it's just a library of Verilog, all mangled to the point of illegibility. I wasn't talking about open sourcing. I accept we won't have open source DRAM controllers and the like from them. I understand the licensing restrictions. I just don't like how they forc…

Well yes, they shouldn't cram the awful GUI tools down HW engineers' throats, but they do.

I'm glad Fusesoc is fighting the good fight and I'm glad you're fighting the good fight, but as you point out, it's definitely a fight. It was hardly fair to call the desire to avoid said fight a "fetish."

Re: The History, Status, and Future of FPGAs

#149

Post by panpanna »

adwn wrote: post #143
panpanna wrote: post #142

Earlier quoted context omitted.

Writing this with good intentions, not trying to start a fight... --- There are some minor issues with your code that shows you are probably a verilog/SV guy and not an experienced VHDL guy. Please read Andrew Rushtons "VHDL for Logic Synthesis". I also recommend you read on VHDLs 9-valued logic and why it was designed this way and how it differs from verilogs Bit.

> you are probably a verilog/SV guy and not an experienced VHDL guy Wrong on both counts. Please, enlighten me, what's wrong with my code? Note that it's in VHDL-2008, and the async. reset is intentional. > I also recommend you read on VHDLs 9-valued logic and why it was designed this way My main issue with VHDL is not the IEEE 1164 std_(u)logic, although it really doesn't help that this de-facto standard type for bi…

Inconsistent Boolean expressions + lack of familiarity with unsigned and how it is supported by the tools.

Nothing major, but in my books this is the difference between a Jr and a Sr designer. Nitpicking, yes. But the hardware business is like.

Re: The History, Status, and Future of FPGAs

#150

Post by adwn »

panpanna wrote: post #149
adwn wrote: post #143

Earlier quoted context omitted.

> you are probably a verilog/SV guy and not an experienced VHDL guy Wrong on both counts. Please, enlighten me, what's wrong with my code? Note that it's in VHDL-2008, and the async. reset is intentional. > I also recommend you read on VHDLs 9-valued logic and why it was designed this way My main issue with VHDL is not the IEEE 1164 std_(u)logic, although it really doesn't help that this de-facto standard type for bi…

Inconsistent Boolean expressions + lack of familiarity with unsigned and how it is supported by the tools. Nothing major, but in my books this is the difference between a Jr and a Sr designer. Nitpicking, yes. But the hardware business is like.

> lack of familiarity with unsigned and how it is supported by the tools

Do you mean this: "x not allow "x > Inconsistent Boolean expressions

Do you mean because I wrote "if rst ..." but later "if c = '0'..."? Come on, you're not nitpicking, you're trying to find issues where there are none. Fixating on such anal-retentive details does not make you a "Sr designer", it makes you a bad engineer.

Post reply on HN