FPGA evangelists like this really need a reality check. Programming in RTL is not easy, and it's not really a skill that most people need, so it doesn't make a lot of sense as an educational tool.

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.

The SoC builder you describe might be the MiSTer project for console hardware emulation. But even then, the number of people who develop verilog for that project is rather tiny.

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.

Meh. HDL isn't that hard and there are good books on it. The main reason FPGA programming is unpopular is because the tools are pretty hideous. Icestorm makes things a lot better but it supports like 5 parts and they're not very powerful ones.

How cheap are the devkits, can I easily source <10 unit quantities for <$ouch, and what are the limitations?

- Fundamental questions I imagine a semi-interested tinkerer would be asking

devkits compatible with icestorm? I have an icestick that I've messed with, at 1x it costs $20 (at least when I bought it off amazon.)

> Since 2000, mainstream FPGA programming has been right around the corner.

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.

> 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

Accessibility of FPGAs has made massive strides since 2000. You can nowadays get people build a really basic FPGA demo in an hour, starting with a dev board and their unprepared laptop, and even I remember times where you'd struggle to get the tooling installed in that time.

(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)

Personally I think "programming" RTL is dead simple. It's so simple, in fact, that it's not even interesting. But I've been doing it forever so my perspective is skewed.

I think you are thinking of different types of tasks. A lot of RTL is brainless, but if you are actually trying to compute with it, it can get tough.

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?

You're not writing a hash table in verilog, you're writing a hardware configuration that can hold and manipulate a hash table. It's a different ball game.

I have to make a lot of assumptions, but a couple hours doesn't seem unreasonable for the core function. Among the many assumptions are the hash function, what is actually being hashed, what processor interface is, desired performance, etc.

Good points! His talk is full of enthusiasm, and I am partial to the overall notion of better integration of data and peripherals.

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.

What constrains PMod to low-frequency applications with sloppy SI? What inherently limits the frequency?

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?

Not trying to be unhelpful, but if the assertion was not immediately evident, then you're missing a huge chunk of basic undergrad EE theory that cannot be dismissed as merely academic. I'd recommend reading the spec (it's only 10 pages) and coming to your own conclusions.

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%.

Yep, I'm undoubtedly missing a huge chunk of basic undergrad EE theory, seeing as I am a CS guy, not EE. That said, I think it's possible (even fun) to explain key concepts to people outside your own field in plain language. I practice on my friends and girlfriend a lot.

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.

You're probing for an easy answer because you think one exists that'll be as easy as handling the commodity 100mil interconnect you've been playing with. But the fact is a minimal satisfactory answer resides in the 2nd level of nature's bowels where the simple conservative models of Ohm's law and the laws of Kirchhoff that you were taught in basic physics start to break down as a useful standalone tool and must be supplemented with more complex models to remain consistent with real world observations. I'm not even talking about Maxwell's equations in the raw either...we're still several orders removed, sandwiched in a domain where lossless transmission line theory and lumped-element modeling still hold. Still not ringing any bells? No worries...most practicing EEs are quite deaf to them after college as well.

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)

Thank you (genuinely) for writing all of this down, but nothing you have written is specific to PMod. I get that complex physical effects cause simple models of the world to break down -- that much is obvious. And of course it's up to you what explanations you are willing to write up for free. But I don't see how any of this supports your claim that PMod is insufficient to high-frequency work when it does not reference any design decisions made by the PMod spec that adversely affect its high-frequency performance.

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.