Going from 20kHz to 20MHz, the C drops to ~1/10th and the R drops to ~1/100th.
I ran the 20MHz OSC simulation again with 100ps max timestep, instead of 10ns, and the jitter went away. I need to understand where the jitter is coming from in the test chip.
That makes more sense, as usually Spice is unable to 'see' cross talk and Supply noise, unless injected deliberately.
What are the R,C values, and what is the circuit ?
Is anything else running at the same time ? - is the 20kHz running, and how close is that ?
The simplest design I'd favour for ~ 20MHz would be a 3 scaled inverter design, with Capacitive divider, single resistor.
Or, you could use a schmitt Inverter + RC, but that has more tolerance issues.
Not sure on what size chip we want to make first, though.
Apple learned an interesting lesson when their laptop line was a bit more diverse - let pent-up demand sell the most profitable product by releasing the top of the line laptops first.
Release your most profitable product first! I'm assuming that would be the FULL 16 cog P2. Most people will want that version first anyways!
Yes, yes, yes and yes. 100% correct, jmg. 'let pent-up demand sell the [..] top of the line [..] first'. That's exactly how it works. I hadn't seen it put into words that way before, but it's truth. At a later time a customer may look at smaller shrinked alternatives for their product, but they'll start their excursions with the fully monty.
Going from 20kHz to 20MHz, the C drops to ~1/10th and the R drops to ~1/100th.
I ran the 20MHz OSC simulation again with 100ps max timestep, instead of 10ns, and the jitter went away. I need to understand where the jitter is coming from in the test chip.
That makes more sense, as usually Spice is unable to 'see' cross talk and Supply noise, unless injected deliberately.
What are the R,C values, and what is the circuit ?
Is anything else running at the same time ? - is the 20kHz running, and how close is that ?
The simplest design I'd favour for ~ 20MHz would be a 3 scaled inverter design, with Capacitive divider, single resistor.
Or, you could use a schmitt Inverter + RC, but that has more tolerance issues.
I imagine this 20MHz mode as having too many "loose" appendages, which wind up causing some kind of perpetual frequency drift.
I'd expect few to use RC Fast alone, but there are Programmable Clock source choices, such as Si5351, which may not output a P2 clock, until programmed.
Drop of RC-boot and force to an External Osc, for boot, constrains the choices.
I'm using a Si514 with a P1 in that way, and drop to RC to reprogram the clock freq on the fly. The only time the P1 is running off RC is during that interval where it's reprogramming the osc, but without RC that won't work, and it's not just at startup. The application is an adjustable disciplined clock source.
I imagine this 20MHz mode as having too many "loose" appendages, which wind up causing some kind of perpetual frequency drift.
Here is the schematic:
Here is a simulation at 'typical' conditions:
OK. Good sims...
I see you have a single Schmitt, with a Fast and Slow mode, so that eliminates the 20kHz Osc as a source, but I'd still think this is more a crosstalk issue, than any inherent 'loose appendage' issue.
Does that PWR source include the metal-route inductance etc ? - the PR ripple looks realistic.
The ripple on PWR is appx one part in 70, and your errors reported are appx one part in 88. Self-ripple does not cause jitter, but any other async digital activity will impose its own similar ripple on PWR, and that will cause jitter as it moves the Schmitt trigger points.
- can you remove all other clock sources / driving signals to the test chip, and check the Jitter again ?
Maybe even run it not connected to the FPGA board ?
Are there any apparent frequency spurs that could give a hint to the crosstalk source ?
Does the test chip have a local analog regulator, or a SMPS one ?
Another test is to check with a SMPS of the typical design / load you expect in a P2, so as to check the Power supply ripple effects on Fc.
If I remember right, with an 8N1 packet (10 bits) you can tolerate 5% drift up or down before it causes problems (you have to be within half a bit at the end of your 10th bit). If your max is at 2.25%, you should be easily within spec, shouldn't you?
Here is a scope picture of the 20MHz RC OSC jitter:
Certainly looks like it is being modulated, somehow.
In some systems spread-spectrum is deliberate
Do you have any spectrum tools that can show the spur/modulation frequencies ?
Failing that, you could write a capture pgm that uses a P1 and HC4060.
Fastest HC4060 tap is 800ns 2^4 tap, for P1 ~64,
P1 ~256 would be /2^6 tap, but you can overflow a little to maybe 2^8 tap, and 1024 MOD 256 captures.
- that would capture +/ 12.8% spread with 0.1% LSB and the 32K P1 memory can capture 2^15 byte samples, every 12.8us for a total capture span of 419.4304ms - that should let you 'see' the modulation artifacts.
This looks like a PLL loop that is slightly overshooting (too much gain) and trying to re-track based on the overshoot error ... "fish tailing"
In the simulation images you provided there appears to be different drive strengths looking at the "XOSC_1.PWR:V" . Every other wave appears consistent with the previous every other wave which leads me to think that this might be an overshooting issue. What I also see is what appears to be an extra knee towards the end of the transistor's turn-on cycle prior to the transistor switching off (you can sort of see on the scope image as well). The 'knee' peaks and is inversely proportional to the amount that the "XOSC_1.SC:V" is pulled LOW .... the closer to 845.0m the XOSC_1.SC:V signal is, the closer XOSC_1.PWR:V approaches 1.710 Volts ... If the amplitude variation is a function the PLL trying to compensate for over shooting as well as under shooting, this will directly translate into frequency modulation seen as "jitter".
I tried a test board out without plugging it into the FPGA board and I still see a consistent +-1.25% frequency variation from mean on the 20MHz fast RC OSC.
This looks like a PLL loop that is slightly overshooting (too much gain) and trying to re-track based on the overshoot error ... "fish tailing"
In the simulation images you provided there appears to be different drive strengths looking at the "XOSC_1.PWR:V" . Every other wave appears consistent with the previous every other wave which leads me to think that this might be an overshooting issue. What I also see is what appears to be an extra knee towards the end of the transistor's turn-on cycle prior to the transistor switching off (you can sort of see on the scope image as well). The 'knee' peaks and is inversely proportional to the amount that the "XOSC_1.SC:V" is pulled LOW .... the closer to 845.0m the XOSC_1.SC:V signal is, the closer XOSC_1.PWR:V approaches 1.710 Volts ... If the amplitude variation is a function the PLL trying to compensate for over shooting as well as under shooting, this will directly translate into frequency modulation seen as "jitter".
The thing is, this is just an open-loop RC oscillator. Why it wanders this much is a mystery to me. I think it might just have to do with thermal noise in the transistors creating some kind of periodic surge in sympathy with biased-off, lower-time-constant elements in the oscillator. I need to see if there is a pattern to the frequency changes.
Hmm any antenna effects that could be received from an external RF source? Are the results different if you place the test chip in a grounded metal box?
Have you tried to audibly "listen" to the noise to see if you can make anything out? <-- Try setting up a beat frequency against a known stable 20MHz signal.
Wait, I think I know what the problem is .... The oscillator needs to switch much sooner on the capacitor charge and discharge cycle ... the greater 't' is in the charge/discharge cycle as the tangent curve begins to flatten, the closer you get to the thermal noise floor ... this area is less stable over time in terms of looking for a "trigger" event. Switching in the linear portion of the charge/discharge cycle is much more stable and predictable.
EDIT: I'm looking at XOSC_1.SC:V and XOSC_1.PWR:V specifically ... NOT XOSC_1:FC , although XOSC_1.SC:V and XOSC_1.PWR:V should look more like XOSC_1:FC
I tried a test board out without plugging it into the FPGA board and I still see a consistent +-1.25% frequency variation from mean on the 20MHz fast RC OSC.
The thing is, this is just an open-loop RC oscillator. Why it wanders this much is a mystery to me. I think it might just have to do with thermal noise in the transistors creating some kind of periodic surge in sympathy with biased-off, lower-time-constant elements in the oscillator. I need to see if there is a pattern to the frequency changes.
I'd call 1.25% of modulation way more than any thermal noise effect.
A quick means to check for patterns, is to capture single-shot, and change the cycles captured.
A scope that can show capture plus a zoomed B trace is good here.
Then, cycle quickly thru a few one-shot captures, and see how the alignment changes.
... creating some kind of periodic surge in sympathy with biased-off, lower-time-constant elements in the oscillator. I need to see if there is a pattern to the frequency changes.
There is a time constant of the M19,M20 and SC present, which will be I think around 6x SC or 120KHz
ie if you see repeat pattern every 166 or 333 Cycles of 20MHz aka 120kHz that points to SC effects.
I would think however, that would be a simple low-pass, and SC shows appx 5mV of FC ripple.
Based on the Tau ratios of 166, that gives a rough indicator of 6.6mV on SC, so looks about right ?
If you Zoom the Spice run, to show a few cycles at 120kHz, what does that show on SC ?
EDIT: I'm looking at XOSC_1.SC:V and XOSC_1.PWR:V specifically ... NOT XOSC_1:FC , although XOSC_1.SC:V and XOSC_1.PWR:V should look more like XOSC_1:FC
Why 'XOSC_1.PWR:V should look more like XOSC_1:FC' ?
I take PWR as the ripple on the system Vcc, and FC is the Schmitt R/C node, so I'd expect very different voltages.
FC looks good to me.
SC I take as the Slow Freq Node, and given that is made from P & N Caps, I'd expect ~50% PSRR, which is what it seems to show. (SC : PWR)
The DC offset appx 855mV on SC is a little harder to explain*, & I wonder if that node should be DC-biased in fast mode, just to make it settle to a stable point.
A floating SC node would allow SC to vary a little, and even tho SC is much larger than FC, that can still modulate FOsc
If that were the case, a mains-component would be expected in the modulation, and a shielding cap on the chip may help ?
*Addit: figured where that 855mV comes from - M19,M20 and SC act as a Low pass filter, which drops the
1.4-0.3V swing of FC, to a DC average and small ripple aka (850mV DC and 6.6mV Fc ripple + 50% PWR Ripple), ie exactly what Spice is showing.
I used a smart pin in 'measure X cycles' mode to check the frequency range of the 20MHz RC oscillator over differing periods.
Here is the program:
dat org
mov dirb,##$FFFF 'make 16 led outputs
wrpin #%10011_0,#0 'ready to measure X cycles
wxpin ##40<<6,#0 'set cycles
wypin #0,#0 'set rise-to-rise
dirh #0 'enable measurement
.wt testin #0 wc 'wait for next measurement
if_nc jmp #.wt
rdpin x,#0 'read time in 80MHz clock cycles
shr x,#6 'shift time down
max tmin,x 'track minimum
min tmax,x 'track maximum
setbyte outb,tmin,#0 'write minimum to bottom 8 leds
setbyte outb,tmax,#1 'write maximum to top 8 leds
jmp #.wt 'get next measurement
tmax long 0
tmin long -1
x res 1
I ran the program 10 times, decrementing the initial 6's each time, until finally I had to start halving the 40.
Here are the results. Note that the variance could be halved to get a +/- frequency drift value:
This shows that the frequency drift is greatest over the short term, and least over the long term. I suppose that a single cycle can vary by maybe 7%. At 80MHz, we get ~4 counts per 20MHz RC cycle, so our resolution is limited at the bottom end.
I think this flatly means that the RC oscillator cannot be trusted to run the autobaud serial interface program in ROM. We are going to have to depend on an externally-connected 20MHz crystal. Any better ideas?
Wait, I think I know what the problem is .... The oscillator needs to switch much sooner on the capacitor charge and discharge cycle ... the greater 't' is in the charge/discharge cycle as the tangent curve begins to flatten, the closer you get to the thermal noise floor ... this area is less stable over time in terms of looking for a "trigger" event. Switching in the linear portion of the charge/discharge cycle is much more stable and predictable.
EDIT: I'm looking at XOSC_1.SC:V and XOSC_1.PWR:V specifically ... NOT XOSC_1:FC , although XOSC_1.SC:V and XOSC_1.PWR:V should look more like XOSC_1:FC
My gut says that you may be right. I think we could tighten the V range on that node and decrease the jitter/drift.
This shows that the frequency drift is greatest over the short term, and least over the long term. I suppose that a single cycle can vary by maybe 7%. At 80MHz, we get ~4 counts per 20MHz RC cycle, so our resolution is limited at the bottom end.
How many samples is the variance over ?
I think a single run ? - if you do repeat 5-10 runs the same, how much does the variance vary ?
I'm not sure I'd call that "frequency drift is greatest over the short term", as your measurement jitter is also climbing there
At 80MHz and 5 cycles of 20MHz, you are sampling only over 20 SysCLKS, for a 5% granularity
I think this flatly means that the RC oscillator cannot be trusted to run the autobaud serial interface program in ROM. We are going to have to depend on an externally-connected 20MHz crystal. Any better ideas?
The 5 & even 10 cycles you cannot read too much into, but AutoBaud will run ~ 5us frames, and subtracting the 0.3125% quanta from 4.4%(4 us), gives a > 4% jitter per character, which is certainly high.
I still think the source of modulation needs to be better nailed down.
Looks to me like it's simply too large to be a random noise or slew-related effect & RC oscillators can be orders of magnitude better than this.
The variance is over maybe 10 seconds, though readings stopped changing within a millisecond, probably. And there is no other switching going on in the test chip during these measurements.
You are right about the shorter-term measurements being somewhat inconclusive. It does seem, though, that we have strong indication that variance is >4% over 20 cycles, or 1us.
I think Beau's idea about tweaking the Schmitt points to stay in the hotter linear region would improve things quite a bit. I just wish I knew how to properly simulate the error that we are seeing.
I just re-ran the test at 5120 clock cycles and the error is now 0.6%. If I go to 10240 cycles, the error drops below what I can see on 8 leds.
I don't think there is a modulation period here. The noise is just inversely proportional to the sample period. It's like most everything else that doesn't have a high Q. I think this can just be labeled 'phase noise'. Sometimes, consecutive phases err in the same direction, giving the short-term effect of frequency drift.
I think Beau's idea about tweaking the Schmitt points to stay in the hotter linear region would improve things quite a bit. I just wish I knew how to properly simulate the error that we are seeing.
... I'm not convinced this is a slew-issue, and care is needed in lowering the RC swing, as you increase the Power supply sensitivity - It could actually get worse.
The FC Sim's to me look well clear of any RC tail effects.
I used to have speakers around me. They are handy for checks like that. Scanners are handy, too, for tuning into nominal carriers. I wonder where my hold hand-held scanner went. Even an AM/FM radio is useful.
If I just toggled a pin after every 10-cycle measurement completed, I could demodulate the noise pattern with a 1MHz FM receiver.
I don't think there's enough complexity in the circuit to generate anything more than Schmitt trip-point phase noise. I think that's all we're seeing here. I just wish it would show up in the simulation.
I don't think there's enough complexity in the circuit to generate anything more than Schmitt trip-point phase noise. I think that's all we're seeing here. I just wish it would show up in the simulation.
Did you run the simulation for > 100us and check SC, for unexpected effects ?
To me it looks a fairly passive node, but it may worsen PSRR at some frequencies ?
What is the Vcc regulator, and have you confirmed it is very clean and stable ?
An oscillating regulator, would give effects rather like this....
If I just toggled a pin after every 10-cycle measurement completed, I could demodulate the noise pattern with a 1MHz FM receiver.
Best to do a simple binary divide aka HC4060 or similar, if you have a 1MHz FM receiver.
An appeal of Divide then Mix, is you can use the very good spectrum abilities of Sound card software.
Jmg,
The variance is over maybe 10 seconds, though readings stopped changing within a millisecond, probably. And there is no other switching going on in the test chip during these measurements.
Does this change at all with Test-Chip RESET pin level ?
Are all the Analog sections OFF during this test ?
The problem is the bypass capacitance on the 1.8V regulator!!!
I used an 0603 2.2uF cap, but I think its ESR must be pretty lousy, because when I put an electrolytic 47uF cap across GND and 1.8V, that RC oscillator suddenly became nearly perfect!
So, we just need a quiet 1.8V supply. No problem, after all. Whew!
Thanks for all your thinking, guys. I should have thought to try this earlier.
"... I could demodulate the noise pattern with a 1MHz FM receiver..."
If your just looking for an audible confirmation, then a standard AM radio tuned to 1000kHz should be sufficient for a 1MHz receiver. In a similar way that amplitude translates to frequency modulation of the 20MHz you are seeing, so will the AM radio receiver translate the modulated frequency to an amplitude.
Comments
That makes more sense, as usually Spice is unable to 'see' cross talk and Supply noise, unless injected deliberately.
What are the R,C values, and what is the circuit ?
Is anything else running at the same time ? - is the 20kHz running, and how close is that ?
The simplest design I'd favour for ~ 20MHz would be a 3 scaled inverter design, with Capacitive divider, single resistor.
Or, you could use a schmitt Inverter + RC, but that has more tolerance issues.
I imagine this 20MHz mode as having too many "loose" appendages, which wind up causing some kind of perpetual frequency drift.
Here is the schematic:
Here is a simulation at 'typical' conditions:
I see you have a single Schmitt, with a Fast and Slow mode, so that eliminates the 20kHz Osc as a source, but I'd still think this is more a crosstalk issue, than any inherent 'loose appendage' issue.
Does that PWR source include the metal-route inductance etc ? - the PR ripple looks realistic.
The ripple on PWR is appx one part in 70, and your errors reported are appx one part in 88.
Self-ripple does not cause jitter, but any other async digital activity will impose its own similar ripple on PWR, and that will cause jitter as it moves the Schmitt trigger points.
- can you remove all other clock sources / driving signals to the test chip, and check the Jitter again ?
Maybe even run it not connected to the FPGA board ?
Are there any apparent frequency spurs that could give a hint to the crosstalk source ?
Does the test chip have a local analog regulator, or a SMPS one ?
Another test is to check with a SMPS of the typical design / load you expect in a P2, so as to check the Power supply ripple effects on Fc.
Jmg, good idea about trying the test chip board without plugging it into the FPGA board. Will try that in the morning.
Certainly looks like it is being modulated, somehow.
In some systems spread-spectrum is deliberate
Do you have any spectrum tools that can show the spur/modulation frequencies ?
Failing that, you could write a capture pgm that uses a P1 and HC4060.
Fastest HC4060 tap is 800ns 2^4 tap, for P1 ~64,
P1 ~256 would be /2^6 tap, but you can overflow a little to maybe 2^8 tap, and 1024 MOD 256 captures.
- that would capture +/ 12.8% spread with 0.1% LSB and the 32K P1 memory can capture 2^15 byte samples, every 12.8us for a total capture span of 419.4304ms - that should let you 'see' the modulation artifacts.
This looks like a PLL loop that is slightly overshooting (too much gain) and trying to re-track based on the overshoot error ... "fish tailing"
In the simulation images you provided there appears to be different drive strengths looking at the "XOSC_1.PWR:V" . Every other wave appears consistent with the previous every other wave which leads me to think that this might be an overshooting issue. What I also see is what appears to be an extra knee towards the end of the transistor's turn-on cycle prior to the transistor switching off (you can sort of see on the scope image as well). The 'knee' peaks and is inversely proportional to the amount that the "XOSC_1.SC:V" is pulled LOW .... the closer to 845.0m the XOSC_1.SC:V signal is, the closer XOSC_1.PWR:V approaches 1.710 Volts ... If the amplitude variation is a function the PLL trying to compensate for over shooting as well as under shooting, this will directly translate into frequency modulation seen as "jitter".
The thing is, this is just an open-loop RC oscillator. Why it wanders this much is a mystery to me. I think it might just have to do with thermal noise in the transistors creating some kind of periodic surge in sympathy with biased-off, lower-time-constant elements in the oscillator. I need to see if there is a pattern to the frequency changes.
Hmm any antenna effects that could be received from an external RF source? Are the results different if you place the test chip in a grounded metal box?
Have you tried to audibly "listen" to the noise to see if you can make anything out? <-- Try setting up a beat frequency against a known stable 20MHz signal.
Wait, I think I know what the problem is .... The oscillator needs to switch much sooner on the capacitor charge and discharge cycle ... the greater 't' is in the charge/discharge cycle as the tangent curve begins to flatten, the closer you get to the thermal noise floor ... this area is less stable over time in terms of looking for a "trigger" event. Switching in the linear portion of the charge/discharge cycle is much more stable and predictable.
EDIT: I'm looking at XOSC_1.SC:V and XOSC_1.PWR:V specifically ... NOT XOSC_1:FC , although XOSC_1.SC:V and XOSC_1.PWR:V should look more like XOSC_1:FC
I'd call 1.25% of modulation way more than any thermal noise effect.
A quick means to check for patterns, is to capture single-shot, and change the cycles captured.
A scope that can show capture plus a zoomed B trace is good here.
Then, cycle quickly thru a few one-shot captures, and see how the alignment changes.
There is a time constant of the M19,M20 and SC present, which will be I think around 6x SC or 120KHz
ie if you see repeat pattern every 166 or 333 Cycles of 20MHz aka 120kHz that points to SC effects.
I would think however, that would be a simple low-pass, and SC shows appx 5mV of FC ripple.
Based on the Tau ratios of 166, that gives a rough indicator of 6.6mV on SC, so looks about right ?
If you Zoom the Spice run, to show a few cycles at 120kHz, what does that show on SC ?
Why 'XOSC_1.PWR:V should look more like XOSC_1:FC' ?
I take PWR as the ripple on the system Vcc, and FC is the Schmitt R/C node, so I'd expect very different voltages.
FC looks good to me.
SC I take as the Slow Freq Node, and given that is made from P & N Caps, I'd expect ~50% PSRR, which is what it seems to show. (SC : PWR)
The DC offset appx 855mV on SC is a little harder to explain*, & I wonder if that node should be DC-biased in fast mode, just to make it settle to a stable point.
A floating SC node would allow SC to vary a little, and even tho SC is much larger than FC, that can still modulate FOsc
If that were the case, a mains-component would be expected in the modulation, and a shielding cap on the chip may help ?
*Addit: figured where that 855mV comes from - M19,M20 and SC act as a Low pass filter, which drops the
1.4-0.3V swing of FC, to a DC average and small ripple aka (850mV DC and 6.6mV Fc ripple + 50% PWR Ripple), ie exactly what Spice is showing.
Here is the program:
I ran the program 10 times, decrementing the initial 6's each time, until finally I had to start halving the 40.
Here are the results. Note that the variance could be halved to get a +/- frequency drift value:
This shows that the frequency drift is greatest over the short term, and least over the long term. I suppose that a single cycle can vary by maybe 7%. At 80MHz, we get ~4 counts per 20MHz RC cycle, so our resolution is limited at the bottom end.
I think this flatly means that the RC oscillator cannot be trusted to run the autobaud serial interface program in ROM. We are going to have to depend on an externally-connected 20MHz crystal. Any better ideas?
My gut says that you may be right. I think we could tighten the V range on that node and decrease the jitter/drift.
How many samples is the variance over ?
I think a single run ? - if you do repeat 5-10 runs the same, how much does the variance vary ?
I'm not sure I'd call that "frequency drift is greatest over the short term", as your measurement jitter is also climbing there
At 80MHz and 5 cycles of 20MHz, you are sampling only over 20 SysCLKS, for a 5% granularity
Adding a Quanta column gives
The 64:128us values show an interesting & significant halve in variance, & quanta is <0.02% out here.
I wonder if that indicates you have now covered more than one modulation-cycle ?
If you bump those cycles higher, say for 1ms, 5ms, & 16.667 ms & 1000 ms , what variances do you get ?
Are there any other oscillators running in the test chip, during this test ?
The 5 & even 10 cycles you cannot read too much into, but AutoBaud will run ~ 5us frames, and subtracting the 0.3125% quanta from 4.4%(4 us), gives a > 4% jitter per character, which is certainly high.
I still think the source of modulation needs to be better nailed down.
Looks to me like it's simply too large to be a random noise or slew-related effect & RC oscillators can be orders of magnitude better than this.
The variance is over maybe 10 seconds, though readings stopped changing within a millisecond, probably. And there is no other switching going on in the test chip during these measurements.
You are right about the shorter-term measurements being somewhat inconclusive. It does seem, though, that we have strong indication that variance is >4% over 20 cycles, or 1us.
I think Beau's idea about tweaking the Schmitt points to stay in the hotter linear region would improve things quite a bit. I just wish I knew how to properly simulate the error that we are seeing.
I just re-ran the test at 5120 clock cycles and the error is now 0.6%. If I go to 10240 cycles, the error drops below what I can see on 8 leds.
I don't think there is a modulation period here. The noise is just inversely proportional to the sample period. It's like most everything else that doesn't have a high Q. I think this can just be labeled 'phase noise'. Sometimes, consecutive phases err in the same direction, giving the short-term effect of frequency drift.
The FC Sim's to me look well clear of any RC tail effects.
Time to scale the LEDs ?
That does rather indicate some higher-frequency modulation source, and not random noise effects.
If there is a modulation-frequency component, that should show up on a spectrum.
What about Divide fOsc by 20~50, and then mixing with a crystal reference, to give an Auto-Sound card spectrum you can hear and see ?
If I just toggled a pin after every 10-cycle measurement completed, I could demodulate the noise pattern with a 1MHz FM receiver.
I don't think there's enough complexity in the circuit to generate anything more than Schmitt trip-point phase noise. I think that's all we're seeing here. I just wish it would show up in the simulation.
To me it looks a fairly passive node, but it may worsen PSRR at some frequencies ?
What is the Vcc regulator, and have you confirmed it is very clean and stable ?
An oscillating regulator, would give effects rather like this....
Best to do a simple binary divide aka HC4060 or similar, if you have a 1MHz FM receiver.
An appeal of Divide then Mix, is you can use the very good spectrum abilities of Sound card software.
Are all the Analog sections OFF during this test ?
The problem is the bypass capacitance on the 1.8V regulator!!!
I used an 0603 2.2uF cap, but I think its ESR must be pretty lousy, because when I put an electrolytic 47uF cap across GND and 1.8V, that RC oscillator suddenly became nearly perfect!
So, we just need a quiet 1.8V supply. No problem, after all. Whew!
Thanks for all your thinking, guys. I should have thought to try this earlier.
"... I could demodulate the noise pattern with a 1MHz FM receiver..."
If your just looking for an audible confirmation, then a standard AM radio tuned to 1000kHz should be sufficient for a 1MHz receiver. In a similar way that amplitude translates to frequency modulation of the 20MHz you are seeing, so will the AM radio receiver translate the modulated frequency to an amplitude.
The 1117 ones are better
I think