This shows you the differences between two versions of the page.
ac-is:teme-ie:course_project [2024/01/07 18:44] ionut.pascal created |
ac-is:teme-ie:course_project [2024/12/29 16:06] (current) ionut.pascal [Recourses] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== MARIE - Extend the ISA ====== | ====== MARIE - Extend the ISA ====== | ||
- | * Soft Deadline: **19.01.2024**, **23:59** | + | * Soft Deadline: **17.01.2025**, **23:59** |
- | * Hard Deadline: **19.01.2024**, **23:59** | + | * Hard Deadline: **17.01.2025**, **23:59** |
- | * Publish date: **07.01.2024** | + | * Publish date: **29.12.2024** |
- | * Last update: **07.01.2024, 20:00** | + | * Last update: **29.12.2024, 16:04** |
* History: | * History: | ||
- | * 07.01.2024, 20:00 | + | * 29.12.2024, 16:04 |
* Publish the assignment - detailed | * Publish the assignment - detailed | ||
===== Objectives ===== | ===== Objectives ===== | ||
- | The main purpose of this assignment is to build up a stronger perspective around the MARIE architecture. You will: | + | The main purpose of this assignment is to build up a stronger perspective around the MARIE architecture and enhance your Verilog knowledge. You will: |
* Use the [[https://marie.js.org | MARIE simulator]] in order to observe the micro-operations specific for each instruction; | * Use the [[https://marie.js.org | MARIE simulator]] in order to observe the micro-operations specific for each instruction; | ||
* Link the behavior with the Verilog implementation; | * Link the behavior with the Verilog implementation; | ||
- | * Implement the new instructions and follow the testcase to determine the correct behavior. | + | * Implement in **Verilog** the new instructions and follow the testcase to determine the correct behavior. |
===== Description and requirements ===== | ===== Description and requirements ===== | ||
+ | For this assignment you shall continue the implementation of our MARIE CPU ISA with the following instructions: | ||
+ | * Input - Request user to input a value (saves the value from the input to the InReg) | ||
+ | * Store X - Stores Contents of AC into Address X (RAM[X] <- AC) | ||
+ | * StoreI X - Stores value in AC at the indirect address (RAM[RAM[X]] <- AC) | ||
+ | * LoadI X - Loads value from indirect address into AC ( AC <- RAM[RAM[X]] ) | ||
+ | * SkipCond C - Skips the next instruction based on C | ||
- | Floating point has a long history in the engineering field and in computer science. The promoter was Leonardo Torres Quevedo back in 1914; nowadays, we use IEEE754 Standard Implementation. [[https://en.wikipedia.org/wiki/Floating-point_arithmetic|Wiki]] | + | <note important>You can find the implementation both in Chapter 4 of the book and in the Databook of the simulator!</note> |
- | The assignment consists in implementing a floating point multiplication algorithm for 2 numbers with the following format (S_EEEE_MMMMMMM): | + | |
- | * 1 sign bit - S | + | |
- | * 4 exponent bits - E | + | |
- | * 7 mantissa bits - M | + | |
- | The implementation can follow the proposed state machine: | + | |
- | {{ :ac-is:teme-ie:untitled_diagram.jpg?nolink |}} | + | |
- | Because we encounter a multiplication of fixed point (mantissa), we should implement a dedicated module responsible for this operation. The Booth algorithm is a suitable option which reduces the complexity but keeps a good understanding behind. The size of the operands is dependent on the size of the mantissa. | + | |
- | Requirements: | ||
- | - Implement Booth algorithm in the dedicated file for 2 8bit operands: | ||
- | - Take 2 random 8bit numbers of your choice and demonstrate the algorithm on the paper; | ||
- | - Implement the Verilog code. | ||
- | - Implement the floating point multiplication algorithm: | ||
- | - Take 2 random 12bit numbers of your choice which respects the floating point format and demonstrate the multiplication on the paper; | ||
- | - Implement the Verilog code. | ||
- | <note important>Don't forget to follow the TODO's inside the code and check for the errors and messages in the console! Checking is implemented inside the testcase!</note> | ||
- | |||
===== Implementation ===== | ===== Implementation ===== | ||
+ | The file to be modified is control_unit.v. Several states shall be added for each instruction in order to implement the desired instructions. You can follow the micro-operations suggested in the recourse files. Each micro-operation shall have one individual state. | ||
- | In order to implement the requirements, you shall build a finite state machine to divide the operations executed per clock cycle. This automata communicates with additional modules with determined behavior. The detailed implementation for each module is described below. | + | <note important>In the simulator you can take the basic example and add your desired instruction. If you assemble and run through micro-step, you can see each instruction executed step-by-step. Your implementation can follow it!</note> |
- | + | ||
- | ==== floating_point_fsm ==== | + | |
- | Finite state machine to be implemented, this module also acts as a top module for the design (the one that have all the additional modules instantiated in it). | + | |
- | + | ||
- | This module respects the following interface: | + | |
- | <code systemverilog> | + | |
- | module floating_point_fsm( | + | |
- | input clk, | + | |
- | input rst, | + | |
- | input en, | + | |
- | input [11:0] a, | + | |
- | input [11:0] b, | + | |
- | output reg done, | + | |
- | output [11:0] out | + | |
- | ); | + | |
- | </code> | + | |
- | The signals' description for this module is: | + | |
- | * ''clk'' - clock signal; | + | |
- | * ''rst'' - reset signal - used to bring the module back to it's initial state; | + | |
- | * ''en'' - when this signal asserts, it marks the valid information for a and b in the next clock cycle; | + | |
- | * ''a'' - value for the first operand, expressed in sign_exponent_mantissa; | + | |
- | * ''b'' - value for the second operand, expressed in sign_exponent_mantissa; | + | |
- | * ''done'' - 1 when the result is ready; | + | |
- | * ''out'' - the result of the multiplication; | + | |
- | <note tip> | + | |
- | Modifying the outputs to ''output reg'' is allowed for this module. | + | |
- | </note> | + | |
- | + | ||
- | The module functionality is: | + | |
- | * Storing the input values ''a'' and ''b'' in their corresponding registers after the ''en'' signal gets asserted. | + | |
- | * Executing the operation and putting it on the output ''out''; when ''out'' is available, ''done'' shall be one, to signalize that the ''out'' is available for the outside modules to be used. | + | |
- | + | ||
- | We already have the input (''A'' and ''B'') and output (''RES'') registers instantiated inside and also an auxiliary register for saving the multiplication result (''MUL'') with their control signals for writing and reading and the proper connections with the environment, except the ones with the ''booth_mul''. | + | |
- | + | ||
- | This module actively used the ''booth_mul'' module to perform any multiplication operations needed. | + | |
- | + | ||
- | ==== booth_mul ==== | + | |
- | Implements the Booth multiplication algorithm applied on 2 8bit numbers. This module uses combinational logic - the result is available as soon as the inputs change. | + | |
- | + | ||
- | This module respects the following interface: | + | |
- | <code systemverilog> | + | |
- | module booth_mul( | + | |
- | input [7:0] op1, | + | |
- | input [7:0] op2, | + | |
- | output [15:0] result | + | |
- | ); | + | |
- | </code> | + | |
- | The signals' description for this module is: | + | |
- | * ''op1'' - holds the operand 1; | + | |
- | * ''op2'' - holds the operand 2; | + | |
- | * ''result'' - holds the result; | + | |
- | <note tip> | + | |
- | Modifying the outputs to ''output reg'' is allowed for this module. | + | |
- | </note> | + | |
- | + | ||
- | The module functionality is: | + | |
- | * Trigger the algorithm and change the ''result'' every time ''a'' or ''b'' changes. | + | |
===== Notes ===== | ===== Notes ===== | ||
- | * For the floating point implementation, the behavior of the register is the one studied in the [[ac-is:lab-ie:lab02#The Register|lab]]. | + | * The implementation shall be similar to the approach we had during the labs, by developing the state machine in the control_unit.v file; |
- | * You can modify the state machine as you like, as long as it respects the requirements. | + | * The number of the states is not limited; you can implement each instruction separately or make use of the common states that are already implemented. |
- | * For VIVADO, the top module for simulation is the booth test; when implementing the floating point multiplication, don't forget to change the test | + | * Implement each instruction and test it **individually**; debug is easier this way. |
===== Additional details ===== | ===== Additional details ===== | ||
- | * In the project resources [[ac-is:teme-ie:proiect#Recourses| recourses]] there are already the files that you need and the prerequisite modules. | + | * In the project [[ac-is:teme-ie:course_project#Recourses| recourses]] there are already the files that you need and the prerequisite modules. |
* The project archive that you shall upload (**zip** compression type) must include in it's root **only**: | * The project archive that you shall upload (**zip** compression type) must include in it's root **only**: | ||
- | * the **floating_point_fsm.v** and the **booth_mul.v** files (you can already find them in the project skeleton); | + | * the **project folder**, compressed in a zip archive format; |
- | * other user-defined files (*.v), if used in your choice of implementation; | + | |
* a README file, which shall contain at least: | * a README file, which shall contain at least: | ||
* your name and group; | * your name and group; | ||
* general presentation of your solution; | * general presentation of your solution; | ||
* description of any complex coding parts that you consider additional explanation is needed and they are too long to be an inline comment; | * description of any complex coding parts that you consider additional explanation is needed and they are too long to be an inline comment; | ||
- | * Pictures/Scans of your paper demonstrations. | + | |
- | * The archive shall __**not**__ contain any other files from the implementation folder (i.e. test files, project specific files, etc). | + | |
<note important>This assignment is an **individual** assignment; using any code from external sources can be considered as plagiarism and can lead to voiding the accumulated points! </note> | <note important>This assignment is an **individual** assignment; using any code from external sources can be considered as plagiarism and can lead to voiding the accumulated points! </note> | ||
- | |||
===== Grading ===== | ===== Grading ===== | ||
- | * +10.0 pts.: Correct implementation with the test passing | + | * +10.0 pts.: Correct implementation with the test passing (2.0 pts for each instruction) |
- | * 1.8 pts.: Each implemented instruction | + | |
- | * 1.0 pts.: Test Passing | + | |
* -10.0 pts.: using looping instructions with variable steps (i.e. while x > 0); | * -10.0 pts.: using looping instructions with variable steps (i.e. while x > 0); | ||
* -1.0 pts.: the absence of the README file; | * -1.0 pts.: the absence of the README file; | ||
Line 137: | Line 65: | ||
===== Recourses ===== | ===== Recourses ===== | ||
- | * **VIVADO Project Files** - {{:ac-is:teme-ie:c_project_vivado.zip| skel_vivado}} | + | * **VIVADO Project Files** - {{:ac-is:teme-ie:MARIEproject_vivado.zip| skel_vivado}} |
- | * **XILINX Project Files** - {{:ac-is:teme-ie:c_project_xilinx.zip| skel_xilinx}} | + | |
* **MARIE Simulator DATABOOK** - [[https://marie.js.org/book.pdf|MARIE Sim Databook]] | * **MARIE Simulator DATABOOK** - [[https://marie.js.org/book.pdf|MARIE Sim Databook]] | ||
* **MARIE Simulator** - [[https://marie.js.org |MARIE Sim ]] | * **MARIE Simulator** - [[https://marie.js.org |MARIE Sim ]] | ||
===== Appendix ===== | ===== Appendix ===== |