Falcon clock patch investigation 2022

General discussions or ideas about hardware.
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Falcon clock patch investigation 2022

Post by exxos »

I started investigating this again because of talks with @Steve about his Falcon having some minor FPU problems despite having a clock patch installed. Also the Falcon clock issues has never been properly documented anywhere to my knowledge. So I thought I would do a quick overview of all these issues.

It is actually interesting because the FPU and SDMA share the same physical clock trace on the Falcon motherboard. Generally when you mess with the SDMA clock end, you inherently change the FPU clock behaviour as well. Though I think the FPU clock end never gets the attention like the SDMA end of the signal does. Unfortunately when you terminate the SDMA clock, you also effect the clock signal on the FPU which can be suffering in logic high voltage switch can lead to FPU issues.

First let's take a look at what the actual problem is to start with.

The problems start because of a weak clock drive from the combel and how the clocks are distributed across the board.

falcon_clock.PNG

The left side (CPUCLK) comes from the output of the Combel (normally via a resistor as well) which drives the 3 main clocks via 3x 33R resistors. It is basically standard practice to have the series resistance to help stop oscillations / ringing etc. Generally this is a good thing. Problem is, when you drive clocks from the same source they actually interfere with each other because of varying reflections from each other's traces. If one track has a lot of noise, it will backfeed the other clock lines as they are all wired together via the 33R resistors. It can even generate harmonics which further compound the issue. The problem is also compounded by Atari's very bad routing of the entire motherboard which has many "no no unnecessary right angle tracks", which increase the impedances of the tracks and make ringing even worse.

The analogy is, if you poured a bucket of water into a long guttering channel which is closed at the both ends for example. The flow of water will travel from the source (bucket) to the opposite end. When it does , the water will bounce back (reflect) from the opposite end and cause a ripple to flow back towards the source.

As I do not have a stock Falcon anymore without the clock patch. I had to do a simulation of the 3 clock signals and what one would basically look like under such a condition.

chaoswave.PNG

The waveform should ideally look like a square wave and not the disaster as illustrated above. If the Falcon were a real bird, we would probably just shoot it and put it out of its misery :lol:

Now enters the "classic" clock patch which the majority of clock patches are based upon. The original clock patch was to just simply fit a 74F04 inverter which can provide a good output to drive the clocks Individually. Aside from the combined clock of the FPU & SDMA that is.

It's worth noting that the Phantom clock patch uses a separate wire for the SDMA clock and is driven via slow gates on a separate IC. The SDMA should get a better clock being on its own separate wire. It is still a long distance away which is still going to cause some with ringing, though maybe not as much as with the original track. The FPU clock will still suffer from the long traces, but again, likely not as much, as the SDMA clock is decoupled from the track.

classic.jpg

This separates the clocks and buffers them individually with a higher current driving signal. It does, however, have the side effect of increasing the ringing problems on the clock lines due to higher output current.

Take the analysis of such a clock patch on the FPU clock.

fpu.png

What we see here is a overshoot of over 8 volts (should be 5volts) and a undershoot of almost 3Volts. This can indeed be extremely damaging to connected chips.

Similarly on the SDMA end of the trace we have a even bigger problem.

sdma.png

Generally this ringing & over/undershoot, which I'll just call "noise" from here on out, is clamped by adding a small value capacitor around 100pF value or clamping it with a low value resistor. But it generally does not fully solve the problems and can result in a lower voltage clock signal. This can indeed greatly help the the SDMA clock end of the trace, but the FPU end will likely end up at a much lower voltage and can even cause FPU malfunctions.

Another problem which I have witnessed on some Falcons is that the logic low level on the SDMA clock is basically dependent on the undershoot of the signal rather than the signal's actual logic low level. The undershoot is generally on the order of 5-10ns and does not stay low long enough for the SDMA to register correctly a logic low level. The later revisions of the exxos V2 clock patch solve this problem by re-biasing the voltage levels so that the undershoot is actually undershoot from 0 volts, as it is supposed to be. The logic low level is thus corrected.

