Can TTL computer microcode be glitchy? - Page 1
Forum section: electronics / projects

author: rea5245
author_rank: Frequent Contributor
timestamp: October 08, 2022, 02:42:12 pm
content: I'm working on a TTL computer. It will be driven by microcode: a big EEPROM whose address lines are the op-code and a cycle counter, and the data outputs drive clocks for latches, R/~W memory signals, counters, etc.The EEPROM's output enable and chip select will always be asserted, so I'm concerned that when the address lines change, the data outputs could be glitchy, e.g. if some random memory location gets accessed briefly as the address pins change.I can imagine a solution: put a latch on the the data pins and clock it with a signal that briefly lags the changes to the address pins.But none of the TTL computer designs I've looked at have that. And yet they work fine.Am I worrying about a problem that's just not going to happen? And if it doesn't happen, I'm a little surprised. Why doesn't it happen? Has Murphy's Law been repealed?Thank you.

author: Benta
author_rank: Super Contributor
timestamp: October 08, 2022, 03:45:39 pm
content: Depends on your design style.If it's a pure synchronous design, it should be OK.But if you use naughty stuff like ripple counters, gated clocks etc. all bets are off.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 04:49:40 pm
content: Quote from: rea5245 on October 08, 2022, 02:42:12 pmGood luck and have fun. You will learn a lot.You will be fine provided:it is a synchronous clocked finite state machine (FSM)you have good signal integrity when the FSM clocksthe power supply doesn't have any significant glitchesall signals meet the setup and hold timesThere are considerations that derive from those points, but the points above are the essentials, e.g.usually the hold time is a trickier problem than the setup timebeware ground bounce in TTL ics with many outputs and power pins in the pessimal place of diagonally opposite cornersif you use solderless breadboards, be prepared to spend more time debugging the breadboards and (inductive) wires than you spend debugging your designYou ought to be aware of the AMD2900 (not 29000) family of devices, together with the excellent book trafitionally referred to as "Mick and Brick" after the authors' surnames

author: rea5245
author_rank: Frequent Contributor
timestamp: October 08, 2022, 04:53:58 pm
content: Quote from: tggzzz on October 08, 2022, 04:49:40 pmAh, but isn't setup and hold time the problem?Since the chip select and output enable are always asserted, I'll be reading and using the data output before the setup and hold times have elapsed.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 05:14:50 pm
content: Quote from: rea5245 on October 08, 2022, 04:53:58 pmThat doesn't make sense.You need to be clear about how to implement an FSM, and to distinguish between which element's setup and hold time you are referring to. hint: "state" implies flip flops

author: rea5245
author_rank: Frequent Contributor
timestamp: October 08, 2022, 05:33:33 pm
content: Quote from: tggzzz on October 08, 2022, 05:14:50 pmIn timing diagrams, an EEPROM's address lines need to be valid for a certain period of time before the data is valid. Before that time, the state of the data lines in undefined.So let's say the cycle counter is 0, so the EEPROM's address lines are 0x0000, and the data lines have the contents of memory location 0.Then the counter changes to 1 and the EEPROM's address lines go to 0x0001. After a certain period of time, the data lines will have the contents of memory location 1.But before then, aren't the data lines' states undefined? So couldn't they be anything? That would wreak havoc.

author: pcprogrammer
author_rank: Super Contributor
timestamp: October 08, 2022, 05:36:04 pm
content: What clock speed are you aiming at?Having the eprom always enabled should not be a problem when there is enough time between the clock edges your state machine steps on. The eprom might output different sets of data on the changing of the address lines, but once the address lines are stable the data lines will be stable soon after. This of course depends on the specifications of the eprom.If your logic connected to the eprom data lines is not clocked, then yes it could cause problems. It all depends on the design you are making, so it is hard to say yee or nee on if it will cause problems or not.Setup and hold times have more to do with the clocking of flip flops. The data input needs to be stable so long before the edge of the clock and remain stable so long after the edge of the clock.

