TimImplementation of the address path is straightforward based on the previously designed gates.
The first design of the adress path is shown above. A half adder is needed to increment the PC. Since the gates are relatevely fast, I used a ripple carry adder. There are two latches for address and PC respectively. An AOI2 gate is used as multiplexer between PC and external address. The address latch can be loaded with zeros by pulling both control inputs of the MUX to low. This can be used to reset the PC.
The image above shows the design after some optimization to reduce part count. Each slice consists of 12 NAND equivalents and 56 components total. Note that the carry delay was increased to two gates.
Six of the bit slices were combined in a testbench to test the design of the full width datapath. A two phase clock is needed to alternatingly clock both latches. In this setting the circuit is configured to reset the PC and then increment it with each clock cycle.
Output traces of clock, reset and the first two output bits are shown above. Everything works nicely.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Hi Tim,
You might simplify your design even more. Did you consider an LFSR counter for the PC ?
https://en.wikipedia.org/wiki/Linear-feedback_shift_register
At every count, the counter will shift its bits one position. The bit that is shifted in, is an XOR function of two of the outputs. You will not need a carry chain. This is not a binary count sequence, but it is a sequence of distinguishable states. I think the TMS1000 also did that for the program counter.
I noticed that your ALU has the same two instructions (ADD and NOR) as my Kobold design:
https://hackaday.io/project/167605-kobold-k2-risc-ttl-computer
I think you're on the right track !
Are you sure? yes | no
That is an amazingly clever trick.
Are you sure? yes | no
Hi Roelh,
you are right, using an LFSR for the PC could remove some gates. In this case I tried to be faithful to the original MCPU implementation, so I did not consider changing the programmer model. In the CPLD there was no benefit to using an LFSR since the design was constrained by macrocell availability.
To be honest, it's not a truely minimal LTL design but a compromise in usability somewhere. I actually did a radically smaller design in RTL, which I should document next, but it is much less blinky and a pain to program anything for...
LFSRs are really neat and I spent a long time pondering about building a CPU that also uses LFSRs for computation. Unfortunately it is very difficult to use them for anything other than counters. (Well, at least as far as I got, hoping that someone has a neat idea :) )
Are you sure? yes | no