The previous section describes each of the instructions of Triscuit. Let's be a little more specific about how these instructions are executed.
The first thing that must happen is that the instruction must be fetched from memory so that the processor knows what instruction is being executed. The Program Counter is a register that holds the address of the instruction that is about to be executed. So, the first thing Triscuit does is put the Program Counter (PC) value on the bus to the memory. The memory sees the address and responds with the data that are stored in that address of the memory. That is, it sends the instruction back to Triscuit on Triscuit's data-in lines. As an aside, we are not actually going to be building a memory for this machine. Instead, the address value will go to lights so we can see what address you're looking at, and the data from memory will be a bank of switches so you can send back the value that would have been sent back if there were actually a memory. This is a little cumbersome, but it's easier than building a memory at this point.
Once the instruction comes back from the memory, it is stored in a register inside Triscuit called the Instruction Register (IR). This is so Triscuit's state machine can refer to this instruction when it's deciding what to do next.
Let's say that instruction was an ADD instruction. In that case the state machine knows that it must get the data to add from the next memory location. So, it must increment the value in the PC by one so the PC points to the next memory location. I suggest you use a counter to build the PC as explained later. If you do, then your state machine will enter a state where the counter is enabled to count so that on the next clock edge the PC counts up by one. When you have the new PC value, you send that to the memory over the bus (really you aren't ``sending'' anything, the PC output is connected to the bus so the memory always sees it. A real bus has a more complicated protocol, but why complicate things?). The memory sees the address and responds (after some propagation delay) with the data to add. Because Triscuit is an accumulator machine, all of the operations use the accumulator as one of the operands. So, you have an adder in the datapath (more on this later) with one of the inputs to the adder coming from the data-in lines, and the other from the accumulator register. Your state machine is now in a state where the add/sub control is set to add (remember Lab 6!), you have the data to add (it just came back from memory, or in our case switches).
The next state your state machine enters is a state where the accumulator is enabled to load. That is, your state machine generates a signal called LD-ACC that goes to your accumulator register. This signal causes the output of the adder to be loaded into the accumulator register.
This completes the execution of the ADD instruction. You have fetched an instruction from memory, decoded is to discover that it is an ADD instruction (your state machine looks at the bits in the IR and goes to a different state based on the value of those bits), incremented the PC again, fetched the value to be added, set up the adder to do an add, and latched the value into the accumulator register. All of this action is controlled by the state machine asserting signals in different states to control the action in the data path.
After all this, you need to increment the PC again so that you can fetch the next instruction from memory and start all over again. This repeats forever as Triscuit executes the instructions that make up the program. (Remember that the ``memory'' is actually switches and lights, but they model what a static RAM chip would be doing if you had one)