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

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

#91

Post by mycall » Tue, Sep 25, 2018, 1:15 AM UTC

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…

Take a look at the LimeSDR Mini device [1] which includes an Intel MAX 10.

[1] https://wiki.myriadrf.org/LimeSDR-Mini_v1.1_hardware_descrip...

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

#92

Post by ChuckMcM » Tue, Sep 25, 2018, 1:27 AM UTC

mycall wrote: post #91

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…

Take a look at the LimeSDR Mini device [1] which includes an Intel MAX 10. [1] https://wiki.myriadrf.org/LimeSDR-Mini_v1.1_hardware_descrip...

Now compare that FPGA with the Xilinx ZU3EG [1] (used on the Ultra96). I have been looking at the USB 3 support on that processor as a means of driving a regular LimeSDR board. Even better would be pulling 4x PCIe[2] lanes of the Zynq and driving an M.2 form factor XTRX or something similar to that. For my purposes I want to insure the SDR has MIMO capability.

[1] https://www.xilinx.com/support/documentation/selection-guide...

[2] And yes I know I would need a ZU4EG rather than the ZU3EG that is on the board. If I was doing my own board I'd use the 4EG and add some extra memory attached right to the FPGA fabric.

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

#93

Post by dkarl » Tue, Sep 25, 2018, 1:37 AM UTC

sfifs wrote: post #10

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…

Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc…

> didn't seem any more complicated than Grade/Maven etc all based Android Studio builds

Can you say anything nicer about it than that? I've used Make, ant, and cmake, I've built and packaged multiplatform GUI apps using Eclipse RCP, I've built modern web apps using npm and babel, and building Android apps was the single worst experience out of all of them. Comparing a toolchain to Android sounds more like a takedown than a defense.

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

#94

Post by IX-103 » Tue, Sep 25, 2018, 1:52 AM UTC

duskwuff wrote: post #83

davemp wrote: post #74

Earlier quoted context omitted.

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

The elements in the primitive library directly map to the hardware components available on the FPGA. There's no "sandbox" involved.

So when you say primitive components, are you talking about directly manipulating the components in a logic block (https://www.xilinx.com/support/documentation/user_guides/ug3...), or do you just mean the abstractions above that like "blockram", "LUT6", "shift register"? Because you can do a lot more with an FPGA's logic blocks than indicated by those higher level abstractions.

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

#95

Post by darkmighty » Tue, Sep 25, 2018, 1:52 AM 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.…

But if those (timing) models are incorporated into current proprietary synthesis systems, can't they be reverse engineered with relative ease, anyway?

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

#96

Post by tejtm » Tue, Sep 25, 2018, 1:56 AM UTC

In case there is some interest in learning hardware

    iCEBreaker FPGA

The first open source iCE40 FPGA development board designed for teachers and students.

https://www.crowdsupply.com/1bitsquared/icebreaker-fpga

full disclosure: I will likely get an enthusiastic "Thank you!" for dropping this here.

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

#97

Post by IX-103 » Tue, Sep 25, 2018, 2:17 AM UTC

tails4e wrote: post #82

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…

verilog has behavioural and synthesizable subsets. One is intended for testing, the other for hardware generation. Once you understand this you can learn which constructs, though syntactically correct, should not be used for hardware generation. Also HDLs are not alone in having 'quirks' that experienced engineers need to know about.. c/c++ for example. cough undefined behaviour cough Code coverage and quality checki…

Languages can have undocumented behavior, that's fine. But if the HDL compiler compiles code that should have a defined behaviour incorrectly, that's just pure frustration. I swear I've lost so many days just trying to find a way to rewrite pieces of logic so that I could find a variation that Vivado would compile according to the HDL spec.

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

#98

Post by FPGAhacker » Tue, Sep 25, 2018, 2:17 AM UTC

tails4e wrote: post #82

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…

verilog has behavioural and synthesizable subsets. One is intended for testing, the other for hardware generation. Once you understand this you can learn which constructs, though syntactically correct, should not be used for hardware generation. Also HDLs are not alone in having 'quirks' that experienced engineers need to know about.. c/c++ for example. cough undefined behaviour cough Code coverage and quality checki…

1: verilog started as a simulation language.

2: if the tools were open source, people would be free to improve on these bags of pain that we have the pleasure of spending thousands of dollars per license.

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

#99

Post by analognoise » Tue, Sep 25, 2018, 2:32 AM UTC

monocasa wrote: post #71

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.

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.

Yeah, we had several interview questions specifically to weed those out too. A favorite was, "How would you design a multiplier, without a wizard/Coregen?"

They didn't have to hit everything, but a couple of general multiplier design points - throughout and area? A MAC, or a straight multiplier? Shift add? Do they know enough to try to hit a certain primitive (DSP48E, fast carry chains?).

The wizard-only designers frequently couldn't even understand the question, and were incapable of discussing tradeoffs of area/time/resources.

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

#100

Post by Cyph0n » Tue, Sep 25, 2018, 2:54 AM UTC

dmitrygr wrote: post #90

Cyph0n wrote: post #81

Earlier quoted context omitted.

So how do you propose a non-profit like the IEEE make money?

Collecting $ from member orgs, and not from hobbyists who just want to tinker? How else do you propose to raise the next generation of hackers? By charging them $6000 to simply see a spec they have a minute interest in tinkering with?

Standards bodies usually give hobbyists access to documents if asked, but with strings attached, of course. In other words, they need to somehow prove that you will not be using the spec in a commercial setting. This was my experience with the TCG, for example.

As for the IEEE 802 standards, it seems like individuals can get full access to all specification documents that are 6 months and older via the IEEE GET program: https://ieeexplore.ieee.org/browse/standards/get-program/pag.... That sounds pretty fair, no?

In general, standards groups provide access in a similar way to software companies that give out free (or low-cost) access to their tools for open source developers and university students.