The original intent for our final project was to recreate the PDP11 on the DE1-SoC. The PDP11 was a series of microcomputers developed in the '70s and '80s by the Digital Electronics Corporation (DEC). We were interested in retro computing and thought that this would be a good opportunity to exercise our knowledge of computer architecture. As mentioned in our proposal, we knew that this project would entail a lot of research to find the proper documentation. After finding the relevant documentation, we anticipated that the implementation of the architecture would be relatively straightforward. This proved to be an incorrect assumption.
After doing some preliminary research, we decided to implement the PDP11/70, since we were able to find sufficient documentation. Specifically, the resources that helped us the most were the KB11-C Processor Manual, and its corresponding engineering drawings. The KB11-C was the processor that the PDP11/70 used. With this project being computer architecture related, we knew that there would be a lot of simulation and verification. In terms of verification, we decided to use CocoTB, a Python-based verification framework, since David had previous exposure to it. We decided to organize our work by creating individual modules that represent different parts of the design (i.e. ALU, Shifter, …), and functionally verifying these modules in CocoTB after they were designed. The two-phased approach meant that one person could work on implementing the SystemVerilog while the other person could focus on writing testbenches in CocoTB.
To familiarize ourselves with the workflow, we decided to start off by implementing the ALU. From the documentation, the PDP11/70 has a 16-bit ALU which is made up of 4 4-bit 74S181 ALU chips. In engineering drawings DAPF and DAPH we can see the connections between the four ALUs. In DAPF we can see the logical and arithmetic functions that are implemented by each ALU. Look-ahead carries are performed with a 74182 chip which produces carry out bits for each of the 4-bit ALUs given propagate and generate inputs.
Figure 1: DAPF schematic showing the two lower byte 74S181 ALU chips boxed in red and the functions they implement (bottom right corner)
Figure 2: Closer look at the functions implemented by the 74S181, as shown on DAPF
Figure 3: DAPH schematic showing the two upper byte 74S181 chips, boxed in red
Given the functional description of the 74S181s, the logic was able to be generated with a case statement based on the select signals. The logic for the 74182 CLA replicated the gate-level implementation from the datasheet because that was the simplest way to correctly implement the logic. It was at this point that we realized we did not know how to implement the propagate and generate bits for the 74S181 functionally. The only place we knew the logic was from the gate-level implementation of the entire 74S181. At this point we needed to revise the 74S181 implementation so that it replicated the gate-level implementation. This made the SystemVerilog harder to understand, but guaranteed functionality.
Figure 4: Gate level implementation of 74S182 chip
The realization that many components of the PDP11 could be like this, requiring painstaking gate-level implementations rather than register-transfer level (RTL), also made us question whether we had enough time to implement the whole CPU, and whether or not it would really teach us anything.
With our straightforward ALU design implemented, we moved onto setting up the verification framework, CocoTB. Initially, we tried to set up CocoTB using the Windows Subsystem for Linux, but were not able to get a working Modelsim simulator up and running with it. We were able to get it running with Modelsim using Miniconda on Windows, as advised on the CocoTB installation page, and also were able to get it running on the ECE Linux s ervers by leveraging the available installation of Anaconda3 and various verilog simulators. After finding two good options for running it, we began testing the ALU design, and kept getting incorrect errors, where one or two bits would be produced incorrectly by the CocoTB model we had written to implement the same functionality as the ALU. By looking at the inputs and outputs, it appeared that the ALU was producing correct results, and after hours of debugging the BinaryValue Class of CocoTB, we decided that it may not be worth using for verification.
To get CocoTB running on ECE Linux, simply load the anaconda3 module (using the command: module load anaconda3) and the Synopsys VCS module (module load synopsys-vcs-R-2020.12) then follow the guides on CocoTB's documentation and that should create a functional verification environment.