Shop OBEX P1 Docs P2 Docs Learn Events
How to use external clock/crystal in P2? — Parallax Forums

How to use external clock/crystal in P2?

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 ?

Comments

  • evanhevanh Posts: 15,912

    That should give you 320 MHz. Does it not?

  • evanhevanh Posts: 15,912

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

  • disha_sudradisha_sudra Posts: 43
    edited 2023-05-22 05:51

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

  • evanhevanh Posts: 15,912

    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.

  • 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

  • @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?

  • evanhevanh Posts: 15,912

    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,
    };
    
  • @evanh
    Is it possible to have frequency more than 340 MHz?

  • pik33pik33 Posts: 2,366
    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.

  • evanhevanh Posts: 15,912
    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.

    Further reading - https://forums.parallax.com/discussion/comment/1545243/#Comment_1545243

    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.

  • evanhevanh Posts: 15,912

    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.

Sign In or Register to comment.