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

41–50 of 63 posts

Re: Implementing FizzBuzz on an FPGA

#41

Post by vvanders »

pjmlp wrote: post #38
vvanders wrote: post #36

Earlier quoted context omitted.

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…

Didn't miss it, just don't think they're equivalent. I appreciate functional programming and block diagrams/black box design are great tools for that space. However they don't capture the nuance of circuit design that goes into FPGA development.

You can't capture pipeline depth, SRAM usage, thermal envelope/clock gating that have significant real world impacts on your design.

Re: Implementing FizzBuzz on an FPGA

#42

Post by aldanor »

mrguyorama wrote: post #6

The most interesting part of all this is just how CHEAP some of the learning boards are. I don't know enough to understand how limited the ElbertV2 is, but at $30, it can still be pretty limited and a fun toy

... or how expensive the ‘real’ boards are, e.g. $7K for a Xilinx US+.

Re: Implementing FizzBuzz on an FPGA

#43

Post by bri3d »

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 entirely see where you're coming from, and this has completely changed in the last 2-3 years. SiliconBlue/Lattice used to be a niche-market low-power also ran in the FPGA world. Documentation was sparse and most examples from academia targeted Altera or Xilinx parts.

The open-source toolchain flipped this and allowed Lattice FPGAs to become the tool of choice for beginners and small-application hobbyists. There's now a tremendous wealth of resource available around getting started with Lattice FPGAs. And as the cherry on top, you don't have to wrangle the gigantic Vivado/Quartus/ISE suites to do so.

Re: Implementing FizzBuzz on an FPGA

#44

Post by asimpletune »

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.

How does the FPGA “non-code” get around the same problems?

Re: Implementing FizzBuzz on an FPGA

#45

Post by pitaj »

eebynight wrote: post #7
Cyph0n wrote: post #5

Earlier quoted context omitted.

The course focuses on synthesizable Verilog for FPGAs, so our instructor has made sure to clarify the upsides and downsides to using different logic for common tasks. Some interesting ones: * Never use asynchronous resets [on FPGAs] * if-else if-else chaining leads to unnecessary delays (priority encoders) * Avoid latches by making sure to assign default values * Never assume default values and/or states

Your professor seems great so far but pretty silly of him to teach you verilog instead of VHDL. As an EE myself I haven't seen a job description that says verilog over vhdl in a long time. Might want to familiarize yourself with both if you plan to pursue hardware design further.

I know Intel uses Verilog.

Re: Implementing FizzBuzz on an FPGA

#46

Post by vvanders »

asimpletune wrote: post #44
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.

How does the FPGA “non-code” get around the same problems?

Lots and lots of simulation :).

Part of it too is that you actually have a different set of problems. Let's say you build and abstract "Foo" block. In programming land you only pay for that block when your branch that selects it runs. Each line of code that references it just is the cost of a single opcode/asm call.

In FPGA/ASIC land each time you reference that block you're instantiating a physical copy of the block. So if your block takes 8-bits of SRAM and you have 300 references(or parent blocks that fan out to 300 references) you're now paying 2.4kB of SRAM from a fixed pool that's usually only a few mB.

Ditto switching logic, one of the fun parts of FPGA bring-up is they can have large in-rush currents of many amps as all the LUTs get flipped to their programmed state. You also have power(and usually thermal that's tied together) budgets driven by how much switching logic you run per-cycle.

It really has a lot more in common with more traditional engineering domains where planning, simulation and strong math models are the standard tools.

Re: Implementing FizzBuzz on an FPGA

#47

Post by xelxebar »

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.

> under the hood

Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood".

Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make?

I've got in mind things like Kirchhoff's laws, where we assume perfectly conducting wires, discrete elements, a conservative ambient B field, and essentially DC current over the size of circuit elements. When those assumptions start breaking down, then we can drop down a layer of abstraction.

Re: Implementing FizzBuzz on an FPGA

#48

Post by wepple »

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…

I’d highly recommend the IceStick for $21 - not only do you get an FPGA but it has an ft2232, so you have a serial adapter and basic JTAG adapter for free!

I’d keep one on my keychain if I could (it’s a tad too large).

Re: Implementing FizzBuzz on an FPGA

#49

Post by vvanders »

xelxebar wrote: post #47
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.

> under the hood Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood". Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make? I've got in mind thing…

I think most HDLs are approaching the diminishing returns of abstraction already. Most of the electrical characteristics are already captured in routing, setup and hold times so while you may not directly interact with them anything more than the most trivial design will be constrained by them.

By "under the hood" I was referring to the constraints you have on what you design. In the software space we are mostly constrained by memory(huge), network speed(blazing fast), CPU time(tasks running long normally don't break things).

In FPGA/ASIC land those constraints are much, much smaller(kB vs gB) and there are many more(thermals, power, hard cycle requirements, etc).

Re: Implementing FizzBuzz on an FPGA

#50

Post by FPGAhacker »

xelxebar wrote: post #47
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.

> under the hood Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood". Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make? I've got in mind thing…

Don’t know why you are downvoted right now.

A major abstraction, absolutely huge, is “Digital.” It’s all analog, and outside of the sanitizing Digital abstraction, it’s not pretty.

But the digital abstraction allowed for astronomically complex designs to be implemented.

Post reply on HN