Note also fpga4fun.com for some very practical examples on how to do common IO, or build a small network or graphics interface:
It's a blast interacting with these kinds of things at the logic level!
I started my (amateur) FPGA journey on a nandland go board a few years ago. Russell's exercises for beginners are an excellent resource.
Did anyone try out the CologneChip GateMate FPGA? It's supposed to have a completely open toolchain, but the dev board isn't exactly cheap at 230€
https://colognechip.com/programmable-logic/gatemate-evaluati...
Some rather affordable dev board is: GateMateA1-EVB
https://www.olimex.com/Products/FPGA/GateMate/GateMateA1-EVB...
This board has RP2040, not the successor RP2350.
Still looking for similar board with 1Gbit-Ethernet.
Place&Route is not yet open:
> nextpnr arch planned in 2023
> nextpnr arch planned in 2024
> there will be a beta version around Q4/2024 or Q1/2025. (24.10.2024) [1]
[1] https://www.fpga.ch/index.php/2024/10/24/gatemate-fpgas/
I started dabbling with FPGAs but having issues finding boards with open toolchains and high* speed peripherals (ethernet and/or PCIe), for now I'm using the Gowin boards with Yosys but they are not the best to get started
This board:
https://digilent.com/reference/programmable-logic/zybo-z7/st...
Because the chip is a processor and FPGA, you can use the FPGA for doing tests and processing without complicated interfaces. Both access the RAM and can work with it!
That’s bad advice. ZynQ brings the steepest learning curve. The developer needs understand FPGA development including tooling, ARM buses and Linux kernel. That’s way too much for a beginner.
The path with normal FPGA like Artix 7 or Spartan 7 and softcore processor would bring one much further. AXI specification alone is few hundred pages.
Aren’t Tang Nano‘s the best starting point? Really affordable and good tooling.
>>> without complicated interfaces
Oh my sweet summer child…
Making FPGA access RAM that is also accessed by the ARM CPU is no small feat. Definitely not for beginners.
I was wondering - if I was to use 2 high resolution (4Mpix each) screens (lvds or mipi), create "Li-fi" like transceiver 20+ Mbps and have ability to decode at 60+ FPS video streams - is there a single simple SoC that could handle this? Or still need FPGA?
It looks fun, until you run into the closed vendor-enforced tooling.
It's not AMD or Intel enforcing the tooling. It's the feds.
If anybody bothered reading the terms, they'd see its export restrictions.
Best avoid altogether, by filtering out hardware without open tooling.
The go-to is Lattice iCE40 (LP8K, UP5K) and Lattice ECP5.
Whereas Gowin GW1N is becoming an option.
Honestly, why is that a problem for a hobbyist? As long as it is not paid tooling, something being or not being open-source is mostly personal preference. I'm not interested in the source code of the Arduino compiler.
A concrete and relevant example: nandland's preferred target is a Lattice ice40 using Lattice's free-for-hobbyists closed-source "icecube" toolchain (yosys opensource doesn't support VHDL). Recently Lattice started charging hundreds of dollars/year for icecube and it was only because of community pushback that Lattice reintroduced a no-charge hobbyist tier. Had Lattice not renegged it would have been a significant detriment to hobby users who "didn't care that icecube sourcecode was unavailable".
It's so criminal and just rank ass terrible for this amazing segment of computing that it is - by and large - locked up behind incredibly hard to negotiate expensive software packages and solutions.
This is totally the gateway to seeing & understanding what computing actually is. And there are outstanding and fantastic chips with all kinds of capability on offer.
But almost universally they require very expensive obtuse custom/proprietary software to do anything at all. And two thirds the features on the chip require expensive IP add-ons to use from there.
It's just so so so unfortunate what a ceiling there is on adoption for fpgas. So much capability and so little ability for an empoweredearned community to form around such amazing power. There's something deeply scary to me especially about how, with fpga and RISC-V chip design in general, digital logic is cheap and plentiful, but as soon as you want interconnect or memory or io, as soon as you are looking beyond the scope of what you can do inside the scope of a chip, it's $$$ galore to buy ways to talk to the outside world, that open chip design & progress is strong but only in the confines of the digital domain.
I remember my college gf was really interested in FPGAs and was always talking to profs and their colleagues to get access to their tech stacks to play around, just to learn. I think she eventually got a job at a networking company like Cisco or other so hopefully got full time access.
> so criminal, rank ass, totally the gateway, empoweredearned, confines of the digital domain
are you an extra from Hackers?
The reason it's like this (and I agree it sucks) is that this kind of software is quite complex to develop and the likely userbase is very small. If you're a hobbyist or even a professional engineer and your goal is to make a specific thing to accomplish a task, rather than use a specific technology, well over 99% of the projects you can think of doing will be much better served by a commodity microprocessor than an FPGA. And cheap MCUs are getting faster every day, so certain things that might have needed an FPGA in the past can make do with programmable microcontroller I/O and maybe an affordable DSP chip today.
Not so complex as to prevent this from existing: https://github.com/YosysHQ (if you have a supported device, these tools work quite well)
The limiting factor is that to support a given device it has to be reverse engineered since FPGA vendors don't want to provide the necessary details... that's the main issue.
The main obstacle in developing such software is not its complexity, but the fact that the FPGA manufacturers do not document the format of their bit streams that must be used to program a FPGA.
It is the same like the difficulty of making a compiler and assembler for a CPU for which the manufacturer does not document its machine language (like the NVIDIA GPUs, but at least NVIDIA documents an intermediate language that you can use as a target for your compiler, while the FPGA vendors do not document anything).
Beaglebone RISC-V + FPGA
https://www.beagleboard.org/boards/beaglev-fire
That gives you access to ModelSIM via Microchip’s Libero suite.