You can actually end up with something like 2v DC offset between the clock source and destination. So if the "logic low" is 2v, you're not at a logic low at all. So when it's crowbarred with a very low resistors such as 47R, it's literally forcing the DC offset down to more like 1V and "mostly" the voltage swing is high enough to still push a logic high over 2v. Basically it's sacrificing logic high voltage for more logic low voltage, while limiting the clock's peak to peak voltage. Not good basically!

However, on my two Falcons, 47R clamps the clock down to more like 0.5v (logic high!) and that's not enough by far, hence then my Falcon won't boot as its SDMA clock is basically low all the time.

So while low values such as 47R are classified as a termination resistor, which is true, it is actually crowbarring the DC offset of the clock line back down towards "normal" logic levels. It also concerns me that 47R by itself could draw up to 100mA! I seriously doubt the Combel could push that current by itself or various buffer/inverter ICs. Hence why I have been recommending for years that such a low value is simply not used.

So the natural progression of the clock patch is to add a small series resistance of generally around 33R, to the clock lines to eliminate the noise and basically cleanup the clock signals.

For example a value of 22R limits the noise as illustrated below.


FPU clock via 22R.

fpures.png

SDMA clock via 22R.
sdmares.png

The exxos V2 patch has suitable resistors so the noise is reduced to levels as illustrated below on the SDMA clock.

f2.png
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Falcon clock patch investigation 2022

Post by exxos »

Enter the exxos Falcon clock patch version 4.

NOTE - Information here-on-in is currently based upon version 4 prototype. Any modifications done to the Falcon are only relevant to the exxos clock patch V4 series.

V4 clock patch is a redesign and comprises two parts. While the exxos clock patch V2 series had an option for a SDMA delay to match the Phantom bus accelerator delay, it was still driving the FPU from the same SDMA clock which is not ideal but generally works for 99% of people. So I wanted to add more variation of delays to improve the signals of the SDMA and FPU clocks Individually.

Part 1: - For stock machines.

V4_PART1.JPG

Looks generally familiar as most classic clock patches do. It fits the same way as the V2 but now the board includes separate noise immune buffers which have a higher output voltage drive than the original clock patches do with the 74F04 inverter. A side effect of this is that there are no longer any "free" inverters to mimic the Phantom delay to the SDMA. This is where Part 2 of the V4 clock patch comes into play which is explained later.

At this point you do not necessarily need the part 2 board If you are just running a stock Falcon. You can cut the "bootleg trace" near the SDMA and insert a 68R resistor across the now cut track. Then to the right-hand side closest to the SDMA, connect a 100pF capacitor to the Ajax GND pin.

This cleans up the SDMA clock which now looks like below.

sdma68r.png

Previously it would look like this (This is including the FPU 100pF added in the steps below.)

sdmav4.png

The FPU clock needs 100pF added which has to be done on the bottom of the Falcon motherboard as illustrated below.

IMG_0040.JPG
IMG_0042.JPG

The FPU clock now looks like this.

fpuv4.png

Part 2: - For experimenters with bus speeders.

IMG_0034.JPG

This part fits on top of the Ajax chip and two pins are soldered for power. This board has noise immune buffers which clean up the signal from the SDMA trace and allow the option of various delays in 10ns increments for experimentation with bus speeders.

The bootleg trace gets cut. The left-hand side of the trace goes to the input of the SDMA buffer board on the left. The right-hand side of the cut track (SDMA side) goes to one of the pads on the top of the buffer board. These are basically in 10ns steps. Technically the first step is about 5ns due to buffer delays. But on the final revision board it will be classified as 0ns.

So what the hell does all this mean?

What we have done is create a new clock buffer board with higher output capabilities and better noise immunity. This still drives the FPU clock directly, but now is terminated with a 100pF capacitor. Any "noise" reflected back from the SDMA trace is basically snubbed out by the patch board. Any noise which is heading towards the FPU clock is snubbed out by the 100pF on the FPU clock anyway.

There is no need anymore to route a separate SDMA clock wire like on the phantom clock patch. It was part of my design goal to make use of the original SDMA trace and not using a separate wire. Noise on the SDMA clock is minimised because we are no longer driving the SDMA clock directly from the clock patch board. The Falcon's clock traces and related issues become basically irrelevant. Any noise present at this point will be snubbed out by the buffer board on top of the AJAX. The SDMA will get the most noise-free and stable clock possible due to it being driven locally.
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Falcon clock patch investigation 2022

