perilus, Part Two

TL;DR: I learned more Chisel and implemented a good portion of the multi-cycle processor from Harris. Chisel is becoming more familiar and comfortable to me now.

I started the week by reading the first few chapters of the Chisel book, which I found and starting reading at the end of my previous project period. The author, Martin Schoeberl, has done an excellent job explaining the language in a practical manner. The book’s contents so far have been approachable and useful. I followed this up with a re-read of the beginning of chapter 7 in Harris, which builds up a single-cycle processor, discusses its properties, and then moves on to the multi-cycle design. This is also a good book that makes a lot of sense to me. It’s so nice to have low-impedance learning resources.

I should mention that the Chisel book is slightly out of date with respect to testing. It recommends ChiselTest in section 3.2.2, but the owners of that repo deprecated it in 2024. The Chisel developers now recommend ChiselSim instead, which has a similar API. In general I’ve found the Explanations section of the Chisel site to be interesting and useful as a companion to the book. The Cookbook also looks enticing, but I haven’t explored it yet.

By this point I’d become more confident in my understanding of how the project should look, so I reorganized the code to emit a single Perilus module with the major block diagram elements separated into Scala packages. I’m still not certain that this is optimal, but it’ll work for now, and in any case it promotes modularity. Within each package I wrote a stub IO Bundle with the signals listed in Harris and drove the outputs with zeros and marked them TODO. Then I took each package in turn, implementing the tests and the actual logic required to make it go. I was surprised at how simple this was. Some of the packages are just combinational logic (like the ALU), so they can be represented by just a few lines. Even the sequential items (like the register file) were relatively easy to build using RegInit.

I got on a roll and managed to implement all of the packages except the control unit, along with tests for each. I’m not certain that the code is entirely correct, but I’m hopeful that the passing tests may reduce integration effort when it comes time to start debugging the processor all together. I left the control unit for last because it contains a finite state machine, and I hadn’t read the right sections of Harris or the Chisel book to build it. That’ll probably be my first task next time.

Once the packages in the data path were complete, I instantiated them in the Perilus class and hooked them together. With Harris open to one of the figures showing the full processor diagram, I traced each connection and translated it into a := statement in the code. The compiler helped me along in several cases by pointing out connections that weren’t being driven anywhere. I also created a few registers and wires in the Perilus class to capture the smaller bits of state in the Harris multi-cycle design, such as the program counter register. These items aren’t substantial enough to live in their own packages in my opinion, so they get a few lines in the top-level module and that’s it. Honestly, the hardest part about this step was coming up with decent names for the items. The Perilus class doesn’t have tests yet and doesn’t even emit any interesting Verilog, but that will come later once the control unit is done and I can maybe try to run some code.

The Chisel template repo that perilus is based on has a basic GitHub CI workflow, so I used GPT 5.1 to rewrite it to fit this project a bit better. LLMs seem to be pretty good at CI YAML files, which is fine with me. It got me pretty close and only needed a little tweaking, and it saved me from having to go through lots of documentation and stepping on YAML’s footguns. The CI workflow runs the tests and then the main package itself, with the resulting Verilog as an artifact. It may be overkill for a tiny project like this, but I do like to see the little green checkmark on GitHub, and it cost me practically nothing.

Next time I’ll:

• implement the control unit FSM and its tests
• add top-level tests for the few instructions that the Harris design supports
• modify the design to add support for more instructions

And for longer-term / stretch goals:

• maybe try to build a standalone simulation under Verilator that can read a memory image from a file and run it
• maybe look into synthesis workflows