Teaching computer architecture by designing and simulating processors from their bits and bytes

Teaching computer architecture (Comp-Arch) courses in undergraduate curricula is becoming more of a challenge as most students prefer software-oriented courses. In some computer science/engineering departments, Comp-Arch courses are offered without the lab component due to resource constraints and differing pedagogical priorities. This article demonstrates how students working in teams are motivated to study the Comp-Arch course and how instructors can increase student motivation and knowledge by taking advantage of hands-on practices. The teams are asked to design and implement a 16-bit MIPS-like processor with constraints as a specific instruction set, and limited data and instruction memory. Student projects include following three phases, namely, design, desktop simulator implementation, and verification using hardware description language (HDL). In the design phase, teams develop their Comp-Arch to implement specified instructions. A range of designs resulted, e.g., (a) a processor with extensive user-defined instructions resulting in longer cycle times (b) a processor with a minimal instruction set but with a faster clock cycle time. Next, teams developed a desktop simulator in any programming language to execute instructions on the architecture. Finally, students engage in Verilog Hardware Description Language (HDL) projects to simulate and verify the data-path designed during the initial phase. Student feedback and their current understanding of the project were collected through a questionnaire featuring varying Likert scale questions, some with a ten-point scale, and others with a five-point scale. Results of the survey show that the hands-on approach increases students’ motivation and knowledge in the Comp-Arch course, which is centered around computer system design principles. This approach can also be effectively extended to related courses, such as Microprocessor Design, which delves into the intricacies of creating and implementing microprocessors or central processing units (CPUs) at the hardware level. Furthermore, the present study demonstrates that interactions, specifically through peer reviews and public presentations, between students in each phase increases their knowledge and perspective on designing custom processors.


A.1.2 MuSe Architecture: The ALU Design
The Arithmetic Logic Unit (ALU) serves as the central component of the CPU, responsible for executing all computational tasks.Within the MuSe Architecture, the ALU manages its operations through two input ports, referred to as input A and input B, along with an output port named output C. The ALU is highly versatile and capable of performing a wide array of calculations.The type of calculation to be executed is determined by the 3-bit ALU control lines denoted as F0, F1, and F2.These control lines are governed by the ALUOp control signal, which is introduced in the data path and changes dynamically as each incoming instruction is decoded.
Table 3 presents a comprehensive list of mathematical operations supported by the MuSe Architecture, along with their corresponding control line values.MuSe Architecture's ALU design accommodates eight distinct operations, each represented by specific combinations of these three control lines.