author: rea5245
author_rank: Frequent Contributor
timestamp: October 08, 2022, 05:55:06 pm
content: Quote from: pcprogrammer on October 08, 2022, 05:36:04 pmSo let's say my Program Counter is implemented with counters that increment on the rising edge of a clock. It sounds like the EEPROM data line can't be directly wired to that counter clock.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 06:01:07 pm
content: Quote from: rea5245 on October 08, 2022, 05:33:33 pmI don't know whatyoumean by a "cycle counter", nor whether it is only part of your thought processes or whether there would be one in your implementation.The ROM doesn't have a setup and hold time; it has a propagation time.You could, in theory, use a ROM in the way you are hinting. It would be an unclocked FSM, i.e. an asynchronous FSM. There are solid theoretical reasons why asynchronous FSMs aren't used at the level you are considering. Asynchronous FSMs are used to implement flip flops and some relatively advanced concepts that aren't relevant here.Your first conceptual design should be something simple, not a computer. I've frequently asked job interviewees for several ways in which they could implement a traffic lights controller. There is no single right answer, but their responses indicate a lot about their thought processes.So, how would you use a ROM to implement a traffic lights controller? Start simple, then add an input that indicates a waiting car has been detected.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 06:05:42 pm
content: Quote from: rea5245 on October 08, 2022, 05:55:06 pmCorrect.Such a clock should come directly from an oscillator that is constantly running, with no gating between the oscillator and the clock inputs.As I said, find out and understand basic implementations of FSMs (a computer is, in a very real sense, merely a glorified very complex FSM).

author: jmelson
author_rank: Super Contributor
timestamp: October 08, 2022, 06:05:59 pm
content: Quote from: rea5245 on October 08, 2022, 05:33:33 pmYes, all true. That is why ANY signal that comes out of the EPROM data pins needs to end up in some clocked logic. So, if the EPROM outputs go to the function select of an ALU, then the output of the ALU must go to FFs that are clocked at a reasonable time later than the address of the EPROM changes. You can accomplish this by having all FFs in the machine clocked by one single clock that is slow enough, or possibly by multi-phase clocks that have the right delays.Jon

author: jmelson
author_rank: Super Contributor
timestamp: October 08, 2022, 06:08:54 pm
content: Quote from: rea5245 on October 08, 2022, 05:55:06 pmRight, but pretty much all TTL counter chips have a clock enable input. You could wire the data line to the clock enable, as long as you study the setup and hold time requirements of the counter chip.

author: pcprogrammer
author_rank: Super Contributor
timestamp: October 08, 2022, 06:32:36 pm
content: Quote from: rea5245 on October 08, 2022, 02:42:12 pmThe data lines should not drive clocks directly. Think of it this way. You have one clock that runs your processor. Lets say this is a 1MHz clock. On this clock you fetch an instruction from memory. Then this instruction needs to be decoded into actions, for which you use the microcode in your ROM. To speed this part up you use another clock of lets say 10MHz, giving you 10 steps in between the 1MHz CPU clock. (These need to be synchronized of course) On each of these clocks you perform an action based on the microcode. So the microcode indicates, load the ALU A register, then this action is performed on the clock edge, and in the mean time you step to the following microcode. Etc. You can also use a clock with multiple phases. (0 degree, 45 degree, 90 degree, 135 degree, etc) This gives multiple moments in time to do things.So bottom line, the data lines make enable signals, not clock signals.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 07:20:37 pm
content: Quote from: jmelson on October 08, 2022, 06:08:54 pmTo save the OP some grief, I'll point out that "clock enable" doesnotmean a gate in the clock line.To use a pseudocode, the implementation of a counter with enable might be something likeCode:on clock rising edge if enable is true thennext state <- current state + 1elsenext state <- current stateIf the counter is a processors program counter, then an unconditional relative branch could be implemented by replacing "one" with the displacement specified in the instruction.Code:if instruction is a relative branch thendelta = offset specified in instructionelsedelta = 1on clock rising edge if enable is true thennext state <- current state + deltaelsenext state <- current stateI expect the generalisation to a conditional branch isn't too difficult

