Generating two fractional-ratio clocks with repeatable phase relationship?

[rasteri]

As you may know, the SNES game console has two clocks - 21.47727MHz for the CPU and 24.576MHz for the DSP. The two clocks are derived from separate oscillators and are not synchronized in any way. This makes the SNES inherently nondeterministic, and thus makes debugging homebrew games somewhat hit-and-miss.

I've been using a fractional-N clock synth (CS2300) to derive the 24MHz clock from the 21MHz one. But because the clock is free-running and the user may reset the console at any time, the two clocks end up on a different phase relationship every time the console is reset, and the game behaves slightly differently. (also the CS2300 PLL takes a random amount of time to lock).

I know the two clocks can't ever be "in phase" as they have such an odd ratio (the exact fraction is 39375/45056), but I would like to ensure that they at least start their first cycle at the same moment, and that they slip in-and-out-of-phase on the exact same cycles, so the console behaves entirely deterministically.

While I would like to generate a repeatable sequence of clock pulses each time, I would settle for just delaying the console reset until the next time the two clocks end up in phase (the beat frequency of the two clocks). But I suspect getting true determinism that way would be tricky (even if we get the first clock more-or-less correct, can we really guarantee the clocks will always slip past each other on the same clock cycle?)

Is this a job for an FPGA, and if so what kind of setup are we talking?

[dmendesf]

FPGA is the way to go. Use an even higher clock for the FPGA with counters to generate each of them. Release the reset at the same time you init the counters. Win.

[PCB.Wiz]

I know the two clocks can't ever be "in phase" as they have such an odd ratio (the exact fraction is 39375/45056), but I would like to ensure that they at least start their first cycle at the same moment, and that they slip in-and-out-of-phase on the exact same cycles, so the console behaves entirely deterministically.

While I would like to generate a repeatable sequence of clock pulses each time, I would settle for just delaying the console reset until the next time the two clocks end up in phase (the beat frequency of the two clocks). But I suspect getting true determinism that way would be tricky (even if we get the first clock more-or-less correct, can we really guarantee the clocks will always slip past each other on the same clock cycle?)

That seems a forlorn hope.
With an exact fraction is 39375/45056, and varying software branches as the code runs, you have no hope of anything deterministic ?


Addit: You may be able to make things 'less random' if you nudge the frequencies a (very) little.
The web finds that  39375/45056, is close to 201 / 230 = 0.873913043478  = 0.662ppm
If you run that through a Si5351 clock generator (yours may be similar),
I get a solution like  Xtal * (35+191/230)/41 is 0.926ppm* from ideal, and that small fractional number means the 191/230 fractional correct, will have a repeat period of 9.3us
It's not phase locked, but the phase choices are greatly reduced. 
Not sure if that helps in a working system ?

* using the NTSC value, (6*315/88) that is then 0.6625ppm minor error using 1-(24.576*(35+191/230)/41)/(6*315/88)

[Someone]

I know the two clocks can't ever be "in phase" as they have such an odd ratio (the exact fraction is 39375/45056), but I would like to ensure that they at least start their first cycle at the same moment, and that they slip in-and-out-of-phase on the exact same cycles, so the console behaves entirely deterministically.

While I would like to generate a repeatable sequence of clock pulses each time, I would settle for just delaying the console reset until the next time the two clocks end up in phase (the beat frequency of the two clocks). But I suspect getting true determinism that way would be tricky (even if we get the first clock more-or-less correct, can we really guarantee the clocks will always slip past each other on the same clock cycle?)

That seems a forlorn hope.
With an exact fraction is 39375/45056, and varying software branches as the code runs, you have no hope of anything deterministic ?

Being asynchronous, there will be non-determinism/jitter in the communications between the two regardless of where the phase starts.

Also the "exact" ratio above appears to be incorrect, the frequencies are NTSC and 512x48kHz. However a) the crystals used in volume consumer products like that wouldn't be highly accurate b) there are some "advantages" for analog video to be slightly off the true frequency and/or noisy, which apparently has been observed in consoles of that era.

[Ian.M]

That seems a forlorn hope. . . . no hope of anything deterministic ?

Not just that, but real life propagation delays vary with temperature, so even if you could maintain a predictable relationship between the two clock's edge timing and your code's execution, two consecutive runs starting at exactly the same relative clock phase, could execute differently due to varying propagation delays affecting how race conditions between near-coincident edge derived events are resolved.

[dmendesf]

See... the guy said that he wants to study how a program performs when the phase between two signals is known at the start of a program. If this is useful or not is beyond the question. He just wants to have fixed inputs to a box (his program).

[PCB.Wiz]

While I would like to generate a repeatable sequence of clock pulses each time, I would settle for just delaying the console reset until the next time the two clocks end up in phase (the beat frequency of the two clocks). But I suspect getting true determinism that way would be tricky (even if we get the first clock more-or-less correct, can we really guarantee the clocks will always slip past each other on the same clock cycle?)

