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

111–120 of 161 posts

Re: The History, Status, and Future of FPGAs

#111

Post by GeorgeTirebiter »

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…

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

Re: The History, Status, and Future of FPGAs

#112

Post by GeorgeTirebiter »

variaga wrote: post #19
rwmj wrote: post #4

> Intel, AMD, and many other companies use FPGAs to emulate their chips before manufacturing them. Really? I'm assuming if this is true it can only be for tiny parts of the design, or they have some gigantic wafer-scale FPGA that they're not telling anyone about :-) Anyway I thought they mainly used software emulation to verify their designs.

Of the half-dozen semiconductor- designing companies I've worked for, all of them used FPGAs for emulation. - modern FPGAs are huge. - when an asic design won't fit in a single FPGA, it's usually possible to partition the design into multiple FPGAs - software emulation/ simulation is not guaranteed to be "more accurate". FPGAs can interact with a real-world environment in ways that simulation simply cannot - simulati…

Is that still true in 2020? Or is the simulation getting good enough to skip the FPGA prototyping phase?

Re: The History, Status, and Future of FPGAs

#113

Post by GeorgeTirebiter »

bsder wrote: post #91

The problem that FPGAs have is that they are only good for low-volume solutions that require flexibility and have no power constraints. 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.

MicroSemi (now part of Microchip) makes some low-power FPGAs. Xilinx has made the coolrunner CPLDs for years that are mighty low-power (they're not huge, but often are big enough for some needed extra logic.). (Another not care too much about power is Military.)

Re: The History, Status, and Future of FPGAs

#114

Post by GeorgeTirebiter »

justicezyx wrote: post #72

FPGAs are good at nothing in the scale that can challenge non-configurable silicons... They are good at a lot of things that are in a smaller scales. Like general prototyping/testing/simulation, telecom, special-purpose real-time computing etc. The behind-scene logic is that FPGAs can never make things as flexible as software. And flexible software always offset the inefficiency in a non-configurable chips. Just comp…

I believe you are incorrect. A counterexample to your claim is the increasing use of FPGAs in the datacenter. And various AI engines are FPGA-based. You'll do better for a CPU in Real Silicon; but a full-featured MPU w/standard peripherals + FPGA for unusual & must-be-fast functions is hard to beat.

Re: The History, Status, and Future of FPGAs

#115

Post by brandmeyer »

GeorgeTirebiter wrote: post #112
variaga wrote: post #19

Earlier quoted context omitted.

Of the half-dozen semiconductor- designing companies I've worked for, all of them used FPGAs for emulation. - modern FPGAs are huge. - when an asic design won't fit in a single FPGA, it's usually possible to partition the design into multiple FPGAs - software emulation/ simulation is not guaranteed to be "more accurate". FPGAs can interact with a real-world environment in ways that simulation simply cannot - simulati…

Is that still true in 2020? Or is the simulation getting good enough to skip the FPGA prototyping phase?

Its still very much true. ASIC designs are described as massively parallel tiny communicating sequential processes. FPGA's are also extremely fine-grained CSP, to a degree that is much finer than anything a CPU can produce today.

Re: The History, Status, and Future of FPGAs

#116

Post by seldridge »

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…

> These are not programming languages, they are hardware definition languages.

There's a subtle point in that Verilog/SystemVerilog and VHDL are also just not powerful languages. While parametric, they lack polymorphism, object oriented programming (excluding SV simulation-only constructs), functional programming, etc.

Your point about the abstraction being different is well taken---hardware description languages describe circuits and programming languages describe programs. However, it's exceedingly unfortunate that the industry is stuck in a rut of such weak languages and trying to explain that weakness to hardware engineers, who haven't seen anything else, runs into the "Blub paradox" (e.g., a programmer who only knows assembly can't evaluate the benefits of C++). [^1]

[^1]: http://www.paulgraham.com/avg.html

Re: The History, Status, and Future of FPGAs

#117

Post by CamperBob2 »

daxfohl wrote: post #97
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…

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.

Re: The History, Status, and Future of FPGAs

#118

Post by exmadscientist »

GeorgeTirebiter wrote: post #110
exmadscientist wrote: post #44

Earlier quoted context omitted.

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…

In my last project, I just big-banged a port to load up the configuration bits in a 4K iCE40, something like 131KBytes; this was just a .h file that was included in the bit-banger; the static array ended up in Flash (the ST MPU had 2 MB flash, so no problem), and it only took a second or so to load the FPGA bits before it was ready-to-go. So, from my perspective, what you describe is already here. If even that's too…

Dropping in a midsize MCU with 256kB of Flash just to program a single FPGA is not viable in a margin-constrained commercial product. It works great if it's already there, of course, but the applications I'm thinking of have been the ones where it isn't.

Not to mention there are many FPGA applications where one purpose of the FPGA is to avoid having software in the path. If software is only responsible for configuration load, it's better, but still can be a problem.

Re: The History, Status, and Future of FPGAs

#119

Post by exmadscientist »

gvb wrote: post #70
exmadscientist wrote: post #44

Earlier quoted context omitted.

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…

The MiniZED is $89 and a ton of fun! It has an ARM processor (Xilinx Zynq XC7Z007S SoC), Arduino compatible daughterboard connectors, microcontroller-like peripheral mix, and runs linux. http://zedboard.org/product/minized https://www.avnet.com/shop/us/products/avnet-engineering-ser... Oh, and Vivado (the FPGA development IDE) is free (as in beer) for that FPGA as well as Xilinx' other mid to low end FPGAs.

The XC7Z007S is $46 in volume at distributors (though with no volume discounts; Xilinx pricing is weird).

Zynq chips are beautiful parts. But they are not "low-cost drop-in" anything. They are chips that you can architect an entire system around and replace a dozen other chips with. I know; I've done it. (But they didn't bite on our proposal, so my sketched architecture remained just a detailed sketch.)

Re: The History, Status, and Future of FPGAs

#120

Post by exmadscientist »

panpanna wrote: post #47
exmadscientist wrote: post #44

Earlier quoted context omitted.

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…

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 voltage supervisor, not the internal PoR/brownout, no matter what the datasheet says because it does not speak the truth

* Actually, just add external ESD diodes to anything even the least bit sketchy

* On-chip analog not good enough for serious applications or stupidly limited (just give me two of those please? no?)

* On-chip routing is very, very limiting

* Weak MCU cores

* Few large parts (high GPIO, fast core, ...); the 5LP is better but needs a refresh with bigger, better, cheaper flagships

* More digital blocks (UDBs). They use a crappy old macrocell architecture, which wouldn't be a problem except they only give you TWO of them!

I've actually whined about the last one to the Cypress FAE (great guy!) and he just started laughing. Turns out, he's repeatedly said that to their higher-ups and gotten shot down... only to have customers like me ask for it again, over and over....

Hopefully under Infineon the PSoC line will be better managed. It could be a huge powerhouse, but right now it just does not have a good enough lineup of sane models.

Post reply on HN