Post by exxos »

Some more investigations due to what is "seen" on the buffer end of the clock patch. Mostly just out of curiosity more than anything.

NOTE: The clock buffer output goes via a 22R resistor and all measurements are taken AFTER the resistor. Measurements were all done with a X10 probe. X1 is not used due to limited bandwidth and additional capacitance which would be tainting the results. The probe was calibrated before the tests as well. There may be some errors in measurement still, i.e. the real under/overshoot is likely a little less than is seen. But for these quick experiments I am not to fussed anyway. Dave Jones has a great video on scope probes if anyone's interested in this stuff.

OK so I did a "worst case" grounding test and a "best case" test.

The worst case grounding is this.

bbbbbbb.png

Best case:

IMG_0047.JPG
aaaaaaaa.png

In the above test the ground lead is removed from the scope probe and a short wire is used instead which goes directly to the FPU 0v pin. Only about 5% difference. Good enough margin for error for the test I wanted to do anyway.

Again if anyone's interested, Texas Instruments has a very good article on probing problems.


So let's just get on with it :)

With the 100pF on the bottom of the FPU clock, it actually gives this waveform on the actual clock patch board itself.The FPU clock is perfectly fine still.

forig.png

I have seen such a "glitch" On the rise and fall before, when building digital power amplifiers, called "Miller plateau". Though in the case of transmission lines, it seems to be a side effect of the capacitor charging. When charging, its varying impedances cause a negative reflection which causes the glitches in the rise and fall part of the waveform. So I thought I would do some experiments with varying "termination" styles to see if I could improve on anything.

Series termination is already explained in the post above where simply a low value resistor of typically 22R is used in series with the track to limit the reflections.

Parallel termination is already explained above, with a capacitor "shunt". Its impedance (effective resistance) is about 100R. So in this first test I simply tried a 100R resistor on the FPU to terminate it to gnd.

FPU CLOCK

Sees the return of the under & overshoot. But interestingly the overshoot isn't actually a overshoot as it doesn't get above 5v.

f100r.png


BUFFER OUTPUT CLOCK

Has cured the "glitches" in the rise and fall but overall it is still a little bit "rough".

cp100r.png

Lowering the resistor from 100R to 45R did not have much effect other than limiting the overall voltage.

Incidentally, adding or removing the series 22R resistor also had no effect other than limiting the overall voltage. Subsequent tests also yielded similar results.

Next up was to try "AC termination". This is with a resistor in series with the capacitor. Again this is done under the FPU.


FPU CLOCK 100R 100pF.

fpures100.png


BUFFER CLOCK 100R 100pF.

cpseriesrc_100R.png




FPU CLOCK 45R 100pF.

f45rseri.png


BUFFER CLOCK 45R 100pF.

cp45rser.png

So with the AC type termination it does not really change anything other than you can either have a good clock on one end or the other, but not both!


Next up is the "Thevenin Parallel" Termination Network. Basically this has a pull-up on the FPU clock to 5V and pull down to 0V. The resistors used were 100R.

FPU CLOCK

f100rt.png

BUFFER CLOCK

cp100rt.png

So again not a ideal solution. But it's not bad either. Shorting the 22R makes the voltages higher but also introduces more under/overshoot. Using higher values than 100R may well improve the logic level, but again we would inherently be increasing the under/overshoot spikes.

There is also diode termination but I do not have suitable fast diodes to try this experiment. But if I remember rightly when I tried this years ago, the hard crowbarring of the voltage actually caused ringing to become worse. Adding a resistor across the capacitor is a parallel termination network basically ended up making things worse overall. I did not document those results.

While the 100R termination resistor does not cure the under and overshoot problem as such, it does not "glitch" on the buffer driver either. The overshoot is actually only up to 5V, so a logic one is sustained above 4V anyway. The undershoot is still rather a lot. So I don't class it as a ideal solution in terms of protecting the FPU clock.

