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

101–110 of 119 posts

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

#101

Post by lnsru »

Shikadi wrote: post #70
sfifs wrote: post #10

Earlier quoted context omitted.

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…

Maybe for personal projects, but I find I spend more time dealing with vivado bugs than I do vhdl bugs. I spent four hours today just getting a simulation to run correctly in 2017.3 upgraded from 2016.1. My Co worker was simultaneously dealing with a bug where deleting a net in ECO was silently deleting other nets, and not necessarily causing an error. EE tools are the worst.

First rule of FPGA development: never ever upgrade IDE in the middle of the project. Even if it’s a move from 2016.x to 2017.y version it can cost 2 months of precious time just dealing with some nonsense migration stuff/broken projects/broken settings.

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

#102

Post by snowwindwaves »

dmitrygr wrote: post #47
Cyph0n wrote: post #17

Earlier quoted context omitted.

IEEE tracks a vast number of open standards and specifications (e.g., Ethernet, WiFi, Bluetooth). I guess the comment was pointing out that there is a degree of openness in EE.

> IEEE tracks a vast number of open standards And demands mega-bucks for a PDF of any of those standards

The few university libraries I have been to had online subscriptions to all the IEEE publications so any standard or paper could be downloaded by anyone who walked in to the library and sat in front of a computer. Not as convenient as downloading from your home and office but as freely available as any book in the library.

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

#103

Post by duskwuff »

IX-103 wrote: post #94
duskwuff wrote: post #83

Earlier quoted context omitted.

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.

The relevant documents here are the "Virtex-6 Libraries Guide for HDL Designs" and "… for Schematic Designs". (There are similar documents for other part families.) These document all primitives available in the Virtex-6 family, including:

• Individual LUTs, with optional local or dual outputs (LUT1, LUT1_L, LUT1_D, … LUT6, LUT6_L, LUT6_D)

• Flip-flops (FDCE, FDRE, etc)

• The carry chain, which can be instantiated directly (CARRY4), or as its individual elements (MUXCY, XORCY)

• Shift registers implemented in LUTs (SRL16E, SRLC32E)

• Dynamically configurable LUTs (CFGLUT5)

https://www.xilinx.com/support/documentation/sw_manuals/xili...

https://www.xilinx.com/support/documentation/sw_manuals/xili...

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

#104

Post by Taniwha »

IX-103 wrote: post #97
tails4e wrote: post #82

Earlier quoted context omitted.

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.

One of the things to realise about HDLs is that they describe hardware - real hardware is non-deterministic, there are race conditions, clock crossings, metastability etc etc

It's honestly not possible to have a "defined behaviour" in all circumstances - verilog simulators don't define event order, if you depend on them stuff will break (we all fought that battle 20 years ago), more importantly you kind of hope stuff breaks to indicate you might not be building designs that work on real hardware

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

#105

Post by atq2119 »

TomVDB wrote: post #54
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…

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

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

... and we have no realistic hope of figuring out whether maybe the tools can be improved to help with that, because the tools aren't open :)

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

And my point was that it's impossible to do Pareto improvements as long as the back-end is a black box. Like, you could come up with a better high-level language for the "front-end", sure. And that new language may be more convenient for writing a design.

But if the way you synthesize this new language is via Verilog, then those nice features you mentioned, like for showing the critical path, will de facto be lost -- because the closed tools will show you the critical path in the intermediate Verilog. And if you've ever actually worked with HLS tools, you'll know that this intermediate Verilog is totally opaque unless you spend a very large time understanding the translation tool.

The new "front-end" solution will be better in some respects, but certainly worse in others, and the only way to get improvements across the board is if you have control over the whole "stack".

So I think you're making some good points, but I feel like you're missing the larger point that a truly open ecosystem is desirable precisely because improvement may come in places and from places that you would never have considered.

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

#106

Post by nielu »

LeifCarrotson wrote: post #32
monocasa wrote: post #3

Earlier quoted context omitted.

And to be fair, since then FPGAs have exploded in non ASIC prototyping use cases. They're even starting to be used for some consumer electronics.

I'm interested in seeing some examples of their use in consumer electronics. I think this article would be a lot more compelling if it had a section on "You've already bought one if you have a (hypothetically) Roomba vaccum/ Tesla Model S/ Thinkpad laptop/ Ubiquiti router." I'm pretty sure most of those don't have FPGAs, but would be curious to see a list of things which do. I am by no means a representative consumer…

There are FPGAs in both vive headset and wands

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

#107

Post by tails4e »

IX-103 wrote: post #97
tails4e wrote: post #82

Earlier quoted context omitted.

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.

Can you give example of a verilog code snippet vivado actually mis compiles? I've found it incredibly reliable and often use it to double check other tools' results.

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

#108

Post by tails4e »

FPGAhacker wrote: post #98
tails4e wrote: post #82

Earlier quoted context omitted.

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.

So you not only want open source hardware specs but open source existing tools? I don't see intel open sourcing icc, or other software devlopment centric companies open sourcing their IDEs - ao why shoukd FPGA vendors? The original point was allowing open source tools to be developed like gcc, and the response was that it has not happened despite some ground up tools do exist but are very primitive.

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

#109

Post by meuk »

duskwuff wrote: post #84
esmi wrote: post #75

Earlier quoted context omitted.

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

The keywords are "device-limited". Xilinx WebPack won't build bitstreams for some of the larger and faster devices.

It is deprecated: it won't generate bitstreams for any new FPGA.

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

#110

Post by skummetmaelk »

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…

Most EE EDA/CAD tools are ancient monstrosities of patchwork with a user experience reminiscent of using eclipse 0.01. Full of bugs, lack of fast CLI tools. Everything must start a core process that takes many seconds to even boot. It's ridiculous. Software engineers don't know how good they have it in terms of tools.
Post reply on HN