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

131–140 of 161 posts

Re: The History, Status, and Future of FPGAs

#131

Post by lnsru »

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…

Thank you, I’ll look at it. Last time I wasn’t happy about KiCad’s differential lines. My design was space constrained and it was really hard to match lengths of short traces.

Re: The History, Status, and Future of FPGAs

#132

Post by IshKebab »

GeorgeTirebiter wrote: post #111
IshKebab wrote: post #64

Earlier quoted context omitted.

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…

Have you tried LibrePCB? https://librepcb.org/

I actually haven't yet - that does look quite good! Will definitely check it out next time I do a PCB.

Re: The History, Status, and Future of FPGAs

#133

Post by henrikeh »

qppo wrote: post #94
henrikeh wrote: post #87

Earlier quoted context omitted.

Chisel is not a HSL. Chisel is much closer to VHDL and Verilog, since the hardware is directly described.

Chisel would allow me to write say, a codec algorithm and compile it into hardware, correct? As well as specify the hardware that is necessary to describe it? I'm a casual in that space but I thought Chisel was an HDL that could be used to support HLS.

And you do the same in VHDL and Verilog. And like in Chisel, you have to manually pipeline it and you can exactly control where registers are used and how resources are reused.

You could build something HLS like using Scala/JVM and Chisel, but Chisel itself is much closer to traditional HDLs.

https://en.m.wikipedia.org/wiki/High-level_synthesis

Re: The History, Status, and Future of FPGAs

#134

Post by IshKebab »

amock wrote: post #109
IshKebab wrote: post #64

Earlier quoted context omitted.

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…

What have you found wrong with KiCad? I've only recently starting designing PCBs and I started with KiCad, but I've found it to be very easy to use after watching one video of someone going through a simple board design.

So many things. It was a few years ago that I tried so I don't remember the specifics but it's just generally very unintuitive and makes questionable UI choices. E.g. when you move a component in the schematic the wires don't stay attached to it.

I didn't need a video to figure out how to use Horizon.

Re: The History, Status, and Future of FPGAs

#135

Post by imtringued »

exmadscientist wrote: post #38
kyboren wrote: post #30

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…

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…

Just let those programmers play around with Redstone in Minecraft before you hand them an FPGA. They'll understand it very quickly.

Re: The History, Status, and Future of FPGAs

#136

Post by imtringued »

phkahler wrote: post #95
kyboren wrote: post #48

Earlier quoted context omitted.

> 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…

Not sure why they think chip details and bitstreams need to be kept secret. If they would open up, people would make better tools for them.

Because competitors could make compatible chips.

Re: The History, Status, and Future of FPGAs

#137

Post by imtringued »

jjoonathan wrote: post #81
cmrdporcupine wrote: post #79

Earlier quoted context omitted.

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…

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.

Re: The History, Status, and Future of FPGAs

#138

Post by ncmncm »

exmadscientist wrote: post #129
ncmncm wrote: post #122

Earlier quoted context omitted.

Crowd Supply has an endless variety of hobbyist-friendly variously FPGA / USB / MCU / PCIE / SDR combination boards. It's ridiculous for anybody to insist that programming an FPGA isn't writing software. By definition, anything you can put in a text file that ends up controlling what some piece of hardware does is software. Probably almost all of what is wrong with FPGA ecosystems comes from failure to treat it like…

FPGAs aren't state machines or processors. Not inherently, anyway, even if you can build those things out of them or if they sometimes are sold co-packaged. And their internal architecture is pretty well documented. See, for example, the Spartan-6 slices: https://www.xilinx.com/support/documentation/user_guides/ug3... What's less well documented, at least publicly, is the routing, but on some level that's less intere…

Why? Because ASICs do one thing from the first time they are powered up until they are finally ground up into sand. But an FPGA could, if programmed right, do completely different things from one millisecond to the next. Their ability to do that is never exploited because our tooling is still much too primitive, and current devices' internal connectivity probably can't route signals to the places needed.

If you think an FPGA is not inherently and necessarily a state machine, no matter how it is programmed (provided power and clock are in specified bounds), that only means you don't know what a state machine is. All clocked digital devices are state machines, and can never be anything other than state machines.

(There is an argument to be made that an FPGA is, itself, an ASIC: an IC whose Specific Application is to be an FPGA. But such an argument would be transparent sophistry.)

Re: The History, Status, and Future of FPGAs

#139

Post by adwn »

roastsquirrel wrote: post #80
adwn wrote: post #62

Earlier quoted context omitted.

> VHDL (and its software counterpart Ada) are very well thought and great to use once you get to know them (and understand why they are the way they are). Yeah, they are a bit verbose but I prefer a strong base to syntactic sugar. As a professional FPGA developer: VHDL (and Verilog even moreso) are bad [1] at what they're used for today: implementing and verifying digital hardware designs. In fact, they're at most mo…

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 whenever c is 0, and you want its reset value to be 25. VHDL code:

    signal x: unsigned(31 downto 0);
    ...
    process (clk, rst)
    begin
        if rst then
            x
The synthesis software has to interpret the constructs you use according to some quasi-standard conventions, and will hopefully emit those hardware primitives you intended. I say "hopefully", because of the many, many footguns arising from those two translation steps.

[1] Okay, I concede that in theory, there might be a use case where VHDL is perfectly suited for, which would make VHDL a not-bad language. But designing digital hardware is not such a use case.

Re: The History, Status, and Future of FPGAs

#140

Post by panpanna »

exmadscientist wrote: post #120
panpanna wrote: post #47

Earlier quoted context omitted.

I think Cypress had a product line that combined a CPU and a small programmable array, just big enough to implement your own custom IO and protocols and maybe some minimal logic beyond that. Maybe that's what most hobbyists need?

You're probably thinking of the Cypress PSoC, Programmable System on Chip. Those things are fantastic for hobbyists and can be nice for low-volume production. But they're kind of crap for higher volume work: * Expensive * Physically fragile/easy to kill: personal experience suggests they are noticeably more fragile than their competition; ALWAYS add pull resistors and ESD diodes to their JTAG/SWD pins and use a real…

Since you seem to have some experience with these: are the tools hoobyist friendly?

(Small install, no need for licences and license renewal, work reasonably well on a cheap laptop)

Post reply on HN