This project is a simulator of a dual-core processor for the ISA of RISC-V. It was developed as a part of the Computer Organization Course.
- Run the main file using the command:
julia main.jl - To simulate other assembly files, place your ASM file within the folder named "Assembly_Codes" and update the file paths in the main file accordingly.
file_path_1is processed by core 1, andfile_path_2is processed by core 2.- The simulator aims to mimic the functionality of Ripes. Reasons:
- The address starts from 0 and goes till 4095.
- Each memory unit holds a maximum of 1 byte (8 bits).
- Instructions in the files are first encoded into 32-bit binary strings and placed in memory from the first address bit.
- Instructions of core 1 are encoded and placed in memory before those of core 2.
- Execution occurs in parallel; each processor cycle executes one instruction from both cores.
- Helper Functions:
- To display memory, use the function:
Display_Memory(processor, starting_row, ending_row)processor: object of the processor createdstarting_row: Lower addressending_row: Upper address
- Example:
Display_Memory(sim, 513, 530) #displays data segment for Core1
- To display memory, use the function:
- Memory Partition Decisions:
- The data segment for both cores is fixed: 1024 bytes for each core's data segment.
- Data Segment:
- For Core 1, data segment starts from address 2048 to 3071 (starting_row = 513).
- For Core 2, data segment starts from address 3072 to 4095 (starting_row = 769).
- Text Segment (Instructions):
- For Core 1, instructions are stored from address 0 (starting_row = 1).
- For Core 2, instructions are stored after the instructions of Core 1 (starting_row = next row after the last instruction of Core 1).
- Branch Prediction
- 2 bit branch prediction implemented
- Caches
- Single cache shared among the two Cores of the processor.
- Cache size can be varied , depends on the input of the user
- Cache replacement Policy :
- Least Recently Used
- Hashing
- Random
- Hit Time and Miss Rate are also user defined values
- GUI
- The front end of GUI is completed but we have to connect it to the backend. We are expecting it to be completed by phase 4.
This project is a simulator of a dual-core processor for the ISA of RISC-V. It was developed as a part of the Computer Organization Course.
/src: This directory contains all the source code files for the project./docs: Documentation files including user guides, and different a report about implementation of different aspects of the project./Assembly_Codes: Test files for testing used in the project.
/Computer Organization Project
├── /src
├──
parser.jl: This code preprocesses assembly code into an array of strings which could be then processed by the code.
├──Encoding Instructions.jl: This file converts assembly instructions into 32-bit encoded instruction, inline with RISC-V standards.
├──Execute_Operations.jl: This directory contains all the source code files for the project.
├──Helper_Functions.jl: This file contains all the miscellaneous functions used across the entire project.
├──Main.jl: This file contains the driver code of the project.
├──Pipeline_with_DF.jl: This file contains implementation of Pipline with Data-Forwarding.
├──Pipeline_without_DF.jl: This file contains implementation of Pipline without Data-Forwarding.
├──Processor_Core_Init.jl: This file contains 4 classes used across the project. Namely: Cache, Instruction, Core, and Processor.
├── /Assembly_Codes
├──
Bubble_Sort.jl: This file contains assembly code for Bubble-Sort.
├──Selection_Sort.jl: This file contains assembly code for Selection-Sort.
└── README.md # Project README
- Privatization of L1 caches for each core will be implemented.
- A Level 2 Cache or Last Level Cache (LLC) will be implemented.
- SIMD instructions were discussed but due to time constraints couldn't be implemented.
- Decided to add user defined input, for Cache size, Block size, Associativity and Cache Replacement Policy. Pre-existing user inputs are Variable Latency of arithmetic opearations and Data forwarding.
- Successfully created a front-end for our code. Attaching it with the backend remains.
- Based on disucssion with sir on 4 Apr, we decided to not split the cache into data and insturction type. Also, time taken for write back remains unchanged at 1 clock cycle.
- Initially, we decide to further the project without taking user inputs.
- Read operation from Cache takes 10 cycles.
- Read operation from Memory takes 100 cycles.
- Discussion about implementation details of the Cache in the existing Simulator.
- Specific focus on separation of Data and Instruction Cache to optimise for performance.
- To ask sir about Write Back policy of the cache.
- Hazard Detection
- Data Hazard Done
- Structural Hazard
- Mem of Load and Store and IF at same clock hazard detection planned to implement
- IPC Calcukation
- Branch Predictor Accuracy
- Variable Latency
- Planned for Add, Sub and Addi as these were the only arithmetic instructions which we used in the sorting files
- Data Forwarding
- Data dependency check when interupted by branch and jump statements .
- Branch Prediction
- Consideration of always branch not taken .
- even though this would yield lesser branch prediction accuracy this was planned to implement because it was comparatively easier .
- Consideration of always branch not taken .
- Discussion on Stalls
- Read after write and write after read hazards detection
- Stalls due to Branch
- Stalls due to jump statements
- Data Forwarding
- Dependecy check on last and second last instructions
- stalls till memory stage for load and store statements dependency
- 5 stage cycle separation and Makefile - Preet
- For IF , we need to create a new special purpose register
- pipelining
- We need to store a new temporary register
- It is a special purpose register which we need to store in the each of the core itself.
- For each function we need to find the cycles/stages omitted - LavKush
- Stalls
- Predictions - Static or Dynamic Prediction : 1 or 2 bit predictor
- break statements
- jump statements
- Hazards
- write after read
- read after write
- write after write
- For each function we need to find the cycles/stages omitted - LavKush
- Predictions - Static or Dynamic Prediction : 1 or 2 bit predictor
- We need to store a new temporary register
- Data forwading and IPC and Hazards(conceptual) - Akilesh
- Restructured code for improved readability.
- Successfully executed Selection-Sort and Bubble-Sort on our simulator.
- Planned implementation of GUI the following day.
- Planned to test the robustness of the simulator the next day.
- Successfully implemented parsing of .data and storing it in memory.
- Completed encoding and decoding of all instructions.
- Minor bug fixes.
- Implemented Selection-Sort in Assembly Language.
- Implemented .data parsing for .word and .string.
- Added necessary helper functions.
- Implemented transcoding algorithm to store strings.
- Started implementation of encoded instructions into memory.
- Implemented LW using Big-Endian Format and LB.
- Implemented JAL and JALR.
- Added Integer to Binary String functions.
- Resolved the issue raised earlier.
- Implemented parser.jl (Analyzing data_instruction and text_instructions).
- Successfully implemented Bubble-Sort in Assembly Language.
- Added instructions addi and sub.
- Members present: Akilesh, Lavkush Kumar, and Preet Madhav Bobde.
- Decisions:
- The project is decided to be implemented in Julia language.
- Reason: Julia is as fast as compiled C and as easy as Python to write.