Can TTL computer microcode be glitchy?

[rea5245]

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.

[Benta]

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.

[tggzzz]

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.

Good 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 clocks
• the power supply doesn't have any significant glitches
• all signals meet the setup and hold times

There 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 time
• beware ground bounce in TTL ics with many outputs and power pins in the pessimal place of diagonally opposite corners
• if you use solderless breadboards, be prepared to spend more time debugging the breadboards and (inductive) wires than you spend debugging your design

You 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

[rea5245]

You will be fine provided:

• all signals meet the setup and hold times

Ah, 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.

[tggzzz]

You will be fine provided:

• all signals meet the setup and hold times

Ah, 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.

That doesn't make sense.

You need to be clear about how to implement an FSM[1], and to distinguish between which element's setup and hold time you are referring to.

[1] hint: "state" implies flip flops

[rea5245]

You need to be clear about how to implement an FSM[1], and to distinguish between which element's setup and hold time you are referring to.

[1] hint: "state" implies flip flops

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

[pcprogrammer]

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.

[rea5245]

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.

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

[tggzzz]

You need to be clear about how to implement an FSM[1], and to distinguish between which element's setup and hold time you are referring to.

[1] hint: "state" implies flip flops

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

I don't know what you mean 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.

[tggzzz]

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.

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

Correct.

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

[jmelson]

You need to be clear about how to implement an FSM[1], and to distinguish between which element's setup and hold time you are referring to.

[1] hint: "state" implies flip flops

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

Yes, 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

[jmelson]

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.

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

Right, 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.

[pcprogrammer]

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

[tggzzz]

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.

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

Right, 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.

To save the OP some grief, I'll point out that "clock enable" does not mean a gate in the clock line.

To use a pseudocode, the implementation of a counter with enable might be something like

Code: [Select]

on clock rising edge if enable is true then
   next state <- current state +  1
else
   next state <- current state

If 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: [Select]

if instruction is a relative branch then 
   delta = offset specified in instruction
else
   delta = 1

on clock rising edge if enable is true then
   next state <- current state + delta
else
   next state <- current state

I expect the generalisation to a conditional branch isn't too difficult

[Benta]

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.

[tggzzz]

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.

Oooh! That was and is one of my favourites too!

And I agree about the OP's lack of basic concepts. I've provided more and less subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no point us spending time poorly duplicating what's available elsewhere!

[rea5245]

And I agree about the OP's lack of basic concepts. I've provided more and less subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no point us spending time poorly duplicating what's available elsewhere!

Gosh, 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. :-(

[Benta]

And I agree about the OP's lack of basic concepts. I've provided more and less subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no point us spending time poorly duplicating what's available elsewhere!

Don'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.

[Benta]

And I agree about the OP's lack of basic concepts. I've provided more and less subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no point us spending time poorly duplicating what's available elsewhere!

Gosh, 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. :-(

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

[fourfathom]

Synchronous design is actually there to reduce all problems to setup/hold times.

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

[tggzzz]

And I agree about the OP's lack of basic concepts. I've provided more and less subtle hints to the right direction; we'll see if he takes any notice. If not, then there's no point us spending time poorly duplicating what's available elsewhere!

Don't be harsh here.
I find it great that someone has the courage to build this kind of thing, and I applaud it.

I 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 dampened my enthusiasm for helping.

[bson]

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

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