FPGAs

[sethp]

We wrote the first thing that came into our heads, and it just so happened to be the best post in the world.

This is not that post, this is just a tribute.

[sethp]

On Toolchains, broadly

What does an FPGA toolchain do? A first-order approximation is that it translates our design intent ("make the part speak SGMII") into a fully programmed FPGA. The next level comes via this survey of open-source FPGA tools:

0. Design & Simulation: Make the thing do what we want (technically, the simulation is optional, but is in practice required; see below)
1. Synthesis: Mapping our design from a high-level model like RTL (where we say e.g. "every cycle, clock in C as A*B") to the sorts of elements that our FPGA actually has (C := LUT{0, 0, 0, 1} addressed by A,B).
2. Place & Route: Knapsack packing our way to success. Given a set of synthesized elements and an even more specific model of our FPGA (e.g. it has 17 LUTs), we have to find homes for our logic in such a way that we can also connect them together (i.e. let's use LUT12 for C's combinatorial parts, and register R27 for clocking in C, and this set of internal traces to connect A & B's registers to LUT12's address lines and this other set of traces to connect LUT12's data output bit to R27).
3. Bitstream: Given a topology for a given FPGA, we've got to convert it into whatever actual bits the FPGA needs to "see" in order to realize that design. For Reasons(tm), vendors don't provide the information required to implement this, so this part of the process is rarely open/reproducible.

And then I'd like to add:

4. "Flashing": Most FPGAs use volatile memory to hold their configuration, so this isn't a once-per-design kind of deal, but something the whole circuit has to handle on every power sequence. As such, I guess it's usually left as an "exercise to the reader": where and how you burn the bits into a memory large enough to handle it and how you sequence the actual programming are out of scope for most tooling. A notable exception here is the Microchip flash-based IGLOO2 and PolarFire FPGA chips, which include on-package (on-die?) non-volatile memory for storing configuration. So programming those is a lot more familiar from programming other devices like the ESP32C3, where we do actually "flash" the bits directly onto the device itself. Nevertheless, on our journey from concept to an actual hardware test, this is a required step.

By comparison to GALs, the work we did to map our logic down to a logic expression in a galasm file is approximately (1), assigning pins to signals is (2)—except this is "placement" only, because routing is trivial on a 22v10 since everything can be connected everywhere—and running the galasm or galette tool itself produces our final "bitstream" for (3). We then used a different tool (minipro) to store the bitstream in the GAL's onboard EEPROM to realize a working part.

Here's a good "map of the territory" from f4pga:

This looks like it ought to be read left-to-right mapping e.g. to get from SystemVerilog on the left to a binary on the right, one can travel via "Yosys+ABC" to an intermediate json file that holds the results of the synthesis, which "nextpnr" can consume to produce a description that's fed into some flavor of an "FPGA assembler" to produce the final bitstream.

Finally, four things we value in toolchains:

1. Iteration speed (measured as total end-to-end "concept through to usable feedback")
2. Openness (freedom-as-in-speech, i.e. the ability to modify the program to meet our needs)
3. Low cost (ideally zero; AKA "free-as-in-beer")
4. Runs on Linux (ideally without needing a whole lot of tinkering around with winetricks etc.)

[sethp]

On Part Selection for a router

Taking a stroll through f4pga's Supported Architectures and prior work we find about three options:

1. (vaguest, at least to me) Xilinx something something? It's a big family and very popular, so there's probably a path to success in here, if we can find it.
2. (medium-vague) Look for an eval board for whichever "Lattice ecp5" chip we think will fit—some of the "sample applications" at least mention GbE for that one, whereas the other Lattice chip and the QuickLogic parts all look more targeted at something more like the weather station project.
3. (where I'm leaning) Pick the BeagleV-Fire as a "starting point" and start figuring out how to add a GbE port via the "high speed expansion header."

A little more about the last option: the good folks at Beagle have already put in a ton of legwork to get a RISC-V SBC-alike based around the PolarFire SoC that'll boot to Linux. All of that is open source (including the PCB, albeit as what looks like "Cadence Allegro" files, which is not the easiest format for us), and there's solid upstream support from microchip, including things like a (C/C++) HAL for writing bare-metal programs.

Especially of interest to me are this block diagram:

(via https://docs.beagleboard.org/latest/boards/beaglev/fire/03-design.html)

In there what I see is that there's already a single GbE port hooked up by way of SGMII to the SoC, with the possibility of a second SGMII path by way of the "High Speed Expansion Header" block. That's corroborated by the introduction to what they're calling "Gateware" that lists (among others) "SYZYGY Gateware" which can support "One SGMII interface" (and, the docs note, "There is a lot of fun that can be had with this interface given its high-speed capabilities.").

They've also got a worked example of modifying the gateware (the FPGA interface-y bits, I think?); the wrinkle here is that it uses "Libero," microchip's FPGA "design suite." There's a free (as-in-beer) license for the software though, and it runs on Linux. Since none of the FPGA or RISC-V core itself is free (as-in-speech), I think this might be a reasonable place for us to draw a line in the sand: if we ship a router based around that system, someone else could still theoretically modify it to their own purposes with their own copy of Libero.