Behavior of addressM and inM

[ouverson]

Let's say I have a 2 instruction program: I want to write the value of R0 into the DRegister.

Instruction 0: @RO - 0000000000000000
Instruction 1: D=M - 1111110000010000

When instruction 0 is executed the ARegister is "loaded" (by way of a Mux gate) with value 0000000000000000 - as my logic sets the ARegister load bit to 1 when an A-instruction is executed.

When instruction 1 is executed the value of ARegister exits the CPU (via addressM) and enters the Memory (via address).

How (at the same clock cycle) can the value of 0000000000000000 exit the ARegister via addressM, and then send the value of R0 to ALU via inM so that value of RO can be written to DRegister?

[WBahn]

Imagine that you have a really slow clock, or perhaps you have a button that you can press in order to generate exactly one clock cycle.

So reset the PC to 0 and then are sitting there waiting to press your button for the first time. While you are waiting the instruction at ROM address 0 (@0) is on the instruction line and all of your control signals see it and are acting on it. So the muxes and load signals are all sitting there ready to put a 0 into the A register. But at the same time there is some value (we just don't know what it is) already in the A register and that value is sitting there being used as the address line on the RAM and so the value stored in RAM at that address is sitting there on the inM data bus. Depending on what your control logic is doing as far as the A/M mux and the control signals for the ALU, that value may also be affecting the output of the ALU right now. But this doesn't matter because your control signals are NOT enabling writing to the D register or the RAM or anything else. Furthermore, the PC is sitting there waiting to increment the value of its internal counter.

Now you press your button and the value that is already sitting at the input of the A register is loaded into the A register because the load signal to it is already enabled. At the same time, the PC increments and the address lines to the instruction ROM change from 0 to 1 and so the new instruction (D=M) appears on the instruction line. It has no effect on anything else yet because by the time it appears on the instruction bus all of the other action related to the previous instruction that was there has occurred and the rising edge of the clock is too far in the past already for anything to be sensitive to what is there now.

However, the decode logic is combinatorial, so it proceeds to decode the new instruction and configure the various control signals appropriately. Since the A register now has the value 0 stored in it, this appears on the addressM bus and the value stored in RAM[0] appears on the inM bus as fast as it can. At the same time, the decoded instruction is setting the A/M mux to pass the signal on the inM line to the Y input of the ALU and the ALU control signals are being configured to make the output of the ALU equal to the Y input. The output of the ALU is then applied to both the input of the D register and also the input of the A register (through the ALU/inst mux), but while the D register load signal is enabled the A register load signal is not. All of this happens in the time between the of the prior rising clock edge and the next rising clock edge (which hasn't happened yet because you haven't pressed the button again yet). It doesn't happen instantly, but it does happen pretty quickly. Eventually the contents of RAM[0] is sitting at the input of the D register and the load signal on the D register is enabled. As long as you wait long enough for that to all settle out, then when you push the button the next time the contents of RAM[A] will get loaded into D.

The longest the amount of time you have to wait for things to settle down across all of the possible instructions determines the minimum amount of time you have to wait between successive clock pulses, which it turn is the maximum clock rate you can run your machine at.

[ouverson]

I'd like to take this one step at a time (one paragraph at a time) if that's okay.

I'm going to assume that nothing of note is occurring prior to pushing the reset button.

I have a question about initial clocks and PC/ROM behavior: it occurred to me that ROM[0] is at the instruction line for the initial 3 clocks.

PC spec: if (reset[t] == 1) out[t+1] = 0

Clock 0:

I push the reset button...

ROM[0] is on the instruction line.
PC out is 0 / ROM in is 0

Clock 1:

ROM[0] is on the instruction line.
PC out is 0 / ROM in is 0

Clock 2:

ROM[0] is on the instruction line.
PC out is 1 / ROM in is 1

Is this  correct?

[WBahn]

How long are you holding the reset HI for?

If you hold the reset HI starting some time before the first clock but release it some time before the second clock, then before the first clock we don't know what the value of the PC is, after the first clock it will be 0, and after the second clock it will be 1.

If you are asserting the reset synchronously so that it gets asserted as a result of the first clock and deasserted as a result of the second clock, then we won't know what the PC value is either before the first clock or after the first clock (because there hasn't been a rising clock edge WHILE the reset is HI). It will go to 0 after the second clock edge.

[ouverson]

According to the PC spec: if reset[t] == 1) out[t+1] = 0

Therefore, I know that PC out[t+1] will be 0, but what about PC out[t]? Some value must leave PC at [t] - correct?

Thanks so much for the help.

[WBahn]

The spec is written (probably for consistency purposes) from the standpoint of a fully-synchronous system. In that case, the signals at a given time are all interpreted as being the signal at a small amount of time after the rising clock edge that happens at time t.

As for how a particular simulator applies the reset signal, that's up to the people that right the simulator. They could write it so that the reset signal goes HI at t = -1 and LO at t = 0, in which case the PC would be 0 at t=0 and 1 at 1 t=1. But they might simply apply a signal at t=0 and relax it at t=1, in which case the PC would be undefined at t=0 and 0 at t=1.

[ouverson]

I very much appreciate your insight on how the simulator could have been written.

When I load the program into the CPUEmulator and click the "Single Step" button for the first time, the value at ROM address[0] is moved to the ARegister; this is what is communicated when "Program & data flow" animation option is selected. I'll interpret this "data flow" as such:

The value at ROM address[0] enters the instruction line; via the Mux, this value ends up in the ARegister; I make sure the load bit is asserted so that the value in ARegister will be available when I click the "Single Step" button for the second time.

Am I on the right track? If so, I think I'll create a new thread to share my CPU implementation to see if you (or another member) can help me understand what's amiss.

[ouverson]

My CPU implementation passed!

Thank you for your help.