How FPGAs work, and why people will buy them (2013) • Hacker News Board

Re: How FPGAs work, and why people will buy them (2013)

#51

Post by noselasd » Mon, Sep 24, 2018, 6:39 PM UTC

user5994461 wrote: post #48

ThePadawan wrote: post #14

Earlier quoted context omitted.

> While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds. I'm not sure many people would share your opinion that Gradle/Maven are uncomplicated. Personally, I would say they belong to the 20% most complicated build toolchains I have encountered - which would make the FPGA process still not very uncomplicate…

Maven is just right click + build to build. Or file + import to import a project. The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.

Maven is that simple when someone have gone through all the pain of setting things up - but someone have to do that too - it is a battle for all but the very simplest of projects.

Re: How FPGAs work, and why people will buy them (2013)

#52

Post by aseipp » Mon, Sep 24, 2018, 6:42 PM UTC

TomVDB wrote: post #38

davemp wrote: post #5

> FPGAs are a programmable platform, but one designed by EEs for EEs rather than for programmers. This is the problem with FPGAs. Their performance and utility is not really disputed. Working with them is so un-ergonomic that it's frankly embarrassing. The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The situation is reminisc…

> The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The EE world could use novelty tooling to increase the efficiency by which you create RTL. But that can easily be done today if you consider Verilog to be an intermediate representation. So I think you're talking about the tooling on the steps to go from RTL to bitstream? Wha…

Xilinx recently created (then revoked) an open-source tool called "RapidWright" that might give you an idea -- it was basically a big Java API for manipulating and controlling Xilinx DCPs/bitstreams, allowing for some interesting tools. They plan on re-releasing it[1], but you can still see the docs here:

  http://www.rapidwright.io

The most interesting part are the tutorials, where they automatically e.g. insert ChipScope ILAs into existing, routed designs, which can only be done with some knowledge over the routed/placed results. (The automated UltraScale+ SLR-crossing example is probably more _interesting_ from a technical POV, but admittedly the ChipScope example was something I wanted recently!) Granted, that's not exposing the level of detail you'll need to write a full place-and-router or anything, but post-route/route-assistance based tooling seems like an interesting possibility.

Honestly, though, I'll take absolutely none of that if an open source tool means you can just fix some of the bugs in the damn things.

[1] I assume they revoked it in the first place due to some outbreak of batshit insanity in a legal department somewhere -- presumably some of the source code should not have been released, or someone's mind changed, or something.

Re: How FPGAs work, and why people will buy them (2013)

#53

Post by nickpsecurity » Mon, Sep 24, 2018, 7:00 PM UTC

monocasa wrote: post #19

davemp wrote: post #5

> FPGAs are a programmable platform, but one designed by EEs for EEs rather than for programmers. This is the problem with FPGAs. Their performance and utility is not really disputed. Working with them is so un-ergonomic that it's frankly embarrassing. The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The situation is reminisc…

The hard part AFAICT, is the modeling of the chip for timing analysis. Whereas all of the timing information is explicitly defined for programmers on CPUs, that timing information (and the models of how FPGAs are binned) is extremely proprietary for FPGA vendors, to the point of being treated as a trade secret. Since they use custom cell layouts, I've heard that they consider the timing information core to their IP.…

I saw some good reverse engineering of FPGA's like this work:

https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/S...

It has a lot of details on things that are clock-related. Since Im not hardware guy, I can't ssy if it has info needed, if another work could get it building on this, or what. So, what you think?

Re: How FPGAs work, and why people will buy them (2013)

#54

Post by TomVDB » Mon, Sep 24, 2018, 7:01 PM UTC

atq2119 wrote: post #43

TomVDB wrote: post #38

Earlier quoted context omitted.

> The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The EE world could use novelty tooling to increase the efficiency by which you create RTL. But that can easily be done today if you consider Verilog to be an intermediate representation. So I think you're talking about the tooling on the steps to go from RTL to bitstream? Wha…

There's potentially tremendous value in having an open bitstream. To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on. It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significa…

> To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on.

In practice, if you code your Verilog with speed in mind (limited levels of combinational logic, plenty of pipeline stages, one-hot encodings, ...), the synthesis and fitter tool will do an excellent job of extracting high speed. The modern ones will do register clone, pull in registers into RAMs and DSPs etc.

In case of timing problems, the timing analyzer will already show you the critical path, the amount of LUTs, and how the critical paths is routed.

The hardest part of figuring out why a particular path is violating timing is not because of the reporting of the tools, it's because a blob of logic has been flattened and merged into a LUT, and it's hard to identify how a LUT corresponds to the RTL.

Maybe a custom tool can help debugging these kind of things, but I think it's a very narrow case, and IMO not the kind of thing that makes EDA tools unergonomic.

> It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.

That was not my point.

My point is: if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.

Re: How FPGAs work, and why people will buy them (2013)

#55

Post by hobo_mark » Mon, Sep 24, 2018, 7:02 PM UTC

snaky wrote: post #29

simias wrote: post #16

Earlier quoted context omitted.

FPGAs have been used in the industry for decades, basically every time you need high throughput and/or very low latencies and you don't have the volume to justify making an ASIC then FPGAs and CPLDs are the way to go. The article is not really talking about that though, it's more about having FPGAs in mainstream desktop computers. This is still far from a reality, even if Intel seems to be pushing for it.

Maybe the only one market segment where FPGAs aren't in wide use yet is desktop computers. iPhone 7 has iCE5LP4K inside, AWS provide FPGA-based instances, and Microsoft have even FPGA-powered NICs. https://www.theregister.co.uk/2018/01/08/azure_fpga_nics/

