MARIE - Extend the ISA

• Deadline: 17.01.2026, 23:59 18.01.2026, 11:59
• Publish date: 07.01.2026
• Last update: 17.01.2026, 21:35
• History:
  • 07.01.2026, 19:05
    • Assignment published, without the code skeleton and associated tests.
  • 14.01.2026, 17:05
    • Update the skeleton and provide sanity tests for each instruction; Add flags port in the control_unit.v; use it for SkipCond
    • Update the implementation section with testing istructions
  • 17.01.2026, 21:35
    • Typo found in RAM.v for LoadI testcase
    • Increase deadline

The primary objective of this assignment is to build up a stronger perspective around the MARIE architecture and to further develop your proficiency in Verilog. You will:

• Use the MARIE simulator to examine the micro-operations associated with each instruction;
• Correlate the observed instruction behavior with its corresponding Verilog implementation;
• Design and implement several new instructions in Verilog, and use the provided test cases to verify and analyze their correct functionality.

For this assignment, you will continue the implementation of the MARIE CPU instruction set architecture (ISA) by adding support for the following instructions:

• Subt X - Subtract value at address X from the AC.
• JnS X - Store the address of the next instruction into memory at address X, then jump to X + 1.
• LoadI X - Use the contents at address X as the address of the value to load into the AC.
• LoadImmi X - Set the AC to the given 12-bit unsigned immediate value X. (This instruction overwrites the Clear instruction)
• SkipCond X - Skip the next instruction if the condition indicated by X holds (see details in the textbook)

The file to be modified is control_unit.v. Several distinct states must be introduced for each instruction to achieve the required functionality. The micro-operations outlined in the simulator should be used as a guide. Each micro-operation should be associated with its own separate state.

For validation purposes, multiple tests were developed to ensure the correctness of the implementation. Test 0 runs by default and is expected to pass. When implementing a specific instruction, switch to the corresponding define. Each test includes both previously implemented instructions and the instruction under test; therefore, the tasks are independent and have no dependencies on one another.

    `define test_legacy   0                 //legacy test for all the lab implemented instructions
    `define test_subst    1                 //simple test for Subst
    `define test_jns      2                 //simp test for JNS
    `define test_loadI    3                 //simp test for LoadI
    `define test_loadImmi 4                 //simp test for LoadImmi
    `define test_skipCond 5                 //simp test for SkipCond
    
    parameter test_scenario = `test_legacy; //Change the desired test here

After the test completes, the first indication of your implementation’s correctness is in the log message (see the images below). If the test passes, great job ! If the test fails, debug it step by step by analyzing the waveform and comparing it with the assembly program. The .asm instructions are available in the ram.v file; load them into the MARIE simulator and run them for reference.

• Your project must include a README file describing the details of your implementation, including the state machine implemented in the control_unit. Inline comments within the Verilog code are also encouraged.
• The implementation should follow the methodology used during the laboratory sessions.
• There is no restriction on the number of states; you may implement each instruction separately or reuse the common states that have already been implemented.
• Each instruction should be implemented and tested individually, as this approach simplifies debugging. A separate test-case is provided for this case.

• In the project 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 folder, compressed in a zip archive format;
  • a README file, which shall contain at least:
    • your name and group;
    • general presentation of your solution and the FSM diagram (it can be handwritten with a picture attached);
    • description of any complex coding parts that you consider additional explanation is needed and they are too long to be an inline comment;

• +10.0 pts.: correct implementation with the test passing (2.0 pts for each instruction)
• -10.0 pts.: compilation failed;
• -10.0 pts.: using looping instructions with variable steps (i.e. while x > 0);
• -50% pts.: the absence of the README file;
• -2.0 pts.: the files are not correctly uploaded in the moodle section;
• -1.0 pts.: bad coding style (chaotic indentation, irregular spacing, strange naming for variables, etc.);
• -1.0 pts.: incorrect using of continuous assignments ( assign ), procedural blocking ( = ) and non-blocking ( ⇐ ) assignments;
• -0.2 pts.: other generic implementation issues (/issue);
• -0.1 pts.: useless code comments;
• +0.5 pts.: bonus for original implementation.

Even if the test(s) are not passing, each instruction may account for up to 25% of it's associated points if you clearly explain he underlying approach in the README file. The submitted code must compile successfully.

The final score will be scaled in the Grade section according to the weighting defined at the beginning of the course.

• MARIE Simulator - MARIE Sim
• VIVADO Project Files - skel_vivado