author: Benta
author_rank: Super Contributor
timestamp: October 08, 2022, 07:48:15 pm
content: I have a feeling that some basic knowledge of synchronous design and FSMs is missing for the OP.Highly recommended read:William I. Fletcher, "An Engineering Approach to Digital Design".40 years old, but that's of no consequence. The principles haven't changed. You'll probably find a used copy for $5...10.It was the absolute "bible" in my university days, I still use it.

author: tggzzz
author_rank: Super Contributor
timestamp: October 08, 2022, 10:43:08 pm
content: Quote from: Benta on October 08, 2022, 07:48:15 pmOooh! That was and is one of my favourites too!And I agree about the OP's lack of basic concepts. I've provided moreandless subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no pointusspending timepoorlyduplicating what's available elsewhere!

author: rea5245
author_rank: Frequent Contributor
timestamp: October 08, 2022, 11:06:21 pm
content: Quote from: tggzzz on October 08, 2022, 10:43:08 pmGosh, I hope I'm not as stupid as I look!I understand the answer that the microcode signals need to be enables and not clocks. I think that answers my question. I'd like to think that the fact that I anticipated a problem with my design, shows I'm not totally ignorant.Have I betrayed ignorance in other ways? It's possible I don't know what I don't know. :-(

author: Benta
author_rank: Super Contributor
timestamp: October 08, 2022, 11:19:13 pm
content: Quote from: tggzzz on October 08, 2022, 10:43:08 pmDon't be harsh here.I find it great that someone has the courage to build this kind of thing, and I applaud it.Some basic rules to lay the ground:1: everything should be clocked by the same clock signal (or synchronized multiples thereof). Other clock manipulation is forbidden.2 functionality is done only by manipulating control and data signals.Synchronous design 101 in two sentences.As an aside: an EEPROM is nothing other than a big array of combinatorial gates = asynchronous.

author: Benta
author_rank: Super Contributor
timestamp: October 08, 2022, 11:25:57 pm
content: Quote from: rea5245 on October 08, 2022, 11:06:21 pmOur posts seem to have crossed each other. It happens.Don't be timid, I like your project. Synchronous design is actually there to reduce all problems to setup/hold times. If your EEPROM is not triggering anything (it shouldn't), then you're fine.

author: fourfathom
author_rank: Super Contributor
timestamp: October 09, 2022, 12:02:30 am
content: Quote from: Benta on October 08, 2022, 11:25:57 pmAnd clock skew. But unless the skew is *really* bad it shouldn't be a problem with this type of design. Do be careful about clock fanout and buffering though.

author: tggzzz
author_rank: Super Contributor
timestamp: October 09, 2022, 12:18:09 am
content: Quote from: Benta on October 08, 2022, 11:19:13 pmI entirely agree - and said as much in my reply #2, "Good luck and have fun. You will learn a lot."But some of the responses have dampenedmyenthusiasm for helping.

author: bson
author_rank: Unknown
timestamp: October 10, 2022, 07:50:24 pm
content: Quote from: rea5245 on October 08, 2022, 05:55:06 pmIt used to be common practice to implement a multi-phase clock, where the same clock is delayed in multiple stages. Sometimes it's just the leading edge that's shifted while the trailing edges are all synchronous, or they might be grouped so various phases have synchronized trailing edges. The first phase could be to clock your state number register, the second to clock the EEPROM read, the third is the EEPROM output hold time, and so on. Either it's done by skewing the master clock, or by implementing M states so that each step always takes fixed number of cycles. It amounts to pretty much the same, although multi-phase clocks are easier to optimize and only need a single clock in. The internal clock generator becomes more complex.Terminology is also important. An oscillator produces an analog waveform; a clock is a periodic pulse train. The latter can be generated from the former, but they're not the same thing.