FPGAs and the renaissance of retro hardware
brainbaking.com
brainbaking.com
It has been a very fun experience, and I've found it to be extremely addicting. It helps that there's a fairly tight-knit community very interested in furthering the development of FPGA hardware preservation, so people are very willing to donate, test, and contribute feedback, which is a great feeling for open source work.
My background is exclusively in software engineering and computer science. I started by reading “Digital Design and Computer Architecture”. There’s new RISC-V edition https://a.co/d/imzGBK5 as well as freely available ARM edition https://dl.acm.org/doi/book/10.5555/2815529. The book starts from Boolean logic and transistor technology and goes all the way to assembly programming with everything in between. Most importantly gives great introduction to HDLs. Next I played with a bunch of hardware projects specifically targeting inexpensive Arty-A7 board to get comfortable with FPGA tooling.
I can attest to the parent saying that this is sufficiently different from software engineering I do at my day job and therefore feels a lot more like hobby. Especially if you also foray into wire-wrap prototyping, PCB design and assembly. Finding and fixing analog "bugs" is so much fun!
The non-open-source-tooling (that is what you need for the dev boards I have played with) is what I've had a real struggle with - Vivado and Quartus are so horrendously complicated, that it seems easy to find a project failing at some late stage because you clicked a button wrong two days ago.
Learning these, and the interplay between board specifics and the way any onboard CPU talks to the FPGA mesh and how you interface between the peripherals just seems like a massive explosion of complexity that you seem to have to know in order to know how to learn it. And every board seems to be a horrendous combination of seemingly opaque "IP" blobs.
I've looked even for paid tutorial series, but everything seems to be assuming you've gotten past this stage, or aimed at the "here is how you build up pure stuff in VHDL/Verilog".
The (open) industry secret is that nobody actually uses the GUIs for anything other than analyzing build products (viewing floorplans, etc.); everything else is done through tcl scripts and Makefiles. This lets you both avoid the disaster that is the GUI portion of the tools and keep the entire project in a regular text representation (which means you can actually edit everything and check it into version control!).
As an extreme example, I've never even managed to get Lattice Radiant's GUI to even run, the damn thing just crashes almost immediately. It doesn't matter though because the backend tools all still work perfectly. We've just written some tcl scripts which handle everything for us and we called it a day.
I've sort of worked out this but it seems to be a weird mix of "you need to know what the UI is doing and why in order to avoid the UI". Getting that initial understanding seems a very high barrier.
(version control also seems to be something they manage to break on a whim over toolchain versions - maybe it's one of these hardware things where people just stick with the same toolchain version over the life of the product).
What sorts of hardware projects?
I don't have much documentation for getting started with HDLs (Verilog, VHDL, etc), but I have tried to document my process as much as possible. I have primarily developed for the Analogue Pocket, so my documentation is themed towards that device, but there's IP (code modules) and wiki entries that would be useful for everyone: https://github.com/agg23/analogue-pocket-utils
I had previously written a cycle accurate NES emulator, so I was familiar with hardware techniques, but not what they look like in circuits. The first core I wrote was a schematic accurate Pong implementation. This was both good and bad because it's very simple and has no CPU (and thus no code), but it also makes it very hard to tell what is going on. I went from there to doing a lot of ports (NES, SNES, PCE, and a few more), and after that I worked on my own cores (Tamagotchi, Game and Watch). Tamagotchi I took a very typical software approach where I wrote massive amounts of unit tests and wrote against those tests. While this is what real hardware developers do, I found it to be a huge waste of time when you're working by yourself on a small project.
I, and a few others, are very willing to help people learn (though I'm still really a noob). If you want to play around in this space, let me know and I'll try to help you with what you need.
I’ve built my first computer with soldering all the parts and then started debugging it with oscilloscope to see signals from chips and analyse them to find the problem. And in doing so I have quickly realised that I am missing something. This something was ‘How chips actually work’. Turned out it was called Digital electronics so I’ve decided to learn this on the way.
My treasure and source of inspiration at school time was this book: Digital Electronics by Roger Tokheim. I was dragging it to school and back every day just like people cary notebooks these days. This was my bible back then. Boys in the school made fun of me for this. The book was amazing and I think it still is.
I remember it all as very exciting time.
Now FPGA seems like a nice opportunity to revisit all of this after many years of programming and developing a new point of view about many paradigms.
May be you can direct me and others like me toward a good community and tips for shortening a learning curve. Possibly many things I am familiar with already and yet with FPGA I didn’t find a good/easy way to start so far. Perhaps you can advice something about ‘how’ and ‘were’ to begin.
I have always been a big advocate of learning while doing, especially in software. Find something, preferably small, that you want to build (your Pong), and work on making it a reality. Maybe it's making Snake entirely in HDL. Maybe it's playing around with LiteX on your preferred development platform so you can build something cool with the RISC-V processor (I don't suggest this though, start with learning a normal HDL). Maybe it's simply looking through one of the existing retrocomputing cores, trying to figure out how stuff ticks.
Until you get to the CPU design level, the general concepts you'll encounter will be fairly simple. I think it's enough to just play around with blinking lights, learning how parallel synchronous logic works, relative to how we think of software working.
My challenge is to play with CPU designs at some point but in the beginning I agree it is easier to start with something like led blink, nand , register and then to other staff.
Is there some FPGA hardware you can advice to use for easy start? One that potentially(once I learn) capable to do let’s say UART or USB ? I do not know really how much of FPGA power required for those. Or it would be too big/expensive ? I can’t orient myself with this yet but I wish something physical to have for real motivation to ignite.
It may sound like shilling, but the Analogue Pocket is actually an excellent development platform because it's everything all in one; you don't need to figure out how to take input, load data, or output to HDMI, because that's all taken care of you automatically. Now you pay for that in having a $200-250 price tag, plus ~$50-70 for your JTAG adapter, but I think it's excellent for starting.
For OSS, I would probably recommend a Lattice FPGA. Gowin FPGAs are really, really cheap (Tang Nano 9k), and _partially_ support an OSS toolchain, but it's missing many core components, and I've actually found bugs in the hardware (confirmed by others), so probably stay away.
The DE-10 Nano is very capable, though fairly sought after at this point. It has a decent amount of IO, and can run the MiSTer retrocomputing project, which has the largest collection of OSS cores out there.
----
However, probably before you even buy any hardware, play with simulations. Choose your HDL (Verilog is US focused, VHDL is EU focused) and choose a simulator. For VHDL, you can use GHDL and GTKWave for an entirely OSS setup. For Verilog, I would recommend downloading the closed source Intel ModelSim, but you can also produce very fast, C++ controlled simulations using Verilator.
In any case, start simulating and looking at waveforms. Debugging multiple sets of nets at once is a very interesting experience and is at the core of what you're doing when working with FPGAs (verification is something like 80-90% of the time), so you can learn a lot without any hardware just working on that. If you use Verilator, you can have psuedo LEDs or even a display to draw on.
That's awesome! I feel this, I've had a software development mental block for a number of years now. I just don't find modern software all that interesting anymore. Lost in mountains of model mapping, layers of terrible abstraction, that never ending package update grind (shudders), bad APIs, closed won't fix works as designed bugs (sigh), truly insane complexity and so many many things that are simply outside of my control.
It's my interest in related, but different areas that has kept me engaged recently: micro electronics, 3d printing, and home automation. They exercise enough of my decades of programming experience to get that fix, but the projects are small and focused on solving very concrete problems instead of moving a decimal point on some spreadsheet somewhere completely disconnected from me. It's great when you make something for a friend and you can see the joy in their eyes as they realize how much this thing you made helps them.
Sounds like FPGAs are doing that for you and that makes me happy!
Now for the vast majority of users, this does not matter at all. As much as I like to think I can tell, it's probably placebo or the slightest feeling like something is not right. But I think it's a worthwhile reason to have a different method of replicating these old and eventually dying machines, and it's much more intellectually interesting as you say.
If a device has the same input and output signal timing as the original hardware, then the implementation - be it custom silicon, FPGA, or software - is largely irrelevant to its functionality.
Regarding parallelism, it doesn't really matter as long as the output signals settle in time to meet the clock boundary.
I agree completely regarding the difficulty of getting input and display timing to work properly in a software emulator, especially running on a PC with a modern OS.
As the ACM Digital has gone open access I can recommend this Jan Gray paper, "Hands-on Computer Architecture – Teaching Processor and Integrated Systems Design with FPGAs"[1] There are different opinions on whether or not understanding computer architecture makes you a better developer or not (I tend to think it does) but its a really amazing time to be able to explore these concepts without the need to be at a company or in an University setting.
I'm happy that these retro hardware projects are working out; I've liked seeing people test out what I've found in Ghidra on real systems.
Do you have any findings to share?
So far I've focused on the Sega Saturn because it is notorious for having a difficult-to-understand assembly language (SH-2). That means there are lots of things to discover, because people haven't really looked yet!
MiSTer doesn't just concern itself with analog signals, it simulates the entire system and outputs the original analog signal or can upscale it for digital output on its own. This description could make somebody think it's just a scaler.
The way it’s phrased in the article linked to makes it sound like it’s “just” a scaler like a Retrotink OSSC. It definitely does fantastic work scaling its own output but it won’t accept an outside analog signal which firmly moves it out of the family of “scaler” to me.
Now there are some exceptions. Nuked MD FPGA[0] is a recent example of an FPGA recreation that is a fairly direct translation of the original logic using silicon die analysis. In this case, the logic is basically identical, but as you guessed the physical layout is different. Generally speaking, you write FPGA "gateware" in a language like Verilog or VHDL. These don't intrinsically have any information about the physical layout of the logic which is handled by the toolchain instead. As wmf says, this is generally not a problem most of the time. For synchronous logic, either the total propagation delay is small enough for a single cycle or it isn't. The toolchain will estimate this delay and report whether you met timing or not for the configured clockspeed.
Not everything you can do in silicon translates well to FPGAs (both clock edges is also generally not well supported for instance), but for the most part these things are easy enough to work around.
You can still do higher level stuff in an FPGA. Maybe you don't actually care how the sprite hardware really works, and you just make your own that mostly works the same. Maybe you don't even care that a PPU is split into 3 chips, you make yours without regard for the physical delineation of the original. There are some cores out there like this - written off of software emulators with minimal original research. It is many times possible to get something that somehow plays games even while being "inaccurate", but yields little benefit over software emulation besides lower latency from controller inputs.
Higher-quality cores always involve original research. It is rare that documentation already exists at the detailed level you need. The best people in the field blackbox the original chips and, based on years of experience and knowledge of sussing out behavior by thinking like the original chips designers, can make a functionally and timing accurate model that can operate in lockstep with the real chip, cycle for cycle the same data on the bus. This is the sweet spot for FPGA implementations, but also requires a lot of skill and expertise.
At the extreme end is stuff like NukeMD and the visual 6502/68k projects. The logic is cloned at the gate level without any guessing. Still, some changes are necessary. For example, chips with internal tristate busses are impossible to do on FPGA fabric. Clocking in both sides of the clock. Using multiple phase clocks. Using dynamic logic. And so on. These implementations are usually much less space-efficient than the paragraph above, but offer the highest accuracy.
(they provide Verilog on this website, but Wirth himself has an HDL of —of course— his own design: https://people.inf.ethz.ch/wirth/Lola/index.html )
NB. Risc5 != RiscV
Practically speaking they're useful for hobbyists who want to push beyond the capabilities of the I/O and crunching capabilities of microcontrollers. In many cases the 32-bit micros around today are good enough, but I think it's satisfying to work with bare logic elements.
How is that world a ripoff?
Hey if I’m going to do something I’m going to do it right.
Whether or not the 2023 entry price of a few hundred US dollars plus shipping (that is, a $225 DE10Nano board + $65 RAM module, with basic analog outs and USB able to be added via ~$20 generic dongles) is a ripoff or not, for a system that uses FPGA tech to simulate/emulate a large range of old computers and consoles to a leading standard, including a long (ever-growing) and impressive feature list of options, and a very stable longterm front-end ...is quite subjective.
I think it's still exceedingly good value. But certainly not the only, or outright cheapest, option.