How to choose an FPGA dev board. A guide for 2020 | Hacker News Reader

How to choose an FPGA dev board. A guide for 2020

thedatabus.io

44 pointsblackSparrow16 comments

My hope is we see io put to better use. Frankly DisplayPort is one of the best, most useful, easiest to use, highest bandwidth connections you can get, with a streams based architecture that supports many manners of interesting use. It seems OT to my following comments, is indeed pretty apes to oranges, but still one of my weirder but better hopes for ways we get fpga & other systems talking interestingly cheaply atop existing everyday consumer tech, which seems to be required for costs to be earthly & useful for integration. Go more open (no licensing fee & flexible) specs.

FMC tends to be big bulky & stupid expensive. PMOD is great for interfacing microcontroller shit, but this is FPGAs we are talking about. Throughput monsters with high speed serdes & rather fast regular io. These two longstanding options put you at a high very expensive end, or a pretty so so low density low data rate low cost end.

Which is silly. Everyone & their uncle is trying to push better high density connectors. Almost none have a community around them.

Very small & not a big community, but one example of an active much denser & higher throughput, there is syzyg.

https://syzygyfpga.io/

Also just a about out to the incoming io specs. There's a very big win when we can get better at stitching together systems & cxl, ccix, opencapi, & gen-z are each massively compelling new io/coherency systems.

> I strongly suggest completely disregarding anything to do with the processor for your first few projects and use only the FPGA part of the device.

I cannot disagree more strongly. Working with a hybrid software+logic project will teach you so much about both the similarities and differences between the two worlds.

CPU+software+fabric DMA+logic accelerator == win

I think what they mean is, as a beginner you don't want to try to learn FPGA and SW/HW codesign at the same time. At least I wouldn't advise it, that's really throwing yourself in the deep end. Better to tackle one area at a time and build incrementally.

If you're talking about people who already know atleast one of digital design or firmware design (writing bare metal drivers etc) then your advice makes sense. But if I were a beginner trying to understand how digital logic design works, the whole Processor + Programmable logic and the complex interfaces between them can overwhelm me and take me away from exploring the base digital logic that is implemented. It will be a much more enjoyable experience to create something in the programmable fabric first and then think about how you can interface it with normal software.

Funny that it doesn't mention the wide variety of very cheap prototyping kits from Crowd Supply -- including Fomu that fits entirely in your USB socket. FPGA kits on CS start at $15.

My disappointment with the FPGA world is how stuck it is in the "emulate an ASIC" rut. These things, physically, could change their whole logic and connectivity design on the fly according to instantaneous requirements, but everybody assumes you have to load them up once at reset and leave them that way. Each switch-point setting is just a flip-flop, no different from any of the ones in the LUTs.

Manufacturers enforce this treatment by providing only serial access to the switch-point settings in their tooling, but there is probably a lot of room for more flexibility, at least in some.

I'm all for cheap stuff for beginners but what good is an fpga board without a lot of peripherals? I mean the whole point of dumping your design into an actual fpga is to see it doing something. If I were just learning to desing, doing so would be very much possible in the software tools itself, if I'm able to succesfully go upto bitstream generation without errors and meet timing, it means my design is going to work on a physical board too. I'm open to changing my opinion on this though.

There are also cheap peripherals, as daughter boards or integrated. See for yourself.

This article aims to guide you in your search for a suitable FPGA development board which can often lead to you pulling your hair out!

I’ve only just got into FPGAs thanks to the Mister project, thankfully the people in charge of that project made a good choice for me. What they’ve achieved with the DE-10 nano to me is some sort of tech voodoo and I’m not easily impressed these days. £100 for the board and £30 for an SDRAM chip and I’m in retro gaming nirvana everyday. I’ve got a pocket sized, low power device that nearly boots instantly, pretty much perfectly plays every old machine from the the Spectrum up to the NeoGeo and GBA. RGB and VGA output, works with my Arcade stick, DS4, SNES/NES classic controllers, etc. Anyone with any interest in retro gaming who hasn’t yet dipped their toe in the water I urge you to give it a go. It’s probably the most exciting and vibrant open source community I’ve immersed myself in for many years.

