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

Implementing FizzBuzz on an FPGA

righto.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Implementing FizzBuzz on an FPGA

#31

Post by vvanders »

pjmlp wrote: post #27
vvanders wrote: post #10

> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.

It depends very much where we as developers come from. My CS degree had quite a few sections of electronic lectures. In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.

That's still an impartial model because each layer of abstraction can introduce path delay and resource usage.

Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.

Re: Implementing FizzBuzz on an FPGA

#33

Post by MisterTea »

gh02t wrote: post #14
leggomylibro wrote: post #8

Earlier quoted context omitted.

I got a couple of ICESticks I've been meaning to play with a little while ago, they're only $25 MSRP and have a 'USB stick' form factor. But it's hard to find and get started with a good open source toolchain. I have heard good things about IceStorm, but haven't gotten around to setting it up. It's great and inspiring to see people successfully stepping through these sorts of starter projects and documenting them, th…

> But it's hard to find and get started with a good open source toolchain That's because there aren't any. The one you have happens to be the exception - it's the only FPGA line with an open source toolchain AFAIK. FPGAs are the realm of large, heavily proprietary build environments.

> That's because there aren't any.

Incorrect. See: http://www.clifford.at/icestorm/

Re: Implementing FizzBuzz on an FPGA

#34

Post by jdswain »

lnsru wrote: post #4

Amazing project to learn how FPGAs work. Not overkill with some high speed interfaces, but touches all problems: no easy division by 3 and 5, counters everywhere, no copy/paste solutions, no libraries with helpful functions. Though Xilinx ISE is obsolete, Vivado is the current tool.

And the QFP Spartan 6 is the most powerful Xilinx FPGA that is hand solderable. Maybe not a concern if you are using an existing board or have a reflow oven, but for me that is a good reason not to go up to Spartan 7 or newer.

Re: Implementing FizzBuzz on an FPGA

#35

Post by pjmlp »

vvanders wrote: post #31
pjmlp wrote: post #27

Earlier quoted context omitted.

It depends very much where we as developers come from. My CS degree had quite a few sections of electronic lectures. In fact, one way I always looked at function composition in FP languages was to think of them as digital circuit modules.

That's still an impartial model because each layer of abstraction can introduce path delay and resource usage. Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.

True, still it is easier than trying to think in imperative programming when doing FPGA programming.

There are quite a few books using LP and FP for modelling of digital circuits.

You can also introduce signal propagation modeling on them.

Re: Implementing FizzBuzz on an FPGA

#36

Post by vvanders »

pjmlp wrote: post #35
vvanders wrote: post #31

Earlier quoted context omitted.

That's still an impartial model because each layer of abstraction can introduce path delay and resource usage. Functional programming doesn't encapsulate interfacing across different clock domains or one hot vs binary state representation. Trying to bring those abstraction models to HDL you'll find a significant impedance mismatch.

True, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.

I think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming.

You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints.

HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.

Re: Implementing FizzBuzz on an FPGA

#37

Post by gh02t »

MisterTea wrote: post #33
gh02t wrote: post #14

Earlier quoted context omitted.

> But it's hard to find and get started with a good open source toolchain That's because there aren't any. The one you have happens to be the exception - it's the only FPGA line with an open source toolchain AFAIK. FPGAs are the realm of large, heavily proprietary build environments.

> That's because there aren't any. Incorrect. See: http://www.clifford.at/icestorm/

I meant to explicitly say that the Lattice iCE40 is the one exception thanks to a heroic volunteer effort. I edited a bit to make that clearer.

Re: Implementing FizzBuzz on an FPGA

#38

Post by pjmlp »

vvanders wrote: post #36
pjmlp wrote: post #35

Earlier quoted context omitted.

True, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.

I think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming. You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints. HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.

And you missed mine, as I mentioned that we had electronic lectures.

I am not talking out of thin air and wild guesses how things should be, rather about my personal experience how we learned digital circuit design and how later, already with that skill, we applied the ideas to FP.

That was the goal of my initial comment, Hardware Design Ideas -> Help understating FP function combinations as if they were ICs, not how to design hardware from FP concepts.

Re: Implementing FizzBuzz on an FPGA

#39

Post by nmz787 »

katastic wrote: post #20
TomVDB wrote: post #18

For those looking for cheap FPGA boards, I highly recommend looking for something that is based on the Lattice ICE40. The cheapest board you can find is probably the $9 Upduino, though trickier to get going. (Complete lack of documentation.) But there are tons of hobby boards in existence. The best part is Project IceStorm, a fully open source tool flow, from synthesis to bitstream. While not the best in terms of opt…

My problem (years ago) was that with Lattice, there just aren't as many tutorials/easy-EDA and they kind of expect you to know what you're doing. So if you've never taken a class on FPGA's and learned how netlists work, et al, Lattice may be a harder time. I ended up buying a cheap Altera afterward just to learn.

I think that's solved now though, at least for a few ICs and toolchains, via things like MyHDL and/or rhea (tldr; Python wrappers) and websites like fpga4fun.com

Re: Implementing FizzBuzz on an FPGA

#40

Post by thewizardofaus »

vvanders wrote: post #36
pjmlp wrote: post #35

Earlier quoted context omitted.

True, still it is easier than trying to think in imperative programming when doing FPGA programming. There are quite a few books using LP and FP for modelling of digital circuits. You can also introduce signal propagation modeling on them.

I think you're missing my point ;). You shouldn't be trying to think in imperative or functional programming because fundamentally FPGAs/HDL isn't programming. You should be thinking in terms of state machines, pipelines, routing, delay & setup+hold constraints. HDLs are just a high-powered blueprint languages. At the end of the day you're still just laying out physical blocks.

I found this discussion interesting to read. It appears it's comp sci FPGA knowledge vs Electrical Engineering FPGA knowledge. Not so much knowledge but how to think about an FPGA as a whole.
Post reply on HN