A.1.3 MuSe Architecture: The Data-path and Control Signals
The data-path within a processor serves as the central framework that interconnects essential hardware components, including functional units like the ALU, adders, memory, and registers.
It is also equipped with a set of control signals that facilitate the coordination of different CPU units.For instance, when the load word (lw) instruction is executed, setting the memory read control signal to 1 enables reading data from memory.When designing the data-path for MuSe Architecture, the developers drew inspiration from the original MIPS data-path.
In the conventional MIPS architecture, there are eight distinct control signals (MIPS, 2001

A.2 DoMe Architecture Design
In this section, we delve into an in-depth exploration of the multiplication algorithm, ALU design, data path, and control signals incorporated within the DoMe Architecture.
The instructions utilized in the DoMe architecture are thoughtfully laid out in Table 2, accompanied by their usage in desktop simulators.Notably, it is important to highlight that the suffix "-c" is exclusive to the application in R-type instructions.

A.2.1 DoMe Architecture: The Multiplication Algorithm
In this section, we delve into the multiplication algorithm employed in the DoMe Architecture design phase.Following extensive research, the DoMe Architecture designers initially opted for the Wallace Tree multiplication method (Wallace, 1964).However, during the design phase presentation, their project co-advisor recommended an alternative multiplication approach.The advisor's advice was grounded in the realization that implementing an 8-bit Wallace Tree multiplier would entail significant costs and complexities, potentially posing challenges during the planned physical implementation phase.Consequently, the DoMe Architecture designers pivoted to adopt the multiplication algorithm suggested by the MuSe Architecture in  3, encompasses a more extensive array of operations and includes the ALU control lines (F3), a notable expansion in comparison to MuSe Architecture's ALU Design.

A.2.3 DoMe Architecture: The Data-path & Control Signals
In this section, we delve into the DoMe Architecture's distinctive approach to designing its data-path and control signals.As previously highlighted in Section 3.2.4,the traditional MIPS architecture encompasses eight distinct control signals.However, the MuSe Architecture augmented this count to 11.In contrast, the DoMe Architecture streamlined its control signals to a total of seven, achieved by the elimination of the Register Destination (RegDst) and Memory to Register (MemtoReg) control signals.An additional control signal, known as "jump," was introduced to facilitate the management of jump instructions.To accommodate DoMe architecture, all unit and control signal connections in the MIPS data-path were meticulously revised.Much like in the MuSe Architecture, the control signal values pertinent to DoMe Architecture can be found in Table 5.

B SIMULATOR DETAILS B.1 MuSe Architecture Simulator
The architecture of the MuSe simulator is intricately composed of several well-defined classes, each dedicated to a specific aspect of the simulation.These classes encompass ALU, Controller Unit, Instructions, Instruction Memory, Data Memory, Register File, Program Counter, and Processor.Within the ALU class, the designers have favored the use of elementary operators for computational tasks rather than embarking on the intricate endeavor of implementing complex logic circuits such as full adders and multiplication logic.The Controller Unit class assumes the pivotal responsibility of assigning control signals to individual instructions through a meticulous evaluation of opcodes, is jump flags, and is imm values.The MuSe simulator primarily 2/14 revolves around three distinct instruction types, namely R-type, I-type, and J-type instructions.
To streamline the management of shared attributes across these instruction types, the simulator extends these instructions from an abstract class named Instruction.The Instruction Memory is constructed as an array of instructions, initialized upon program commencement.Meanwhile, the Data Memory module houses a two-dimensional byte array augmented with a stack pointer, effectively governing all essential memory read and write operations.The Register File class boasts a roster of registers, encompassing eight pre-defined registers and proficiently manages

C SURVEY
This section delineates the survey questions and presents the responses provided by 50 students.
Question 1 aims to assess participants' perception of their hardware design knowledge and experience, both before and after the course (Fig. 2).
Question 2 measures the participants' self-reported self-learning ability before and after the course, which is a vital aspect of their educational growth (Fig. 3).

Question 3 gauges the change in participants' interest in working on low-level systems like
Computer Hardware Engineering from before to after the course, helping understand how the course impacts their preferences (Fig. 4).
Question 4 investigates participants' awareness of developing software considering hardware limitations before the course, offering insights into their initial perspectives (Fig. 5).
Question 5 focuses on the impact of visual tools on the participants' learning experience throughout the course, examining how such tools influenced their engagement (Fig. 6).
Question 6 explores the influence of group work on the learning experience, uncovering the effect of collaborative learning on participants' perceptions (Fig. 7).

3/14
Question 7 assesses how hands-on experiences during the course influenced participants, providing insights into the practical aspects of their learning (Fig. 8).
Question 8 evaluates the effect of designing their own architecture on participants' learning experience, highlighting the significance of practical application in the course (Fig. 9).
Question 9 measures the impact of simulators and internet-shared tools on participants' learning experience, indicating the relevance of digital resources (Fig. 10).
Question 10 evaluates the overall satisfaction level of participants with the Computer Architecture course, summarizing their general contentment (Fig. 11).
Question 11 investigates the alignment between participants' expectations and the course's content and delivery, offering insights into how well the course met their initial anticipations (Fig. 12).
Question 12 assesses participants' confidence in their understanding of hardware design after completing the course, indicating the level of self-assuredness in their knowledge (Fig. 13).
Question 13 aims to measure how well participants believe the course prepared them for low-level system work like Computer Hardware Engineering (Fig. 14).
Question 14 captures participants' overall enjoyment of the course, providing a holistic perspective on their satisfaction and engagement with the educational experience (Fig. 15).
Section A.1.1 MuSe Architecture: The Multiplication Algorithm to enhance feasibility and practicality.A.2.2 DoMe Architecture: The ALU Design DoMe Architecture has been meticulously crafted to provide support for a broader spectrum of instructions compared to the MuSe Architecture.Consequently, the repertoire of DoMe Architecture instructions includes division and exclusive or (xor) operations, in addition to the other eight operations.Recognizing the challenge of representing ten different operations with merely three control lines, the DoMe Architecture designers astutely incorporated an additional control line (F3).This design choice resulted in six unused control signals.Further elaboration on ALU operations and their corresponding control line values can be found in the supplementary materials.Furthermore, the ALU operation list for the DoMe Architecture, as delineated in Table both read and write operations in alignment with control signals.The Program Counter class is characterized by its simplicity, storing merely an integer value to represent the program counter value and adeptly governing its manipulation.The Processor class orchestrates the harmonious interaction of the previously mentioned classes, meticulously choreographing their workflow.The program commences with the initialization of instruction memory, and as it unfurls, the processor diligently fetches instructions in a loop.Notably, in the MuSe architecture, the absence of a pipeline implementation means that the simulator only progresses to the next instruction once the current instruction is successfully executed.The program culminates either when all instructions are executed or in the event of an encountered error.B.2 DoMe Architecture Simulator The intricate structure of the DoMe Simulator consists of an array of classes, with certain classes sharing functional similarities with their counterparts in the MuSe Simulator.The essential classes used in the DoMe Simulator include Registers, Instructions, Data Memory, Instruction Memory, Definitions, Instruction Functions, Assembler, and Processor.The Registers class, much like in the MuSe Simulator, serves as the repository for registers, with their initialization taking place here.The Instructions class stores the assembly instructions within an array and enables their retrieval by the Processor class through a systematic loop.Data Memory, much like its MuSe counterpart, plays a pivotal role in memory operations, with memory contents being stored within an array.It's noteworthy that, unlike the MuSe Simulator, the DoMe Simulator foregoes the inclusion of a dedicated ALU class.Instead, it features the Instruction Functions class, which defines a function for each instruction operation and establishes a linkage between function and instruction.This unique approach allows the simulator to directly access these functions and execute the requisite operations.The Assembler class within the DoMe Simulator shares similarities with the Control Unit class in the MuSe simulator, responsible for the assignment of control bits, opcodes, registers, and other essential values.The Definitions class serves as a valuable look-up table, pre-defining the properties of each instruction and is instrumental in aiding the Assembler class in the configuration of instruction attributes.Despite disparities in the implementation of specific components within their data-path, the designers of the DoMe Simulator are acutely aware that this aspect of the project places a distinct focus on augmenting the capacity and workflow of their architecture.

Table 4 .
MuSe Architecture Control Signal Values Format Instruction RegDst ALUSrc RegWrite MemRead MemWrite Branch ALUOP Jump JumpReg ShiftReg Syscall Architecture are thoughtfully compiled in Table4, aiming to facilitate and guide researchers in replicating the MuSe Architecture design.
).However, in the design of MuSe Architecture, 11 control signals are integrated to accommodate various instructions effectively.These additional control signals, in addition to those inherited from traditional MIPS architecture, include the System Call (syscall), Jump Register (JumReg), and Shift Register (Shift Reg) control signals.Control signal values for each instruction in MuSe

Table 1 .
Instruction Format of each Architecture

Table 2 .
Instruction List (*Not a MUST instruction)

Table 3 .
Operation Control Values