-
What could be the cause of "Warning: Extra bit(s) in control store file ucode."?
This means that the ucode file has more than 35 columns. One reason
why this can happen is if you've transferred the ucode file from
Windows to Unix. Run dos2unix program on UNIX machines to remove the
extra control characters inserted by Windows. You can do this by typing:
dos2unix ucode ucode
on any Linux machine. If this doesn't work, check to make
sure that your ucode file has at most 35 columns.
- How do we implement decode operation based on what instruction we
have. For example, how do we differentiate LDB vs. XOR instruction
what bits of information do we have to use in the control store. To
construct control store.
The microsequencer (Figure C.5) decides the next state using J bits, cond bits and 00IR[15:12] and IRD bit. There is a mux which selects between J bits with combinational logics and 00IR[15:12].
Hence, IRD bit should select 00IR[15:12] at state 32 to decide the next state.
- What should happen to unused states? How should they be encoded?
with all zeros?
It's your design choice but filling with 0s would be a good idea.
- In this homework what do we need to do if we encounter illegal opcode
for a certain instruction?
You do not implement state 11, 10. We will not test illegal opcodes.
-
What is CYCLE_COUNT? Is this the counter for memory access?
CYCLE_COUNT is a global variable used by the simulator to
count the number of machine cycles elapsed since the program started
execution. Do not change this variable. You will need to use another
variable for simulating memory latency.
- Is there any difference between states 23 and 24?
at 23, MDR = SR[15:0]
at 24, MDR = SR[7:0]@SR[7:0]
See Notes on state 17
-
How do we handle Memory Mapped I/O for this lab?
You do not need to implement Memory Mapped I/O for this lab.
- You do not have to implement the RTI instruction for this lab. You can assume that the input file to your simulator will not contain any RTI instructions.
- For this assignment, you can assume that the programmer will always give aligned addresses, and your simulator does not need to worry about unaligned cases.
-
You may assume that the code running on your simulator has been
assembled correctly and that the instructions your simulator sees
comply with the ISA specifications, i.e. all instructions are valid
and there are no unaligned accesses.
-
In your code that you write for hw #2 , do not assign the current latches
to the next latches. This is already done in the shell code.
-
I am getting values like xFFFFFFFF in my registers when they should be xFFFF instead, why is this?
The variables in your c program are 32 bit values, so the nubmer -1 is xFFFFFFFF.
You need to make sure that when you store values in a variable you mask them properly.
For instance you would need to assign the var1 from var2 the statment var1 = var2 & 0xFFFF, or
its equivalent var = Low16bits(var2). This zeros out the top 16 bits before writing it into var1.
-
Do we need to implement the TRAP routines?
No. Whenever a TRAP instruction is processed, after the last state, PC
will be set to 0, if you implement the TRAP instruction correctly. The
simulator halts whenever PC becomes 0.
You are still implementing states 15,28,30 associated with the TRAP instruction.
-
Why am I not getting the result I expect from a C expression?
Please read and make sure you understand the precedence of C operators. Examples:
- "a & b == 0" means "a & (b == 0)", therefore you might want to write "(a & b) == 0"
- "a >> 1 + b" means "a >> (1 + b)", therefore you might want to write "(a >> 1) + b"
- "a = b + c? d : e" means "a = (b + c)? d : e", therefore you might want to write "a = b + (c? d : e)"
- there are other examples from some lab 2 implementations... If you do not want
to remember or to think too much about this, just use parenthesis!