PLL settings calculator

2

Comments

  • Rayman wrote: »
    Ok, thanks, I see now...

    What about changing from one PLL clock mode to another?
    Do you have to know the current clock mode in order to do this?

    If you switch the %PPPP field to or from value %1111, you could get a glitch. Otherwise, there's no harm.
  • Sure it's not just switching away?
    Docs say this:
    *** Warning about switching away from the PLL setting:
    
    When switching away from the PLL setting (%SS = %11), care must be taken to avoid a clock glitch which can hang the P2 chip.
    
    You must switch away from the PLL while preserving the last-written %EDDDDDDMMMMMMMMMMPPPP bits. This means a copy of the last HUBSET clock value should be maintained for this purpose.
    

    If so, and you have a crystal in your system, can you:
    1: Switch to PLL mode with %PPPP=%1111
    2: Switch away from PLL mode while preserving settings from step 1
    3: Switch to the mode you want
    ?
  • Chip: you probably know this, but that BASIC ROUND() function you are using implements Bankers Rounding. Is that going to make any subtle gremlins for you?
  • evanhevanh Posts: 9,962
    edited 2020-01-10 - 22:00:12
    Rayman wrote: »
    If so, and you have a crystal in your system, can you:
    1: Switch to PLL mode with %PPPP=%1111
    2: Switch away from PLL mode while preserving settings from step 1
    3: Switch to the mode you want
    ?
    Yes. Here's the sequence I use now:
    		andn	clk_mode, #%11			'clear the two select bits to force RCFAST selection
    		hubset	clk_mode			'**IMPORTANT**  Switches to RCFAST using known prior mode
    
    		mov	clk_mode, new_clk_mode		'replace old with new ...
    		hubset	clk_mode			'setup PLL mode for new frequency (still operating at RCFAST)
    
    		or	clk_mode, #XSEL			'add PLL as the clock source select
    		waitx	##25_000_000/100		'~10ms (at RCFAST) for PLL to stabilise
    		hubset	clk_mode			'engage!  Switch back to newly set PLL
    
  • jmgjmg Posts: 14,494
    I thought the issue was one of clean clk signal ? (avoiding runt pulses, or clks outside spec)

    Thus :
    Enable of XTAL clock source too soon (before Osc has reached full amplitude) is to be avoided.
    Likewise, switch to PLL before VCO.PLL has settled (locked) is also to be avoided.
    IIRC, PLL -> Select RCFAST -> LoadNewPLL Setting -> WaitTime -> Select VCO.PLL is always OK ?
  • evanhevanh Posts: 9,962
    edited 2020-01-10 - 22:06:44
    jmg wrote: »
    I thought the issue was one of clean clk signal ? (avoiding runt pulses, or clks outside spec)

    Thus :
    Enable of XTAL clock source too soon (before Osc has reached full amplitude) is to be avoided.
    Likewise, switch to PLL before VCO.PLL has settled (locked) is also to be avoided.
    IIRC, PLL -> Select RCFAST -> LoadNewPLL Setting -> WaitTime -> Select VCO.PLL is always OK ?
    That was the original requirement until the flaw was identified. Now, both that and the PPPP=%1111 glitching has to be handled.

    PS: The original sequence could switch to RCFAST and load the new PLL config in the same instruction.
  • evanh: Are you saying this sequence should always work?
    If so, there's no need to know the current clock setting before switching to a new one, right?
  • One important point with the "clk_mode" variable, in the above snippet, is it already holds the prior setting value. So first step is use that to switch to RCFAST. Hence the "** IMPORTANT **" comment.

    That code is in my gerenal setting routine that I use when doing tests of multiple sys-clock frequencies.

  • evanhevanh Posts: 9,962
    edited 2020-01-12 - 01:45:09
    Err, your sequence is not correct. The docs are talking about when PPPP = %1111 is already in use. When PPPP != %1111 then glitch can't happen. I probably should have said no in my first reply. :)

    So steps are:
    1: Switch to RCFAST mode with pre-existing PLL config staying the same.
    2: Reconfig the PLL mode, discarding settings from step 1 but staying in RCFAST.
    3: Wait 10 ms for oscillators to stabilise.
    4: Switch to the PLL mode.

    The original method is steps 2 to 4, so just step 1 is added for workaround.

    If you know you are in RCFAST already, on power up for example, then original method is fine.

  • What I'm wondering about is the case where you know the system has a crystal installed...

    I think in this case, you should be able to switch to another clock setting without knowing the current clock setting by doing this:

    1: Switch to PLL mode with %PPPP=%1111 (you are now in a known clock state with no glitch possible because of the %PPPP setting)
    2: Switch away from PLL mode while preserving settings from step 1 (switch to, say, rcfast while keeping %PPPP setting)
    3: Switch to the mode you want

    Is there a reason this won't work?
  • Rayman wrote: »
    1: Switch to PLL mode with %PPPP=%1111 (you are now in a known clock state with no glitch possible because of the %PPPP setting)
    That's the one mode that is known to glitch for sure.

  • Are you saying you can’t switch into that mode without a glitch?

    Docs say you just can’t switch out...

    Maybe it’s best to just avoid this mode all together?
  • Assuming the crystal is swinging okay, already, the only thing you need to be careful about is switching away from the PLL when the post divider is set to 1.
  • evanhevanh Posts: 9,962
    edited 2020-01-12 - 20:08:17
    Rayman wrote: »
    Are you saying you can’t switch into that mode without a glitch?

    Docs say you just can’t switch out...
    Oh, I wasn't trying to understand your idea as an alternate workaround. Right, yes, switching into doesn't glitch and by forcing it to that mode it guarantees you aren't switching away.

    And by selecting RCFAST mode in the same config word, it should cover the second criteria of not engaging the PLL for the duration of oscillator settling time too.

    ie:
    		hubset	#%1111<<4 | XOSC<<2		'Switches to RCFAST using safe PLL config
    		hubset	new_clk_mode			'setup PLL mode for new frequency (still operating at RCFAST)
    		or	new_clk_mode, #XSEL		'add PLL as the clock source select
    		waitx	##25_000_000/100		'~10ms (at RCFAST) for PLL to stabilise
    		hubset	new_clk_mode			'engage!  Switch back to newly set PLL
    

    EDIT: Shortened the safe config word to minimum needed.
  • Preliminary testing seems to be fine. :) Good thinking there Rayman.

  • RaymanRayman Posts: 11,352
    edited 2020-01-12 - 22:12:56
    Great! So, this means we don't need to know the current clock setting to safely switch to another, right?

    I wasn't 100% sure you could do this:
    hubset	#%1111<<4 | XOSC<<2		'Switches to RCFAST using safe PLL config
    

    Good to know.
  • evanhevanh Posts: 9,962
    edited 2020-01-13 - 00:15:14
    Rayman wrote: »
    Great! So, this means we don't need to know the current clock setting to safely switch to another, right?
    Yep, so far so good. I've now got this as my regular method. All my test programs will now use it.
    I wasn't 100% sure you could do this:
    hubset	#%1111<<4 | XOSC<<2		'Switches to RCFAST using safe PLL config
    
    Good to know.
    Same. I had a full length config word with multiplier to above 100 MHz and the enable bit set. Tested with that first. Seemed good so tried it this way as well and still good.

  • Can you guys state the new magic recipe for a glitch-free return to RCFAST?
  • evanhevanh Posts: 9,962
    edited 2020-01-13 - 07:19:11
    It feels backwards but the idea is sound.

    Basic idea is that when switching to the prep'ing RCFAST clock source, also force the PLL mode to PPPP = %1111. This works because changing into that mode doesn't glitch. And it also means it doesn't matter if it already was in that mode since it isn't changing out of it.

  • evanhevanh Posts: 9,962
    edited 2020-01-13 - 07:54:27
    Hmm, I think I might have pondered something like this when the glitch was discovered but I shelved pursuing it as not as solid a solution.

    EDIT: Here's my first inclination - https://forums.parallax.com/discussion/comment/1466409/#Comment_1466409

    EDIT2: This is it - https://forums.parallax.com/discussion/comment/1466475/#Comment_1466475

    Yeah, now I remember. I think I'd miss-read the guidance at the time and figured this idea wouldn't be reliable so stop testing it.
  • Slightly unrelated but is it possible to safely change the PLL operating frequency on the fly while keeping the PLL as the active clock source? ie. change MM...MM, PPPP, DD..DD bit values but maintain SS as 11 in a system that has already been setup following it's usual bootup config. What happens?
  • > @rogloh said:
    > Slightly unrelated but is it possible to safely change the PLL operating frequency on the fly while keeping the PLL as the active clock source? ie. change MM...MM, PPPP, DD..DD bit values but maintain SS as 11 in a system that has already been setup following it's usual bootup config. What happens?

    Changing PPPP could cause a glitch. The other two fields could be changed, though. Just beware of frequency overshoot possibly creating too short of a clock pulse and hanging the chip, as a glitch would do.
  • roglohrogloh Posts: 2,768
    edited 2020-01-13 - 13:12:52
    Ok, seems safer to just do it the regular way going back via RCFAST as the intermediate state.
  • > @rogloh said:
    > Ok, seems safer to just do it the regular way going back via RCFAST as the intermediate state.

    Yes. That way works for sure.
  • Rayman wrote: »
    Great! So, this means we don't need to know the current clock setting to safely switch to another, right?

    I wasn't 100% sure you could do this:
    hubset	#%1111<<4 | XOSC<<2		'Switches to RCFAST using safe PLL config
    

    Good to know.

    Is this now the agreed, always safe to do when not known for certain, clock switching code?

    Any recommendations for this switching if video is running?
  • This isn't mutually exclusive to the two handover options. But I guess it really does supersede them since mailboxing can completely return to original use without the handover requirement. RCFAST handover can stay the default for loaders since it doesn't impose any others.

    Video monitors have no issue resync'ing. If you're adjusting the sys-clock then you'll be adjusting the video NCO to match. It would be a good trick to not trip a resync event!

  • roglohrogloh Posts: 2,768
    edited 2020-01-14 - 00:02:33
    @TonyB_,
    In the case of my driver, if you wanted to change the PLL rate while video was running you'd need to re-initialize the video COG with the new timing for the new operating frequency. The driver can't easily re-patch itself on the fly once already up and running, at least the way it is coded at the moment and there's no room to try to add that without taking something else out. Quite a bit of recomputation of COG register parameters is needed, so it is far easier to just restart the COG. The video off time wouldn't last long.

    I imagine the same situation applies to other frequency dependent COGs such as USB.
  • cgracey wrote: »
    Man, the forum software hides things when it sees two @ symbols together.

    Looks to be fixed for now !

  • evanhevanh Posts: 9,962
    edited 2020-01-19 - 01:10:40
    Cool.

    On the other issue with the quoting, I edited a reply to one of Chip's replies and reformatted his quoted section to conform with normal quoting and when I previewed it it looked normal again but I also got a little black popup saying "The quote had to be converted from TextEx to BBCode. Some formatting may have been lost."

  • Thanks Evan. Yeah, there's something odd going on with the quoting. I'm glad you mentioned the TextEx clue.
Sign In or Register to comment.