Yep, figured that's what you meant. And that's internal to XO, right. So a shorted XO externally won't have any effect on the inverting 1 MOhm performance, right?
Yep, figured that's what you meant. And that's internal to XO, right. So a shorted XO externally won't have any effect on the inverting 1 MOhm performance, right?
The resistor goes directly between the XO and XI pins, actually. It was done that way to avoid any other interpretation of threshold. There is a single inverter with a 600 ohm output that goes from XI to XO. This inhibits crystals from oscillating in any overtone mode. Low gain.
... Judging from the results I got using a capacitively coupled freq generator as the clock input, the P2 seems happiest with a swing bigger than about 1.5 volts p/p at 20 mhz while the TG output is about 1.25 v.
I've had clipped sine oscillators work fine (26MHz & 38.4MHz), and they are 0.8V MIN specs, usually just over 1V p-p, of a heavily filtered square output, source impedance ~ 180-200 ohms.
I'd expect P2 to work well under 1Vp-p at low MHz, and need progressively more p-p as MHz climbs, and there may be a slew rate rule too..
So this 5P35021 that generates up to 500MHz will be integrated into an experimental P2D2 module that also includes the DAC trimmable 0.5ppm oscillator as well as other "enhancements"
I will have this experimental "lab" version of the P2D2 ready for testing in the next few weeks.
@"Peter Jakacki" may very well beat me to an answer based on how poorly today went. No answers. Just more questions about why I cant drive this with the SA. Even downshifting to perfectly safe values like 80 mhz isnt working. That should be a no-brainer. So I need to start fresh with the basics tomorrow and see what I missed.
And Peter... I really NEED one of your new crop. I already have a nice P2-sized copper heatsink and fan just waiting for a willing victim.
@"Peter Jakacki" may very well beat me to an answer based on how poorly today went. No answers. Just more questions about why I cant drive this with the SA. Even downshifting to perfectly safe values like 80 mhz isnt working. That should be a no-brainer.
I'd try even lower, like 20~26MHz, and then move upwards.
One problem I think will be getting a clean RF signal into P2, due to gnd noise issues.
Maybe a ferrite bead transformer can give a cleaner signal ? (and might give you some free gain too ?)
The resistor goes directly between the XO and XI pins
Thanks. So definitely have to be careful what is hanging off the XO pin. Preferably nothing.
Yes, and at highest MHz, any skews in the XO drivers may 'walk' the DC bias point, but hopefully not by enough to be significant.
That could be checked with a meter and a > 10K resistor to XO. Ideally, as MHz ramps, that does not change DC voltage.
IIRC the internal XTAL buffer picks off XI, so the XO swing does not matter in these tests.
I'm curious to see the outcome of this. However, injecting 400MHz directly won't be easy. Either your source clock is placed very near the XI pin, or you'll have to devise a way to transmit a differential clock via a controlled impedance transmission line. Then you could use a differential to single ended clock buffer near the previous pin.
By the way, what is the maximum clock attainable without the PPL? Is 500MHz feasable?
The PLL has always been the speed limiter. On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.
By the way, you will want to use clock mode %01_10, which doesn't enable any internal loading caps. The XI capacitance is still maybe 4pF including the package pin.
The /1 column (XDIVP = 1) shows that heatsink below 35-40 °C the program would crash instead of PLL limited. EDIT: Err, maybe more like 25-30 °C. I missed this detail for 390 MHz:
So that table shows that if you want to operate at 360 MHz from the PLL then the die temperature has to stay below 67 °C. That will be a challenge if the cogs are being worked hard.
If using an external oscillator then there will be a little more temperature increase before reaching the crash limit but, to be honest, I wouldn't want to get any closer to that limit.
PS: I estimate the crash limit will be around 75 °C die temp for 360 MHz sys-clock.
PPS: And it looks like 400 MHz is very difficult to make non-crashing stable. That's one I'd thought I'd achieved at an earlier date but was fooled by not actually measuring the clock rate.
Hmm, I've just tried again and the PLL is the limit all the way down for XDIVP = 1! I'm confused. Only explanation I can give is I must have been using a buggy loader previously. I've got PLL limited operating at 440 MHz sys-clock doing that simple toggle at -8 °C. A little faster still at -10 °C where I started. 430 MHz looks to be about -1 °C.
I can no longer say what the crash limit is. It seems the door is open to an external oscillator. I can't imagine it's that far away though.
EDIT: 420 MHz is 9 °C, 410 Mhz is 20 °C, 400 MHz is 31 °C, 390 MHz is 42 °C
The numbers don't even line up any more. Grr. Another explanation would be I was using a more complex program that did more and produced a bigger temperature diff on the die. Dunno, doesn't really fit either since the old same results table is present as comments in the old test program I'm reusing now.
Here's the actual source. You can see that I've got a bunch of duplicated blocks with small edits for each test case. I uncomment the one I want to test. Which means I've also accidentally got a slight log of the old HUBSET settings used. The only one I've re-edited for this round is the top most block. There is one other tiny change today - replaced the WAITX immediate with the "pause" variable.
OH! DOH! It was all the revA board I was testing previously! I must have gotten distracted and never did the revB at all. EDIT: It wasn't as simple as shift the plugs over since the temperature probe is soldered to the bottom centre of the Eval Board. I couldn't find a spare set of plugs ready to make another thermocouple with so I had to move the existing thermocouple over.
Okay, so sys-clock crash limits of the revB silicon are wide open then.
OH! DOH! It was all the revA board I was testing previously! I must have gotten distracted and never did the revB at all. EDIT: It wasn't as simple as shift the plugs over since the temperature probe is soldered to the bottom centre of the Eval Board. I couldn't find a spare set of plugs ready to make another thermocouple with so I had to move the existing thermocouple over.
Okay, so sys-clock crash limits of the revB silicon are wide open then.
Are the numbers posted above that sound like recent measurements all for Rev B ?
(and older remembered values are for rev A?)
... On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.
That post makes it sound like the revA crashes were possibly just from the PLL producing a garbage clock gen at the top end of range. And that even the revA silicon could run faster if clocked from an external clock source ... maybe?
... On an early test chip, the PLL's VCO was outpacing the PLL's divider, so I slowed the VCO down by slightly increasing its differential inverters' gate lengths. That got the logic under control, but the VCO now tops out at around 390MHz at room temperature. So, the PLL has always been the limiter.
That post makes it sound like the revA crashes were possibly just from the PLL producing a garbage clock gen at the top end of range. And that even the revA silicon could run faster if clocked from an external clock source ... maybe?
The PPPP = %1111 glitch is a real problem that's always been there. To fix it, I'll need to insert 16 series'd inverters between the PLL output and the clock mux (deglitcher) input. That way, the deglitcher captures the current PLL output state BEFORE it sees it change.
Both RevA and RevB should clock fast with an external XI input (mode %01_10). RevB should be able to go faster due to less self-heating.
Comments
The resistor goes directly between the XO and XI pins, actually. It was done that way to avoid any other interpretation of threshold. There is a single inverter with a 600 ohm output that goes from XI to XO. This inhibits crystals from oscillating in any overtone mode. Low gain.
Err ? the P2 has a 1M internal bias resistor, when the Xtal is enabled ?
So AC coupling (1nF?) is all that is needed
I'd expect P2 to work well under 1Vp-p at low MHz, and need progressively more p-p as MHz climbs, and there may be a slew rate rule too..
I will have this experimental "lab" version of the P2D2 ready for testing in the next few weeks.
And Peter... I really NEED one of your new crop. I already have a nice P2-sized copper heatsink and fan just waiting for a willing victim.
I'd try even lower, like 20~26MHz, and then move upwards.
One problem I think will be getting a clean RF signal into P2, due to gnd noise issues.
Maybe a ferrite bead transformer can give a cleaner signal ? (and might give you some free gain too ?)
SIngle ended differential output capacitively coupled is all you need to feed into the XI input.
LVDS on that part specs > 247mV and LVPECL specs > 550mV on a single output, and 1.1V differential.
I wonder if a balun allows more useful drive ?
LVCMOS specs 1ns rise times (for 1.98V slew) into 5pF, so maybe that can still drive useful swings above that 160MHz spec limit.
That could be checked with a meter and a > 10K resistor to XO. Ideally, as MHz ramps, that does not change DC voltage.
IIRC the internal XTAL buffer picks off XI, so the XO swing does not matter in these tests.
By the way, what is the maximum clock attainable without the PPL? Is 500MHz feasable?
Kind regards, Samuel Lourenço
By the way, you will want to use clock mode %01_10, which doesn't enable any internal loading caps. The XI capacitance is still maybe 4pF including the package pin.
P = F*C*V*V
At 500MHz with a 2V swing, considering 4pF:
P = 500M * 4pF * 2*2 = 8mW
No much power needed.
The /1 column (XDIVP = 1) shows that heatsink below 35-40 °C the program would crash instead of PLL limited. EDIT: Err, maybe more like 25-30 °C. I missed this detail for 390 MHz:
Program was simple 1/1000 pin toggle https://forums.parallax.com/discussion/comment/1476949/#Comment_1476949 It wouldn't produce much internal heat so the heatsink then should be reasonably representative of the die temperature.
Ah, okay. So, it's not always the PLL.
If using an external oscillator then there will be a little more temperature increase before reaching the crash limit but, to be honest, I wouldn't want to get any closer to that limit.
PS: I estimate the crash limit will be around 75 °C die temp for 360 MHz sys-clock.
PPS: And it looks like 400 MHz is very difficult to make non-crashing stable. That's one I'd thought I'd achieved at an earlier date but was fooled by not actually measuring the clock rate.
I can no longer say what the crash limit is. It seems the door is open to an external oscillator. I can't imagine it's that far away though.
EDIT: 420 MHz is 9 °C, 410 Mhz is 20 °C, 400 MHz is 31 °C, 390 MHz is 42 °C
Here's the actual source. You can see that I've got a bunch of duplicated blocks with small edits for each test case. I uncomment the one I want to test. Which means I've also accidentally got a slight log of the old HUBSET settings used. The only one I've re-edited for this round is the top most block. There is one other tiny change today - replaced the WAITX immediate with the "pause" variable.
Okay, so sys-clock crash limits of the revB silicon are wide open then.
PS: Here's the photos of the revA board between tests - https://forums.parallax.com/discussion/comment/1477027/#Comment_1477027
(and older remembered values are for rev A?)
Now that I've caught up with revB reality ...
That post makes it sound like the revA crashes were possibly just from the PLL producing a garbage clock gen at the top end of range. And that even the revA silicon could run faster if clocked from an external clock source ... maybe?
The PPPP = %1111 glitch is a real problem that's always been there. To fix it, I'll need to insert 16 series'd inverters between the PLL output and the clock mux (deglitcher) input. That way, the deglitcher captures the current PLL output state BEFORE it sees it change.
Both RevA and RevB should clock fast with an external XI input (mode %01_10). RevB should be able to go faster due to less self-heating.