PC Counter

[runningdawg]

     It isn't explicitly stated in the chip's API but are we justified in assuming that the three selectors (inc, reset and load) are mutually exclusive in that a client of the chip is only supposed to select one of them and not 2 or more in any given point in time? And furthermore, in those cases where 2 or 3 are enabled at the same time (or none are enabled), that no action is to be taken, i.e. the chip's state remains unchanged?

[ybakos]

Not necessarily. Functionality really is summed up by the chip specification (see the nested 'if' statements?).

If you're having trouble realizing the PC, note that the order of the if statements and the order of your circuitry are related.

[runningdawg]

Ok I redesigned my circuit to hew closer to the spirit of the chip's specification. I understand that IF statements can be modeled with MUX chips, and that chip input pins have a fan-in of one (and output pins can have unlimited fan-out). I'm currently bogged down because of the fact that the Counter's selection bits retain their state until they are explicitly reset by the chip's client. We obviously don't want the circuit to continue incrementing the value in the register until inc is reset to zero! Back to the drawing board...

[Todun]

Chapter 3 has the remedy to your question. You can use one of the other chips in the chapter to control and recall different states of the counter. Hopefully this helps.

[runningdawg]

Got it. Thanks for the input guys. It's lonely out here doing self-study, but quite stimulating!

[runningdawg]

 

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Tuesday, March 30, 2010 6:39 PM

Subject: Re: PC Counter

Not necessarily. Functionality really is summed up by the chip specification (see the nested 'if' statements?).

If you're having trouble realizing the PC, note that the order of the if statements and the order of your circuitry are related.

 

I've reached another impasse related to the PC, as it is used in the CPU implementation. I am unsure if the control logic we are required to build is supposed to manipulate the inc function of the counter. If I just set this value to 'true', the counter will automatically

increment after each clock cycle until a jump directive is issued. Then it 'skips' a heartbeat before resuming counting upwards, but of course this means it is now out of sync with the program. It seems as though it needs to be goosed to continue counting like it is supposed to. I thought of trying to tie in the jump logic to the control of the pc counter but the problem is the circuit that causes the counter to load a new address retains its state until another ALU operation resets it. So if for example the next operation is a load operation into the A register, jump logic will retain its state and not be very useful in helping to control the pc counter. I looked at the results of the compare file in the test script and it is the value of the pc counter that causes the test to break down. I've kind of thrown my hands up at this point, which is disappointing because otherwise I think I have figured out how to wire everything up.

---

View message @ http://n3.nabble.com/PC-Counter-tp687060p687184.html
To unsubscribe from PC Counter, click here.