So, while capacitors can indeed cure the over and undershoot problems on the FPU clock, it seems it just basically shifts the problem over to the opposite end of the track and dumps it onto the buffer driver instead. So adding 22R series resistance ensures the driver doesn't get such abuse like shown in the images. The only real downfall is the rise and fall times of the clock are slowed down slightly. But I doubt it would make any difference anyway. Using resistors, we can indeed remain between 0V-5V, still with ringing present, and with lowered logic one voltage to about 4V.

While we could be theoretically improve on the resistor situation, I think the problem is we are basically dealing with a three-way termination line. Resistors could possibly work well for a normal "single" line. But we are basically dealing with a 'Y-shape" track, so things are just never going to be simple.

There are more complex solutions to solve such issues, but I feel it's getting to the point of simply being over complicated. There could be many more ways to "solve" the issues and maybe even better values to what I have used. Though even if better values were found, it may not work on a different machine anyway. One could spend several months experimenting with it all. It was just my intention to do a quick experiment with various termination styles more than anything to see what the differences were basically.

The ideal solution would just to just cut the FPU clock and drive it from its own oscillator instead. Like with my FPU clock boards I designed some years ago. This way the FPU is driven locally and won't suffer the same as being driven from the clock patch board.

Overall sticking with a 100pF on the FPU clock is the best cleanup. While we get some nasty signals bouncing back to the driver board, they are basically snubbed out via the 22R anyway. So overall this just seems to be the best compromise.
You do not have the required permissions to view the files attached to this post.
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Re: Falcon clock patch investigation 2022

Post by exxos »

I could do with a couple of testers for the V4 clock patch who also have a scope for the first part of the clock patch. I've not had chance to finish the second part yet. It could well be in the new year before I get back to it.
Steve
Posts: 3305
Joined: 15 Sep 2017 11:49

Re: Falcon clock patch investigation 2022

Post by Steve »

exxos wrote: 02 Oct 2022 13:40 I could do with a couple of testers for the V4 clock patch who also have a scope for the first part of the clock patch. I've not had chance to finish the second part yet. It could well be in the new year before I get back to it.
When you're ready I'll make the time to dissect my Falcon again, poor old bird ;)
User avatar
JezC
Posts: 2783
Joined: 28 Aug 2017 23:44

Re: Falcon clock patch investigation 2022

Post by JezC »

I need to check what is installed in my Falcon (when I finally fit the Exxos PSU) but will help if you want?

It's accessible, just need to test the STE with the hard drives & then there's room on the operating table...
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Re: Falcon clock patch investigation 2022

Post by exxos »

I will try and get the updated boards on my current PCB order as they seem to be on holiday so gives me a extra few days.

The problem with "part 2" of the patch is delaying the signal precisely is difficult without upsetting the duty cycle. And this is problematical because specifications of chips are different across patches and it could upset the duty cycle by several percent. I'm trying to get this as tight as possible but is definitely not so simple. But it probably does not matter all that much because it is only really relevant for people with bus speeders anyway. People are likely running with a skewed clock anyway.
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Re: Falcon clock patch investigation 2022

Post by exxos »

Updated boards now in production.

1.JPG
2.JPG
You do not have the required permissions to view the files attached to this post.
Plagued
Posts: 25
Joined: 30 Jun 2020 23:57

Re: Falcon clock patch investigation 2022

Post by Plagued »

I'm running your V2 patch, and happy to poke about with one of my scopes. But there's probably people with much better scope wizardry than me if it's any more than "clip this here and this here, what does it say", I'm more of a solder and wires man :)
User avatar
exxos
Site Admin
Site Admin
Posts: 28354
Joined: 16 Aug 2017 23:19
Location: UK

Re: Falcon clock patch investigation 2022

Post by exxos »

Plagued wrote: 04 Oct 2022 13:08 I'm running your V2 patch, and happy to poke about with one of my scopes. But there's probably people with much better scope wizardry than me if it's any more than "clip this here and this here, what does it say", I'm more of a solder and wires man :)
There is a bit of soldering to do which needs a bit of delicate work. Really it is just measuring with the scope the two clocks. FPU end and SDMA end. was running all the relevant test programs to make sure it is all behaving.

viewtopic.php?f=17&t=5851

Return to “HARDWARE DISCUSSIONS”

Who is online

Users browsing this forum: ClaudeBot and 8 guests