Single stepping with RDY, re-implementing Woz's circuit

[gfoot]

akohlbecker wrote:

On the right, PHI2 is generated from a combination of the input CLK and RDY_IN sampled on the falling edge of CLK_SRC (so 20ns early). The sampling needs to be advanced to give time to the flip flop to propagate. Unfortunately, because the '112 is the only available logic IC I know capable of triggering on the falling edge of the clock, RDY_IN also needs to be inverted, which adds a bit of delay.

Is there some way you can just generate RDY_IN inverted to begin with, to avoid the delay?

I also came across BigDumbDinosaur's thread here - we'd both posted to it so must have read it before, I'm afraid my memory is terrible and I always forget these things. It's worth another look though: viewtopic.php?f=4&t=5229 In particular, if you're already evening-out your clock through a D flip-flop, it looks like an easy way to build in this kind of clock stretching.

[gfoot]

I just turned the computer off and then had another thought - is some variation of the standard two-phase non-overlapping clock circuit useful here?

Standard circuit

Some examples of letting a RDY-like signal stop the clock:

RDY via OR gate forces phase 1 immediately

RDY via AND gate stops in next phase 2

Similar effect but only using NOR gates

[akohlbecker]

Thanks for the suggestions!

I've looked into the NOR circuit in more details, and built a timing diagram for it. Considering the use of an AHC02 and our pseudo-RDY changing during the low phase of the input clock, we get this:

It looks like it works well for stretching. Timing is a bit tricky because if it happens to go low when the source clock is already low, a partial PHI2 low is generated (see fourth cycle above).

So, it needs to only change during the high phase of the source clock. Presumably up to right before the edge. I'm not sure if two logic inputs could have different propagations, ie should RDY be setup some nanoseconds before CLK or is 0ns acceptable

Assuming 0ns is, this is what it looks like from the point of view of Q/PHI2

So it would need to be stable from 17ns before the falling edge of PHI2, until 2ns before the rising edge of PHI2.

Note that this assumes a very worst case of everything taking either the maximum time to propagate, or the minimum, depending on which edge we're at. In the real world there wouldn't be these massive swings on two consecutive edges for the same IC... But the result is still the same, it needs to be stable a bit before and during PHI2 low.

This is where I'm at, I haven't looked in details into the thread you linked yet, but I will keep thinking about this!

[gfoot]

akohlbecker wrote:

So it would need to be stable from 17ns before the falling edge of PHI2, until 2ns before the rising edge of PHI2.

Ah yes, it is not as effective as I thought - I think it handles one transition direction well but not the other.

Quote:

So, it needs to only change during the high phase of the source clock. Presumably up to right before the edge. I'm not sure if two logic inputs could have different propagations, ie should RDY be setup some nanoseconds before CLK or is 0ns acceptable

I have experienced problems due to this in a video circuit where I was ORing together two adjacent counter outputs, and when they changed together in opposite directions (quite common of course for a counter!) it caused small dips in the OR gate output, randomly updating some dependent things that were edge-triggered.

Since then I've been more careful to not rely on that - I use a flipflop after the OR gate, or similar methods, to only sample the state of the OR at a time when its inputs aren't in flux, or create overlap between the signals that I'm ORing. I'm probably overcautious about this now.

[barnacle]

gfoot wrote:

I'm probably overcautious about this now.

I don't think it's even possible to be too overcautious when using combinational logic to drive edge-triggered inputs. And even then, I get burned sometimes.

I think life would have been so much simpler if instead of binary counters, they all used gray codes. At least only one bit changes per transition there... of course, sticking a binary-gray code converter after the counter doesn't work, because of the aforementioned edges...

Neil

[akohlbecker]

gfoot wrote:

I have experienced problems due to this in a video circuit where I was ORing together two adjacent counter outputs, and when they changed together in opposite directions (quite common of course for a counter!) it caused small dips in the OR gate output, randomly updating some dependent things that were edge-triggered.

Since then I've been more careful to not rely on that - I use a flipflop after the OR gate, or similar methods, to only sample the state of the OR at a time when its inputs aren't in flux, or create overlap between the signals that I'm ORing. I'm probably overcautious about this now.

Interesting! Thanks, that's valuable feedback.

[akohlbecker]

I've mentioned earlier my idea to trigger this single-stepping circuit using a hardware breakpoint. The idea behind it is to be able to run the computer at full speed, without the impediment of synchronous tracing, while still being very precise in where to pause the execution.

Using a trio of 74HC688 comparators and 74HC595 shift registers (can be reduced to duos for the 6502), and a bit of logic, it is possible for an external system to set and activate a breakpoint triggered at a specific address.

Here is what that could look like:

During normal execution, /BRK_ENABLE is kept high. When a breakpoint is set, the external system sends it over serial, then it brings /BRK_ENABLE low to enable detection. If the three comparators agree, and breakpoints are enabled, the single stepping circuit is activated.

The '688 propagates in 37ns, and each '32 in 8.5ns, totaling 54ns. With the bank address latch delay, this could be ready around maybe 100ns after the falling edge of the clock. So, unfortunately due to the comparators only existing in the HC family it is not as fast as I would like. A CPLD implementation would be doable quite easily in a small ATF1502 though, or integrated in a larger logic design. Assuming the CPLD already needs the address pins for address decoding, it would only add around 24 flip flops plus 3 control input pins.

[gfoot]

CPLD is probably the tidiest solution but you could also use loads of fast XOR gates. XOR is a relatively complex gate but the propagation delay for AHC series is under 10ns. I guess you then need to OR the outputs together - I don't think wide OR/NOR gates are readily available, but you can invert your compare value so that the required operation is an AND, and you can get fast 8-input NAND gates (74AHC30) which are also under 10ns propagation delay. So all together you'd need 16 XOR gates, two 8-input NAND gates, and a 2-input OR gate like 74AHC32, probably 25-30ns worst case propagation delay I think.