That also presumes your reset-exit in both domains is highly deterministic, which is a big ask.

It may be easy to try tho ?
Using my suggestion of a small nudge, every 9.358us you can expect closest align, and each cycle will 'phase walk' by ~176.9ps.
A dual D-FF with a tiny clock skew, could allow you to look for an align aperture - you will get a 0b10 on one edge and 0b01 on the other and 0b00, 0b11 in most cases.

[rasteri]

Thanks for the replies. A slightly more friendly ratio may be beneficial - 8/7 is close enough considering the 24mhz clock is a ceramic resonator.

I think I'll PLL the 21MHz clock by 16x, then divide by 14 to get the 24MHz clock. I can also generate a 3MHz "beat frequency" clock (divide by 112) to use as the reset signal. Probably there is an off-the-shelf chip that can do this.

[PCB.Wiz]

Thanks for the replies. A slightly more friendly ratio may be beneficial - 8/7 is close enough considering the 24mhz clock is a ceramic resonator.

..and here I was looking for nudge solutions in the ppm ballpark 

I thought colour burst needed crystal level precision ?

I think I'll PLL the 21MHz clock by 16x, then divide by 14 to get the 24MHz clock.
I can also generate a 3MHz "beat frequency" clock (divide by 112) to use as the reset signal.
Probably there is an off-the-shelf chip that can do this.

The Si5351A / MS5351M can  generate multiple clocks from a crystal, or TCXO.

The challenge here will be locking or determining the reset signal phase.
You can use a HC4046 series phase comparators, to extract the phase/beat info, and trigger from that.
The 74HC7046 part has a inbuilt lock detector that has a 10:1 resistor ratio and a capacitor pin, with post schmitt. (or you can clone that yourself)

[Ian.M]

Well that's more likely to work, but you've got to keep the relative drift of the propagation delays in the two clock paths (including inside the CPU and DSP) well under 3 ns to have any chance of success.  If there's a critical clock path with N*2.91 ns delay, expect indeterminate behaviour.

[rasteri]

So turns out the Si5351A with its three clock outputs can do everything I need if I pick the ratios carefully. I'm using one clock to generate the reset signal (yellow), and it repeatably generates the 21 and 24MHz clocks in an exact phase relationship (blue/pink).

Just need to latch the reset.

Thanks for the help!

[BrianHG]

Tadaaaa: https://github.com/BrianHGinc/Verilog-Floating-Point-Clock-Divider

Well, make sure that the source clock which is used for the color sub-carrier can evenly be generated by your source crystal while using my code to make any other clocks you may need.  The higher frequency you run the FPGA core PLL at, the less the clock output jitter when it does its floating point correction step.  I recommend something like 500mhz to 1ghz core clock range if you are generating an output at ~20 mhz.  (If it is used internally to step a simulated SNES core, then you will only need something like 100-200MHz as the FPGA can step any way it likes.)

[S57UUU]

Maybe AD9959 would be useful.

https://www.analog.com/en/products/ad9959.html

https://www.ebay.com/itm/364361995848?hash=item54d5aad648:g:0McAAOSw2WBkuNKI&amdata=enc%3AAQAIAAAA4HMKT7VpAGyRUODxQYcmkA%2BlXmKRDlP4KdG6E6p98X6P8P3m7sPNQqbaeJPMycskzZHPPNg6R4tTert4GmSXJzpEglY1A5bxTs1Oca9qYPdDGdF6PdgfnYS5R848GjF8jWt8PxD064yn%2FdOoNA390h7vKBHvX5x919%2FL3CNW0W8nFUsxc70U3SAb0ruhEyB7wCkVwA4JUagt1XHv029tv5Mxjr1yGqFPYsQvgTehQbVkqcrnQvnapoufifpzq0SGek3wJQZxNSMAp%2BngLGfcecTq8yLdCfa23ImVt6AiPafR%7Ctkp%3ABk9SR6Dvi4neYg

https://www.ebay.com/itm/171870562248?hash=item280448a7c8:g:toMAAOSwqLFfLnu4&amdata=enc%3AAQAIAAAAwLHiPL3y7ZeM7OEPNdqFG0GUP7RpjPdQEZT5mdmHD2%2FDT67NBQLwOMns8zLJj5ogKklWxY3Hm8Nx%2FTOVeqCN5uChVwT6wR3Nxt%2BKa3sg4AaMjmE%2FLAb0jAmZqRMBX%2F8DE2ynCGfegcWClTWWzaIi17uvg8eKFLRHRmBzEhN6BNygfYYYrt5TDy8yOiiRlezC%2F%2FhwHsy%2B4RBdSfQC%2F1amnrf76%2B8t6SxM%2FjmlPgaV2SbtyfSUizMIag6kxddGfqCcOw%3D%3D%7Ctkp%3ABk9SR6Dvi4neYg