The decoders are a nice touch in the design. I'm guessing that other have done it too, but I really can't recall seeing it before. But being able to use fewer microOps-ROMs by decoding some of the outputs instead of having all control signals individually controllable is really nice. It will limit what the opcodes can do, but with enough planning it apparently is fully viable. Did you have to sacrifice some functionality that you might have wanted to include because of them or was it just "smooth sailing"?
@@MatsEngstrom Oh, it was definitely a major crunch to get everything to fit down to two EEPROMs. Life would be so much easier with three. But, one of my design goals is to use the minimum ROMs possible. That has definitely limited functionality. For example, the computer doesn't have the space to do the 6502-equivilants of JCC or JNZ. So, the assembler creates 'virtual' opcodes during assembly that emulate those opcodes. It also means that some of the control signals can't occur at the same time, such as manually changing the carry flag of the ALU at the same time as component output is being driven to the databus. So, unfortunately, it makes the overall microprograms longer for many opcodes. That said, I think I can still squeeze a few more control signals out of it - assuming the testing goes okay. The control logic and timing is really the only thing holding me back from building a finished version lol. It gets really complex very quickly.
Awesome video. I worked at a defence contractor that had legacy designs using 8 and 16-bit processors like this. By the time I started working there, they had moved on to implementing these systems in FPGAs. Once I understood timing closure and setup/hold times, I took for granted that the compiler tools did all of that thinking for me. After watching this video, I am super grateful that a lot of the analysis is automated. I cannot fathom the amount of time and rework that would be needed to analyze every signal's timing characteristics by hand.
Yeah, it can be rude awakening when working with the discrete components. For small systems like this it's not so bad, especially at the frequency it runs at. But, it's definitely still a job in itself.
When your circuits get big enough and/or fast enough, there's a good chance you switch everything over to synchronous design and just reclock just about everything after it's decoded. In FPGAs, there's a FF sitting after each LUT, so you might as well use it. For particularly wide input functions, breaking up the decode into several stages, and then pipelining around it to account for the delay may be the only way to get the circuit to run at speed reliably.
Wow, great stuff. I'm still extremely new to super low level stuff and electronics in general, and my first instinct when you posed the problem was to just disable the decoder using the opposite clock (eg: load the eeprom address and disable the decoder output on clock high, then enable the decoder output on clock low). Actually splitting the clock into multiple phases though seems way more flexible, not only allowing prefetch like you mentioned, but in theory allowing for other combinations of more granular execution timing. Super elegant solution that I doubt I would have ever come up with.
My bet is he's already at the raggedy edge of clock cycles that board can handle, so while your solution solves the problem theoretically it's a lot harder to pull that off practically. Generally you're gonna have to lose clock cycles in order to get it all working. And who wants to lose speed? That's been my experience anyway when prototyping... The hardest part for me is getting those clock cycles to work correctly with the board and its components at a speed that makes it worth doing. But this guy Yeah, he's insane. Why? Build your own processor... I wish I had the time cuz this would be fun and I get why he's doing it... but at the same time he sounds insane. They're a nickel a piece in any size and speed. But hey, we 're probably gonna need this guy after the great AI wars.
Nice summary of the issues with asynchronous signalling in a system. Perfect length & depth and no annoying extra fluff. I wish all content creators was as succinct as you. But there's still a chance of a latch/FF not actually having the same propagation delay between CP to Qn for all outputs. The datasheets doesn't usually mention any delta or variation figures between the outputs, but I'm sure there are some, and they will also be affected by the capacitive load on the particular output. Granted, the possible glitches (which should be just overlaps and not real glitches unless you have combinatorial logic using multiple outputs from the latch - like a decoder ^__^ ) will be *much* shorter than the outputs taken directly from the ROM. They're probably so short that they won't be interpreted as a valid signal for an Enable / Clr /Latch on the destination ICs anyways.
Thanks! That is a good point about the possible skew of the register outputs. It could result in the decoders briefly fluttering an output it's not supposed to. But, yeah, like you said, the propagation delay/skew is likely so short it wouldn't register as a valid input for the 74HC138s. My development computer currently uses 74HC595's feeding into the decoders and (so far) I haven't had any instabilities. But, to be extra safe, qualifying the critical signals against a clock phase would be enough insurance.
I totally agree. The control logic is by far the most difficult part of designing a microprocessor. You could latch the output of the eeprom in conjunction with a capacitor, but there's no way around its high latency. A state machine driven by a counter or timer performs faster, but adds a lot of complexity, however, it can be simplified with a careful optimization of the control path.
The same issue arises when using FPGAs to replace discrete logic. The logic can be designed so that unexpected changes are suppressed by the order in which things are gated, but FPGAs are usually using a logic LUT which will need some form of clocking once the result has settled.
A LUT doesn’t, by default, need clocking. There’s a D type latch that can be enabled in the output path to make the LUT synchronous, but it is perfectly possible to write completely combinatorial logic using an FPGA (no clock needed). The compiler will tell you what the propagation delay is for the combinatorial parts of your design.
In theory you could use a grey-code sequence for the EPROM address inputs, that way only one line changes at a time. I keep meaning to try it out sometime. Thanks for the video.
I feel like youve missed an important part of the design you'll see with Ben Eater and similar. All registers and anything else that might output data onto the bus or read from the bus uses ics that are clock controlled. So if you something like a 74hc377 buffer for your register, you dont care what those control line are doing during the setup time since there is no clock pulse. Also if youre using the AT28C256 or similar eeprom, your setup time is down to 70ns. So if your breadboard computer clock is less than 10MHZ, you dont have to worry about it.
Ben Eater's computer is still vulnerable to the undefined outputs during address transition. Specifically, the halt line is tied directly into the EEPROM outputs. When the EEPROM changes addresses, the halt line can flutter which results in multiple unwanted clock pulses Which can then lead to registers and counters storing invalid data. Whether or not it happens is down to chance.
This issue pops up in a few places. I've just discovered that during bootup, a lot of the output pins on the ESP32S3 have undefined output states for something like 60ųS, which is definitely enough time to trip up direct hardware. For devices connected via I2C, not a problem; they'll see a garbage packet and ignore it. But direct logic will respond as if those are valid outputs O_O
I have little experience but I thought that with a synchronous circuit the norm was the central clock connects directly to the clock pin of every register. The register then has either an enable and maybe a direction control, but they are just levels that must be setup properly with respect to clock. Or a D or JK flip flop for flags. Now I did work with an asynchronous computer, the PDP-10 KA10 CPU, where all registers are made of set/reset flip flops. In that case, to load a value one must find a short pulse to clear the register, then a later pulse ANDed with the data to be loaded to set the flip flop. The AND function would be built into the module's set inputs since every use case requires it (no ICs in this CPU except for some 8 bit RAM chips to implement 16 36 bit CPU registers, those 72 bytes were a $9000 option, $81,000 in today's dollars, ). Since there is no clock, the machine is driven by pulses that flows through all the delay lines and conditional pulse directors, and if it ever gets lost, the machine ceases. Fun to design but rather parts hungry. If the designer follows the rules, it simply works, except for everything else waiting to bite his butt.
Yeah the trouble with the 74HC273 registers is they don't have any chip enable lines - only a clock and async reset. The clock of the chip is qualified against a system clock phase through a NOR gate. But, qualifying the reset would take extra gates I don't really want to spend if I can help it. I can only imagine how much time and effort went into getting those flip-chip computers operating properly.
@@HalfBurntToast - I'd do everything I could to find a way to not have a clear pin and go with the 74HC377 that replaces clear with enable. I'd forgotten how slim the pickings were back then.
Design rule: Asynchronous signals like output enables or set/reset signals must always be registered ("qualified"?) by a flip-flop if there is any change of spurious transitions.
Okay, so this is why it's really hard to design a working CPU if you aren't already experienced at designing digital logic in general. If you are, you already know that you have to be very disciplined about timing, & timing diagrams are your friend, so none of this stuff will come as a surprise to you. (Citation: I was designing high speed embedded control systems back in the late 80s.)
The latches have a much shorter window where they stabilize. There's still a chance that the skew between the settling bits causes an invalid signal being decoded. But, the window for when that happens is so small it likely won't overcome the hold times needed by the chips. If you want to be extra safe, you could still qualify the outputs against a clock phase.
You’re looking at D type latches here, that sample the input state at (typically) the rising edge of your clock and stabilise their outputs in a few nanoseconds, they work about as fast as the decoders so the decoders don’t have time to react to any transients.
Also, I know I keep saying 'demultiplexer' when I mean to say decoder. Sorry about that.
The decoders are a nice touch in the design. I'm guessing that other have done it too, but I really can't recall seeing it before. But being able to use fewer microOps-ROMs by decoding some of the outputs instead of having all control signals individually controllable is really nice. It will limit what the opcodes can do, but with enough planning it apparently is fully viable. Did you have to sacrifice some functionality that you might have wanted to include because of them or was it just "smooth sailing"?
@@MatsEngstrom Oh, it was definitely a major crunch to get everything to fit down to two EEPROMs. Life would be so much easier with three. But, one of my design goals is to use the minimum ROMs possible. That has definitely limited functionality.
For example, the computer doesn't have the space to do the 6502-equivilants of JCC or JNZ. So, the assembler creates 'virtual' opcodes during assembly that emulate those opcodes. It also means that some of the control signals can't occur at the same time, such as manually changing the carry flag of the ALU at the same time as component output is being driven to the databus. So, unfortunately, it makes the overall microprograms longer for many opcodes. That said, I think I can still squeeze a few more control signals out of it - assuming the testing goes okay.
The control logic and timing is really the only thing holding me back from building a finished version lol. It gets really complex very quickly.
Awesome video.
I worked at a defence contractor that had legacy designs using 8 and 16-bit processors like this. By the time I started working there, they had moved on to implementing these systems in FPGAs. Once I understood timing closure and setup/hold times, I took for granted that the compiler tools did all of that thinking for me. After watching this video, I am super grateful that a lot of the analysis is automated. I cannot fathom the amount of time and rework that would be needed to analyze every signal's timing characteristics by hand.
Yeah, it can be rude awakening when working with the discrete components. For small systems like this it's not so bad, especially at the frequency it runs at. But, it's definitely still a job in itself.
When your circuits get big enough and/or fast enough, there's a good chance you switch everything over to synchronous design and just reclock just about everything after it's decoded. In FPGAs, there's a FF sitting after each LUT, so you might as well use it. For particularly wide input functions, breaking up the decode into several stages, and then pipelining around it to account for the delay may be the only way to get the circuit to run at speed reliably.
Wow, great stuff. I'm still extremely new to super low level stuff and electronics in general, and my first instinct when you posed the problem was to just disable the decoder using the opposite clock (eg: load the eeprom address and disable the decoder output on clock high, then enable the decoder output on clock low). Actually splitting the clock into multiple phases though seems way more flexible, not only allowing prefetch like you mentioned, but in theory allowing for other combinations of more granular execution timing. Super elegant solution that I doubt I would have ever come up with.
My bet is he's already at the raggedy edge of clock cycles that board can handle, so while your solution solves the problem theoretically it's a lot harder to pull that off practically. Generally you're gonna have to lose clock cycles in order to get it all working. And who wants to lose speed?
That's been my experience anyway when prototyping... The hardest part for me is getting those clock cycles to work correctly with the board and its components at a speed that makes it worth doing.
But this guy Yeah, he's insane. Why? Build your own processor... I wish I had the time cuz this would be fun and I get why he's doing it... but at the same time he sounds insane. They're a nickel a piece in any size and speed.
But hey, we 're probably gonna need this guy after the great AI wars.
There's always a lot of interesting things to learn at the boundary between theory and practice. Very nicely done!
"Im Engineerin' my freaking limit, partner!"
Nice summary of the issues with asynchronous signalling in a system. Perfect length & depth and no annoying extra fluff. I wish all content creators was as succinct as you.
But there's still a chance of a latch/FF not actually having the same propagation delay between CP to Qn for all outputs. The datasheets doesn't usually mention any delta or variation figures between the outputs, but I'm sure there are some, and they will also be affected by the capacitive load on the particular output.
Granted, the possible glitches (which should be just overlaps and not real glitches unless you have combinatorial logic using multiple outputs from the latch - like a decoder ^__^ ) will be *much* shorter than the outputs taken directly from the ROM. They're probably so short that they won't be interpreted as a valid signal for an Enable / Clr /Latch on the destination ICs anyways.
Thanks! That is a good point about the possible skew of the register outputs. It could result in the decoders briefly fluttering an output it's not supposed to. But, yeah, like you said, the propagation delay/skew is likely so short it wouldn't register as a valid input for the 74HC138s.
My development computer currently uses 74HC595's feeding into the decoders and (so far) I haven't had any instabilities. But, to be extra safe, qualifying the critical signals against a clock phase would be enough insurance.
I totally agree. The control logic is by far the most difficult part of designing a microprocessor. You could latch the output of the eeprom in conjunction with a capacitor, but there's no way around its high latency. A state machine driven by a counter or timer performs faster, but adds a lot of complexity, however, it can be simplified with a careful optimization of the control path.
This is great. Thank you!
And now I know _why_ an EPROM doesn't necessarily work as an instruction/address decoder. Thanks.
The same issue arises when using FPGAs to replace discrete logic. The logic can be designed so that unexpected changes are suppressed by the order in which things are gated, but FPGAs are usually using a logic LUT which will need some form of clocking once the result has settled.
A LUT doesn’t, by default, need clocking. There’s a D type latch that can be enabled in the output path to make the LUT synchronous, but it is perfectly possible to write completely combinatorial logic using an FPGA (no clock needed). The compiler will tell you what the propagation delay is for the combinatorial parts of your design.
In theory you could use a grey-code sequence for the EPROM address inputs, that way only one line changes at a time. I keep meaning to try it out sometime. Thanks for the video.
I feel like youve missed an important part of the design you'll see with Ben Eater and similar. All registers and anything else that might output data onto the bus or read from the bus uses ics that are clock controlled. So if you something like a 74hc377 buffer for your register, you dont care what those control line are doing during the setup time since there is no clock pulse. Also if youre using the AT28C256 or similar eeprom, your setup time is down to 70ns. So if your breadboard computer clock is less than 10MHZ, you dont have to worry about it.
Ben Eater's computer is still vulnerable to the undefined outputs during address transition. Specifically, the halt line is tied directly into the EEPROM outputs. When the EEPROM changes addresses, the halt line can flutter which results in multiple unwanted clock pulses Which can then lead to registers and counters storing invalid data. Whether or not it happens is down to chance.
This issue pops up in a few places. I've just discovered that during bootup, a lot of the output pins on the ESP32S3 have undefined output states for something like 60ųS, which is definitely enough time to trip up direct hardware.
For devices connected via I2C, not a problem; they'll see a garbage packet and ignore it. But direct logic will respond as if those are valid outputs O_O
I have little experience but I thought that with a synchronous circuit the norm was the central clock connects directly to the clock pin of every register. The register then has either an enable and maybe a direction control, but they are just levels that must be setup properly with respect to clock. Or a D or JK flip flop for flags.
Now I did work with an asynchronous computer, the PDP-10 KA10 CPU, where all registers are made of set/reset flip flops. In that case, to load a value one must find a short pulse to clear the register, then a later pulse ANDed with the data to be loaded to set the flip flop. The AND function would be built into the module's set inputs since every use case requires it (no ICs in this CPU except for some 8 bit RAM chips to implement 16 36 bit CPU registers, those 72 bytes were a $9000 option, $81,000 in today's dollars, ). Since there is no clock, the machine is driven by pulses that flows through all the delay lines and conditional pulse directors, and if it ever gets lost, the machine ceases. Fun to design but rather parts hungry. If the designer follows the rules, it simply works, except for everything else waiting to bite his butt.
Yeah the trouble with the 74HC273 registers is they don't have any chip enable lines - only a clock and async reset. The clock of the chip is qualified against a system clock phase through a NOR gate. But, qualifying the reset would take extra gates I don't really want to spend if I can help it.
I can only imagine how much time and effort went into getting those flip-chip computers operating properly.
@@HalfBurntToast - I'd do everything I could to find a way to not have a clear pin and go with the 74HC377 that replaces clear with enable. I'd forgotten how slim the pickings were back then.
Design rule: Asynchronous signals like output enables or set/reset signals must always be registered ("qualified"?) by a flip-flop if there is any change of spurious transitions.
Thank you
Okay, so this is why it's really hard to design a working CPU if you aren't already experienced at designing digital logic in general. If you are, you already know that you have to be very disciplined about timing, & timing diagrams are your friend, so none of this stuff will come as a surprise to you.
(Citation: I was designing high speed embedded control systems back in the late 80s.)
? and when the E2PROM does a page write? I don't quite get why using one here anyway.
I recognize you are using KiCad for your board design, but I'm curious about what you are using for your logic simulator?
Logisim Evolution
can i know what is the simulator used in video??
Logisim Evolution and CircuitJS
@@HalfBurntToast thank you sir
But what if the output latch takes a long time to settle?
The latches have a much shorter window where they stabilize. There's still a chance that the skew between the settling bits causes an invalid signal being decoded. But, the window for when that happens is so small it likely won't overcome the hold times needed by the chips. If you want to be extra safe, you could still qualify the outputs against a clock phase.
You’re looking at D type latches here, that sample the input state at (typically) the rising edge of your clock and stabilise their outputs in a few nanoseconds, they work about as fast as the decoders so the decoders don’t have time to react to any transients.
Sample the outputs of the EEPROM, all of them
Bad design!!! You can add a register at the output of the eeprom... Your design should be synchronous ONLY!!!
You didn't get the idea
3:01 that's why you use an output buffer / latch ... are ok that's where you where going