CSE 141L –Fall 2023

This document describes the en re course project for CSE 141L.

This is a very large document. Please do not be too in midated, it is a full quarter’s worth of
work! Normally, courses dole our assignments in smaller pieces. One of the goals of 141L,
however, is to help you develop skills to manage a large-scale, longer term project.
Skim it once, digest it, and then take a moment. Then go back and re-read smaller pieces in
more detail. This document is broken down into the major milestones, so focus on each in turn.

Introduc on
Your task this quarter is to design a custom processor that supports speci c Forward Error
Correc on (FEC) tasks. FEC is commonly used in radio communica ons with lossy links where
retransmission is expensive, challenging, or imprac cal (as well as other domains). As an
interes ng and mo va ng example, consider one of the longer-lived computa onal systems
humanity has ever built, the Voyager Probe, which passed out of the heliosphere last year but is
s ll sending us data! As an example closer to home, satellite radio streams allow for 4-5s of
signal loss (e.g. driving under a highway underpass) without any interrup on in the audio
stream. Sirius receivers use a custom chip, historically the STA210/240, which is in many ways
simply an advanced form of what you are designing and implemen ng in this course.1

Conceptual model of what a generic error correc on scheme does

1To be clear, you do not need to know anything about FEC design for this course, Voyager’s implementa on, or
Sirius’s implementa on. Your processor just needs to run the provided programs correctly. However, for those who
are interested in learning more on their own for fun, NASA has an excellent technical document on the Voyager
communica on system: voyager.gsfc.nasa.gov/Library/DeepCommo_Chapter3--141029.pdf. Similarly, here are
some details on how early Sirius worked (a lot is s ll proprietary, unfortunately): spectrum.ieee.org/amp/the-
consumer-electronics-hall-of-fame-siriusxm-satellite-radio-system-2650279127.
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
 2

Table of Contents
Introduc on .........................................................................................................................................................1
ISA Requirements ......................................................................................................................................................3
Some Things to Think About ................................................................................................................................3
Architecture Limita ons and Requirements .............................................................................................................4
Some Things to Think About ................................................................................................................................4
Top-Level Interface....................................................................................................................................................5
What must the processor do? ...................................................................................................................................6
Program 1 (forward error correc on block coder/transmi er) ...........................................................................6
Program 2 (forward error correc on block decoder/receiver) ............................................................................6
Program 3 (pa ern search) ..................................................................................................................................8
What to Submit? .......................................................................................................................................................8

Milestone 1 — The ISA .........................................................................................................................................9

Milestone 1 Objec ves..............................................................................................................................................9
Milestone 1 Components ..........................................................................................................................................9
What to Submit? .....................................................................................................................................................10

Milestone 2 — 9-bit CPU: Register le, ALU, and fetch unit .................................................................................11
Milestone 2 Objec ves............................................................................................................................................11
CPU Design Refreshers and Helpful Tips .................................................................................................................11
How to Present Your Implementa on .....................................................................................................................12
Milestone 2 Components ........................................................................................................................................13
What to Submit? .....................................................................................................................................................13

Milestone 3 — An Assembler & Early Integra on ................................................................................................14

Milestone 3 Objec ves............................................................................................................................................14
Tasks .......................................................................................................................................................................14
Milestone 3 Components ........................................................................................................................................14
What to Submit? .....................................................................................................................................................14

Document Revision History.................................................................................................................................15

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
tt
ti
ti
ti
ti
ti
ti
ti
fi
ti
tt
 3

ISA Requirements
Your instruc on set architecture shall feature xed-length instruc ons (machine code) 9 bits
wide.

Given the ght limit on instruc on bits, you need to consider the target programs and their needs carefully.
The best design will come from an itera ve process of designing an ISA, then coding the programs, redesigning the
ISA, etc.

Your ISA speci ca on should describe:

