The History, Status, and Future of FPGAs • Hacker News Board

Re: The History, Status, and Future of FPGAs

#151

Post by exmadscientist » Fri, Jul 24, 2020, 4:51 PM UTC

panpanna wrote: post #140

exmadscientist wrote: post #120

Earlier quoted context omitted.

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)

Yeah, not bad at all. A little annoying, but above average for the HW side of things.

But that's PSoC Creator, used for their PSoC 4 and 5 lines. (Avoid the 3 and older -- they're really old.) The newer 6 requires Modus Toolbox, which I think doesn't support the 4 or 5 lines (STUPID). I have no experience with that one. It's Eclipse based, so who knows.

Re: The History, Status, and Future of FPGAs

#152

Post by exmadscientist » Fri, Jul 24, 2020, 4:55 PM UTC

ncmncm wrote: post #138

exmadscientist wrote: post #129

Earlier quoted context omitted.

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…

There's also plenty of unclocked stuff in the FPGA... like the LUTs that do all the work. There's enough of this and it's important enough that I believe thinking of FPGAs as "just state machines" is dumb. But then I also believe that digital electronics are not "just digital circuits", but better thought of as "bistable analog circuits", so what do I know....

Re: The History, Status, and Future of FPGAs

#153

Post by cmrdporcupine » Fri, Jul 24, 2020, 6:28 PM UTC

jjoonathan wrote: post #148

cmrdporcupine wrote: post #108

Earlier quoted context omitted.

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."

I can only assume hardware engineers are asking for this kind of tooling, because I can't imagine why companies would be spending the enormous development effort on them and then giving them away for free if they weren't being asked for?

So many things that could be done in a programatic, testable, declarative, scriptable, repeatable way are done with futzy GUI tools in hardware land. Schematic design _could_ be a matter of declaring components, buses, etc. and letting the tool produce something (and then manually manipulate the visual layout if necessary) ; I mean you could literally describe your board using something similar to Verilog and get the tool to produce the schematic for you... we have these kinds of powers in the 21st century -- Instead it's futz with tools that are vaguely Illustrator-esque, find that half your connection points are not actually connected, etc. Why do people want to suffer like this?

Want to use a DRAM controller in Vivado? Find the wizard, enter into 10 text boxes... and if you're lucky you can find the Tcl scripts it generated and in the future just write your Tcl script... but they certainly won't make it easy.

Vivado project in source control? You're going to jump through hoops for that.

I want hardware engineers to demand better.

Re: The History, Status, and Future of FPGAs

#154

Post by tinus_hn » Fri, Jul 24, 2020, 7:11 PM UTC

adwn wrote: post #62

panpanna wrote: post #45

Earlier quoted context omitted.

> FPGA tools are just some of the lowest quality garbage out there I think things are about to change thanks to yosys and other open source tools. > VHDL (bad) or Verilog (worse, 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.

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

So what’s better?

Re: The History, Status, and Future of FPGAs

#155

Post by phendrenad2 » Fri, Jul 24, 2020, 8:22 PM UTC

beefok wrote: post #61

lnsru wrote: post #23

I am working right now on bare metal websockets implementation on Xilinx Series 7 FPGAs. Currently it’s ZynQ SoC, but final product will probably have Kintex 7 inside, so no Linux. The tools make me cry, no examples, application notes from 2014 with ancient libraries. I hope, vendors will fix tooling. But I see, Xilinx has released Vitis, so their scope is elsewhere, no interest in old crap. Using Git with Vivado is…

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.

FPGA vendors are in a tight spot, thanks to their customers. Their customers want better silicon, so they're forced to allocate their resources toward R&D, rather than making their software tools better. If you look at the Xilinx jobs page, you'll see maybe ONE job related to software tools programming, which is shocking given the complexity of Vivado/Vitis.

If some FPGA company comes along and throws out conventional market wisdom (the old Henry Ford quote seems pertinent: "If I'd asked customers what they wanted, they would have said "a faster horse"") and makes a FPGA with software tools that are fast, non-buggy, with good UI/UX, I think they would be able to steal significant market share. Early FPGA patents should be expiring by now...

Re: The History, Status, and Future of FPGAs

#156

Post by ncmncm » Fri, Jul 24, 2020, 9:07 PM UTC

exmadscientist wrote: post #152

ncmncm wrote: post #138

Earlier quoted context omitted.

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…

There's also plenty of unclocked stuff in the FPGA... like the LUTs that do all the work. There's enough of this and it's important enough that I believe thinking of FPGAs as "just state machines" is dumb. But then I also believe that digital electronics are not "just digital circuits", but better thought of as "bistable analog circuits", so what do I know....

If the results of the LUTs don't end up clocked into a register, where do they go?

Of course everything is analog, and ultimately quantum-electrodynamic, but the languages FPGAs are programmed in don't provide access to those domains.

Re: The History, Status, and Future of FPGAs

#157

Post by IshKebab » Fri, Jul 24, 2020, 9:25 PM UTC

imtringued wrote: post #141

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…

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

Parts management is a pretty significant part of the UX I would have said!

I have yet to design a PCB where I didn't have to create basically all of the components myself.

Re: The History, Status, and Future of FPGAs

#158

Post by mikevin » Sat, Jul 25, 2020, 6:41 PM UTC

seldridge wrote: post #116

exmadscientist wrote: post #38

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…

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

While there's plenty of room to improve a language like Verilog I fail to see how these paradigms would help me in RTL. What would polymorphism even look like in an environment without a concept of runtime? Can you elaborate and enlighten me?

Edit: Disclaimer, I'm well aware of the pros and cons of these paradigms in software development and use them plenty

Re: The History, Status, and Future of FPGAs

#159

Post by fanf2 » Sun, Jul 26, 2020, 2:23 PM UTC

tinus_hn wrote: post #154

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…

So what’s better?

I've heard good things about Bluespec. It is used for Cambridge's CHERI capability architecture extensions, for example - https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

Re: The History, Status, and Future of FPGAs

#160

Post by justicezyx » Tue, Jul 28, 2020, 6:28 PM UTC

GeorgeTirebiter wrote: post #114

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.

Tell me how much users are using FOGAs and why xillinx is just a fraction of nVidia's market cap. 5 years ago, nvidia was 2x of xillinx in market cap, now it's 10x.