Address Registers (3: Bus Timing) - Making an 8 Bit pipelined CPU - Part 4

[@user-zx3zm7bd5i]

I am rewatching this series as I plan to build a CPU for my own. I've also watched Ben Eaters series aigain. I don't think that the timing issue you are describing in this video actually exists, because in the previous video you showed that the carry signal is already on when the counter sits at 15. The reason being that the carry flags are set on the falling edge if I recall correctly. This means that at the rising edge, the carry flags are already set correctly and all counters can be updated at once, meaning their "uncertainty"-time does *not* stack.

[@weirdboyjim]

I may revisit this in the future, this was very early in the development. I may not have explained it well, and I was probably over cautious at the clock rates I actually achieve.

[@RetroEcoChicken]

i like this guy alot more then ben eater because he dosent just skip and heres a prebuilt thing, he shows you how and explains WELL why he does it like this.

[@GORF_EMPIRE]

This stuff is the coolest. I want to do something like this in FPGA. I'm really digging the LED's giving off a laser beam like effect. :D

[@weirdboyjim]

Jump on the discord, there are a few people who are doing similar things on fpga's.

[@GORF_EMPIRE]

@@weirdboyjim Once I get my Linux boot back up. Tried to upgrade to 20.04 and it failed... unfortunately.

[@davidrosset4457]

I am having trouble going with the inverter clock. The 74ls193’s increments then decrements, but with normal clock it works fine. Know what’s wrong?

[@weirdboyjim]

Hmm, that sounds weird. Sounds like you have some noise, make sure the decrement line is pulled high.

[@davidrosset4457]

Thanks, that solved it !

[@davidhand9721]

Sometimes I wonder why chips don't have a "ready" pulse output bit you could plug into the next chip's clock input. That way you could be certain about ordering rather than guessing how far into the cycle you can count on one of these counter outputs.

[@weirdboyjim]

Nice idea, but you would soon run into a problems of different bits of circuit having ready pulse inputs that don't line up.

[@TomStorey96]

Personally I don't think you'd be likely to have an issue with clocking your increment and the latches from the same clock edge. But to be sure, take a look at the setup and hold parameters of the latch inputs. Likely the setup time will be met for the latches because the output of the counters will be stable from the previous increment, and given the latches will be triggered from the clock edge, they will probably latch their inputs quicker than the counters can output a new value. So the question becomes, how quickly do the counters output their new value and is that slower than the hold time for the latches, if it has any. If it is slower then you are golden, if it's faster then you may have a problem, but you could potentially use a tiny capacitor to ever so slightly delay the clock pulse to the counter chips. Or you're into the realm of "overclocking". 😄

[@TomStorey96]

I cant find much data on the LS variants of the chips, but if I use the HC variant datasheet as an example, the '193 has a propagation delay of 11ns in its quickest parameter, and the '574 requires a "typical" hold time of 0ns and a "minimum" of 5ns (tbh Im not quite sure how to interpret that....) but it would seem to suggest to me that the hold time for the '574 is reasonably near zero, and even at its worst it is much shorter than the '193 can propagate a change to its outputs - perhaps twice as long. So I would say that clocking both of them from the same edge would actually be perfectly fine, and you dont need to run them out of phase.

[@weirdboyjim]

Going back to these early videos you'll find a bunch of things that I was less sure on than I am now. I could indeed clock the counters at the same time as the latches. In the circuit as it exists now I clock the latches on the rising edge of the main clock, the increment or decrement return high at the mid point of the cycle. Latching at the start of the cycle allows me to be certain of the address register state thru a memory operation, if I were to clock it at the same time it would work but I wouldn't be able to use that register on the address bus in that cycle. I could defer the increment / decrement to the back half the cycle, that would give me a higher theoretical count rate but that would leave the register output an additional cycle behind.

[@0xABADCAFE]

@@weirdboyjim That's what makes watching it all now for the first time so interesting.

[@genxtech5584]

Does the fact that your counters run at 40Mhz but are being cascaded by 4x means the maximum clock rate is 10Mhz for this part? OR because it's changing on the falling edge and being clocked in on the rising edge you only have 1/2 of that time? That would mean this register can only run about 5Mhz?

[@weirdboyjim]

I’m going to prefix everything I say here with “I am not an expert, I may be wrong about most of this”. Thinking in terms of half the clock rate is right, the count happens on the rising edge halfway thru my cycle, so I have a maximum rate of 20mhz on a single 40mhz part. I’m pretty sure that was a mistake and I could latch the output at the same time, so it gets a full cycle. However the propagation delay for the carry (15ns) is faster than the overall delay (25ns), so the time to settle 4 chips would be 15+15+15+25 = 70ns, our worse case scenario is in a carry ripple all the way down. That works out at 14.28mhz, halved to 7.14mhz if I don’t re-spin the counter registers. So somewhere between the numbers you were looking at.