A lot of the old silicon created in the 80's are unobtanium -- particularly certain chips in the Amiga hardware line.

> DO NOT fall into the 'Write code in C++/Python and run it on FPGA' trap. A lot of youtubers seem to be promoting stuff like that for beginners these days which is just sad.

Yeah, I'm not a big fan of this statement. Imagine if people said in programming, "Don't fall into the Rust/Python/.NET trap. Use Java."

Well comparing the FPGA world to the programming world cannot get any meaningless. If you read up about the state of HLS tools as of today, you will find enough experts telling you that they're nowhere near finding actual use in the industry, most of them only end up taking away the control you have over the design and all of them use way more resources when implemented than HDLs.

On the other end you have beginners asking stupid questions like 'okay how do I print hello world using python on this FPGA?' instead of thinking about the digital logic design that goes into it. Which is why I discourage the beginners from using anything but HDLs.

If anything HLS can be a good tool for professionals who already know what they're doing and understand what they're giving up by using an inherently sequential (programming) language to model inherently parallel hardware. They are in a position to use it as a tool to rapidly prototype their design and make incremental improvements thereafter, not beginners.

> If you read up about the state of HLS tools as of today, you will find enough experts telling you that they're nowhere near finding actual use in the industry, most of them only end up taking away the control you have over the design and all of them use way more resources when implemented than HDLs.

> On the other end you have beginners asking stupid questions like 'okay how do I print hello world using python on this FPGA?'

And why is it not simple? Dogma? Industry standards? Drinking the FPGA vendor kool-aid?

What's wrong with having "print('hello world')" run on a micropython running on a risc V core on an FPGA? Because that's not an optimal solution? Are you serious? To me that seems like an awesome first step.

> What's wrong with having "print('hello world')" run on a micropython running on a risc V core on an FPGA?

Because it betrays a misunderstanding of WHY you are using an FPGA in the first place.

If you want to program a microcontroller, go get a microcontroller.

You generally use an FPGA for a reason. And that reason almost always relates to speed (either latency or throughput). VERY occasionally it has to do with simply translating logic standards (changing from something like LVDS differential to standard CMOS, for example).

If you don't need speed, you should go back to the microcontroller. And, even if you need speed, you should still go back to a microcontroller and see if you can bend it to your needs somehow.

Programming an FPGA isn't just "throw some HDL around". Why do you need a clock? What are synchronizers and why do you need them? Why does my FPGA suddenly not have enough resources when I design a numerical divider and ask it to be fast?

Digital design != programming. And vice versa.

Programmers complain all the time "Git is easy. You just have to learn its mental model." and bitch about people that won't. So, why do you believe that wouldn't also hold for digital design?

> And why is it not simple?

How would you answer to someone complaining that "Why isn't programming simple? Dogma? Industry standards? Drinking the IDE vendor kool-aid?"

As a reminder, remember, "Hello, world." is a very difficult hurdle for most non-programmers.

> What's wrong with having "print('hello world')" run on a micropython running on a risc V core on an FPGA?

RISC-V is slightly odd in that actual microcontroller hardware is a bit thin on the ground. However, wanting to play with RISC-V via an FPGA development board that isn't explicitly set up for that purpose is kind of like learning Rust by programming an STM32F7 development kit.

You can, but boy are you making your life miserable.

The first thing one needs to understand is that FPGAs are highly specialised tools. They're only used in cases where extraordinary performance is required, more than what processors can provide, just because there are tools nowadays that let you print hello world doesn't mean it's a good idea. The entire thought process behind digital design is very different from that of programming.

Whether or not that's a valid critique, it puts you as a gatekeeper to who can or cannot learn what an FPGA can do.

Sorry, I believe knowledge should not have gatekeepers.

Reply on news.ycombinator.com