• What opera ons it supports and what their respec ve opcodes are.
o For ideas, see the MIPS, ARM, RISC-V, and/or SPARC instruc on lists
• How many instruc on formats it supports and what they are
o In detail! How many bits for each eld, where they are found in the instruc on.
o Your instruc on format descrip on should be detailed enough that someone
other than you could write an assembler (a program that creates machine code
from assembly code) for it. (Again, refer to ARM or MIPS.)
• Number of registers, and how many general-purpose or specialized.
• All internal data paths and storage will be 8 bits wide.
• Addressing modes supported
o This applies to both memory instruc ons and branch instruc ons.
o How are addresses constructed or calculated? Lookup tables? Sign extension?
Direct addressing? Indirect? Immediates?
The more me and care you put into your speci ca on, the easier the rest of the project will be. This is the design
element, and it harder than it seems (you have a lot of op ons!).

Some Things to Think About

For instruc ons to t in a 9-bit eld, the memory demands of these programs will have to be
small. For example, you will have to be clever to support a conven onal main memory of 256
bytes (8-bit address pointer). You should consider how much data space you will need before
you nalize your instruc on format. Your instruc ons are stored in a separate memory, so that
your data addresses need be only big enough to hold data. Your data memory is byte-wide, i.e.,
loads and stores read and write exactly 8 bits (one byte). Your instruc on memory is 9 bits wide,
to hold your 9-bit machine code.

You will write and run three programs on your ISA. You may assume that each program starts at
address 0, and that you will reload the instruc on memory speci cally for each program. The
speci ca on of your branch instruc ons may depend on where your programs reside in
memory, so you should make sure they s ll work if the star ng address changes a li le (e.g., if
you have to rewrite one of the programs and it causes the others to also shi ). This approach
will allow you to put all three programs in the same instruc on memory later on in the quarter.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
fi
fi
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
fi
ti
ti
fi
ti
ti
fi
ti
ti
fi
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ft
tt
 4

Architecture Limita ons and Requirements

We shall impose the following constraints on your design, which will make the design a bit
simpler:

1. Your core should have separate instruc on memory and data memory.
2. You should assume single-ported data memory (a maximum of one read or one write
per instruc on, not both — Your data memory will have only one address pointer input
port, for both input and output).
3. Your instruc on memory should not exceed 2^10 entries; it must not exceed 2^11
entries. If you need the larger number of instruc on entries, your writeup must explain
how these extra entries improve some other performance element.
4. Your data memory should not exceed 2^8 entries; it must not exceed 2^9 entries. If you
need the larger number of data entries, your writeup must explain how these extra
entries improve some other performance element.
5. You should also assume a register le (or whatever internal storage you support) that
can write to only one register per instruc on.
a. The sole excep on to this rule is that you may have a mul bit ALU condi on/ ag
register (e.g., carry out, or shi out, sign result, zero bit, etc., like ARM's Z, N, C,
and V status bits) that can be wri en at the same me as an 8-bit data register, if
you want.
b. You may read up to two data registers per cycle.
c. Your register le will have no more than two output ports and one input port.
d. You may use separate pointers for reads and writes, if you wish.
e. Please restrict register le size to no more than 16 registers.
6. Manual loop unrolling of your code is not allowed – use at least some branch or jump
instruc ons.
7. Your ALU instruc ons will be a subset of those in ARMsim, or of comparable complexity.
8. You may use lookup tables / decoders, but these are limited to 32 elements each (i.e.,
pointer width up to 5 bits).
a. You may not, for example, build a big 512-element, 32-bit LUT to map your 9-bit
machine codes into ARM- or MIPS-like wider microcode. (It was amusing the rst
me a team tried it, but it got old ☺.)

Some Things to Think About

In addi on to these constraints, the following sugges ons will either improve your performance
or greatly simplify your design e ort:
1. In op mizing for performance, dis nguish between what must be done in series vs.
what can be done in parallel.
a. E.g. An instruc on that does an add and a subtract (but neither depends on the
output of the other) takes no longer than a simple add instruc on.
b. Similarly, a branch instruc on where the branch condi on or target depends on a
memory opera on will make things more di cult later on.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
fi
ti
ft
ff
tt
ti
fi
ti
ti
ffi
ti
ti
ti
ti
ti
ti
ti
fl
fi
 5

2. Your primary goal is to execute the assigned programs accurately. Secondary goals are:
a. Minimize clock cycle count.
b. Minimize cycle me (short cri cal paths).
c. Simplify your processor hardware design.

Generic, general-purpose ISAs (that is, those that will execute other programs just as e ciently
as those shown here) will be seriously frowned upon. We really want you to op mize a crea ve
special purpose design for these programs only.