[@GORF_EMPIRE]

@@weirdboyjim Those numbers, 14.28 and 7.14 mhz are really nice and close to NTSC and PAL pixel clock frequencies. Even more so to NTSC, like really almost dead on.

[@bkahlerventer]

Will it not be easier to use a CLA carry-look-ahead circuit in between each of the carry out and carry in circuits? That will keep the propagation delay more deterministic? Much like the 74F182

[@weirdboyjim]

Depends on your definition of “simpler”. The look ahead carry devices require a “propagates” input which you would need to add circuitry to generate separately for borrow and carry. My estimate is that it would double the number of chips in the register. Additionally I’m not aware of any sources of the 182 (or similar) that are still active parts, I’ve tried to avoid using obsolete parts in the build.

[@bkahlerventer]

@@weirdboyjim understandable

[@johncochran8497]

Just did a little thinking about the ripple carry/borrow between the '193s. Turns out it's easy to do. Just for each carry/borrow between the '193s, use U+C and D+B instead of simply C or B. U = Count up D = Count down B/C = Borrow/Carry. So each 16 bit register would require 6 2 input OR gates, or a total of one and a half 74LS32 chips. But there's no need to use the boost between every chip. Would be reasonable to use the existing ripple carry/borrow on the 2nd chip in the chain, and use the OR speed up on the 3rd and 4th chips, reducing the additional cost to a single '32 chip.

[@KeesJanLogemann]

Just curious: Why didn't you choose for 8-bit synchronous Up/Down counter like 74ALS869? Cost? That's 2 chips instead of 4!

[@weirdboyjim]

A couple of reasons, but my reasons are not necessarily great. My preference was to use commonly available parts that are also available in a wide variety of logic types. 869 seems to be a less common Part that only comes in a limited range of families. In terms of your own circuit design there is definitely scope to use them though.

[@RetroEcoChicken]

one thing i dont understand is why did he not use 2 4 bit counter chips for the jump feature instead? you can basicly just hook the load lines together and it becomes a one button buffer just like the line driver. personally i used those since the line bufferes i ordered are defective.

[@weirdboyjim]

Not sure what your query is. You still need something between the counters and outputting to the bus if it's going to share those lines with other devices.

[@pawelczarnecki7780]

Great stuff James 😁

[@weirdboyjim]

Thanks!

[@jellevanderbeek650]

Hey James! Another question. I've gone ahead and bought a couple of 193 ICs myself. I'm basing my setup on HC instead of LS logic and I'd rather have used a 74HC169, but that IC doesn't seem to be available in HC form. The closest IC is the one you're using: the 193. However, it has asynchronous loads. How are you dealing with loading the register on the rising edge of the clock (as it isn't a synchronous input?). If I look ahead in your playlist, your PCB also doesn't appear to have some edge detection logic on it. We could NAND the clock and load lines together, but that'd still make it level triggered and not positive edge triggered (and causing potential races). Really curious to hear your thoughts!

[@weirdboyjim]

That's an interesting question. The other registers load on the rising edge, so the load line goes low for the first half of the cycle. The 193's don't edge detect, you think about them constantly loading while the parallel load line is active (low). The important difference is that you have to treat the outputs of the 193 as unknown until that line return returns high. In my build this doesn't matter because the outputs from the 193's are latched separately, so the overall register output is never unknown.

[@jellevanderbeek650]

@@weirdboyjim Thanks for the answer. Unfortunately it raises a couple of more questions though :). I really hope you'd like to elaborate! When you say that the load line goes low for the first half of the cycle, what do you mean by that exactly? In Ben Eater's setup, the control logic runs half a cycle out of sync with the main clock so that when control lines are changed, there's enough time (half a cycle) to compensate for any setup times. For example: an output on reg A is enabled, a load on reg B is enabled. Half a cycle later, the edge detection will kick in. The control lines are then always high or low for an entire cycle (and offset by half a cycle). If you have load lines enabled for only half a cycle, how do you avoid racing with either rising or falling edges? Yes, if the load line is not synchronized, it's all about the time when the load line switches back from low to high. But if that point falls exactly on a rising or falling edge of the clock, I don't quite understand how that doesn't cause races (even in your setup). I hope I made sense. Any info is greatly appreciated!

[@crazyboy2006cashier]

@Weirdboyjim Did you ever find a requirement to do count down?

[@weirdboyjim]

The stack pointer uses that all the time! I have used the decrement on Si and Di but I never found a use for it on the program counter.

[@teunschuur7988]

So cool! Thanks!

[@weirdboyjim]

Thank you!