> Sadly the article doesn't go into details about how the programmable RAM is wired to the actual logic gates, which seems to me the most interesting and challenging part of designing an FPGA.

It does, that's the part under the 'Look-Up Tables' section. The key is there aren't any actual logic gates just lots of little RAMs. You implement an arbitrary blob of logic by having the inputs form the address then the RAM gives the result of the logical function.

Well, they do have some logic gates - usually the cells have at least one flip flop, as well as the LUT.

Although flip flops can be created from gates (and they are usually taught this way), in silicon they are usually implemented from raw transistors in feedback configurations, because implementing a flip flop from gates requires more transistors than it does when you bypass the gate-level abstraction.

> You implement an arbitrary blob of logic by having the inputs form the address > then the RAM gives the result of the logical function.

This is incorrect. Modern FPGAs are composed of small, configurable blocks which contain all sorts of logic. The idea is that the configurable blocks can be (internally) wired-up to implement your logic of choice. The wiring configuration is "loaded" at power-on and retained in memories within each, configurable block.

Well indeed modern FPGA fabric along with the various fixed function blocks can be very complex, but this is a beginners 'How Does an FPGA Work?' for which a bunch of LUTs connected by programmable interconnect is a useful approximation.

You may be right; I don't know. It may be the case that a modern LUT is implemented as a bunch of logic plus a switch matrix. If so, this is for real estate, power, or speed reasons but not for functional reasons.

The fact remains that you can implement any logic function with static RAM LUTs, and the early Xilinx chips (like from 30 years ago) were implemented with static RAM.

The LUTs are still the core of these general-purpose blocks, however (as opposed to the more fixed-function blocks like DSP blocks). There's only a little extra logic, mostly focused on muxing and flip-flops (I would argue the flip-flops are the main thing to realise is dedicated hardware). The only thing that's really a different kind of logic is dedicated carry-chain circuitry.

> I would argue the flip-flops are the main thing to realise is dedicated hardware

Fun fact: The Microchip [1] ProASIC3 logic area is mostly composed of core cells, each of which can be configured to be either one 3-input LUT or one D-flip-flop, so not even the flip-flops are dedicated hardware.

[1] Formerly Microsemi [2].

[2] Formerly Actel.

Both Intel and Xilinx sell FPGAs with hard ARM cores inside so you can run real Linux while being able to interface with custom logic. Additionally, it's pretty common to create ARM, RISC-V, or PowerPC soft cores in the FPGA when there is no hard cores available. These mimic the real cores and will run software while allowing for things like custom instructions that can take advantage of the flexibility of FPGA fabric. The Xilinx Zynq and Intel Cyclone V have options for hard ARM cores. There are various designs of boards out there you can buy that implement Arduino or Raspberry Pi shield compatibility. The XUP PYNQ-Z2 supports both interfaces and runs a Zynq-7000 with a real ARM core.

You can do other things with soft cores that are not possible with an off the shelf CPU like triple mode redundancy. This is when you run a lot of the logic in triplicate and vote on the results to prevent a bit flip from messing up the software. This is common for space-based CPUs that are running on FPGAs. It's expensive to design a new chip in a very small run so it's much cheaper to just put the core on an off the shelf FPGA and use the rest of the FPGA fabric for custom logic functions.

Xilinx teaching/student boards:

https://www.xilinx.com/support/university/xup-boards.html

Excellent point.

PYNQ transformed my experience on these boards.

I had a ZCU-104 on my desk for a year circa 2021. It took a while to wrap my head around given I have no background in embedded engineering, FPGA, or hardware eng. But that board was transformative to what I've seen over twenty years working around mobile, edge, and IoT products, particularly given the availability of the PYNQ stack and the fact that someone like me could take the same old Linux/GCC skills and port, run, and profile code there from x86 while getting wormhole effects from a few compiler switches that opened pathways to things none of us had ever seen before, at least not optimized the way they are there.

> Sadly the article doesn't go into details about how the programmable RAM is wired to the actual logic gates

Not sure what you mean by that. Do you mean how a RAM is used as a lookup table to implement logic gates, how routing works, or how block RAM is integrated into the FPGA fabric?

> is there a SoC board, ARM or RISC-V based, with an FPGA on board?

Better yet, there are a number of FPGAs available with an ARM SoC on board. Xilinx Zynq, Intel Cyclone V SoC, various others.

There are plenty of boards that have one of the combined ARM & FPGA chips, Zynq (Xylinx/AMD) or Cyclone (Altera/Intel).

As for question 1, they're far more common in server grade stuff where typically they are baked in. Consumer stuff just doesn't need/use as much IO throughput and muxing that the FPGA provides on say, a large networking switch.