Top-Level Interface
Your microprocessor needs only three one-bit I/O ports: clock input and start input from
the testbench and done output back to the testbench.

We will use the start and done signals to drive your processor. During nal tes ng, the
sequence will be as follows:
1. The testbench will set the start bit high.
a. Your processor must not write to data memory while the start bit is asserted.
2. The testbench will load operands into speci ed loca on in the data memory.
3. The testbench will lower the start bit.
a. This should cause your processor to begin execu ng the rst program.
4. When your program has run and your device has stored the result into the speci ed
loca on(s) in data memory, your device should bring the done ag high.
5. The testbench will respond by reading and verifying your results.
6. You may then set up your second set of instruc on 9-bit words.
7. The testbench will assert the start bit
a. Your processor should deassert the done ag in response
8. The testbench will load the next set of operands into the speci ed loca ons in data
memory while the start bit is high.
9. The testbench will lower the start bit.
a. Your device should start running the second program.
10. When the second program completes, your processor should assert done.
11. The testbench will read and verify your results from the second program, then issue the
nal start command while loading the third set of operands into data memory. Your
done ag at the end of this program will terminate simula on a er the testbench reads
and veri es your results.

If you cannot get all three programs to run, separate testbenches for individual programs will
also be provided, with correspondingly lower course grades awarded.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
fi
ti
fl
fi
ti
ti
fl
fi
ti
ti
ti
fi
ti
fi
fl
ft
ti
fi
ti
fi
ti
ffi
ti
 6

What must the processor do?

Your processor must be able execute the following three programs.

Program 1 (forward error correc on block coder/transmi er)

Given a series of een 11-bit message blocks in data mem[0:29], generate the
corresponding 16-bit encoded versions and store these in data mem[30:59].

Input and output formats are as follows:

input MSW = 0 0 0 0 0 b11 b10 b09

LSW = b8 b7 b6 b5 b4 b3 b2 b1, where bx denotes a data
bit

output MSW = b11 b10 b9 b8 b7 b6 b5 p8

LSW = b4 b3 b2 p4 b1 p2 p1 p0, where px denotes a parity
bit

Example, to clarify “endianness”: binary data value = 101_0101_0101

mem[1] = 00000101 -- 5 bits zero pad followed by b11:b9 = 00000_101
mem[0] = 01010101 -- lower 8 data bits b8:b1

You would generate and store:

mem[31] = 10101010 -- b11:b5, p8 = 1010101_0

mem[30] = 01011010 -- b4:b2, p4, b1, p2:p1, p0 = 010_1_1_01_0

p8 = ^(b11:b5) = 0;
p4 = ^(b11:b8,b4,b3,b2) = 1;
p2 = ^(b11,b10,b7,b6,b4,b3,b1) = 0;
p1 = ^(b11,b9,b7,b5,b4,b2,b1) = 1;
p0 = ^(b11:1,p8,p4,p2,p1) = 0;

Program 2 (forward error correc on block decoder/receiver)

Given a series of 15 two-byte encoded data values – possibly corrupted – in data
mem[30:59], recover the original message and write into data mem[0:29].

This is just (sort of..) the inverse problem. However, in Program 1 there was only 1 unique
output for each unique input. Now there are several (how many?) possible inputs for each of
the 2**11 possible outputs.

This coding scheme can correct any single-bit error and detect any two-bit error.

The testbench will generate parity bits for various random data sequences, occasionally ip one,
occasionally two, of the parity or data bits, and then ask you to gure out the original message.
Your nal format = F1 F0 0 0 0 D11 D10 D9 D8 D7 … D0
If no errors, F1F0 = 00; if one error (data or parity), F1F0 = 01; if two errors, FIFO = 1X

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
fi
fi
ft
ti
ti
tt
fi
fl
 7

(If there are two errors, the test bench looks only to see that you put a 1 in F1, and does not look
at any other bits.)

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
 8

Program 3 (pa ern search)

