Hi everyone,

I am currently working a simple 8-bit hobby processor design.
I am still in the early phases of designing the processor logic and haven't started on the actual circuit.

Premise: my processor's control unit design was inspired by what Ben Eater has done in his project: basically, the instruction register (IR)'s value is used to address a variable number of EEPROMS which in turn output the control lines that enable the components (in my case, 6 EEPROMs output 48 control lines).

While doing some testing, I saw that the simulator I'm using (Logisim-evolution) briefly showed intermittent error values on the data bus. I investigated some more and saw that the errors only happened during the switch between one microinstruction and the next; furthermore, the errors where only detected when sampling in continuous mode, which means that bus contention only happened during the propagation phase of the simulation and not when the circuit is stabilized.

Basically what I think is happening is that the EEPROMS in the control unit are not updating their values and propagating simultaneously, so when switching from a microinstruction to the next it may happen that one EEPROM and its signals have already been updated to the next state (and so have the components they control) while another EEPROM is still behind, briefly resulting in a "mixed" state where two or more components are enabled to write to the bus during the switch.
I initially shrugged it off as an issue with Logisim, but then I started wondering if it could be an problem when I eventually design and build the hardware, and I think it will.

The EEPROMs I plan to use (AT28C64B) specify a maximum 150ns delay between a change in the address and a the output. Also, the line drivers that prevent components from writing to the data bus, switch from output enabled to floating within 30 ms.
Basically, with this uncertainty in the propagation and with the right control lines placement I think there can be bus contention during control lines switching for a very brief time each transition.

I couldn't find any resources on this particular problem.
Is it going to be an issue?
What can I do to deal with it?

Thanks in advance.

 

It could easily become a real issue. Ripple-thru propagation delay is real. All those microseconds add up.

 

The usual solution is to only act on the outputs once they are stable, either by clocking them into a latch or providing a READY signal to the following logic. The clocked latch is quite a common approach as it allows the next microcode address to be provided and accessed while the previous one is being acted on, so-called pipelining allows a faster solution than an asynchronous one.

 

The usual solution is to only act on the outputs once they are stable, either by clocking them into a latch or providing a READY signal to the following logic. The clocked latch is quite a common approach as it allows the next microcode address to be provided and accessed while the previous one is being acted on, so-called pipelining allows a faster solution than an asynchronous one.

I think you are confusing a single cycle synchronous approach with an asynchronous one.

Pipelining is synchronous approach that is an alternative/enhancement to a single cycle synchronous approach. It gains a throughput advantage by, as you say, starting a new instruction while the prior instruction is still being acted upon in a prior stage. But you can do the same thing with an asynchronous approach and, in general, an asynchronous approach will be faster, lower power, and smaller. The problem is that designing it properly is a much more difficult task than doing a proper design of a synchronous system, so we usually accept the speed, power, and space penalty that comes along with it. But high-end processors have more and more asynchronous sub block within them because the need to have the higher speed, lower power, and smaller real estate justifies the expense of doing the design and verification, since this effort can be amortized over millions upon millions of processors.

 

All digital systems experience propagation delays in their components. These can be mitigated by slowing down clock speeds and allowing for slower components. Conversely, timing becomes more critical as clock frequencies get higher.
In order to maximize clock frequencies while maintaining full accuracy, one has to study switching times with the use of oscilloscope wave forms known as "eye diagrams".



With oscilloscope eye diagrams, one can observe the variability of signal switching times at both rising and falling edges.
The center of the eye indicates the optimum point at which data must be captured in order to achieve zero error rates.

 

Thanks everyone for your input.
Rather than accuracy and errore rates, my main worry was regarding the actual stability of the circuit.

My design features a two-phase clock with two clocks 90° apart.
Control lines switching happens at the rising edge of C1, while data transfer happens at the falling edge of C2, so the signals will be stabilized by then.

To put it simply, what I'm worried about is that what I see as a "red line" in the simulator due to two components briefly outputting different values to the bus while the control lines are propagating will translate (when I actually build the circuit) in a literal shortcircuit due to multiple components being allowed to output to the data bus in this "mixed state" during control lines propagation.

 

Every device that outputs to the bus has to have /CS and /OE control signals. You need to control the timing of these signals so that no two devices can output to the bus at the same time.