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

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

yosefk.com

Post reply on HN
Print view View original

31–40 of 110 posts

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

#31

Post by sklogic »

elihu wrote: post #26
nulldozer wrote: post #15

Earlier quoted context omitted.

That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc…

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

I'd rather classify HDLs as dataflow languages.

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

#32

Post by platz »

aprdm wrote: post #9
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.

Try to start modeling your problem as a state machine. Separate the combinational and the sequential part in two state machines. The flow becomes quite similar to regular embedded system software (that can be programmed using state machine pattern as well). Say e.g: state read_input => reg_a state multiply_input_by_10 => reg_b state send_to_output => finish_reg and then parallel to that you would have finish_wire or…

Sounds like flow-based-programming or even FRP (e.g. netwire)

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

#33

Post by vonmoltke »

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 pass on the black arts of chip design, tool usage, Verilog/VHDL quirks, and such. You slowly move up the ranks, either at your first company or another semiconductor company, until you are the senior engineer mentoring new grads. Then you retire.

Any deviation from this path and you're screwed. You don't come into this clique from the outside, and they won't let you back in if you move too far away. It has resulted in a negative feedback loop: this attitude is bolstered by how odd, archaic, and inaccessible the tooling is, but also serves to keep different approaches out and keep the tooling odd, archaic, and inaccessible.

Disclaimer: I'm a disgruntled EE and systems software developer who gets a steady stream of pings for web and NLP dev jobs but can't get the time of day from a hardware company.

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

#34

Post by aprdm »

lmeyerov wrote: post #16

Our experience with GPU cloud computing at Graphistry should be pretty representative. We spend a lot of effort getting subsecond interactivity in funny C dialects (OpenCL/CUDA). To get those down further, we can put together a few GPUs and reuse most of the code. Eventually, however, data communication costs get too high, so FPGAs would be the next step. That is certainly doable: OpenCL -> FPGA compilers are a thing…

With OpenCL + FPGA what you do is basically instantiate a GPU architecture inside an FPGA and then execute the OpenCL algorithm into that.

I think that's cool but you aren't getting a better throughput than what you would get with a GPU.

The better solution would be to do your custom optimised control/data path for the FPGA architecture you are currently using (VHDL/Verilog).

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

#35

Post by [deleted] »

sklogic wrote: post #28
nulldozer wrote: post #15

Earlier quoted context omitted.

That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc…

Of course they are programming languages. Anything with a well-defined semantics is a programming language.

[deleted]

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

#38

Post by noselasd »

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'm sure a lot of knowledge of hardware design helps, but it's not necessary. I've toyed around with VHDL on a DE0-Nano board, and while I have a lot of C experience I have none with HW design.

I can still program enough to do simple things, e.g. sample an analog temperature sensor, drive a simple led display that display current temperature, average of last hour etc.

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

#39

Post by Everhusk »

jonaldomo wrote: post #11

I think FPGAs are an untapped technology. I would love a book by Manning or Pragmatic called "FPGAs in Action" or "101 FPGA Projects". I have no idea what to do with it besides try to make a bitcoin miner.

Data science and Artificial Intelligence also comes to mind.

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

#40

Post by aprdm »

beeworker wrote: post #29
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…

While this is sort of true, this attitude contributes to the problem another commenter mentioned about how working with FPGAs is like taking a trip to the 70s. There's no reason you can't use a full-fledged programming language like Python to specify your hardware with the strict HDL subset at the RT Level, then use the full language's power to test it off-FPGA, and use all the software tooling around your full langu…

Yup, made an experiment with it -> http://www.eetimes.com/author.asp?doc_id=1323837

I really like MyHDL!

Post reply on HN