Given a con nuous message string in data mem[0:31] and a 5-bit pa ern in bits [7:3] of
data mem[32]:
a. Enter the total number of occurrences of the given 5-bit pa ern in any byte into data
mem[33]. Do not cross byte boundaries for this count.
b. Write the number of bytes within which the pa ern occurs into data mem[34].
c. Write the total number of mes it occurs anywhere in the string into data mem[35]. For
this total count, consider the 32 bytes to comprise one con nuous 256-bit message,
such that the 5-bit pa ern could span adjacent por ons of two consecu ve bytes.

Note the order ("Endian-ness") of the sequence:

data mem[0] = first byte in message string;

bit [7] is the first bit in the entire string;
data mem[1] = second byte;
bit [7] of [1] comes right after bit [0] of [0]

Example:

data_mem[0:31] = 8'h0,8'h0.. Memory to search is all zeros

data_mem[32] = 8'b00000_000 The pattern to search for is ‘00000’
data_mem[33] = 4*32 = 128 because the string can show up in any
of 4 different locations in each byte
data_mem[34] = 32 because every byte contains at least
one copy of the pattern
data_mem[35] = 252 because pattern can start at bit 0, 1, 2, ..,
251
It cannot start at bit 252, because one bit of the pa ern would fall outside the string; likewise, 253, 254, and 255 are "nonstarters," as well

What to Submit?
You will turn in milestone reports and (eventually) all your code.

Reports will address ques ons for each milestone. In describing your architecture, keep in mind
that the person grading it has much less experience with your ISA than you do. It is your
responsibility to make everything clear. One objec ve of this course is to help you improve your
technical wri ng and repor ng skills, which will bene t you richly in your career.

For each milestone, there will be a set of requirements and ques ons that direct the format of
the writeup and make it easier to grade, but strive to create a report you can be proud of.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
tt
tt
ti
ti
ti
tt
tt
ti
ti
fi
ti
tt
ti
tt
ti
 9

Milestone 1 — The ISA

For the rst milestone, you will design the instruc on set architecture (ISA) for your processor. A
quick reminder that an ISA is more than just an instruc on set. It describes a fair bit about how
the machine will work [at least from the programmer’s perspec ve]. It speci es how many
registers are available, how memory operates, how addressing works, etc. Your ISA design will
dictate your implementa on — plan ahead!

Milestone 1 Objec ves

For this milestone, you will design the instruc on set and instruc on formats for your processor.
You will then write code for the three programs to run on your instruc on set.

Milestone 1 Components
1. Team.
i. List the names of all members of your team, but only one copy of the report
should be submi ed.
2. Introduc on.
i. This should include the name of your architecture (have fun with this ☺), overall
philosophy, speci c goals strived for and achieved.
ii. Can you classify your machine in any of the classical ways (e.g., stack machine,
accumulator, register, load-store)? If so, which? If not, devise a name for your
class of machine.
3. Architectural Overview. This must be in picture form.
i. What are the major building blocks you expect your processor to be made up of?
NOTE: This is not your nal processor design, rather an early rough dra of the
major elements. Missing details and imprecision are okay at this stage, but you
should con nue to re ne this picture as your design evolves. You will submit an
updated diagram with every milestone.
4. Machine Speci ca on
i. Instruc on formats.
i. List all formats and an example of each. (ARM has R, I, and B type
instruc ons, for example.)
ii. Opera ons.
i. List all instruc ons supported and their opcodes/formats.
iii. Internal operands.
i. How many registers are supported?
ii. Is there anything special about any of the registers, or all of them general
purpose?
iv. Control ow (branches).
i. What types of branches are supported?
ii. How are the target addresses calculated?
iii. What is the maximum branch distance supported?
v. Addressing modes.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
ti
fi
fl
ti
ti
ti
fi
tt
fi
ti
ti
fi
fi
ti
ti
ti
ti
ti
ti
ti
ft
fi
 10

i. What memory addressing modes are supported, e.g. direct, indirect?

ii. How are addresses calculated?
iii. Give examples.
5. Programmer’s Model [Lite]
i. How should a programmer think about how your machine operates?
ii. Give an example of an “assembly language” instruc on in your machine, then
translate it into machine code.
6. Program Implementa ons
For each program, give assembly instruc ons that will implement the program correctly.
Make sure your assembly format is either very obvious or well described, and that the code is
(very) well commented. If you also want to include machine code, the e ort will not be wasted,
since you will need it later. We shall not correct/grade the machine code. State any assump ons
you make.
i. Program 1
ii. Program 2
iii. Program 3