Most desktop and server motherboards embed small CPLDs and FPGAs for low-level stuff, like power sequencing.

Re: How FPGAs work, and why people will buy them (2013)

#56

Post by TomVDB » Mon, Sep 24, 2018, 7:04 PM UTC

snaky wrote: post #44

TomVDB wrote: post #42

Earlier quoted context omitted.

I just googled it and they seem to be MCUs with no programmable logic? What feature gives them a taste of an FPGA?

Cypress call it 'UDB'. https://www.eevblog.com/forum/projects/no-bitbanging-necessa...

That's much more FPGA-like than I expected.

Re: How FPGAs work, and why people will buy them (2013)

#57

Post by bsder » Mon, Sep 24, 2018, 7:08 PM UTC

TomVDB wrote: post #42

nraynaud wrote: post #39

Earlier quoted context omitted.

I'd advise people to start with a Cypress PSoC MCU, they have the taste of FPGA, but have a lot of useful stuff for various projects, and I bought 10 MCUs for $10.

I just googled it and they seem to be MCUs with no programmable logic? What feature gives them a taste of an FPGA?

You have a very small number of blocks of analog and digital functions that can be connected together in various ways. Cypress are not open source, but the tools are better than average (FWIW).

FPGA's are a pain because you get a gigantic quantum jump in complexity right away. For example--a system clock. Do you want a single one? Okay, now you have to deal with distributing that clock and dealing with termination and reflections. Do you have more than one? Okay, now you need to deal with synchronizers right out the chute.

For most hacker types, the Cypress chips are a MUCH better match to what they need to do. Generally these digital tasks break down into something like "Catch a very tight margin digital signal, respond with ACK and wait signal, and signal the core that something needs serviced." (example: communicate with a GPIB device) or "Have a tight feedback loop that receives slow commands" (example: PWM for a motor with an encoder).

Re: How FPGAs work, and why people will buy them (2013)

#58

Post by monocasa » Mon, Sep 24, 2018, 7:20 PM UTC

nickpsecurity wrote: post #53

monocasa wrote: post #19

Earlier quoted context omitted.

The hard part AFAICT, is the modeling of the chip for timing analysis. Whereas all of the timing information is explicitly defined for programmers on CPUs, that timing information (and the models of how FPGAs are binned) is extremely proprietary for FPGA vendors, to the point of being treated as a trade secret. Since they use custom cell layouts, I've heard that they consider the timing information core to their IP.…

I saw some good reverse engineering of FPGA's like this work: https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/S... It has a lot of details on things that are clock-related. Since Im not hardware guy, I can't ssy if it has info needed, if another work could get it building on this, or what. So, what you think?

It's not quite what I'm talking about, and what he has listed there is generally pseudo publicly documented. Xilinx for instance, more or less supports programming at the bitstream level rather than the HDL level for stuff like runtime reconfigurable blocks. So there isn't much there in his thesis that isn't covered in the docs.

What he covers (for the purpose of this discussion) is how the clock blocks (straight up PLLs if you've done any embedded development) are connected to the rest of the fabric. That's sort of the digital side, and the hard part is the analog side. Ie. "what are the propagation delays of different configuration of LUTs and fabric, and who can you play games with in place and route in order to meet timing". It's an important feedback step in place and route. You can get neat trivial stuff running, but without decent timing analysis it'll be hard to tell if your design will have weird bugs at runtime. Or will lack optimizations that will help you meet timing with an equivalent design. I mean, that stuff is almost a black art even with high quality timing analysis.

Re: How FPGAs work, and why people will buy them (2013)

#59

Post by TomVDB » Mon, Sep 24, 2018, 7:24 PM UTC

bsder wrote: post #57

TomVDB wrote: post #42

Earlier quoted context omitted.

I just googled it and they seem to be MCUs with no programmable logic? What feature gives them a taste of an FPGA?

You have a very small number of blocks of analog and digital functions that can be connected together in various ways. Cypress are not open source, but the tools are better than average (FWIW). FPGA's are a pain because you get a gigantic quantum jump in complexity right away. For example--a system clock. Do you want a single one? Okay, now you have to deal with distributing that clock and dealing with termination an…

The learning curve of FPGAs is steep because it's a completely different way of thinking. And if you're thinking about a particular application, I agree that the Cypress chip might be the best solution in a bunch of cases.

But the original question was which would be a good FPGA learning platform. I don't think the Cypress MCU are the best way to learn about FPGAs.

Similarly, your example of a system clock is only relevant if you're thinking about designing your own boards. That's even more beyond the scope of the question.

Re: How FPGAs work, and why people will buy them (2013)

#60

Post by analognoise » Mon, Sep 24, 2018, 7:39 PM UTC

user5994461 wrote: post #48

ThePadawan wrote: post #14

Earlier quoted context omitted.

> While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds. I'm not sure many people would share your opinion that Gradle/Maven are uncomplicated. Personally, I would say they belong to the 20% most complicated build toolchains I have encountered - which would make the FPGA process still not very uncomplicate…

Maven is just right click + build to build. Or file + import to import a project. The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.

I went on an interview once where part of the process was "here is a development board. Here is a computer and the internet. Make a full adder, connect the inputs to push buttons and the outputs to LEDs. You have all day, by yourself, in a cubicle."

I was told it cut out something like 95% of candidates who looked good on paper. It was an interesting approach.