EEPROM Traps! (Combinational logic / TTL Computer microcoding)

EEPROMs are a common way of implementing control logic in custom (TTL) computer architectures. But, there are a few characteristics with EEPROMs that could bite you in the butt if you're not aware of them!
Music by Joystock - www.joystock.org

[@colewyant4271]

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.

[@HalfBurntToast]

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.

[@lmamakos]

There's always a lot of interesting things to learn at the boundary between theory and practice. Very nicely done!

[@altra8911]

"Im Engineerin' my freaking limit, partner!"

[@MatsEngstrom]

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.

[@HalfBurntToast]

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.

[@Yeoman35]

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.

[@HalfBurntToast]

Also, I know I keep saying 'demultiplexer' when I mean to say decoder. Sorry about that.

[@MatsEngstrom]

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

[@HalfBurntToast]

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

[@jrstf]

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.

[@HalfBurntToast]

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.

[@der.Schtefan]

But what if the output latch takes a long time to settle?

[@HalfBurntToast]

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.

[@DeVibe.]

Can't download-> won't watch.