=====================
= Lec-4-HW-hintsOnTesting.html
====================

When you start working on your LC3 design, you will make a few small changes 
and then test the result. You could write your own testbench, but I wrote 
one that is probably all you'll need for a while, test:top_rtl_testInstr{sch}. 
Here is the output you should get when you run that testbench before you've 
made any changes:

----------------------------(3)----
---((( 18 )))-----[ ]----[ ]--
PC[0200] MAR[0000] MDR[0000] IR[0000 000 000 000 000] PSR[0--000--000]
R0[0000] R1[0000] R2[0000] R3[0000] R4[0000] R5[0000] R6[0000] R7[0000]
----------------------------(24)----
---((( 33 )))-----[ ]----[ ]--
PC[0200] MAR[0000] MDR[0000] IR[0000 000 000 000 000] PSR[0--000--000]
R0[0000] R1[0000] R2[0000] R3[0000] R4[0000] R5[0000] R6[0000] R7[0000]
STOPPED AT 1002 ==============

The first 4 lines are to be read together.

1st: time when all 4 display lines were generated, "---(3)---" for tick 3.

2nd: current state "---((( 18 )))---", non-zero control signals "---[]---", 
non-zero mux selects "---[]---".

3rd: current values of the PC, MAR, MDR, IR, and PSR (last two shown as 
bits, others as hex.)

4th: current values in REG_FILE registers (in hex).

Since the control signals are mostly all set to all zeroes in the version 
of uStore you use as a starting point in your project, nothing is shown in 
the first pair of brackets "---[]---" in Line 2. If some control signal was 
non-zero (ie., equal 1) the name of that signal would appear in the brackets. 
For instance, having figured out that the LD_MAR and LD_PC should be 1 in 
state 18, Joe makes that change in uStore and tests again:


----------------------------(3)----
---((( 18 )))-----[ LD_MAR LD_PC ]----[ ]--
...

The second pair of brackets is for all MUX select control signals. If any 
MUX select signal is non-zero in that state, the signal's name and value will 
appear inside the second pair of brackets.

So, here is the work cycle:
1. Fix something (a wire or bus connection, a control signal setting).
2. Generate the top_rtl_testInstr.v testbench
3. Do "iverilog top_rtl_testInstr.v", and "vvp a.out"
4. Inspect the output to see if the correct registers changed as they 
should have. Go back to 1 if not.

Note that registers capture their input and change their output accordingly 
on the rising edge of the clock signal, if their write-enable "we" is 1. 
LD_MAR is the name of the wire (aka, net) connected to the MAR's "we" input. 
In Joe's case, he checks the MAR's value in state-33 to see if the MAR was 
correctly written into by state-18: he looks at the value of the PC in 
state-18, and checks that that value appears in the MAR in state-33 as 
required by the RTL for state-18: "MAR <== PC".

Note also that only two state changes are shown over the entire 1002 
simulation ticks. The display is only triggered when the state-changes. 
We conclude that the controller repeatedly looped back to state-33, ie., 
after entering state-33, the controller remained in state-33. If we look at 
the LC3's state diagrams in PP, appendix C, we see that state-33 is waiting 
for the memory's ready signal, R. Apparently, it never became a 1. We can 
confirm this by looking at the state display "---((( 33 )))---". If a 
controller input signal is non-zero in some state, that signal will appear 
next to the state number. Those input signals are R, BEN, IR[15:12], INT, and 
PSR[15]. The IR bits are not shown since they already appear in the display 
of the IR's content. Since the display is only triggered when the 
controller's state changes, any signals changing value before the next state 
change will not appear until that next state's display comes out. If state-33 
does receive the R=1 signal sometime after entering state-33, the R signal 
will show up in the next state's display. In this case, state-35:


---((( 35 R )))-----[ ]----[ ]--

However, this display will never appear unless the controller actually moves 
out of state 33. And that will only occur if all the wire connections and 
controls are correct, at least for having the Memory-IO bus generate the 
R=1 signal in state 33.

A final note on wire connections. Some wire or bus connections are missing. 
You can check on connectivity by selecting a device's input or output port 
crosshair. If you have selected it, the icon will change to have a white 
border, and the selected port's crosshair will also appear in white. Any 
wires (busses) connected to that port will also become highlighted in white. 
Zoom out to see all the connections. The highlighting does not go through 
devices though. All the control signals are properly connected, but it's a 
good idea to check nevertheless.