Agreed on the lowest xtal that makes sense. For me, it's deffo 8Mhz tops, because the variance on props is too high otherwise.
Personally, I love running Props at either 96 or 100Mhz. That's the sweet spot, given stuff is written to operate well at 80Mhz, the reference frequency.
I have always pushed overclocking to its safe limits (and never trust what the manufacturer says the limit is), I always test and test to verify that the limits to which I push overclocking is safe, and under what conditions. I run MC68SEC000 CPUs at 48MHz (pretty much the safe limit at up to about 38 Degrees C with out a heat sink).
David: Are you using a DIP40 Prop? I could not get the QFP prop to run at 7.3xxx MHz let alone my 7.9xxMHz and 8.00MHz. The fastest was 14.31818MHz @ PLL8. However, I used the standard 3V3 supply. No heating or cooling and ambient ~20C. Guess I should try my TriBlade (DIP40) to see what I can wring out of it because Sapieha achieved 15MHz (120MHz) on it.
FWIW I went to 6.5MHz because they were cheap and easy to get at DigiKey. Same with 13.5MHz and 14.31818MHz and some others too. My preference was to use PLL16 but Sapieha found that PLL8 were better - something to do with the PLL failure mode.
Cluso99:
I am using the P8X32A-D40 part. I made this decision after much reading on the forums, as it seems that most have the best luck with the P8X32A-D40 part for overclocking. I do not know yet rather it makes a difference, though the clock source is currently a counter on a P8X32A-Q44.
I should note:
For testing I am running video full out on all cogs, as well as having all cogs switch the state of an LED every 130_000_000 clocks (So I do not have to keep my extra monitor turned on).
BTW, both the Spin Stamp and the Propeller Backpack use 10 MHz crystals, due to space constraints -- not for overclocking. I have yet to hear of any issues emanating from that choice. 14+Mhz is pushing one's luck, however. And it's easy to be deceived, unless you're doing video or serial I/O that requires accurate timing. If you push the PLL too hard, the VCO will happily oscillate out-of-lock at its free-running frequency, as if nothing were amiss, and you might think you're getting the frequency desired when you're not. (At least that's what happens with the counter PLLs.)
More generally, is there a test we can establish so the Prop itself knows when it is starting to fail or lose sync? Could we run this deliberate stress test in one cog as an 'early warning' that the max "suggested" clock freq might have been hit? What instructions/operations/functions start to fail first?
Such a test would enable us to close a feedback loop and effectively free run at max frequency, and that might shed more light on the best package, voltage, decoupling strategy etc
I couldn't see if this has been stated before on this thread but the leap from 7MHz with PLLx16 to 14MHz with PLLx8 was a thought that the final divide by two would neaten the possibly less than 50/50 clock resulting from overclocking.
In time I tested overclocking I asked on forum programmings gurus to help write that program - But none answered.
What instructions/operations/functions start to fail first? - It is not that simple - That program need even use random start/stop COG's by instructions type Wait-on for Testing Voltage stability in Propeller.
Toby. I couldn't see if this has been stated before on this thread but the leap from 7MHz with PLLx16 to 14MHz with PLLx8 was a thought that the final divide by two would neaten the possibly less than 50/50 clock resulting from overclocking.
It is not only for 50/50 state of signal that I used 14.318.180 - It is even for at Buffer PLL signal to it's full voltage. As normally PLL will have smaller Voltage out in time You have higher Frequency on it (It is normal behavior of PLL's).
And if you not Buffer that by any circuity that recondition signals to Logic Voltage states - Voltages will be to small at last to drive Propeller. Even if You have stable frequency on it's output stage.
More generally, is there a test we can establish so the Prop itself knows when it is starting to fail or lose sync? Could we run this deliberate stress test in one cog as an 'early warning' that the max "suggested" clock freq might have been hit? What instructions/operations/functions start to fail first?
Such a test would enable us to close a feedback loop and effectively free run at max frequency, and that might shed more light on the best package, voltage, decoupling strategy etc
Thanks for explaining that. I could see that the 50/50 was required but I hadn't thought of falling off levels. The final devide by 2 stage does both in one move.
This just leaves the stated resriction of 4MHz - 8MHz a bit out on a limb, at x16 PLL a 14MHz Xtal would give the PLL running at 224MHz which is a lot over the stated maximum. I suppose that this shows that Parallax have been very conservative on their stated maximums for comercial reasons (but is good for experimenters).
@Sapieha: Thanks. I hoped you would chime in as I knew there was a reason you thought PLLx8 would be better.
Sapieha found the prop requires more decoupling capacitors due to switching currents. This would be particularly when waitxxx instructions are exitted and the cog goes into high power mode from a semi sleep mode. So, I presume if all cogs were in a waitpxx state and a pulse was supplied to that pin, then this may be the max voltage required at a single point in time and that may cause the prop to fail. However, any testing/discussion is pure speculation.
The fact that we can overclock the prop to such an extent is an indication of the extent Parallax have been conservative in the specs. So, while discovering the max that appeared to work, that being around 115-120MHz, I thought 104MHz & 108MHz would be quite realistic, and provides a huge increase over 80MHz.
Most of the stuff i've done lately other than the android thing (which means 6Mhz, because usb) has actually been running at 30Mhz or less... I found a nice crystal at 7 and a bit that plays very well with the serial objects while keeping clock rate and thus power use low.
Why the implicit assumption that the VCO does not provide a 50:50 clock naturally or that its output (i.e. the "PLLx16" output) is not internally buffered? There's really no way (for us) to measure either one, but I would wager that both potential issues were accounted for in the Prop's design.
More generally, is there a test we can establish so the Prop itself knows when it is starting to fail or lose sync? Could we run this deliberate stress test in one cog as an 'early warning' that the max "suggested" clock freq might have been hit? What instructions/operations/functions start to fail first?
Why don't we start with issues at nominal frequency (80MHz)? waitpeq can't always see a 40Mhz pulse train, DUTY pulses - when counted - clock in as 0/1/2 cycles, a DUTY pulse which increments LOGIC A by 2 doesn't necessarily trigger a waitpeq on the same pin ...
All that on a rev G demo board. Then again maybe said h/w isn't really built for this?!
All program snippets that can stress Propeller and can be build in more advanced program are welcome.
If them are good described what part of COG/HUB else entire propeller them will Stress/Test.
Why don't we start with issues at nominal frequency (80MHz)? waitpeq can't always see a 40Mhz pulse train, DUTY pulses - when counted - clock in as 0/1/2 cycles, a DUTY pulse which increments LOGIC A by 2 doesn't necessarily trigger a waitpeq on the same pin ...
Why don't we start with issues at nominal frequency (80MHz)? waitpeq can't always see a 40Mhz pulse train, DUTY pulses - when counted - clock in as 0/1/2 cycles, a DUTY pulse which increments LOGIC A by 2 doesn't necessarily trigger a waitpeq on the same pin ...
All that on a rev G demo board. Then again maybe said h/w isn't really built for this?!
I was kind of hoping for something arithmetic, or perhaps a jump-to operation starts failing, or something else that can be measured internally starting to fail, but I guess that is wishful thinking.
It would be interesting to repeat those tests with an optimised hardware setup (bare chip, ground plane, possibly with local fast clock buffers right next to the pin under test). I guess there are possible race condition style problems depending on which cog is receiving the pin status.
Why don't we start with issues at nominal frequency (80MHz)? waitpeq can't always see a 40Mhz pulse train, DUTY pulses - when counted - clock in as 0/1/2 cycles, a DUTY pulse which increments LOGIC A by 2 doesn't necessarily trigger a waitpeq on the same pin ...
All that on a rev G demo board. Then again maybe said h/w isn't really built for this?!
Time to learn about metastability. If your sampled signal transitions too close to the clock pulse, the
behavior of the hardware may be indeterminate, or if you are unlucky, inconsistent.
All of this is standard digital electronics, and is at the point where analog effects start to break down the nice
logical abstraction. But always remember, we are dealing with real circuits here that have analog behavior,
not with some ideal perfect digital simplification.
Why don't we start with issues at nominal frequency (80MHz)? waitpeq can't always see a 40Mhz pulse train, DUTY pulses - when counted - clock in as 0/1/2 cycles, a DUTY pulse which increments LOGIC A by 2 doesn't necessarily trigger a waitpeq on the same pin ...
All that on a rev G demo board. Then again maybe said h/w isn't really built for this?!
Kuroneko is there a thread here already with more detail on this?
Time to learn about metastability. If your sampled signal transitions too close to the clock pulse, the
behavior of the hardware may be indeterminate, or if you are unlucky, inconsistent.
I am aware of that. Point being the nominal operating frequency is hailed as 80MHz. All pulses and signals originate from within the propeller. This is supposed to workA. All those tests perform fine at e.g. 40MHz.
I had a funny one yesterday, waitpeq mask, mask doesn't waitpne par, mask does work on the same internal signal (DUTY pulse).
We have been using the 6.25 MHz crystal in all our PoS terminals without any problems. The power consumption
difference between 80 and 100 MHz is negligible.
Yeah, I'm not convinced this is supposed to work. Just because (for instance) the PLL can generate
a free-running 124MHz (+/-) signal doesn't mean that there is magic in the inputs that permit you to
sample something like that.
Keeping signals on-chip will help solve some problems, yes, but I'd be very careful about expecting
behavior at 40MHz when sampling signals generated by the chip itself, to continue to work at 80MHz.
There are setup and hold times that need to be respected for proper sampling, and it's clear we can
easily generate signals that do not meet those times.
Comments
Personally, I love running Props at either 96 or 100Mhz. That's the sweet spot, given stuff is written to operate well at 80Mhz, the reference frequency.
FWIW I went to 6.5MHz because they were cheap and easy to get at DigiKey. Same with 13.5MHz and 14.31818MHz and some others too. My preference was to use PLL16 but Sapieha found that PLL8 were better - something to do with the PLL failure mode.
I am using the P8X32A-D40 part. I made this decision after much reading on the forums, as it seems that most have the best luck with the P8X32A-D40 part for overclocking. I do not know yet rather it makes a difference, though the clock source is currently a counter on a P8X32A-Q44.
For testing I am running video full out on all cogs, as well as having all cogs switch the state of an LED every 130_000_000 clocks (So I do not have to keep my extra monitor turned on).
-Phil
More generally, is there a test we can establish so the Prop itself knows when it is starting to fail or lose sync? Could we run this deliberate stress test in one cog as an 'early warning' that the max "suggested" clock freq might have been hit? What instructions/operations/functions start to fail first?
Such a test would enable us to close a feedback loop and effectively free run at max frequency, and that might shed more light on the best package, voltage, decoupling strategy etc
In time I tested overclocking I asked on forum programmings gurus to help write that program - But none answered.
What instructions/operations/functions start to fail first? - It is not that simple - That program need even use random start/stop COG's by instructions type Wait-on for Testing Voltage stability in Propeller.
Toby.
I couldn't see if this has been stated before on this thread but the leap from 7MHz with PLLx16 to 14MHz with PLLx8 was a thought that the final divide by two would neaten the possibly less than 50/50 clock resulting from overclocking.
It is not only for 50/50 state of signal that I used 14.318.180 - It is even for at Buffer PLL signal to it's full voltage. As normally PLL will have smaller Voltage out in time You have higher Frequency on it (It is normal behavior of PLL's).
And if you not Buffer that by any circuity that recondition signals to Logic Voltage states - Voltages will be to small at last to drive Propeller. Even if You have stable frequency on it's output stage.
Thanks for explaining that. I could see that the 50/50 was required but I hadn't thought of falling off levels. The final devide by 2 stage does both in one move.
This just leaves the stated resriction of 4MHz - 8MHz a bit out on a limb, at x16 PLL a 14MHz Xtal would give the PLL running at 224MHz which is a lot over the stated maximum. I suppose that this shows that Parallax have been very conservative on their stated maximums for comercial reasons (but is good for experimenters).
Sapieha found the prop requires more decoupling capacitors due to switching currents. This would be particularly when waitxxx instructions are exitted and the cog goes into high power mode from a semi sleep mode. So, I presume if all cogs were in a waitpxx state and a pulse was supplied to that pin, then this may be the max voltage required at a single point in time and that may cause the prop to fail. However, any testing/discussion is pure speculation.
The fact that we can overclock the prop to such an extent is an indication of the extent Parallax have been conservative in the specs. So, while discovering the max that appeared to work, that being around 115-120MHz, I thought 104MHz & 108MHz would be quite realistic, and provides a huge increase over 80MHz.
xtal = 7_372_800
http://forums.parallax.com/showthread.php?131739-130MHz-test-status.-%28YMMV%29
-Phil
All that on a rev G demo board. Then again maybe said h/w isn't really built for this?!
All program snippets that can stress Propeller and can be build in more advanced program are welcome.
If them are good described what part of COG/HUB else entire propeller them will Stress/Test.
I was kind of hoping for something arithmetic, or perhaps a jump-to operation starts failing, or something else that can be measured internally starting to fail, but I guess that is wishful thinking.
It would be interesting to repeat those tests with an optimised hardware setup (bare chip, ground plane, possibly with local fast clock buffers right next to the pin under test). I guess there are possible race condition style problems depending on which cog is receiving the pin status.
There was an interesting article on this topic in this month's IEEE Spectrum magazine, which is also available online here:
http://spectrum.ieee.org/semiconductors/processors/transistor-aging
Time to learn about metastability. If your sampled signal transitions too close to the clock pulse, the
behavior of the hardware may be indeterminate, or if you are unlucky, inconsistent.
All of this is standard digital electronics, and is at the point where analog effects start to break down the nice
logical abstraction. But always remember, we are dealing with real circuits here that have analog behavior,
not with some ideal perfect digital simplification.
Kuroneko is there a thread here already with more detail on this?
I had a funny one yesterday, waitpeq mask, mask doesn't waitpne par, mask does work on the same internal signal (DUTY pulse).
A assumption on my part
difference between 80 and 100 MHz is negligible.
Yeah, I'm not convinced this is supposed to work. Just because (for instance) the PLL can generate
a free-running 124MHz (+/-) signal doesn't mean that there is magic in the inputs that permit you to
sample something like that.
Keeping signals on-chip will help solve some problems, yes, but I'd be very careful about expecting
behavior at 40MHz when sampling signals generated by the chip itself, to continue to work at 80MHz.
There are setup and hold times that need to be respected for proper sampling, and it's clear we can
easily generate signals that do not meet those times.
-tom