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.

Line 1: time when all 4 display lines were generated, 
        "---(3)---" for tick 3.
Line 2: 
       current state "---((( 18 )))---" 
       non-zero control signals "---[]---" 
       non-zero mux selects "---[]---".

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

Line 4: 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. iverilog top_rtl_testInstr.v, vvp a.out
4. inspect the output for the state you are working on. go back to 1.

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.