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

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

embeddedrelated.com

Post reply on HN
Print view View original

71–80 of 119 posts

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

#71

Post by monocasa »

analognoise wrote: post #60
user5994461 wrote: post #48

Earlier quoted context omitted.

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.

Ironically enough, a lot of the people I've cut in the interview process seemed like working their way through Vivado, Lattice, etc. wizards was the only development they had ever done. They could get an env setup, but would be completely lost outside of a trivial hello world style project.

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

#72

Post by esmi »

ChuckMcM wrote: post #65
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…

I too decry the lack of openness with respect to the data file encoding which would allow for more open source tools to be created. I had a hilarious discussion with Xilinx's VP of tools about this[1]. The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactical…

The arguement in [1] doesn't make sense to me. Xilinx tools are free, as in beer, and the sale of ICs funds those tools so they are implementing your system of a "tax on every chip". Surely the VP of tools at Xilinx knows this.

What problem are you unable to solve with an FPGA because you do not have the source code to Vivado?

I understand why Xilinx doesn't want to release their source. They don't want to support it. Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.

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

#73

Post by davemp »

esmi wrote: post #72
ChuckMcM wrote: post #65

Earlier quoted context omitted.

I too decry the lack of openness with respect to the data file encoding which would allow for more open source tools to be created. I had a hilarious discussion with Xilinx's VP of tools about this[1]. The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactical…

The arguement in [1] doesn't make sense to me. Xilinx tools are free, as in beer, and the sale of ICs funds those tools so they are implementing your system of a "tax on every chip". Surely the VP of tools at Xilinx knows this. What problem are you unable to solve with an FPGA because you do not have the source code to Vivado? I understand why Xilinx doesn't want to release their source. They don't want to support it…

> Xilinx tools are free, as in beer

This is untrue. [1]

> Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.

In what world is this the case? You host the project on github or the like and let people contribute bug fixes at the cost of filtering pull requests. Letting the community contribute bug fixes is a huge reason companies open source their tools.

[1]: https://www.xilinx.com/products/design-tools/vivado.html#buy

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

#74

Post by davemp »

esmi wrote: post #63
davemp wrote: post #20

Earlier quoted context omitted.

For basic implementations in ways intended by the vendor, I'm sure the supplied tools are fine. When you want to leave the sandbox and do interesting things, it's hard. I was thinking along the lines of writing your own tools that would require information about timings and chip resources/layouts. EDIT: your cpu ISA is open, but fpga layout/bit-stream is not--locking you to your vendor's innovation and ideas for how…

What does leaving the sandbox mean when implementing an FPGA? I'm not aware of any soft resource one can't completely control in Vivado/Xilinx as every hard resource can be completely described in your own design via the primitive library. That doesn't mean it is always a good idea, but one can do it.

> described in your own design via the primitive library

There's your sandbox

EDIT: If you cannot replace their tools with yours, it is a sandbox.

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

#75

Post by esmi »

davemp wrote: post #73
esmi wrote: post #72

Earlier quoted context omitted.

The arguement in [1] doesn't make sense to me. Xilinx tools are free, as in beer, and the sale of ICs funds those tools so they are implementing your system of a "tax on every chip". Surely the VP of tools at Xilinx knows this. What problem are you unable to solve with an FPGA because you do not have the source code to Vivado? I understand why Xilinx doesn't want to release their source. They don't want to support it…

> Xilinx tools are free, as in beer This is untrue. [1] > Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature. In what world is this the case? You host the project on github or the like and let people contribute bug fixes at the cost of filtering pull requests. Letting the community contribute bug fixes is a huge reason companies open source their tools. [1]: ht…

From your link: Vivado HL WebPACK™ Edition: no-cost, device-limited version of the Vivado HL Design Edition

It's not as simple as an upload to github. https://opensource.com/business/16/5/how-transition-product-...

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

#76

Post by hak8or »

user5994461 wrote: post #64
analognoise wrote: post #60

Earlier quoted context omitted.

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.

That's what the interns were trying to do. Get a push button to a LED working, on a Xilinx SoC, with the Vivado IDE. They couldn't figure it out in days. I don't blame them. I tried and couldn't get it working in a day either. We were lucky we found another guy in the company who worked with that board on a different project. He showed us and he had extensive notes to get the environment working. Embedded development…

Not all embedded. Thankfully there is a sort of standard embedded mcu arch showing up via arm (would love risc v but I'll take what I can get). This has support via mainline clang/llvm and gcc, and isn't much work to get a more modern setup going via cmake, c++17, and clion.

But the amount of people who are still going the raw c route for often times unfounded reasons (c++ is slower or has more bloat), prefer one large c file, don't do code based testing, etc, in embedded is staggering.

And for more niche areas (like FPGA) it's extremely behind the times. Not to say c is behind the times, it has its time and place, but 99% of the time they aren't bale to properly articulate it.

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

#77

Post by TomVDB »

esmi wrote: post #67
atq2119 wrote: post #43

Earlier quoted context omitted.

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…

Why do you think this information is unavailable today? I can get the critical paths, device utilization, power, etc. from every vendor's software suite I'm aware of. And they are all fully scriptable from the TCL interface. Once I have a mostly stable design, I usually run Xilinx/Vivado from the command line. Same with Lattice. The reports the vendors provide are much better than what would get from the raw bitstrea…

LUTs are still the building block of all FPGAs. Logic elements are just a higher level of hierarchy.

For example, according to the Intel Arria 10 handbook, an ALM contains 2 4-input LUTs and 4 3-input LUTs, which can be combined in various ways. (See figure 7 of the A10 handbook.)

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

#78

Post by Const-me »

ChuckMcM wrote: post #65
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…

I too decry the lack of openness with respect to the data file encoding which would allow for more open source tools to be created. I had a hilarious discussion with Xilinx's VP of tools about this[1]. The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactical…

> where you can write something that is both syntactically correct and cannot by inferred into logic by the synthesis part of the tool (equivalent of the code generator in a compiler).

A decade ago, programming GPU shaders was similar to that. You could use a higher-level language but there were tight limits on everything, instructions, branches, texture lookups, etc. Here’s a summary for GL, DX was the same because they were hardware limitations of corresponding GPUs: https://stackoverflow.com/a/5601884/126995 Modern GPU chips are way more capable so that’s mostly history now.

Post reply on HN