Team 2-3 Log
Assembly Language Instructions: add, addi, sub, branch, lw, sw,
Registers: 16 general purpose registers, 0 register, 2 – return registers, EPC
Opcode depends on registry
Now we’ve decided to use 8 general purpose registers because we have realized that all 16 are unnecessary for our project.
GCD Function in higher level language:
While (b>0)
if (b>a)
temp = a
a = b
b = temp
else a= a – b
return a
Implementation of the GCD function in higher level language:
Interrupt 1 -> number is assigned to m
Output m to port
Interrupt 2
Set i = 2
While (GCD(i,m) != 1)
i + +
return i
output i to port
Now we have to include the interrupts into our function:
The program must be able to accept a 4-bit hex number and then send it through the Relative Prime function. It must then return the lowest relatively prime number in 4-bit hex
We have finished our list of Assembly Language Instructions that we intend to include in our final project. These are all listed on the Assembly Language Instructions page.
Next is to implement the above higher language program (likely done in Java) into assembly language using only the instructions that we’ve included on our list.
In designing our machine language code we were originally going to use more instructions than needed. Where we were first going to us an li instruction and we changed that to an ori and then finally a move. This allowed us to eliminate an instruction
We created 4 types of instructions: R-Type, I-Type, B-Type, and J-Type. Each is necessary for the functionality of our Relative Prime procedure. We assigned each of our instructions to a specific type, and then assigned each one a different opcode. The opcodes were arbitrarily assigned, however each type includes codes in a given range.
We are now in the process of converting our Assembly Language Implementation into Machine Code. We are using the opcode that we assigned to each of our instructions in order to convert the assembly to machine. We are also debating whether or not LA actually does anything and whether or not we need to include it in our Instruction set and/or the Assembly implementation. If we do need to include it, we will add it later.
We have now realized that we need 3-bits to represent 8 registers. This will require us to change our Assembly Language Specification sheet and Implementation to reflect this change.
After meeting with the instructor, we have learned that our Specifications were satisfactory, but were missing a few key components. First and foremost we needed to implement the inputs from the buttons to be pressed. Also, the OP code for Load Address was missing from the MIPS specs.
Our first task was to change the bits amount for the immediate value in the programming model for the I-type instructions. This was done because we had made a mistake earlier in our specs and called for two bits for registers. When we corrected the issue, we forgot to update the specifications of our code to reflect that change.
Our inputs are now implemented. At first, there were problems with how to actually enter it into the code, but the instructor helped alleviate any problems. The end product ended up looking very different from our original Assembly code. This change to our assembly code has made us realize that once again some instructions aren’t needed and others can be replaced with instructions that perform the same task. Some examples: la has been removed, Read was replaced with Write, etc.
While converting the Assembly code to Machine code, we once again ran into problems with the MIPS documentation. We found that there is no bit code for a $0 register, yet the assembly code called for one. This topic is to be resolved at the next group meeting.
A major flaw was found in our Machine Language specs that no one had noticed before. The specs state that there are to be 8 general purpose registers, and 5 special purpose ones. However, only 3 bits were used to represent the registers, which mean 5 of the registers cannot be represented. This meant rewriting the specs to allow 4 bits for representing registers, instead of 3. This also meant rewrite the machine code, so that it properly implements our specs.
There is also the issue of how to implement procedures into our machine language. Joe suggested utilizing the program counter to perform this task. We’re still up in the air on this decision as of right now.
Our RTL has been written and typed up, it can be fond on our web page.
The test cases are now made, consitering that they are not proofs like we origionally thought. they are a simple list of functional requirements. the list is almost complete and is to be looked over by the group. The RTL issues about interupts have been cleared up and the pc counter should be incremented by 2 and not 4. all of these issues should be delt with by tonight.
After
Ross became occupied with numerous exams and fraternity activities so this milestone seems very hard to complete.
We used the figure in the comp arch book as our base for the datapath. This seemed reasonable because it contained many of the instructions we use in our project.
We added a few Mux’s that the control unit deals with to determine what signal is transferred to the desired piece of hardware.
Paisley initially wrote a single cycle datapath with the help of Joe but they learned that we had to use a multi-cycle datapath so we had to start it all over again.
The image became very cramped but time constraints did not allow us to design a larger datapath image.
Using our assembly, machine, and RTL specifications, we noticed the register bits were incorrect, so we quickly fixed that. We had it done,
But due to numerous versions, we had an older version up on the server.
The datapath is now complete but we think it is very cluttered, if we have time we will reconstruct the datapath to make it look better
Jump and link has made our group argue a lot over differences in the definition. So we hope we have done it correctly because over time
We have confused ourselves.
Joe is drawing up the finite state diagram
Matt is updating the log and memo while helping our
We have completed the milestone. We do not feel 100% confident about it, but due to lack to resources/manpower/time this is the best we feel
We can do at this time. When it is graded we will have the
opportunity to correct our mistakes so we can move on to the next milestone.
Ross constructed the alu over the
weekend in xilinx and now it needs to be tested. Pisley will test teh aul later tonight and when the group meets at some other
meeting. joe is trying to correct our mistakes from teh last milestone, paisley is getting the registers and
Ross will start on the mux's.
testing will be done tonight for the alu and the registers i think we will start using veralog and the state diagram will be inputed tonight. I think we will do fine this milestone.
This milestone we started early on the project, having most
of it completed on Monday. Ross and
We also started working on the hardware aspect of the control. Going from a finite state machine to the hardware component.
There was not much involved in this milestone, mainly just putting our last milestone into xilinx and explaining it.
However, our group has vastly improved on teamwork and we have a good amount of the next milestone completed.
We met with our prof and there were a lot of things we need to fix, first we need to incorperate some interupts, and i thought we did that, but we have not. To do that we need another 4 registers and some new signals. also we need to fix our memory problem and we emailed our grader and hoped we know what he is actually talking about because we were all confused. we are also thinking about making an assembler and getting a few points. Also, we do not have anymore than 256 lines, and since the programs will be small our branch takes an IMM so its more efficient b/c we do not have to load. We tried to make everything more efficient... we need to talk about efficency in our presentation. While it may be harder with larger programs is simple with efficient progams.
Hanlon is working on the state diagram and is having
problems. Work is getting done, we are all working on
different things. Our interrupts are now in our datapath and are useable. We
have added 4 registers, one to flag an interrupt for
the first interrupt, the second will hold the value of the memory address of
the first interrupt. The last two are a place for the value of the first
interrupt, and the last is a display register. These registers will be written
to from seperate control signals from the interupts and can also be writen to
from the datapath. We also added signal into the control for interupts, as per
our graders request. we are trying to figure our if we are changing our load
and store word to 2 registers and an immediate or just 3 registers. this would
mean that we would completly elliminate out imm feild. The RTL is now being
updated and the four registers are now I0-I3 for the interumps. The RTL will
now show those changes. we decided to go with the professor recomandation and
change the load and store to 2 registers and an immediate. this will help use
address memory and use it more efficently. The machine language implmentation
is now updated as well to show the changes in the load and store. The assembler
is now being constructed.
Happy Halloween, and we are testing our ALU, Xilinx is a pain with naming and other things so far all our components work, but because of the naming xilinix goes ape on us. The RTL, and everything is now updates\d with our new IMM type.
Much work was done testing each component in ModelSim, every component has had issues at one points or another. The worst offender was the ALU. Xilinx was not liking the operation control bits on the ALUs and pretty much required a requiring of the single bit ALUs that made up the 16 bit one. We have also verified that all of our registers work, including our Register File. However, we still have an issue with our Register File that needs to be sorted, specifically, it doesn’t correctly handle interrupts, and this is being worked on.
Much revision has had to be done on all of our previous milestones, but we feel confident that we are getting much closer to our desired final project.
11/15-17/03
Progress is being made in our testing, but the machine seems
to not like the register file. The report is coming along except for one hitch, hanlon is no longer work on
it due to his grandfather being newly deceased. Hanlon was working on tow
sections of the report and only had time to write on of them. He will also not
be able to present with us an thus our presentation
must change. The sections were redistributed and the presentation has also been
rethought. Our implementation for our interrupts is gone, again, this is the
second time this has happened, the file is missing the
interrupt section. Our interrupts are like what was stated on 10/24. This WAS
implemented but has since gone missing from our documents. We have been working
a lot around our finals to test and debug our project. Our speeds seem to work,
but the chip does not. The problem we are seeing is that when you make small
mistakes early on you pay for them now. We would like to see that things are
graded before the next step is due to see what there is to correct, rather than
assuming. But progress is being made. The powerpoint
is nearly done and sent to archana, also the report
is 20 pages minus a lot of work. It is looking like the presentation my go well
even if our project does not work totally.