How FPGAs work, and why you'll buy one (2013) • Hacker News Board

Re: How FPGAs work, and why you'll buy one (2013)

#51

Post by sklogic » Thu, Apr 16, 2015, 6:36 PM UTC

Matumio wrote: post #46

sklogic wrote: post #37

Earlier quoted context omitted.

And why setting up LUTs and interconnect is not a programming?

(Apologies for deletion. I moved my comment to parent. Won't try that again.) It is, but on a different level. I think the analogy would be that in VHDL/Verliog you are dealing with a template or macro language (which is executed to generate code) as opposed to a low-level language (which translates almost directly to machine instructions).

I'm not sure a presence of a stream of instructions or anything comparable is a requirement for a definition of a "programming". You can program a DNA, or a slime mold: http://www.wired.com/2013/06/slime-mold-computers/

Or even crabs: http://hackaday.com/2012/09/28/making-logic-gates-out-of-cra...

Anything which can be used to implement any kind of computing in a broad sense is a programming, as long as it's done using a well-defined formal language.

Re: How FPGAs work, and why you'll buy one (2013)

#52

Post by azeirah » Thu, Apr 16, 2015, 6:40 PM UTC

sklogic wrote: post #30

TorKlingberg wrote: post #12

Earlier quoted context omitted.

As a C programmer, I don't think C is suitable for such a fundamentally parallel architecture as an FPGA. I would prefer a higher level language, maybe declarative, where it is up to the compiler to lay out the parallel operations. Unfortunately the engineering culture gap from HDL to a high level language is much wider than to C.

Actually it's easier and more natural to translate a (domain-specific) high level language into RTL than trying to fit an alien but so-called "general-purpose" C. I'm using a language which translates into Verilog, but features native support for expressing things like FSMs, pipelines, buses, FIFOs - and something as simple as this makes HDL coding much simpler and much less error-prone than a conventional low-level…

This is because C, as I understand it, is a language that best described the fundamental workings of processors, and let you work with a thin-abstraction layer over the cpu/memory architecture.

FPGA don't have this traditional cpu/memory architecture, and as a result, C fits them poorly.

Re: How FPGAs work, and why you'll buy one (2013)

#53

Post by davexunit » Thu, Apr 16, 2015, 6:41 PM UTC

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them.

The only project I know of to make any real progress on fixing this is fpgatools. [0] It supports a single model of the Xilinx Spartan-6 series, the XC6SLX9. I know almost nothing about FPGAs, but seeing as how almost no one is working on this problem, I figured I'd try to add support for the XC6SLX45, the model that is the Novena motherboard. So far I've added the C code to represent all of the pins. [1] Unfortunately, I haven't heard anything from the maintainer about how to proceed further.

fpgatools is only a single piece of the puzzle, though. It provides libraries to build the low-level bitstreams, but we'd still need Verilog/VHDL implementations that use it, as well as replacements for the proprietary "soft cores" that most people are using. The amount of work required is intimidating. Not having an HDL readily available did motivate me to have some fun rewriting the example C programs in Scheme, though. [2]

Does anyone know about other such efforts to free FPGAs? I'd be very grateful to hear about them.

[0] https://github.com/Wolfgang-Spraul/fpgatools [1] https://github.com/Wolfgang-Spraul/fpgatools/pull/8 [2] https://gitorious.org/davexunit/guile-fpga

Re: How FPGAs work, and why you'll buy one (2013)

#54

Post by frozenport » Thu, Apr 16, 2015, 6:41 PM UTC

vonmoltke wrote: post #33

jychang wrote: post #13

I am currently just another college student, but I have some experience in this field, as I had interned at Xilinx (which is the largest FPGA maker right now, iirc, although Altera may have taken the crown). I don't think your typical college CS student, and by extension, the average programmer, would be interested in using FPGAs right now. This isn't an issue of performance, or costs, or lack of use cases- FPGAs are…

One of the biggest problems is how insular and impenetrable that community is. The FPGA community, and to a certain extent the entire semiconductor industry, seems to have a prescribed path for engineers. First, you get an electrical or computer engineering degree with a couple internships at semiconductor companies. Then, you get a junior role at one of those companies where you are mentored by senior engineers, who…

This is non-sense, consider the thousands of self taught FPGA programmers in Asia.

Re: How FPGAs work, and why you'll buy one (2013)

#55

Post by jeremycw » Thu, Apr 16, 2015, 6:41 PM UTC

viccuad wrote: post #18

I think a lot of people posting here don't realize that programming an FPGA means programming how the gates are set up on the FPGA, not software programming. VHDL/Verilog etc are descriptive languages, not software languages ala C/Python/Java/etc. You should have enough hardware design knowledge (at RT level) to be able to sketch your HW design in a piece of paper, and then, you are apt for writting VHDL/Verilog and…

I disagree that you need that much hardware knowledge. I also think that statements like these can be discouraging to people that don't have a background in hardware. That's a shame because for me playing around with HDLs was one of the most mind opening experiences for a software developer.

I wrote tetris in Verilog that outputs to VGA[0]. I definitely encourage anyone interested in HDLs and FPGAs to start learning.

[0] https://github.com/jeremycw/tetris-verilog

Re: How FPGAs work, and why you'll buy one (2013)

#56

Post by sklogic » Thu, Apr 16, 2015, 6:45 PM UTC

azeirah wrote: post #52

sklogic wrote: post #30

Earlier quoted context omitted.

Actually it's easier and more natural to translate a (domain-specific) high level language into RTL than trying to fit an alien but so-called "general-purpose" C. I'm using a language which translates into Verilog, but features native support for expressing things like FSMs, pipelines, buses, FIFOs - and something as simple as this makes HDL coding much simpler and much less error-prone than a conventional low-level…

This is because C, as I understand it, is a language that best described the fundamental workings of processors, and let you work with a thin-abstraction layer over the cpu/memory architecture. FPGA don't have this traditional cpu/memory architecture, and as a result, C fits them poorly.

Exactly. C assumes too much about the hardware semantics, it's got a peculiar memory model, sequential execution and all that. There are tricks, of course, allowing to get out of the C box a little bit - e.g., using multiple address spaces to simulate distinct memory and memory-like blocks, but it's still unnatural and do not make hardware description any simpler than doing it manually in RTL level.

Re: How FPGAs work, and why you'll buy one (2013)

#57

Post by sklogic » Thu, Apr 16, 2015, 6:49 PM UTC

davexunit wrote: post #53

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them. The only project I know of to make any real progress on fixing this is fpgatools. [0] It supports a single model of the Xilinx Spartan-6 series, the XC6SLX9. I know almost nothing about FPGAs, but seeing as how almost no one is working on this problem, I figured I'd try to add support for the XC6SLX45, t…

Wow! How did I managed not to know of this project?!?

Re: How FPGAs work, and why you'll buy one (2013)

#58

Post by cfsc » Thu, Apr 16, 2015, 6:52 PM UTC

tel wrote: post #47

elihu wrote: post #26

Earlier quoted context omitted.

Hardware description languages are not imperative programming languages (even if they might superficially resemble them). That doesn't mean they aren't programming languages at all -- they just belong to a different category of language. (I suspect that there's a connection between hardware design and functional programming, but I don't have enough hardware design experience to know how closely the two are related.)

Conal Elliott, Haskeller of FRP fame, was recently working for a company where he was developing a compiler of functional programming into categorical semantics which is actually quite neatly similar to the layout of a circuit. The company went under, unfortunately, so I'm not sure of the status of his research, but some remarks are available on his blog [0] [1] [2]. Further, there is a notion of a Generalized Arrow…

You have CλaSH [0] based in Haskell developed at University of Twente that has the same goal.

[0] http://www.clash-lang.org/

Re: How FPGAs work, and why you'll buy one (2013)

#59

Post by varelse » Thu, Apr 16, 2015, 6:54 PM UTC

Right now, FPGAs deliver slightly better perf/W than GPUs, but significantly inferior FP32 performance. That said, they do shine for simple embarrassingly parallel tasks assuming the task does not require FP32 operations. A good example here is bitcoin mining.

That changes this year with the release of Altera's Arria 10, which comes with 1.3 TFLOPS of hardcoded FP32 math units. The other gamechanger is the ability to write kernels in OpenCL rather than VHDL.

However, the build time for OpenCL on FPGAs is still many hours compared to tens of seconds for GPUs so my guess is that GPUs will remain the development platform for FPGA code for the foreseeable future, occasionally deploying to FPGA on a daily basis or so.

Drifting a little off-topic, the SDKS and libraries for all the accelerators should be free. That's what makes me such a CUDA fanboy. I'm looking at you Intel. Charging for your Xeon Phi/CPU OpenCL compiler? Bzzzzt wrong...

Re: How FPGAs work, and why you'll buy one (2013)

#60

Post by jamieiles » Thu, Apr 16, 2015, 6:54 PM UTC

Igglyboo wrote: post #7

The trouble I had with FPGAs is how radically different languages like Verilog and VHDL are when compared to languages like Java, Python, or C++. Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.

I have mostly the same experience as a software engineer playing with FPGA's. I don't buy the argument that Verilog isn't a programming language - there are still plenty of software principles that apply to a HDL and we should take advantage of those. There are interesting differences to software - we're used to sequential software being easy and parallelizing it being hard. In a HDL, parallel is easy but sequential logic is much harder requiring state machines. Writing testable software was historically hard, but test cases cheap. It is easy to write a testable Verilog module, but fairly expensive to write test cases compared to software.

Software tools are also way ahead of FPGA tools. I'm not sure how folks that develop FPGA designs professionally retain their sanity after using the tools...