There are PCIe compatible FPGAs that you can plug into your desktop like a graphics card to accelerate certain tasks. In general though, our workstation hardware just isn't specialized enough to require them, but can be extended to do so. If something is a large enough business model, they'll just make an ASIC.

> 1. why don't we have more user-programmable FPGAs in our fancy desktop mainboards

It has been tried, but GPUs are so fast and efficient enough that it’s rarely worth it.

It’s very easy to attach an FPGA to the PCIe bus as an add-in card exactly like your GPU. In fact, many FPGA dev boards come in exactly this format. They’re available, they’re just not in demand.

> 2. is there a SoC board, ARM or RISC-V based, with an FPGA on board? The slower the CPU, the more useful an FPGA would be to accelerate compute tasks

Plenty of FPGA parts include ARM cores. It’s a fairly standard chip configuration.

You can also connect an FPGA and an SoC with PCIe or other interconnects. It’s really not an obstacle.

FPGAs just aren’t very efficient from a cost or dev time perspective for most applications. They’re indispensable when you need them, though.

After Intel acquired Altera they released a series of x86 Xeon chips with integrated FPGAs. Look up the Xeon 6138P.

> RAM is usually addressable, so it has to be wired in a more direct manner to enable such a design

DRAM is necessarily a grid.

SRAM, in e.g. the standard 6-transistor cell form, you can kind of dump individual bits anywhere you need one.

> why don't we have more user-programmable FPGAs in our fancy desktop mainboards

They tend to be horrifyingly expensive and there are few use cases you can't outperform with a GPU or even just vector instructions. Most of the interesting use cases for FPGAs are when you have direct access to the pins and can wire them up to high-speed signalling, which really isn't home user friendly.

Also all the tooling is proprietary.

> is there a SoC board, ARM or RISC-V based, with an FPGA on board

Buy a medium sized FPGA and download a CPU of your choice.

(I have a downloadable-CPU-sized FPGA board on my desk for testing not yet shipped ASIC designs. It costs about six thousand dollars and has a 48-week lead time on Farnell)

> Buy a medium sized FPGA and download a CPU of your choice.

Damn, of course one would be able to download a CPU and "emulate it" in hardware.

I never imagined that would be possible. Now I'm thinking that I had infinite free time, I would buy an FPGA and design a modern Lisp CPU. A RISC-V based design with native Lisp support. Who needs hardware when you can just emulate it in an FPGA.

That's seriously cool technology.

>and "emulate it" in hardware.

>Who needs hardware when you can just emulate it in an FPGA.

I would go with something like "configure it into hardware" or "upload it into hardware".

It is important to be aware and spread awareness of FPGAs as configurable hardware. Once configured, it is the hardware you've configured into it, for all means and purposes. No emulation involved.

>Now I'm thinking that I had infinite free time, I would buy an FPGA and design a modern Lisp CPU. A RISC-V based design with native Lisp support.

There's even VRoom![0], a very high performance open microarchitecture effort. They were already at ~10.3 DMips/MHz a few weeks ago.

0. https://moonbaseotago.github.io/index.html

> Also all the tooling is proprietary.

yosys/nextpnr/apio/icestorm isn't

> Buy a medium sized FPGA and download a CPU of your choice.

even a small fpga like the ice40-hx8k can fit picorv32 or serv, and it costs 13 dollars on digi-key https://www.digikey.com/en/products/detail/lattice-semicondu...

but it sort of seems like a waste of perfectly good luts if your objective isn't to develop a cpu but to use the cpu to script whatever heavy-duty data crunching the fpga is doing

People have mentioned that the RAM is the logic (or at least most of it), but you are correct that it's only half the challenge: the routing of signals between logic blocks is also a huge part making an FPGA: there's a bunch of painful tradeoffs between flexibility, cost, and performance (and predictability of signal propagation). It's probably the area with the most secrecy from the vendors, as well. But broadly speaking there's usually a hierarchy of potential connections, from many local connections which can connect adjacent logic blocks together to a smaller number of connections which can jump longer distances (though you can always push a signal by hopping between logic blocks, this takes more resources and is slower), and a few connections which cover the whole of the chip, usually used for clock signals (and there's some extra stuff to care about here, since you usually want the clock signal to arrive to every flip-flop at the same time, you need to design the shape of these connections carefully)

For RISC-V, there's the PolarFire Icicle from Microchip. Fully supported in mainline Linux.

https://www.crowdsupply.com/microchip/polarfire-soc-icicle-k...

Not cheap at $599.