What to Submit?
You will submit a wri en report that contains all of the required components of Milestone 1. It
is your responsibility to make this report clear and well-organized.

Your report should be a single document, in PDF form.

• Excep on: You may include your program implementa ons as separate “source code” les
if you wish.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
tt
ti
ti
ti
ti
ff
ti
fi
 11

Milestone 2 — 9-bit CPU: Register le, ALU, and fetch unit

In this milestone, you will design the top level, register le, control decoder, ALU (arithme c
logic unit), data memory, muxes (signal rou ng switches), lookup tables, and fetch unit
(program counter plus instruc on ROM) for your CPU.

For this and future designs, we want the highest level of your design to be a schema c and
SystemVerilog code. You may either hand-draw the schema c or generate it using the Quartus
RTL Viewer func on.

Anything below that can be schema c (again either drawn or generated by Quartus) and
SystemVerilog, or just SystemVerilog. The SystemVerilog les implement the symbols included in
the block diagram le. Everyone will use Questa/ModelSim for simula on and Intel (formerly
Altera) Quartus II for logic synthesis in the Cyclone IVE family, device EP4CE40F29C6.

In addi on to connec ng everything together at the top level, you will demonstrate the
func onality of each component separately through schema c, SystemVerilog, and ming
printouts.

Milestone 2 Objec ves

The primary goal of this milestone is to show individual components opera ng as desired. All of
the pieces of your processor will need to work in isola on before nal integra on.

CPU Design Refreshers and Helpful Tips

The fetch unit points to the current instruc on from the instruc on memory and determines
the next out of the program counter (PC). It should look something like the following diagram:

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
fi
ti
fi
fi
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
 12

The program counter is a state element (register) that outputs the address pointer of the next
instruc on. Instruc on ROM is a Read Only Memory block that holds your 9-bit machine code. It
does not have to hold your actual code (generated in Milestone 3) yet at this point (but if you
have already wri en it then it might as well). It should hold something so we can see the e ect
of changing PCs while your processor runs. The next PC logic takes as input the previous PC and
several other signals and calculates the next PC value.

The inputs to the next PC logic are:

• start – when asserted, it sets the PC to the star ng address of your program.
• start_address – has the star ng address of your program.
• branch – when asserted it indicates that the prior instruc on was a branch.
• taken – [op onal.. more on this in lecture] when the instruc on is a branch, this signal
when asserted indicates the branch was resolved as taken.
• target – [some op ons.. more on this in lecture] where this branch is going

On non-branch instruc ons, the next PC should be PC+1 (regardless of the value of taken). For
branch instruc ons, the new PC is either PC+1 (branch not taken) or target (branch taken). If
your branches are ALWAYS PC-rela ve, then you can rede ne target to be a signed distance
rather than an absolute address if you want. Make sure you tell us this is what you’re doing.
(Note: ARM and MIPS increment their respec ve PCs by 4, simply by conven on because their
machine codes are 32 bits = 4 bytes wide. We'll just increment by 1, for each 9-bit value of our
machine code.)

How to Present Your Implementa on

You will demonstrate each element of your design in two ways.

First, with schema cs such as the one shown above, plus your SystemVerilog code. Obviously,
you must also show all relevant internal circuits with further SystemVerilog code.

Second, you must demonstrate correct opera on of all ALU opera ons, register le
func onality, and fetch unit func ons with ming diagrams. An example of a (par al) ming
diagram will be demonstrated in class; yours will be longer. The ming diagrams, for example,
should demonstrate all ALU opera ons (this includes math to support load address
computa on, or any other computa on required by your design), each with a couple of
interes ng inputs. Make sure any relevant corner/unusual cases are demonstrated. If you
support instruc ons that do mul ple computa ons at the same me, you need to demonstrate
them happening at the same me. Note that you’re demonstra ng ALU opera ons, not
instruc ons. So, for example, instruc ons that do no computa on (e.g., branch to address in
register) need not be demonstrated. There will also be a ming diagram for the fetch unit,
showing it doing everything interes ng (increment, absolute jump/branch, condi onal jump/
branch, etc.). The schema cs and ming diagrams will be di cult for us to understand without
a great deal of annota on. Good organiza on of les and Verilog modules also helps.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
ti
ti
ti
ti
ti
ti
tt
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
fi
ffi
ti
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ff
 13

