pete > courses > CS 202 Spring 24 > Tier 3, Phase 2, Problem 01: ARM32 processor
Tier 3, Phase 2, Problem 01: ARM32 processor
This is a long description. Be sure to read all of it, as there are important details throughout, and especially at the very end.
The purpose of this assignment is for you to bring together your understanding of the various parts of the ARM32 processor as presented in class and make them into a functional whole. While we discussed the large building blocks (eg, register file, ALU) and you have already implemented those building blocks as Tier 2 problems, there are several other aspects of the processor described below that we have not discussed and you will have to discover and implement yourself.
Your processor will implement the following instructions (if applicable, both register and immediate variants):
- AND
- EOR
- SUB
- RSB
- ADD
- ORR
- MVN
- MOV
- B
- CMP
Note that LDR and STR are not on this list; this is because we will take a few shortcuts with memory in this assignment.
The first shortcut is that you will store instructions in a read-only memory: a ROM, available in Logisim’s Memory library. (The default appearance is kind of unwieldy; I suggest you use the "Classic Logisim" appearance instead.) Since instructions are 32 bits, it is acceptable (and indeed required) to set the Data Bit Width of your ROM to 32—this is the second shortcut. To set the contents of the ROM, right-click the component and select "Edit Contents"; you can save and load these contents in a file in the obvious way.
Setting the Data Bit Width to 32 introduces a complication: the zeroth instruction will be at address 0 but the first instruction will be at address 1, which is different from the behavior of a "real" ARM32 processor, in which the zeroth instruction would be stored at addresses 0-3 and the first instruction would be stored at addresses 4-7. When the program counter in your processor has value 0, the zeroth instruction should run; when the program counter has value 4, the first instruction should run; and so on.
The final shortcut is that the ROM may be relatively modest in size: it is sufficient to allow space for 256 instructions.
As a starting point for instructions, here is a file, which can be loaded into the ROM (right-click -> Load Image), that contains the instructions for the multiplication program from lecture 19. You may use it directly, and also a basis for developing your own test instructions to load into the ROM.
You can (and should) reuse your solutions to t2p2p01, t2p2p02, and t2p2p03 in your implementation. You may modify these circuits any way you see fit. Two changes will be necessary, however:
- In the ALU, operation 1101 should produce the value of operand_1, not operand_0 as originally required.
- In the condition-code registers, you should add a "clk" input such that the registers inside only store new values on the rising edge of "clk" if the "ld_cc" input is high. (That is, "ld_cc" behaves like write-enable.)
You may assume that only valid instructions will be put into the ROM. You do not need to handle, eg, invalid opcodes.
Interface & Behavior
The subcircuit named main must have the following inputs and outputs:
| name | width | direction |
|---|---|---|
| clk | 1 bit | in |
| r0 | 32 bits | out |
| r1 | 32 bits | out |
| r2 | 32 bits | out |
| r3 | 32 bits | out |
| r4 | 32 bits | out |
| r5 | 32 bits | out |
| r6 | 32 bits | out |
| r7 | 32 bits | out |
| r8 | 32 bits | out |
| r9 | 32 bits | out |
| r10 | 32 bits | out |
| r11 | 32 bits | out |
| r12 | 32 bits | out |
| r13 | 32 bits | out |
| r14 | 32 bits | out |
| r15 | 32 bits | out |
This subcircuit must contain a ROM component with a Data Bit Width of 32 which can be filled with machine-code instructions.
On the rising edge of clk, the instruction identified by the program counter (r15) must execute. As part of this, the program counter should also update appropriately.
The outputs r0 through r15 should always reflect the values of the respective registers.
Advice
Make a checklist of all the instructions you need to implement. Order them by increasing perceived complexity.
Pick the first instruction. Write down a specific instance of that instruction (ie, arguments to it). Write down the effect this instruction should have. Assemble it to machine code and put it in your processor’s ROM. Connect together the various components to implement the behavior. Test it.
Pick the next instruction. Write down a specific instance of that and its effects, put the machine code in the ROM. Then modify the existing circuit to implement it as well. Test both.
Rinse and repeat. Run all tests every time you add functionality.
Don’t implement stuff because you think it might be useful later. Only implement stuff if it is useful for the instruction you are attempting to implement right then. By the same token, don’t be afraid to disrupt your circuit if you feel it will result in a cleaner or more efficient implementation.
Similarly, don’t be afraid to re-order your checklist if you decide that testing a particular instruction will be easier if another instruction is implemented first.
Test often.
This one requires a lot of wires and it will be extremely difficult to come up with a well-styled solution up-front. I suggest you initially use tunnels to connect things together (see the documentation: Help -> Library Reference -> Wiring Library -> Tunnel) to get it working. Once all required circuit components have been placed and they behave correctly, you can replace tunnels with wires as you see fit. In general, well-routed wires are stylistically superior to tunnels because it’s much quicker to see and reason about where the wires go than to find all the similarly-named tunnels. (Yes, I’m offering this advice even though style isn’t a factor in your grade.)
If you are embarking on a significant restructuring, make a copy of your circuit file before you really dig in so you have something to return to if you decide that development path isn’t promising.
Submission Requirements
You will submit a single Logisim-Evolution circuit file and a single text file containing tests that verify your circuit’s correctness. The name of the circuit file must be arm32_processor.circ and the name of the test file must be test-vector.txt.
The main circuit within arm32_processor.circ must implement exactly the set of inputs and outputs enumerated above, no more and no less. Your test-vector.txt should be a file loadable into a Logisim ROM with a Data Bit Width of 32 that contains ARM32 machine-code instructions for testing your processor. It should test all relevant functionality.
You are limited to components from the following Logisim libraries:
- Wiring
- Gates
- Plexers
- Arithmetic
- Memory
You may add as many subcircuits as you deem appropriate. You may (and indeed should) use the circuits you have already implemented: register file, ALU, condition-code register; be sure to paste these circuits into new and separate subcircuits within the arm32_processor.circ file.
Submission Instructions
Copy the arm32_processor.circ and test-vector.txt files to weathertop and then run:
$ 202 submit t3p2p01 arm32_processor.circ $ 202 submit t3p2p01 test-vector.txt
Submissions will not be accepted after 2pm on Monday, 13 May. This is a hard deadline. There will be no extensions without a Dean’s note.