jordan-cottle / computer-architecture Goto Github PK

The risc-v instruction set has a specific use for registers. To make the cpu behave like a risc-v cpu, we need to make sure the registers match.

The assembly files are linked, now we need to read the "binary" output into the RAM so that the CPU can read instructions from there.

For the instructions in the isa to make sense, the cpu must operate on a byte addressable memory.

Currently the memory acts more like an array of objects and separate ones are needed for int, float, and instruction data.

The memory in the simulation should store bytes that can be addressed individually.

part of #38

The second cpu should use the memory bus to coordinate with cpu 1.

The second cpu runs program 2, while the first cpu runs program 1.

part of #50

Convert .cpp files in a test directory into .report files.

Python script for compiling a test module, executing it, and generating the report file.

A second python script then would go through the root test directory and invoke the first script on each file. A final report can be collected at the end.

Add this process to the github action to enforce no tests are broken with each PR.

The cpu should read all of its instructions from a RAM

Assignment 3 Part 1 provides a CPU0.s file for executing on our simulator.

It contains instructions for the logic of an algorithm but does not set up the memory beforehand.

The CPU and simulation set up should be done prior and be separate from other files so that they can all be run. Switching between tests like I've been doing so far is tedious and it'd be nice to keep adding to the suite that can be run all at once.

The Decoder needs to be able to decode the new binary instruction format.

The cpu in the simulation should have 32 integer registers and 32 floating point registers, both 32 bits wide.

The halt command should trigger the cpu (and simulation) to stop.

The halt should not need to go through the whole pipeline. It can be scheduled for later.

Work for #3 was unable to meaningfully implement branches and stalls without more more of the cpu being completed.

#67 made sweeping changes to the project and caused a ton of compilation errors with some of the tests.

The tests are the only think keeping me sane, so I need to fix them.

Memory bus should be able to take requests from arbitrary cpus and handle balancing the single memory between the two.

Conflicting requests should be handled by rescheduling one of them.

Don't worry about implementing the branch command just yet. Assume it will always branch to continue the loop.

The simulation should be able to report on the CPI of the cpu.

Since most devices right now need to tick on each clock cycle, the simulation is doing that manually.

Use events to trigger a tick on each device instead of calling it manually by the sim.

First part of #1

The cpu should have a separate program counter module that keeps track of which instruction to fetch next.

Use the Pipeline struct as a base for four new pipeline stage structs, each with a small set of events (or a shared, PipelineLoad event)

If a pipeline detects that it needs to stall while it is executing, it should be able to insert stalls for as long as needed.

Rather than push data directly across pipeline stages, create events that get placed into the queue.

The TA wants a document describing why/how the design is modular and scalable.

The programs given to use use some of the macros defined by riscv. These don't mean anything to the actual computer, they are just make writing the assembly easier.

Only the ones used in the provided programs need to be implemented.

Fourth part of #1

Branch commands should be decodable and executable by the cpu.

In order for the instructions to be stored in the RAM they need to have a 32 bit fixed width representation.

Use events for devices to signal a need to process something.

Events shouldn't be used to pass data around, the devices should have a mechanism for doing that directly. Ex: pipelines should stage() instructions into their neighbors directly, not with PipelineInsertEvents

This should dramatically simplify the Event class to only require a time, type and device. The subclasses behavior can all be collapsed and logic placed into the devices.

after the cpu simulation is done, the cpi for each cpu should be calculated independently.

part of #50

The programs given to use use a subset of the pseudoinstructions. For this assignment I only need to implement the ones needed for the given programs.

Render the pseudoinstructions into their actual instructions at link time. The binary loaded by the simulation should have no pseudoinstruction details.

The RAM should be designed to emulate the structure and behavior of a real cpu.

With the due date coming up, I may not have the time to implement all of the instructions in all of the extensions.

Start with just the ones in the provided programs. The unused ones can be implemented last so that things like the memory bus and multiple cores have a better chance of getting done.

Both floating point and integer data should be in RAM

Part of #47

When the wrong branch prediction is made (and detected) the cpu should flush it's pipelines and fetch the proper instruction.

Flush of the pipeline does not clean events that are in flight.

Third part of #1

Second part of #1

Part of #38

part of #47

This cpu needs to have the following instruction sets implemented

RV32I

RV32M

RV32F

cpu cycle should be 10 simulation cycles long

part of #38

The second part of the assignment is to add multiple cpus and a bus to arbitrate memory contention.

There should be a delay of 2 cpu cycles when reading/writing to RAM.

NOPs for waiting on a load
STALL for waiting on a store

FLD
FADD.D
FSD
ADDI
BNE

Different types of instructions should take different amounts of time in the cpu.

RV32I instructions = 1 CPU cycle (10 sim ticks)
RV32M instructions = 2 CPU cycles (20 sim ticks)
RV32F instructions = 5 CPU cycles (50 sim ticks)