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?
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...
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.