Milestone 2 Components
Your Milestone 2 report should add on to your Milestone 1 report (you are building your nal
report over me).

Your Milestone 2 report must include a changelog that indicates where any signi cant changes
have been made since your Milestone 1 submission. Please restrict this to highligh ng
substan al architectural or opera onal changes. You may include a changelog per sec on, or a
nal changelog at the end, or something in between as best suits your report. You do not need
a changelog for new sec ons.
• Some things, such as your Introduc on, may have no changes; this is ne/expected.

Your Milestone 2 reports must add the following. You may add these to exis ng sec ons in your
report or add new sec ons, as you deem appropriate:

• A list of ALU opera ons you will be demonstra ng, including the instruc ons they are
relevant to. Also, a brief descrip on of the register le func onality is needed.

• Full Verilog models, hierarchically organized if your top level module contains
subassembly modules, some of which contain smaller modules.

• Well-annotated ming diagrams or transcript (diagnos c print) lis ngs from your
module level Questa/ModelSim runs. It should be clear that your program counter /
instruc on memory (fetch unit) and ALU works. If your presenta on leaves doubt, we’ll
assume it doesn’t.

• Your Architectural Overview gure should be revised with more detail / needed updates.

Answer the following ques on:

• Will your ALU be used for non-arithme c instruc ons (e.g., MIPS or ARM-like memory
address pointer calcula ons, PC rela ve branch computa ons, etc.)? If so, how does that
complicate your design?

What to Submit?
You will submit a wri en report that contains all of the required components of Milestones 1
and 2. It is your responsibility to make this report clear and well-organized.

Your report should be a single document, in PDF form.

• Excep on: You may include your program implementa ons as separate “source code” les
if you wish.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
fi
ti
ti
ti
ti
ti
ti
tt
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
ti
fi
ti
ti
ti
ti
ti
ti
fi
ti
ti
fi
ti
ti
ti
fi
fi
 14

Milestone 3 — An Assembler & Early Integra on

Assemblers convert human-readable assembly code to computer-readable machine code. Your
code from Milestone 1 is the former, but your processors will need the la er.

Milestone 3 Objec ves

Implement an assembler. Begin the process of integra ng your processor components.

Tasks
1. Write an assembler which converts your assembly code from Milestone 1 into 9-bit
binary machine code. We will provide sample code, but you may use any language you
wish. This should be a fairly simple string access, map, print sequence.
2. If you have not already done so in Milestone 2, write a top-level SystemVerilog model of
your design which instan ates the ALU, fetch (program counter) unit, instruc on
memory (either inside fetch or separate), register le, data memory, control decoder,
and any other blocks you need. This does not need to actually run the three problems
yet — that will be the nal piece — but it should compile cleanly in both Questa/
ModelSim and Quartus II.

Milestone 3 Components
Your Milestone 3 report should add on to your Milestone 2 report.

Your Milestone 3 report must include a changelog that indicates where any signi cant changes
have been made since your Milestone 2 submission.

Your Milestone 3 reports must add the following. You may add these to exis ng sec ons in your
report or add new sec ons, as you deem appropriate:

• An example of input to and output from your assembler.

o [unlikely]: If your assembler does anything beyond what a ‘normal’ assembler
would be expected to do, explain this as well.

• Your Architectural Overview gure should be revised with more detail / needed updates.
[Might you be able to automate this drawing now?]

What to Submit?
You will submit a wri en report that contains all of the required components of Milestones 1, 2,
and 3. It is your responsibility to make this report clear and well-organized.

Your report should be a single document, in PDF form.

• Excep on: You may include your program implementa ons as separate “source code” les
if you wish.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti
tt
ti
fi
ti
fi
fi
ti
ti
ti
tt
ti
ti
fi
ti
fi
 15

Document Revision History

• v1.1.0
o Limit instruc on memory capacity
o Limit data memory capacity
• v1.0.0
o Ini al Release.

WI22 - CSE141L CC-BY-NC-ND © Pat Pannuto, John Eldon, Dean Tullsen, & the UCSD Architecture Faculty
v.1.0.0
ti
ti