How to use external clock/crystal in P2? — Parallax Forums

# How to use external clock/crystal in P2?

Posts: 31

I am using Parallax Propeller 2 Edge Rev D module. I have defined clock frequency in my C++ code as below :

```enum {
_xtlfreq = 20_000_000,
_clkfreq = 320_000_000,
};
```

To achieve high speed how can I use external clock to increase clock frequency ?

• Posts: 14,278

That should give you 320 MHz. Does it not?

• Posts: 14,278

Oh, for it to work, that needs to go in the top C file - where `main()` is.

• Posts: 31
edited 2023-05-22 05:51

Yes, it gives 320 MHz.
Can frequency be increased from 320 MHz if I use external crystal?

• Posts: 14,278

No, external makes no diff. 320 MHz is already overclocked. You can set that 320 to a higher frequency but reliability gets more questionable. Temperature dependant. The less work the Prop2 is performing the lower the die temperature will be and therefore can go to a higher frequency. The more work it is doing the higher the temperature and therefore more limited max frequency.

• Posts: 3,672

no external crystal needed, you can go a little bit higher, depending on board, but not much, maybe 340.
at the current process the P2 tops out at 350.

The official recommended Speed is way lower, planned for 180 so 320 is already way faster.

Mike

• Posts: 31

@evanh said:
No, external makes no diff. 320 MHz is already overclocked. You can set that 320 to a higher frequency but reliability gets more questionable. Temperature dependant. The less work the Prop2 is performing the lower the die temperature will be and therefore can go to a higher frequency. The more work it is doing the higher the temperature and therefore more limited max frequency.

Does that means adding external crystal will not increase the frequency from 320MHz? I want higher than 320MHz frequency, is it possible?

• Posts: 14,278

Correct, but you can simply change that number in the source code and the PLL will be configured for the new frequency.
eg: For 340 MHz

```enum {
_xtlfreq = 20_000_000,
_clkfreq = 340_000_000,
};
```
• Posts: 31

@evanh
Is it possible to have frequency more than 340 MHz?

• Posts: 2,013
edited 2023-05-23 13:27

Going higher than that can be unstable. It depends on board, temperature and the individual chip.

Eval boards have better heat dissipation. I used a P2 on the Eval at 354 MHz, long hours, without any fails caused by the high clock frequency. I also experimented at higher clocks - problems start over 370 MHz, and it became unstable somewhere between 370-380 MHz. A simple program in one cog may run at 390-400 MHz and there is a PLL frequency limit - it can't go faster than that.

P2-EC32 cannot run stable over something about 340 MHz when using PSRAMs at CLK/2. They start to be unstable first. 170 MHz is much more than these PSRAMs maximum clock (133 MHz) so nothing strange they can stop working properly at 170 MHz. The P2 on the Edge board also runs hotter so there is less stability margin.

It seems that in standard desktop conditions, at temperature about 25C/80F, 360 MHz with Eval and 340 MHz with EC32MB are the practical limits of stability.

• Posts: 14,278
edited 2023-05-23 14:07

The PLL frequency limit is temperature dependant too - specifically tuned as such. But it's actually tuned just a little too high as there is a failure condition for hubRAM accesses just below the PLL's frequency limit. HubRAM reads and writes both get corrupted when sitting on the PLL's limit.

EDIT: Just been looking at some unfinished testing I did after that work and note the two graphs (PLL limit and hubRAM errors) are not parallel. They might cross - didn't finish the tests to prove it - with lower temperatures being more prone to hubRAM errors.

• Posts: 14,278

Continued with a little more of that testing tonight. It has been piecemeal and the graph contains some erratic stabs at the raw data when measuring due to slope timing of the temperature gradient. I don't have the kit to hold a steady ambient temperature and also only have one or two thermocouple meters, one at the moment.

So there is reasonable grounds for a decent margin of error on both lines. Meaning, although the two are just crossing at the top of the graph I don't believe that is actually the case. They come close but don't quite cross.