I'm the author of the blog .
Not trying to promote myself but since you posted, the v3 of the board is available on the tinyvision.ai and tindie stores.
I discontinued v2 as it was a terrible design that I couldn't stand behind.
There are many reasons to learn about fpga's. Yes micros have their place as well and are very capable and cheap like the Nxp RT series.
alfiedotwtf
What's the best place to start learning about FPGAs? I've been wanting to dip my toes in, but not sure where to begin.
Also, icestudio (https://icestudio.io/) is a gentle way to get introduced with minimal knowledge to the verilog side of things.
As others have posted, the learning curve for HW can be steep and development tools tend to be in the dark ages as compared to those for SW development. eg. you will spend a lot of time hitting your head on a wall with debugging HW if you arent careful to follow a process of linting and simulating your design well before going to HW.
nMigen is highly recommended.
alfiedotwtf
Excellent. Thanks to you both!
dancek
While it's not about FPGAs, I got started by working through https://www.nand2tetris.org/ . After that I bought an UPduino v2 and started hacking. Of course working on a fantasy CPU and a real FPGA are completely different, but the mindset of how hardware works vs. how software works is very valuable.
MuffinFlavored
Can it run Linux? What comes close to beating the $10 Raspberry Pi Zero W?
gorkish
It is an FPGA; it can run synchronous logic operations. This could include something like the encapsulation of an entire gate and circuit accurate simulation of an entire system of processors, memories, and interfaces, like say, a Super Nintendo (see MiSTer for more of this). This is a very different domain than a raspberry pi, and while the chip here lacks the resources to run something like MiSTer it will likely be used to run something like a microcontroller SoC with customizable peripherals. The $25 price point for everything and the kitchen sink is just right. The comparison to Arduino is much more apt than to the Pi.
numpad0
Not enough RAM. 640kB is actually enough for anyone as far as scalar variables in a single app are concerned so that’s what these small single task microcontrollers have.
spongeb00b
> 640kB is actually enough for anyone
For a minute there I thought you were about to quote a certain Mr Gates...
But I'm now claiming "Mr Gates" to be the name of my first FPGA project
ktm5j
This gave me a good chuckle
funkasterOP
I was looking for a cheap (< $30) board to start playing with FPGAs and found this one. It's a good improvement over the v2 that had some signal issues[0]. The examples also include a RISC-V core.
I love the emphasis on breaking out all of the GPIO pins, it is incredible today how many dev boards either leave pins as not connected or hard wire them (no jumper to disable) to some onboad peripheral. Looking at you stm32 discovery boards...
the__alchemist
The Discovery boards are a bit of a minefield over which pins you're allowed to use. It can cause surprising problems if you don't check the dev board manual's pin table, or don't know how to interpret it. Additionally, you need to plug the jumpers into the bottom of the board; it looks like you can use the top, but the jumpers tend to fall out!
The nucelo ones are even weirder. The pins aren't labeled on the board, and they're in a weird layout, with some male and others female.
fpgaminer
> It can cause surprising problems if you don't check the dev board manual's pin table
Nah, you got it all wrong. You need to pull up the devboard's Pinout, User Guide, and Overview documents. Sometimes cross reference those to the devboard's schematic for the trickier pins. Alongside the specific User Guide and Programming manuals for the MCU on the board. Plus the MCU's guides don't typically cover stuff that's common to all MCUs in a particular Cortex family, so you need to pull up the Cortex documentation. And then, finally, the errata documents.
Typically speaking you'll need to cross reference across all of those documents, all at once, and several places _within_ each document ... all at once.
That's assuming you're using one of the more common pins. If you've decided to dabble with any of the more exotic functionalities you'll want to pull up one or several Application documents, as the former pile of documentation is unlikely to accurately describe the necessary "voodoo" to get things working.
(I kinda wish this comment was a joke ... but it's not. The STM line of chips are truly wonderful machines but ... golly are they a pain to develop on. There's a reason most people just use Arduino to plaster over this stuff.)
EDIT: Oh and make sure you don't confuse the labeling of the pins on the board, with the label of the pins on the pinout, with the label of the pins on the schematic, with the label of the pins in the registers, with the label of the pins in the various HAL libraries...
EDIT2: Geez, how could I forgot the most crucial thing: you of course have to modulate all of these by which specific package of the chip you're actually working with. No sense spending half an hour of your life wadding through all of this documentation only to get to the dev board pinout to find that pin is only available on the largest package and the dev board only came with the 2nd to largest package... (and also doesn't include that one peripheral you were planning to use because ... reasons).
the__alchemist
Those issues transcend the discovery board. It's frustrating how much the Reference Manuals leave to the imagination. A lot of the peripherals are similar or identical across families. Some have subtle differences, and some have large ones. I haven't found a shortcut - seems you really need to bring up parallel reference manuals.
For example, the RTC periph is the same on most STM32 devices. Clocks vary significantly between families, as expected, but at their core, are just different combos of multipliers and internal oscillators, which you can break out by comparing clock trees. Things like I2C vary wildly between families, and sometimes within families.
duskwuff
> For example, the RTC periph is the same on most STM32 devices.
There's actually two major versions of the RTC peripheral. :) The v1 RTC counts in seconds, v2 has explicit date/time fields.
A lot of other STM32 peripherals can be seen as "versioned" in similar ways. There's a lot of different combinations of those peripherals on different parts, but there's usually only two or three major revisions present of each peripheral across the entire product line, and they tend to follow a pretty consistent timeline. (That is, a newer part will usually use the newest version of each peripheral at the time it was designed, rather than using a mixture of old and new peripherals.)
cerplum
One potential shortcut is if you install their CubeMX and take a look in it's data files there are XML files for each distinct peripheral. So there'll be something like RTC_v1.0.xml and RTC_v2.0.xml. Someone uploaded an old copy of them [1] if you just want a quick look.
Then there's also device & device family xml files that link to the various peripherals they have [2].
There's probably no guarantees but in my experience if two devices link to the same version xml file their peripheral registers at least will be identical. Quirks and silicon bugs, you are on your own of course... but then the ref manual doesn't help with that either!
It's amazing how many dev boards with 300 GPIOs on the chip give you... 50 (especially looking at you, Xilinx!). At least give me a tiny little header that I can use if I'm determined enough.
Signed,
Someone who needs 200+ pins in a current design and doesn't want to make their own board from scratch.
webgoat
Not to snipe this post or anything, but you can get a Xilinx zynq 7000/7010 on Aliexpress for ~$20 right now (likely old bitcoin mining boards being tossed).
DoingIsLearning
Clearly you haven't had the pleasure of completing any production grade projects using 'Xilinx Vivado', or for an even richer experience they're repackaged Eclipse 'Xilinx SDK'.
I really hope yosys matures and is adopted in large numbers in industry, to become a de-facto gcc equivalent for FPGA compilation. Decoupling FPGA designs from the half-baked tools that vendors push out would be real progress.
Maybe depends on where you are, but I got this board with shipping to Europe for ~14USD a few weeks ago
qwerty456127
How about an FPGA dev board that's cheap, simple (or not really), supported by OSS toolchain and can emulate a RISC-V SoC with performance sufficient to run a fully-functional Linux desktop?
I once stumbled upon an article where somebody FPGA-ed (with a much bigger board, I don't insist it has to be this small and simple) a RISC-V system to make a "RISC-V PC" and I'm thinking about getting an FPGA to explore that since then.
ohazi
"Linux on LiteX-Vexriscv" [1] is a fun way to get started. The readme includes a table of supported boards, as well as the amount of memory and maximum tested clock frequency.
I played with it on an OrangeCrab [2], and was shocked by how easy it was to get it running and by how well it worked despite the slow clock. The FPGA design includes peripherals for GPIO, PWM, serial interfaces, etc., and the kernel includes drivers to talk to them. On the OrangeCrab, everything I thought to try pretty much just worked as expected.
That being said, this is mostly just a fun exercise in SoC building, and isn't going to give you PC-like performance. VexRiscv is small and fast and super configurable, but you're still looking at "high-end microcontroller" rather than "low-end application processor" levels of performance.
I'm not sure if there really are any affordable FPGAs that are capable of running a RISC-V core with anything even approaching desktop performance. You'd likely struggle to get even original gen 1 Raspberry Pi performance out of anything in the sub-$100 range. I'm far from an expert on FPGAs though and have only dabbled, so if anybody knows differently I'd love to hear it.
rcxdude
Unlikely to be availible. FPGAs are orders of magnitude slower and more expensive than the equivilent hard silicon. You can get the performance at a much higher price (high $100s to low $1000s) or much less performance (maybe you can run linux but it won't be a desktop) for the price.
ncmncm
Crowd Supply has quite a selection of often astonishingly cheap FPGA prototype boards supported by all Free toolchains.
The mother lode of cheap, capable FPGAs seems to be supply chains for makers of TVs.
KMag
Is the reason for this that smart TVs need to be able to add real-time video codecs (actually, just the decoders) on a shorter lead time than is possible with ASICs? TVs generally strike me as things where economies of scale make FPGAs look less attractive. Though, I clearly don't know much about the industry.
ncmncm
My interpretation is that they expect to need to add decoders as firmware upgrades after the product ships. It is awkward to have a warehouse full of TVs no one will buy because they don't handle somebody's new AV1 streaming format.
I bet most don't plan to let customers upgrade that way, instead of buying a new TV. I expect they will sell the same hardware with a different model number and just new firmware. They like changing model numbers frequently anyway to frustrate reviewers and people consulting them.
tieze
Not extremely cheap, but the ULX3S fits the bill. It's got the inputs and outputs and all.
MobiusHorizons
It has only 32meg of ram though, so that would likely limit you to terminal linux.
qwerty456127
Thanks!
snvzz
There's plenty of such boards these days.
I generally recommend the iCESugar and the ULX3S, for iCE40 (UP5K) and ECP5 respectively.
I own both boards, and a few more I don't feel like recommending.
mhh__
FPGA Thread: Bluespec SystemVerilog is now completely open source, very nice HDL although quite opinionated.
I am not versed enough in FPGA to know if this is just a marketing rebranding of common features (apparently a focus on LUTs and add-and-multiply operations) or if it is an actual edge.
Though, if that thing can do pattern recognition in images and draws 10 mA max, that's an interesting package for $24
the__alchemist
How does this compare to alternatives for learning FPGA? What's the significance of the duino suffix?
When would you choose FPGA over something like an STM32? From what an internet search leads to, they can be faster / do more things in parallel for the price. And you can add capabilities (More timers? More op amps?) with firmware updates. Is this at the core of when you'd choose one?
I've no experience with FPGA, but would like to learn. This is listed as "no longer available for sale". Which dev board do you recommend? Thank you.
bsder
> When would you choose FPGA over something like an STM32?
The answer is "almost never". Qualifications below.
Learn the Cortex-M4 ecosystem first. You can do a remarkable amount of stuff by abusing microcontroller systems in weird ways. The tools for dealing with microcontrollers are MUCH better than the FPGA ecosystem tools (which suck--and that's on a good day).
If you need an FPGA, generally you know it. The first sign is: "There's no way to do this with my microcontroller." That step is generally followed by: "Is there a different microcontroller that could do this?" followed by asking the old greybeard "Is there really no way to do this on a microcontroller?" And finally, "Crud, this can't be done on a microcontroller"--at that point you can consider an FPGA.
As someone who has been dealing with this for mumble too many years, I've been slowly migrating functionality of my clients away from their FPGAs and into the microcontrollers more and more. It's just way easier on too many fronts--and they don't have to learn Verilog/VHDL. The FPGAs will never go away, but they will have the minimum functionality we can get away with.
> I've no experience with FPGA, but would like to learn.
I'm likely to get some static for this, but get an actual supported dev board and not an open-source hacker board. I would recommend something like this that has an academic version:
Use the manufacturer tools (which, in this instance, are free) as using an "open-source toolchain" is NOT for beginners.
Once you understand FPGA's a bit more thoroughly, then you can take the leap to the open source stuff.
analognoise
100%, all the recommendations to "start" with the FOSS toolchain are totally bogus.
"You want to learn FPGAs! Let's simulate with Verilator. No, it can't simulate delays, or your vendor's IP library. No, it's not mixed language - hope all your IP is Verilog! And you'll need to know C or C++ to write your test bench, but that's ok right? The examples online involve templates (ZipCPU), so you're OK with Makefiles, and templated C++, obviously. Now, you have the FOSS P&R tools! They use a primitive simulated annealing placement algorithm that's like what we did in the 90's. Yeah, that's terrible, but don't worry, it works fine because the only parts you can target are really, really tiny Lattice parts! No, you can't even use all the hard blocks on the 7 series Xilinx parts - you can fit ONE whole RISC-V superscalar OoO core on the $3500 VC707 (https://github.com/csail-csg/riscy-OOO), running at ~120MHz - but I'll bet you'll do some primitive microcontroller RISC-V instead, something that fits on these really, really, REALLY tiny parts. Then you'll obviously want to augment that with Migen - don't you also know Python? Or Chisel! How great is Scala right? Yeah, it couldn't simulate a simple tri-state until version 2, but you're OK with the concept of domain specific languages already, right? You love the first-class functions and code as data concept! I know, I know. No, nobody in industry cares about any of this stuff, they're too busy using actual FPGA knowledge to like build real systems and circuits. Yeah, a microcontroller-level RISC-V style processor is a handful of undergraduate labs, but RISC-V IS OPEN! Anyway, back to FPGAs...hey where are you going?!"
snvzz
>Use the manufacturer tools (which, in this instance, are free) as using an "open-source toolchain" is NOT for beginners.
As someone who learned the ropes with the open toolchain, I have to strongly disagree.
It's perfectly feasible, and from what I've seen (videos and such), the closed toolchains are way messier and do not provide much in terms of tools unless you pay for time-limited licenses. No thanks.
bsder
I disagree, but please don't downvote stuff like this--respond with a thought out comment, thanks. I upvoted you.
Perhaps Xilinx-land is different, but I have seen an intern go from blank Windows machine to "blink an LED" on an Altera board in about an hour or so with no Verlog/VHDL.
I have never seen this with the open-source toolchains.
Your experience differs. YMMV. Disclaimers. etc.
snvzz
For the record, just months ago I installed the open tools and did get to the led blinking in less than 10 minutes, with no prior Verilog experience.
I could count the time to "install open tools", too, but it would be even less favorable to the proprietary toolchain. It was, after all, a single command (on Arch Linux) that finished in a few seconds at worst.
There's a lot of tutorials these days based on iCE40 and open toolchain.
Then I went on to read yosys's documentation, and learned a great deal about how the flow from verilog to hardware works in a very short amount of time, by just doing so.
rvense
It really depends on your prior experience. If you're a programmer that's used to working with a command line-based Unix environment, the open tools will feel a lot more familiar than the proprietary ones.
I think it took me about that long using the open tools. There is a 2 hour self-hosted beginner workshop for the icebreaker that gets you a little further than blinking.
I'm just going to chime in as well. OSS tools were a breeze to set up. And the compile loop is so very quick comparatively.
ruslan
I'm currently learning programming FPGAs using open source toolchain, my idea is to completely go away from MCUs towards cheap FPGAs and RISC-V. This is actually my third attempt to mess with FPGAs. Several years ago I tried Xilinx, before that I tried Altera. But their proprietary bloatware made me sick. Maybe I'm too much used to command line hence cannot comprehend their world-wide recognizable goodies. On the opposite I pretty much like Yosys, Verilator and SpinalHDL (I didn't like nMigen because of python). In my opinion, nMigen, SpinalHDL and other higher level HDLs are much more freindly to beginners than Verilog to which you are bound if you decide to go conventional way.
funkasterOP
if you're more comfortable with the CLI, you should take a look at the apio project (https://github.com/FPGAwars/apio). It neatly bundles all the required tools. Regarding HDLs, I'm still learning so can't offer any good advice on that.
the__alchemist
I appreciate the direct answer - it sounds like it might still be worth learning from an academic perspective. Most of my project ideas are readily done with a Cortex-M and programmed in Rust, but I'm curious about Verilog/VHDL, even if just to expand horizons.
colejohnson66
As their name implies, FPGAs are field programmable[a] gate arrays[b].
[a]: They can be reconfigured (like flash program code in your PIC) instead of being write-once (like ye old PALs and GALs)
[b]: Essentially a configurable array of transistors (technically the transistor interconnects)
On a big scale, an STM (or whatever SoC you choose) is designed for running code. You tell it what to do. FPGAs, OTOH, are for when you want to tell the individual transistors how to connect to each other. When you just need to make an IOT widget, use a SoC. If you need to prototype an ASIC, use an FPGA. FPGAs allow more real time parallel applications by their nature of not being processors.
Then there’s the whole issue of FPGA vendors being terrible about interoperability. Want to use a Lattice part? You need Lattice’s toolchain. Want to use a Cyclone part? You need Intel’s “Quartus” toolchain. And those toolchains are multi-gigabyte monsters. Contrast that with a PIC where you can use pretty much any retargetable compiler and any USB-COM tool.
Jtsummers
-duino typically means that it's physically drop in compatible with Arduino devices, so you can (physically) connect it to anything you'd connect to an Arduino without needing to make any (physical) modifications.
Of course, you still have to make the FGPA do something. An advantage of an FPGA over an STM32 would be if you're willing to invest some time in hardware description languages (HDLs) like VHDL or Verilog to design your own system, or want to drop in novel cores (like RISC-V) that aren't physically available yet or are still in a state of flux. RISC-V isn't fully specified yet so a "soft" core version on an FPGA offers you the ability to upgrade your device without needing to actually purchase a new one, and remove and replace the old one.
In theory, an Arduino compatible FPGA-based device could be used to develop applications totally sans software (that is, all the logic is encoded in the HDL) as well, which can be advantageous in prototyping, and maybe in performance depending on the FPGA in question.
mhh__
> More timers? More op amps?
FPGA's can't do that (or at least one's mere mortals can buy), but Cypress have a line of parts called PSoC (programmable system on chip) which can effectively synthesize analogue cells like op-amps in an analogous way to an FPGA. They also have a cut-down (surprised?) version of verilog, so you can write a few CPLD-y verilog modules to go on it as well.
The dev boards are very reasonably priced, well worth having one around to play with - can't comment on using them at scale. Cypress have some pretty good video lecture/tutorials on using them by Alan Hawse (Who is very stereotype-engineer https://youtu.be/0IKuUgEWAqg)
topspin
> When would you choose FPGA over something like an STM32?
Essentially for the same reason you choose to use a GPU instead of a CPU. FPGAs deliver application specific circuitry that outperforms a general purpose device. Typically these are high throughput applications; signal processing (SDR), image processing (find the license plates), audio processing etc. While it might be conceivable to do many of these tasks with very fast MCUs, often there are power budgets or other constraints that can't be met.
For example, imagine your application might be handled by either a.) STM32F4 running full tilt at 160 MHz or b.) an iCE5LP4K at 50 MHz. The former could consume just south of 200mW, whereas the latter might be around 10mW. That's a very big difference when you're running on a 100mAh embedded lipo battery or 40mAh coin cell.
MasterScrat
Here's the board I still have from my student years. I'm curious how it compares to modern alternatives? I haven't kept up with that field at all:
Take a look at the de10 nano. Crazy good board for the price. No OSS tool chain though.
mhh__
To flesh this out, the de10 is a cyclone V board, so you actually end up with an ARM core/s to play with as well.
Lattice has a line called PolarFire which combines a fairly big FPGA and a RISC-V core, but they're very expensive, so I doubt I'll have my hands on one for a while.
The ULX3S FPGA board has the Lattice ECP5 FPGA, and an ESP32 that connects to wifi and can reprogram the FPGA.
xnzakg
Really neat. I've been looking for something like this to try out open source FPGA development tools, just wish it came with a usb-c port instead of micro.
noncoml
I had fun playing with the Lattice ICE40 Ultra Plus Breakout board.
I wouldn't call it expensive (~$60) and it's pretty simple.
The toolchain by Lattice however is not the best
colejohnson66
nMigen supports the Lattice ICE40. However, instead of writing you Verilog/VHDL, you write Python that generates the Verilog.
mtve
nMigen still requires toolchains, perhaps you mean that iCE40 is just supported by Yosys+nextpnr?
colejohnson66
I’m assuming one would use nMigen with Yosys instead of Lattice’s bloated toolchain. That wasn’t clear.
snvzz
iCE40 and/or ecp5, with yosys+nextpnr, is absolutely the way to go.
inamberclad
Just bought one of these a few days ago, I've been meaning to put a RISC-V core on it.
mrlonglong
Could this board be useful for playing with RISCV?
mhh__
Should have enough LUTs to play with, although not much to spare if you built a core for work rather than play
funkasterOP
yes. Even one of the examples is a RISC-V core. However, your expectation should be around a RISC core that can be used as a microcontroller rather than a RISC CPU for running linux.
There are many reasons to learn about fpga's. Yes micros have their place as well and are very capable and cheap like the Nxp RT series.
nMigen is highly recommended.
For a minute there I thought you were about to quote a certain Mr Gates...
But I'm now claiming "Mr Gates" to be the name of my first FPGA project
[0]: https://tinyvision.ai/blogs/processing-at-the-edge/ground-tr...
The nucelo ones are even weirder. The pins aren't labeled on the board, and they're in a weird layout, with some male and others female.
Nah, you got it all wrong. You need to pull up the devboard's Pinout, User Guide, and Overview documents. Sometimes cross reference those to the devboard's schematic for the trickier pins. Alongside the specific User Guide and Programming manuals for the MCU on the board. Plus the MCU's guides don't typically cover stuff that's common to all MCUs in a particular Cortex family, so you need to pull up the Cortex documentation. And then, finally, the errata documents.
Typically speaking you'll need to cross reference across all of those documents, all at once, and several places _within_ each document ... all at once.
That's assuming you're using one of the more common pins. If you've decided to dabble with any of the more exotic functionalities you'll want to pull up one or several Application documents, as the former pile of documentation is unlikely to accurately describe the necessary "voodoo" to get things working.
(I kinda wish this comment was a joke ... but it's not. The STM line of chips are truly wonderful machines but ... golly are they a pain to develop on. There's a reason most people just use Arduino to plaster over this stuff.)
EDIT: Oh and make sure you don't confuse the labeling of the pins on the board, with the label of the pins on the pinout, with the label of the pins on the schematic, with the label of the pins in the registers, with the label of the pins in the various HAL libraries...
EDIT2: Geez, how could I forgot the most crucial thing: you of course have to modulate all of these by which specific package of the chip you're actually working with. No sense spending half an hour of your life wadding through all of this documentation only to get to the dev board pinout to find that pin is only available on the largest package and the dev board only came with the 2nd to largest package... (and also doesn't include that one peripheral you were planning to use because ... reasons).
For example, the RTC periph is the same on most STM32 devices. Clocks vary significantly between families, as expected, but at their core, are just different combos of multipliers and internal oscillators, which you can break out by comparing clock trees. Things like I2C vary wildly between families, and sometimes within families.
There's actually two major versions of the RTC peripheral. :) The v1 RTC counts in seconds, v2 has explicit date/time fields.
A lot of other STM32 peripherals can be seen as "versioned" in similar ways. There's a lot of different combinations of those peripherals on different parts, but there's usually only two or three major revisions present of each peripheral across the entire product line, and they tend to follow a pretty consistent timeline. (That is, a newer part will usually use the newest version of each peripheral at the time it was designed, rather than using a mixture of old and new peripherals.)
Then there's also device & device family xml files that link to the various peripherals they have [2].
There's probably no guarantees but in my experience if two devices link to the same version xml file their peripheral registers at least will be identical. Quirks and silicon bugs, you are on your own of course... but then the ref manual doesn't help with that either!
[1] https://github.com/esden/stm32cube-database/tree/master/db/m...
[2] https://github.com/esden/stm32cube-database/tree/master/db/m...
Signed,
Someone who needs 200+ pins in a current design and doesn't want to make their own board from scratch.
I really hope yosys matures and is adopted in large numbers in industry, to become a de-facto gcc equivalent for FPGA compilation. Decoupling FPGA designs from the half-baked tools that vendors push out would be real progress.
Exciting times!
I once stumbled upon an article where somebody FPGA-ed (with a much bigger board, I don't insist it has to be this small and simple) a RISC-V system to make a "RISC-V PC" and I'm thinking about getting an FPGA to explore that since then.
I played with it on an OrangeCrab [2], and was shocked by how easy it was to get it running and by how well it worked despite the slow clock. The FPGA design includes peripherals for GPIO, PWM, serial interfaces, etc., and the kernel includes drivers to talk to them. On the OrangeCrab, everything I thought to try pretty much just worked as expected.
That being said, this is mostly just a fun exercise in SoC building, and isn't going to give you PC-like performance. VexRiscv is small and fast and super configurable, but you're still looking at "high-end microcontroller" rather than "low-end application processor" levels of performance.
[1] https://github.com/litex-hub/linux-on-litex-vexriscv
[2] https://1bitsquared.com/products/orangecrab
The mother lode of cheap, capable FPGAs seems to be supply chains for makers of TVs.
I bet most don't plan to let customers upgrade that way, instead of buying a new TV. I expect they will sell the same hardware with a different model number and just new firmware. They like changing model numbers frequently anyway to frustrate reviewers and people consulting them.
I generally recommend the iCESugar and the ULX3S, for iCE40 (UP5K) and ECP5 respectively.
I own both boards, and a few more I don't feel like recommending.
https://github.com/B-Lang-org/bsc
it's Haskell underneath (https://xkcd.com/356/)
https://www.latticesemi.com/en/Products/FPGAandCPLD/iCE40Ult...
I am not versed enough in FPGA to know if this is just a marketing rebranding of common features (apparently a focus on LUTs and add-and-multiply operations) or if it is an actual edge.
Though, if that thing can do pattern recognition in images and draws 10 mA max, that's an interesting package for $24
When would you choose FPGA over something like an STM32? From what an internet search leads to, they can be faster / do more things in parallel for the price. And you can add capabilities (More timers? More op amps?) with firmware updates. Is this at the core of when you'd choose one?
I've no experience with FPGA, but would like to learn. This is listed as "no longer available for sale". Which dev board do you recommend? Thank you.
The answer is "almost never". Qualifications below.
Learn the Cortex-M4 ecosystem first. You can do a remarkable amount of stuff by abusing microcontroller systems in weird ways. The tools for dealing with microcontrollers are MUCH better than the FPGA ecosystem tools (which suck--and that's on a good day).
If you need an FPGA, generally you know it. The first sign is: "There's no way to do this with my microcontroller." That step is generally followed by: "Is there a different microcontroller that could do this?" followed by asking the old greybeard "Is there really no way to do this on a microcontroller?" And finally, "Crud, this can't be done on a microcontroller"--at that point you can consider an FPGA.
As someone who has been dealing with this for mumble too many years, I've been slowly migrating functionality of my clients away from their FPGAs and into the microcontrollers more and more. It's just way easier on too many fronts--and they don't have to learn Verilog/VHDL. The FPGAs will never go away, but they will have the minimum functionality we can get away with.
> I've no experience with FPGA, but would like to learn.
I'm likely to get some static for this, but get an actual supported dev board and not an open-source hacker board. I would recommend something like this that has an academic version:
https://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=...
Use the manufacturer tools (which, in this instance, are free) as using an "open-source toolchain" is NOT for beginners.
Once you understand FPGA's a bit more thoroughly, then you can take the leap to the open source stuff.
"You want to learn FPGAs! Let's simulate with Verilator. No, it can't simulate delays, or your vendor's IP library. No, it's not mixed language - hope all your IP is Verilog! And you'll need to know C or C++ to write your test bench, but that's ok right? The examples online involve templates (ZipCPU), so you're OK with Makefiles, and templated C++, obviously. Now, you have the FOSS P&R tools! They use a primitive simulated annealing placement algorithm that's like what we did in the 90's. Yeah, that's terrible, but don't worry, it works fine because the only parts you can target are really, really tiny Lattice parts! No, you can't even use all the hard blocks on the 7 series Xilinx parts - you can fit ONE whole RISC-V superscalar OoO core on the $3500 VC707 (https://github.com/csail-csg/riscy-OOO), running at ~120MHz - but I'll bet you'll do some primitive microcontroller RISC-V instead, something that fits on these really, really, REALLY tiny parts. Then you'll obviously want to augment that with Migen - don't you also know Python? Or Chisel! How great is Scala right? Yeah, it couldn't simulate a simple tri-state until version 2, but you're OK with the concept of domain specific languages already, right? You love the first-class functions and code as data concept! I know, I know. No, nobody in industry cares about any of this stuff, they're too busy using actual FPGA knowledge to like build real systems and circuits. Yeah, a microcontroller-level RISC-V style processor is a handful of undergraduate labs, but RISC-V IS OPEN! Anyway, back to FPGAs...hey where are you going?!"
As someone who learned the ropes with the open toolchain, I have to strongly disagree.
It's perfectly feasible, and from what I've seen (videos and such), the closed toolchains are way messier and do not provide much in terms of tools unless you pay for time-limited licenses. No thanks.
Perhaps Xilinx-land is different, but I have seen an intern go from blank Windows machine to "blink an LED" on an Altera board in about an hour or so with no Verlog/VHDL.
I have never seen this with the open-source toolchains.
Your experience differs. YMMV. Disclaimers. etc.
I could count the time to "install open tools", too, but it would be even less favorable to the proprietary toolchain. It was, after all, a single command (on Arch Linux) that finished in a few seconds at worst.
There's a lot of tutorials these days based on iCE40 and open toolchain.
Then I went on to read yosys's documentation, and learned a great deal about how the flow from verilog to hardware works in a very short amount of time, by just doing so.
Installation instructions (basically just extract the folder somewhere): https://github.com/im-tomu/fomu-toolchain
Workshop: https://github.com/esden/wtfpga
[a]: They can be reconfigured (like flash program code in your PIC) instead of being write-once (like ye old PALs and GALs)
[b]: Essentially a configurable array of transistors (technically the transistor interconnects)
On a big scale, an STM (or whatever SoC you choose) is designed for running code. You tell it what to do. FPGAs, OTOH, are for when you want to tell the individual transistors how to connect to each other. When you just need to make an IOT widget, use a SoC. If you need to prototype an ASIC, use an FPGA. FPGAs allow more real time parallel applications by their nature of not being processors.
Then there’s the whole issue of FPGA vendors being terrible about interoperability. Want to use a Lattice part? You need Lattice’s toolchain. Want to use a Cyclone part? You need Intel’s “Quartus” toolchain. And those toolchains are multi-gigabyte monsters. Contrast that with a PIC where you can use pretty much any retargetable compiler and any USB-COM tool.
Of course, you still have to make the FGPA do something. An advantage of an FPGA over an STM32 would be if you're willing to invest some time in hardware description languages (HDLs) like VHDL or Verilog to design your own system, or want to drop in novel cores (like RISC-V) that aren't physically available yet or are still in a state of flux. RISC-V isn't fully specified yet so a "soft" core version on an FPGA offers you the ability to upgrade your device without needing to actually purchase a new one, and remove and replace the old one.
In theory, an Arduino compatible FPGA-based device could be used to develop applications totally sans software (that is, all the logic is encoded in the HDL) as well, which can be advantageous in prototyping, and maybe in performance depending on the FPGA in question.
FPGA's can't do that (or at least one's mere mortals can buy), but Cypress have a line of parts called PSoC (programmable system on chip) which can effectively synthesize analogue cells like op-amps in an analogous way to an FPGA. They also have a cut-down (surprised?) version of verilog, so you can write a few CPLD-y verilog modules to go on it as well.
The dev boards are very reasonably priced, well worth having one around to play with - can't comment on using them at scale. Cypress have some pretty good video lecture/tutorials on using them by Alan Hawse (Who is very stereotype-engineer https://youtu.be/0IKuUgEWAqg)
Essentially for the same reason you choose to use a GPU instead of a CPU. FPGAs deliver application specific circuitry that outperforms a general purpose device. Typically these are high throughput applications; signal processing (SDR), image processing (find the license plates), audio processing etc. While it might be conceivable to do many of these tasks with very fast MCUs, often there are power budgets or other constraints that can't be met.
For example, imagine your application might be handled by either a.) STM32F4 running full tilt at 160 MHz or b.) an iCE5LP4K at 50 MHz. The former could consume just south of 200mW, whereas the latter might be around 10mW. That's a very big difference when you're running on a 100mAh embedded lipo battery or 40mAh coin cell.
https://core.ac.uk/download/pdf/147963601.pdf
Lattice has a line called PolarFire which combines a fairly big FPGA and a RISC-V core, but they're very expensive, so I doubt I'll have my hands on one for a while.
If I ever luck into the big money, I know for sure I'm going to bankrupt myself buying toys like https://www.xilinx.com/products/silicon-devices/soc/rfsoc.ht...
The ULX3S FPGA board has the Lattice ECP5 FPGA, and an ESP32 that connects to wifi and can reprogram the FPGA.
I wouldn't call it expensive (~$60) and it's pretty simple.
The toolchain by Lattice however is not the best