Right now I'll just briefly explain my conceptual understanding of the Program Counter adn the Branch Unit.

The program is a list of instructions numbered "0, 1, 2, 3 . . . " and so forth. So the program counter is basically the indicator for which instruction we're on. This number then corresponds to the Instructions and Operands in the RAM--both of which then send their information to where it needs to go. Then, the clock/switch bounces up one.

We start with the first instruction, "0," which is then sent as the address to the Instruction RAM and the Operand RAM. In the instruction RAM, there is a certain code, let's say we call it "MOV" (that has a particular binary code) that is associated with address "0." The Operand has a value like "5" associated with the address "0." These are then sent their way along the microprocessor. After this is complete, we hit the switch again, so that now the PC is at "1." This is the new address for which the Instruction RAM and Operand RAM pull data from.

However, when we have branches, the program counter cannot just go sequentially from line to the next. Instead, it must be able to load a line number (stored in the Operand RAM with the address of instruction for the branch) for which it should start reading from.

So for a BEQ label, when we get the Z flag, then that line will send the number of the address the Program Counter should now show. So the the Z flag will turn on a "load" in the Program Counter, which will then store the new address we're on, and then begin counting again and proceed with the counting process as described above.

That's all I have for now, feel free to correct me!

-- ReidGinoza - 27 Nov 2005

Exactly right, and a good description of how programs are run. The design question you need to get clear on for the Program Counter is: What is your interface to the rest of the microprocessor?

My thoughts are that you should load the Program Counter from the data bus for a branch, so in other words you've got 8 bits in. To be used in case of a branch. You really don't care where the 8 bits come from.

You should have a few bits telling you whether the instruction is a branch or not, and whether it cares about the Z (conditional or not), and what the Z should be in order to branch (BNE or BEQ).

You also have 8 bits of output that is the Program Counter. These get hooked up to the RAM, as you describe, but you don't really care where those bits go either.

Take a look at the instruction set. I designed the branch opcodes with you in mind. Notice how they say: Is it a branch? Do we care about Z? What does it need to be? I left room in the opcode in case there's another flag (Carry?) that we want to be able to branch on, too. Or maybe we should branch on whether it's light or dark. Hmmm.

By the way, it's not your job to discover that the instruction is a branch. That's the Instruction Decoder's responsibility.

-- JoeHolt - 27 Nov 2005

Update!

I've made progress! I have everything down on my breadboard and just need to test my program counter and branch unit. I'll put up my schematic later, once I draw it in a nice fashion (Joe told me, "Schematics like 90 degree angles" . . . ).

To test the branch unit and program counter, I'll be basically checking my relatively short truth table:

• No branch, therefore the counter should increment
• Branch where Z flag doesn't matter (unconditional branch), therefore counter will load the number on the data bus
• Branch where Z flag does matter and isn't there, there counter will increment
• Branch where Z flag matters and is there, counter will load the number on the data bus

-- ReidGinoza - 01 Dec 2005