Schedule Syllabus Resources Moodle Gradescope

Milestone 1

1 Assembly Language Specifications

Your first step is to describe everything that a user needs to know in order to write an assembly language program for your processor. You should then use your assembly language to write relPrime and Euclid's algorithm. Make sure that you satisfy the requirements listed in the project overview. In particular, you should provide support for general computations and procedures. You should definitely consider how your processor will receive the input number for relPrime. You must also write several small programs to demonstrate common operations (loops, loads, procedures, etc.). These programs will serve as a test to help determine if your instruction set is implemented correctly. Think about what the first programs you would write in any new programing language would be.

2 Machine Language Specifications

Your next step should be to describe everything that a user needs to know to write an assembler for your processor (i.e. to translate statements from your assembly language to your machine language). Along with this, you should translate your assembly language programs into machine language.

You may have to modify your assembly language specifications while working on the machine language specifications.

3 Turning In M1

Submit the following for this milestone:

1. Design document that includes the following information.
   • A cover page including your team name and team member's names.
   • A one paragraph description of your design at a high level including your design philosophy.
   • A description of how you plan on measuring "performance" of your processor.
   • Description of the registers available to the assembly language programmer and those reserved for any specific purpose. This is like the register list from the green sheet, notice that PC and other such registers are not included here.
   • An unambiguous English description of each machine language instruction format type and its semantics including a visual depiction of the allocation of bits in each instruction type (like on the green sheet).
   • An unambiguous English description of the syntax and semantics of each instruction (see Figure 2.1 on page 69 of the book).
   • A symbolic description of the behavior of each instruction (like those on the green sheet).
   • You should summarize the ISA in a table like the one on the green sheet. This table should include (at minimum) instruction mnemonic, type, opcode, and symbolic description.
   • The rule for translating each assembly language instruction into machine language.
   • A section describing each addressing mode your processor will use, explain how immediate bits are manipulated by each instruction type. be defined (i.e. is branch PC relative?).
   • An explanation of any procedure call conventions, especially relating to register and stack use. You should write a minimum working example of procedure calling in your ISA.
   • Example assembly language program demonstrating that your instruction set supports a program to find relative primes using the algorithm on the project page.
   • Assembly language fragments for common operations. For example, this might be loading an address into a register, iteration, conditional statements, reading data from the input port, reading from the input port, and writing to the output port.
   • You should draw a memory map allocating space for text, data, and any special addresses your design needs.
   • Machine language translations of your assembly programs (relprime and your fragments). This code should be appropriately commented, and formatted such that the addresses and machine translations of each instruction is easily seen:

Address	Assembly	Machine code	Comments
0x0000	add x1, x2, x3	0101 1010 1111 0000	//an add instruction
0x0002	L: beq x1, x8, L	0101 1010 1111 0000	//a branch with a label

As an example of a professional report on a processor you can reference the data sheet for the MIPS R4300i processor. This has much more information than you will have ready during this milestone, but you should reference it early and often.

2. An individual design journal for each member. This must:
   • Include details about what that member worked on for the week (including time taken)
   • Include design decisions the team and individual member made during this milestone, including summary of meetings' outcomes, and work that may not be reflected in the design journal.
   • Include a list of tasks the member was assigned for the next milestone (planning for the next Milestone), including estimated time required for each task.
   • Be commited by the individual author. Each member must commit their own log. Teammates cannot do this for you.
   • If you need help writing the journal, try adding one or two sentences for each work session in the form "I did X because of Y". The justification ("Y") is really important to show the depth of your design process.

4 Getting Your Team Repository

IMPORTANT: Read the entire rest of this section before you click any links in here.

Your team repositories will be managed through github, just like the labs. You will access and add files to them as usual, there is a base file structure set up, but you can customize this (within reason). Check the instructions for above for how to turn in files each week. Read the README in each folder of the repository before you start making changes.

Whoever accesses github first on your team will need to name the team, copy paste the exact name from the list of Teams on Moodle. Do not name your team something other than the name we have assigned. Later teammates who click the link will simply select the appropriate team name from a list of names.

To clone your repository you follow the standard procedure:

1. Copy the repository URL (the green CODE button on your team's github page will show you this, I recommend you use SSH to authenticate, and follow the instructions in the next section to set up an SSH key if you dont have one yet.)
2. Make a folder on your computer somewhere you want your local copy to live (don't put this in a path with spaces -- no OneDrive folders).
3. Open GitBash in that folder (or use your favorite git-GUI)
4. Execute the following command, but replace YOURTEAMSURL with... your team's URL.:

   git clone YOURTEAMSURL

5. Email your teammates and get goin'!
6. Avoid merge conflicts by setting up your project(s) correctly and maintaining good git practices. [Note, every time you add a file to a Xilinx project the 'project file' is updated. That means that if two people are adding files to the project at the same time it will cause a merge conflict in the project file. Plan appropriately.]

Assuming you read everything up there your reward is this github link

5 Fixing GitHub Authentication Issues

Here is a quick and dirty guide to setting up SSH keys if you have been having trouble accessing repos.

1. Make an SSH Key
   1. Open "Git Bash"
   2. Change to the ~/.ssh directory (cd ~/.ssh)
   3. Generate an SSH key by typing ssh-keygen
      1. Hit "enter" any time it asks you a question (default RSA type, blank passphrase)
   4. display the contents of the new public key (cat id_rsa.pub)
   5. Copy all the contents it displayed (right click to copy in GitBash, ctrl+c won't work)
2. Add the SSH key to your github account
   1. In your web browser, go to the github website.
   2. Open your account Settings on the github website (click the user icon in upper-right corner of the web page and choose "settings")
   3. Select "SSH and GPG Keys" on the left
   4. Click "New SSH key" green button
   5. Give it a name like "232 ssh key"
   6. Paste the key you copied into the large text box
   7. Click "Add SSH key" button
3. Use the key to clone your repo
   1. In your web browser, open your new repository in the github web page (the URL it gave you when you first created it)
   2. Click the green "Code" button
   3. Note that it says "Clone with SSH": copy that URL (looks like git@github.com/....)
   4. Go back to Git Bash and git clone that copied URL

Example individual journal

Selana McIntosh, WORK LOG

MILESTONE 1 WORK:

Tuesday, December 3, 2067

Met with team [35 min]

• We decided to build an accumulator based processor. An accumulator design will fit well with the 16-bit requirements. We then decided to include 4 special registers for tracking old accumulator values. These registers can be accessed with a 'move' instruction allowing the benefits similar to stack-based designs.

Wednesday, December 4, 2067

Design procedure call conventions, we decided to split temporary and saved registers this allows our design to minimize memory accesses across procedure calls. [20 minutes]

Thursday, December 5, 2067

Write up call conventions, we made some changes to decrease the number of saved registers because we want programmers to think carefully about using them. [25 minutes]

Friday, December 6, 2067

Met with team [30 min]

We assigned tasks for milestone 2. My tasks are:

1. Draft RTL for addi instruction [est 20 min]
2. Review RTL for bne and jal (reviewing Alexa's work). [est 1 hour]
3. Brainstorm a list of components we'll need to create. [est 15 min]

Your documents should be placed in the main design directory of your team's repository. Your instructor will specifically check for each bulleted item when grading.