I have been knee-deep into hardware and software design and development. Boukou okipe. Very busy. More than two weeks full time. Seven days a week. Era ora – it was time –, I really have missed this. The mental challenges, the required precision and clarity of thinking. And of doing. Your ideas and concepts, as well as their implementations, either work, or they don’t. No hand-waving.
Before you tell me “but this is not real life, which is messy”, yes, I am aware of this. I can handle messy. My current binge-working in this exacting field might just be a reaction to the “contextual messiness” of my last months, and me escaping this. In the same vein, I have been reading a lot, and have listened to podcasts, about all kinds of topics not related to technology, from history to politics to philosophy to consciousness. And I have dusted off my camera. I am sure you nerds out there can understand the feeling of satisfaction if an idea of yours comes to life through your thinking and your work. And probably re-work, again and again, mulling over structures and their interfaces, until they fit. Not just fit somehow, but beautifully. Minimalistic. The result can be like poetry. I am not even a good poet, but I have my moments.
I had to pick up, and collect, all the hardware and software pieces from many months ago. Good Thing™ is, I mostly still understand what I have been doing. To consolidate my basis, I have decided to restructure my repositories. A lot has changed since the beginnings, and I now have a better understanding of what I am doing. I have separated the Git repos of the hardware and the software. Joining repos is pretty straightforward, should I ever want to, splitting not so much.
Technologies
On the hardware side, I work now with two FPGA technologies, from Xilinx and Altera. For each, I have different boards. I have tried to find a suitable directory structure to keep as much as possible common, and “single out” modules for the separate FPGA technologies and boards as little as possible. I know it’s basic engineering, but it can be quite tricky at times, in particular on the hardware side, where I have a less up-to-date know-how and experience. For example, the PLLs for the clocks are pretty much technology-specific. Also, each board has different additional components and connectors. Like with software, the key is to find suitable abstractions, and then hide the specific implementations inside one or more modules. The “silicon compilers” are actually pretty smart to find and use good FPGA-specific solutions, so whenever I can, I just describe the logic, and refrain from using technology-specific components directly in my designs.
New Ground
Moreover, I have started to work with a different architecture for the RISC5 processor. Right now I am busy getting my hardware and software working on this new architecture. Porting an operating system – even if small – and the corresponding hardware over to a new architecture at the same time is quite a daunting prospect. To try to first get the hardware ready, and then to port and adapt the software would not work for me. I need continuous testing, and mental reinforcement. Short cycles. Failing early and fast. So I have developed a stripped-down version of my existing hardware platform and the software, which I now get running on the other architecture. This way, I have a functioning reference to test changes.
Subsequently, I plan to extend both the hardware and software again stepwise, in lockstep on both architectures. This parallel work on two platforms, each with a different architecture and technology, and different boards, is also useful to determine the boundaries between the hardware and software modules.
Included in this process is to weave in any possible improvements, which can also mean simplifications of all sorts. If you are the master of both your hardware and software, a lot can be done. I get carried away sometimes. There are also many lessons learned, which I hope I can use going forward. Step by step.
Anyone who has worked in this field knows how nice it is to put things on a new basis. Improve. Refine. Clean up. And avoid all old mistakes, right? Exactly.
Writing Hardware
For the new architecture I use Altera FPGAs, the current one uses Xilinx. Which also means different toolchains. The fun never ceases. Since the two architectures use incompatible buses, my current modules need some adaptations. To keep things simple to get off the ground, I try to re-use them unchanged, and just write adapters for the other bus. “Write” — still sounds funny. It is writing indeed, but from the text actual hardware is created. Not just that soft programming stuff. I know this is normal these days, also for discrete electronics on boards and the like. But for an oldie like me it’s still astounding. But once you get the hang of it, it’s actually more intuitive than drawing schematics. Which the tools will create for you if you so desire.
The Repositories
As said, I have started new Git repositories, in order to cover the new working directory structure. To start, I have put the new hardware repo publicly on GitHub. I have pushed only the basic commits yet, which allow to build the first two platforms, one for each architecture, for the basic Embedded Project Oberon software:
https://github.com/ygrayne/oberon-rts-hw
I am still struggling with how to organise everything in there, given that I have all the different architectures technologies, and boards, which do share components. I am not exactly a Git expert, alas.
The software repo will follow. Real Soon Now. I am serious. At least well-intentioned.
Now back to work.