MicroFPGA – A coming revolution in small electronics (2019) [video]
youtube.com
youtube.com
Interesting talk but I remain skeptical. Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? From a cursory search it seems: 1. There are very few PMOD suppliers 2. They do extremely low volume. So low, in fact, it appears there is simply ~no demand. Therefore, good luck hiring and scaling a team that is familiar with this stuff on a budget. Especially since the half-life of the software tooling is probably 3-6 months and the majority of toolchains are still vendor-specific. Further, in terms of supply chain security, the plethora of suppliers for lower-end MCUs cannot be matched in lower-cost FPGA offerings, which rely heavily on specific vendors who cannot readily guarantee global availability.
M-LVDS is an onboard high speed signalling standard whereas USB and ethernet are specifically designed for off-board connectivity (and have features like power distribution, dynamic topologies, etc.). They are apples and oranges.
The notion of a baseboard for these things is so simple, why isn't there a FPGA+PMOD+baseboard PCB generation and fabrication webservice offered by Digilent? Because it's not that simple. PCB design is often largely constrained by non-electronic functional aspects such as form factor, thermals, mounting and assembly considerations. Having modules to just plug in is great for a quick test, but the second you actually want a product you have to consider the whole problem and that typically means multiple iterations of traditional PCBs for these reasons.
Conclusion: The case is over-stated and the market has effectively rejected the current offerings.
No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply.
The vendor-specific toolchains and supply chain security issues you point out are huge issues, and ones most people (even security experts) are a bit blind to. You can't verify the state of a programmer FPGA by inspection (at least not using normal techniques), so you can't easily verify the output of your bitstream compiler, which is the output of the complex design toolchain.
The toolchain output and bitstream are probably encrypted (or heavily obfuscated at minimum), and this will make it near impossible to audit the component. I don't see how anyone can defend against a Solarwinds (i.e. Stuxnet style attack) in the long run, as a toolchain compromise could introduce arbitrary modification of the logic, and would be unlikely to be spotted, and very difficult to ever detect once in the field.
With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected.
Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.
I want to write FPGA code like any other high-level programming language (but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally a lot more akin to architecting physical hardware).
I want to use FPGAs because they're powerful (but only when a conceptual design aligns with a traditional microcontroller architecture).
I want to use FPGAs because they're flexible (but I need to nerf proprietary building blocks that endow specific devices with competitive edge, or trade significant performance in other ways to do so).
I want to commodify the development peripheral market (but only if they conform to a certain commercially trademarked and weakly defined spec[2] inherently constrained to low-frequency applications where sloppy SI is presumed to be inconsequential).
I want to standardize high-performance interfaces (so arbitrarily "abandon standards you don't like" and simply write your own, but only if they're not "annoying"...and look like a custom FIFO with specific signal labels).
I'm sure this will be an unpopular opinion, but the positive feedback loop generated around this topic needs a stability check.
[1] https://youtu.be/ME_e06ApxJA?t=2080
[2] https://digilentinc.com/Pmods/Digilent-Pmod_%20Interface_Spe...
The "killer app" for hobbyist FPGAs might be some sort of "SoC builder" tool that lets you build a specific microcontroller around a few high-performance cores, and then program it like software.
But don't worry. Since 2000, mainstream FPGA programming has been right around the corner.
However, it's the first platform that has gotten me, a long time software developer, to really look into how it works. As in, I've been working through verilog tutorials, etc. and formulating a project to build on it. Compare to when I first bought a Xilinx FPGA dev board some 20 years ago, I found that I had no idea what to do with it, and there were not many resources to learn from compared to today. I don't think it's going to be mainstream soon, but there's definitely been some progress.
As an avid technologist I dabble in everything from electronics to assembler. But, every time I try dipping my toe into FPGA programming I quickly retreat!
The tools are too complex and the whole process has a learning curve that far out weigh using a stock CPU/SoC.
Sadly this is true, although the open source tools are gaining ground pretty quickly from what I understand. https://symbiflow.github.io/getting-started.html
A mediocre C++ programmer can write a (bad) hash table in C++ in a few hours. How fast can you give me one in Verilog?
- Fundamental questions I imagine a semi-interested tinkerer would be asking
(Not going to go into "mainstream", because that's a) incredibly vague (is microcontroller programming "mainstream"?) and b) IMHO not that interesting - it's fine for specialist things to be accessible but not mainstream)
Still it seems much of what he's wanting could be handled by approaches like the RP2040 chip from the RPi folks that let's you define your own low level pin level protocols using assembly to program state machines. Also many newer MCUs allow you define almost any function on any pin via internal IO muxes. Some MCU's even contain a small FPGA / CPLD.
Also, I prefer the "Mikroe Click" add-on / peripheral board from Mikroe Electronics. It's got a decent ecosystem and it handy for making quick "proto-pcb"'s that integrate sensors but allow you to iterate smaller circuits (even with hand made proto boards https://www.mikroe.com/proto-click). There's a few other non-Mikroe vendors as well.
Given how difficult FPGA's seem to be to program, there's lots of alternatives to achieve the same goals. Things like RISC-V or OpenPOWER and the leveling off of improving semiconductor node sizes will probably lead to a lot more "customizable peripherals" in the next decade, but programmed using the MCU.
I have been dabbling in FPGA programming on a Xilinx Nexys A7. Through some PMod ports, I've managed to drive the shift registers on an LED matrix display at 20MHz. Is this considered high frequency?
My oscilloscope shows that the signal is somewhat messy at this frequency. But the data sheet for the shift register suggests that the thresholds are 0.7xVcc and 0.3xVcc for high and low, so it seems to be good enough. Is this shift register unusually accepting of sloppy SI?
I'm not understanding how a PMod port would constrain the usable frequency. If my clock is going at 100MHz inside the FPGA, what prevents signals of this frequency being sent through PMod wires? Is a PMod port different than the normal I/O pins offered on a board like TinyFPGA?
To your shift register question---which is the only one with enough detail to afford a quick answer---referencing JEDEC JESD8C.01 § 2.3 Table 2 as basis of comparison: yes wrt VILmax, and no wrt VIHmin...at face value, it doesn't comply with industry standard, but is nevertheless permissible by Pmod spec because, well, it's a shit spec by a sample size of 1 engineer's measure.
To your TinyFPGA question, I don't care to ponder the design considerations (or lack thereof) of arbitrary hobbyist dev boards in the wild. In the nicest way possible, it's a complete waste of my time, sorry.
Suffice it to say the spec's interconnect choice is the primary limiter, compounded by permissiveness in some aspects, poor specificity in others, and the general ease of abusing objective interoperability while still complying with normative language.
I leave it to the passerby as an exercise to consider the implications of the following notions in this context:
1. All real conductors exhibit certain parasitic properties which deviate from an ideal model; whose characteristics are largely a function of physical geometries, relevant material properties, and the signals that flow in/around them; and whose significance is almost entirely dependent on the application under consideration.
2. An arbitrary signal that satisfies the 3 Dirichlet conditions can be summarily expressed as the linear sum of its fundamental and harmonic sinusoidal components.
3. As a back-of-the-envelope measure, transmission line effects cannot be so easily neglected when, in a point-to-point system, the ratio of the distance that a signal must traverse to the wavelength of the propagating signal itself exceeds roughly 1%.
To say that PMod's primary limiting factor is its interconnect choice is not very specific. The spec itself says that "speeds greater than 100MHz should be achievable using high-speed ports", so the claim that PMod is "inherently constrained to low-frequency applications" seems at best incomplete. I'm not arguing that every PMod port will support that -- obviously most are not designed for this -- but I am not seeing a fundamental limitation.
If you insist on settling on an answer constrained to classical 1st-order models, then you're in for a treat: everything should just work! The guzzintos perfectly match the guzzoutas, first law of thermodynamics is demonstrably preserved, motherhood and apple pie, happy endings.
Except that's not how the real world works...and it almost certainly won't meet any pragmatic definition of commercially reliable at the limits you're wanting to probe at. But why trust what I have to say? You have an entirely capable Artix-7 dev board at your beck and call. And you have an oscope that'll generate eye diagrams all day to your heart's content. And the Pmod interconnect is so trivial that you could even hack together a throwaway DUT load...or why bother with that when you could use one of your existing Pmods as a real world DUT to characterize?
I thought I left enough breadcrumbs for the incidental reader to self-service on how deep down this infinite rabbit hole will be sufficient to grasp the magnitude of the questions being asked, and I thought my language was appropriately tailored. Maybe not. Here's a few more courtesy hints:
1. The first remark was to steer towards qualitatively thinking about the role of parasitic inductance and how this parameter will dominate the interconnect at higher frequencies as skin effect kicks on. It's worth noting that you'll be quickly sucking hind tit attempting to control impedance through a board-to-board interconnect of this design, which immediately kills reasonable prospects for a huge chunk of the application space that FPGAs are chosen as a viable host for right out of the gate!
2. The second remark was to kindly say that EEs who care about SI couldn't care less about the fundamental frequency of your digital signal when what matters in practice are the significant harmonics that said signal's edges are comprised of. The term significant here is roughly defined as at least 10%ish of the fundamental's magnitude. To get a feel for the landscape, derive the Fourier series expansion of (keeping things simple) an ideal square wave and interpretation of the rest should naturally follow.
3. The third remark was to establish a ballpark basis for independently sizing up when the convenience of simple 1st-order models start to break down and it becomes necessary as a matter of due diligence to kick it up a notch. Determine the permissible distance your signal needs to travel. Determine the wavelength of the highest significant harmonic of the signal to account for (assume in a vacuum to keep it simple, completely ignoring substrate permittivity). If the ratio of distance to wavelength exceeds 1%, consult with a competent electronics engineer if you objectively care about quality.
That's about the best approximate free answer this engineer is willing to extend. Need better precision? I'd recommend deferring to a billable scientist.
(P.S. only about as fun as trying to explain the merits of idempotency to my wife /s)
One of the following must be true:
1. The PMod interconnect is specified in a way that inherently limits high frequency applications, whereas it could have been specified in a different way that would allow for them.
2. Something about the design space PMod is trying to solve (off-board peripheral modules connected to a main board through a standard connector) is inherently hostile to high-frequency applications, and no specification is capable of getting around this limitation.
3. PMod is actually capable of high-frequency applications, although most PMod ports are not particularly designed for this.
Your original message seemed to be claiming (1), but none of your subsequent arguments have offered any support for (1) that I can see. You have absolutely convinced me that complex physical effects must be taken into account, but that information does not help resolve which of 1-3 is true.
To convince me of (1) I would need to see a specific design decision in the PMod spec that makes high-frequency applications impossible, as well as the alternative design choice that would have allowed for them. For example: "PMod does not allow shielded wires, but high-frequency requires shielding" would be a convincing argument if true.
PMODs are good for university/hobby projects with FPGAs, though, and I'm glad the bar is getting lower and lower. FPGAs are usually built on very high-tech processes, so the gap between an FPGA (at 28 nm) configured like an SoC and an actual microcontroller (at 90 nm) may be smaller than we think, and that may be the saving grace of FPGAs as hobbyist devices.
I have anecdotally heard of FPGA/RTL devs leaving the field mostly because of the poor tooling etc.
In addition, lack of a standard library and bad tooling (buggy, slow compilers) makes developing simple things very difficult.
The same attributes that made me a good FPGA developer have also made me a good low-level software developer (x86 assembly doesn't hold a candle to FPGA dev in complexity), so I do that now.
The current state of the open source tool chain is looking pretty reasonable (covering the development life-cycle with yosys/nextpnr/iverilog/verilator/etc) and a few FPGA families having been reverse engineered (the ones I find the most interesting are also the furthest along: the ice40 and ECP5) so you can buy/build open devices and use them with open tooling today. Granted, the devices to choose from are at the low end of the universe of FPGAs out there (i.e. <100k LUTs) but that's enough to do a lot of interesting things with for now and (hopefully) eventually higher-end devices will be added. That's not terribly different than the state of play re: microcontrollers and SoCs these days in the open source world.
The one part of his talk that I think is off base is replacing microcontrollers/SoCs with FPGAs in most scenarios. At any given process node, the specialized device (i.e. a processor) should be able to crush the generalized one (i.e. FPGA) every time in terms of cost, raw performance and perf/watt and it would likely take more than the current ~2-3 process node delta to overcome that. I don't look at an FPGA as being an either/or proposition: use a microcontroller/SoC for what they're good at in conjunction with an FPGA for what it's good at where the application warrants it. Sure, if you need a tiny bit of software control throw a soft core in there and save the hassle of adding a micro. But don't try to replace a hard core with a soft one just because you can.[1]
[1] Two cases where exceptions seem to be obvious and make sense: - New/experimental ISAs like RISC-V where you can't readily/affordably source CPUs in the open source world yet. - Emulators mainly because the ISA you need is typically at least effectively dead. Any devices still available aren't often good fits for what you're trying to accomplish.
iCE40 are a relatively simple, cheap and easy to work with architecture with a focus on low power usage. iCESugar + nanoDLA (cheap sigrok-friendly logic analyzer) is a good cheap set to get started on FPGAs with. These are cheap on aliexpress.
ECP5 are much larger, much more complex and powerful enough to fit a whole computer (e.g. the minimig open Amiga implementation) in. I don't recommend going anywhere near this until you've already got started with iCE40, but a high-density and price-effective development board is the ULX3S.
More coarse-grained architectures like GPUs or reduced-scope architectures with a less intense cognitive load like the programmable IOs found in Raspberry Pi Picos or some Texas Instruments MCUs seem like a much more feasible solution for the vast majority of potential FPGA use-cases a tinkerer would run into.
Is that about right?
If even close, (3) is very interesting to me for a variety of reasons. Is my understanding correct that this is a reasonable use of FPGAs and that maybe now is a reasonable time to get into it?
The only real benefit of an FPGA for algorithms is when you're algorithm benefits from parallelization.
There is nothing intrinsically faster in programmable logic.
The point is that execution is truly concurrent, as long as you have space in the FPGA fabric, you can _almost_ do everything at the same time.
I say this as someone who has done a fair share of FPGA projects, it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU.
Regardless of whatever you read, FPGA's do have a purpose but will most likely continue to only be used in niche/custom applications.
It probably depends what you're comparing to.
Yeah, since FPGAs essentially implement combinatorial logic, and hard CPUs are also implemented in combinatorial logic, you gain no benefit from directly "porting" the hard CPU to the FPGA.
But, if your hard CPU is a microcontroller that can only process say 8 bits at a time, but you really want to process say 256 bits at a time, it might be more efficient to use an FPGA to build a soft CPU whose architecture better matches your problem. In that case, you should be able to do more work per clock cycle with the FPGA.
That's arguably "increased parallelization", but what I'm talking about applies to sequential algorithms.
Of course, in that case, maybe you chose the wrong microcontroller. Maybe a full CPU would be a better choice, or maybe there's a DSP that can be adapted to the specific use case.
it is very difficult to make the business case for an FPGA, if your problem can be solved with GPU programming on a COTS GPU
Sure, that makes a lot of sense at the high end. I'm thinking of problems more in the embedded space, where FPGAs might be a bit more attractive.
1. (general) application reconfigurability where the benefits of SRAM performance, integrated hard IP, fabric real estate, and/or cycle-accurate RTL control cannot be easily replaced by other roughly asymptotic solutions;
2. (general) offloading massively/embarassingly parallel compute architectures where commodity GPGPUs are either physically incompatible and/or power-wise too inefficient;
3. (enterprise) overall volume/performance/budget/schedule objectives fall short of the sort needed to justify pushing a bespoke ASIC design through process pipeline.
Relatively speaking, "blazing fast implementations of algorithms" is possible iff the compute bottleneck can be effectively parallelized; I'm not certain what was meant by "hard to run otherwise".
To put this into perspective, reliably clocking a non-trivial FPGA application at 200 MHz is objectively hard in a way that hobbyist types outside of the professional domain can't seem to understand (or arrogantly dismiss). And yet for the right class of problems, such an application may have the potential to put a GPGPU clocked in the GHz to shame on both compute throughput and power consumption fronts.
1. https://ieeexplore.ieee.org/abstract/document/5747245 Implementation of pin point landing vision components in an FPGA system for NASA stuff
[1] - https://www.youtube.com/watch?v=gYmDpcV0X7k
[2] - https://github.com/reds-heig/logisim-evolution