This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[C6655] Minimizing Main PLL Jitter Usage Note

Hi,

About "Usage Note 9 Minimizing Main PLL Jitter Usage Note" from C6655 errata document.
We suggest the customer to reconfigure PLL on their original bootloader (or application code), but in fact, I'm not exactly sure about the actual problem when we don't follow this usage note. Do you have any comments on this ? 

Best Regards,
Naoki Kawada

  • Naoki,

    In KeyStone I devices, including C665x, the BOOTROM does not always use the most optimum PLL configuration.  It was found after the silicon was characterized that operating the VCO within the PLL at a higher frequency and then dividing it to obtain the PLL output frequency resulted in the lowest jitter.  Therefore, we only support an output divider of 2.

    See section 3.6 of the C665x DM SPRS814 for recommended PLL configurations.  The equation below must be used:

    CLK = CLKIN × ((PLLM+1) ÷ ((OUTPUT_DIVIDE+1) × (PLLD+1)))

    The SECCTL[22:19] register value of OUTPUT_DIVIDE must always be set to [0001] so that the output of the VCO is always divided by 2.  Then the equation above can be used to obtain the required PLLM and PLLD values to properly configure the PLL.

    Tom

     

  • Hi Tom,

    Okay, but let me confirm one more thing. ROM Bootloader picks the information for PLL configuration from common boot table parameter (it would be delivered from BOOTMODE pin configurations), and based on that information, ROM Bootloader sets SECCTL[22:19]. It can be 0 or 1. At this point, even if SECCTL[22:19] is 0, should we still reconfigure PLL on user program ? I think SECCTL[22:19] would be a fixed value (0) under some certain BOOTMODE configurations.

    Naoki
  • Hi Tom,

    Do you have any answers for the above question ? Thank you in advance.

    Best Regards,
    Naoki
  • Naoki,

    I am saying that you should program the PLLs based on the desired frequencies using the equation provided.  The SECCTL[22:19] bits must b e programmed to [0001] if not already at that value.  Please refer to the C6657 GEL file that can be downloaded from:

    http://software-dl.ti.com/sdoemb/sdoemb_public_sw/ti_emupack_keystone1/latest/index_FDS.html.

    Note on line number 1068 that it calls the subroutine prog_pll1_values(pll_mult, pll_div, 1) with the last argument fixed at 1.  The subroutine uses this value to set the SECCTL[22:19] bits to [0001].  The sample code in MCSDK should do something similar.  Therefore, if you follow the examples provided, the requirement in the erratum will be met.

    Tom

     

  • Hello Tom,

    Oops, I had a typo in the previous post. What i wanted to say was :

    ========================================

    Okay, but let me confirm one more thing. ROM Bootloader picks the information for PLL configuration from common boot table parameter (it would be delivered from BOOTMODE pin configurations), and based on that information, ROM Bootloader sets SECCTL[22:19]. It can be 0 or 1. At this point, even if SECCTL[22:19] is 1, should we still reconfigure PLL on user program ? I think SECCTL[22:19] would be a fixed value (1) under some certain BOOTMODE configurations.

    ========================================

    And you answer was ..... "I am saying that you should program the PLLs based on the desired frequencies using the equation provided.  The SECCTL[22:19] bits must b e programmed to [0001] if not already at that value."

    So I understood we wouldn't have to re-configure PLL on application code context when SECCTL[22:19] has being configured as 1 in ROM Bootloader. Correct me if I'm wrong. 

    Best Regards,
    Naoki

  • Naoki,

    We need to tell the customer to follow the recommendation that is in the Errata document.  It says that the customer design should properly re-configure the PLLs and to not rely on the BOOTROM programming.  The GEL file does that.  The MCSDK sample code should do that too.  That guidance is sufficient.

    I do not know the exact details behind this usage note.  I assume that some BOOTROM configurations are suboptimal.  If the customer wants to read the registers after BOOTROM configures the PLLs and determines the optimal configuration already exists, then they can leave it unchanged.  However, we can only support the guidance that we provide.

    Tom

  • Hello Tom,

    Thanks for your answers. I understand your policy for this. I will share this thread with our customers.
    Please note i always suggest the customers to implement the 2nd bootloader in order to do initial or optimal setup for PLL/DDR/PSC. So, I think reconfiguring PLL wil be easy to implement for them.
  • Hello Tom,

    The last question.

    KeyStone Architecture Phase-Locked Loop (PLL) User Guide

    3.1.1 Initialization to PLL Mode

    A sequence 7) has already been assumed that SECCTL.OUTPUT_DIVIDER should be set as 1 (divide-by-2) so I was assuming application code can re-initialize PLL just by following the described sequences after exiting ROM Bootloader.

    At this point, please note PLL multipliers/divisors will be configured prior to SECCTL.OUTPUT_DIVIDER.  Please take a look at sequence 4 and 6.
    On the other hand, the errata document says:

    Note—It is only after programming the SECCTL register to enable the
    divide-by-2 that the following equation can used to program the PLL as
    specified in the data manual.

    CLK = CLKIN × (PLLM+1) ÷ (2 × (PLLD+1))

    This errata statement leads me to understand SECCTL.OUTPUT_DIVIDER has to be configured BEFORE configuring multipliers in PLL.
    So I'm now wondering we might need to change the current PLL re-initialization sequence documented in the above user's guide....
    Could you please clarify on this ?

    Best Regards,
    Naoki

  • We are still so confused by PLL re-initialization.
    PLL re-intialization has been introduced to the errata, so please clarify the exact usage for PLL re-initialization.

    First of all, your recommendation is referring GEL file and porting the related PLL initialization code to the application.
    Yes, I understood this, but its initialization sequences does not match to the descriptions from errata and PLL user's manual:

    - As I mentioned in the previous post, it seems SECCTL.OUTPUT_DIVIDER might have to be configured BEFORE configuring multipliers in PLL, but your GEL file does not. If your answer is we can still follow the initialization sequence (To be more exact, run the code equivalent to Init_PLL() twice), please suggest the same here.

    - Also, the PLL user manual says "Do not re-program the PLLDIVn values if the PLL has previously been placed in PLL mode and is being re-programmed during this initialization" in initialization sequence 8. We can ignore this remark, right ?
    The workaround (usage note) itself is that PLL initialization should be done in application code even if ROM Bootloader has done, so I believe we would have to configure PLLDIVn twice (The first initialization on ROM Bootloader --- it will enable PLL mode, and the second initialization on Application --- PLL usage note) . My understanding is that errata suggestions have higher priority than the PLL user guide for PLL usage. So I belive no problem in double initialization for PLLDIVn register. Please correct me if I'm wrong.

    - Further more, ROM Bootloader looks initializing reserved SECCTL bit field.

    PLL_REG_SECCTL_SET_POSTDIV(secctl,postdiv-1);
    where,
    #define PLL_REG_SECCTL_SET_POSTDIV(x,v) BOOT_SET_BITFIELD((x),(v),16,16)

    So the above code is assuming post divisor should be bit16 on SECCTL, but user guide says the divisor should be bit22-19 and bit16 is stated as *reserved*. This really makes me so confused for SECCTL configuration itself. Please clarify what is true , what is wrong.

    Best Regards,
    Naoki
  • Hello,

    Sorry for rushing you, but we are waiting for your response.

    Best Regards,
    Naoki
  • Naoki-san,

     

    THJ: Sorry for the delay.  I was out for holiday last week and I needed to research your questions this week.  My answers are below:

     

    We are still so confused by PLL re-initialization. PLL re-intialization has been introduced to the errata, so please clarify the exact usage for PLL re-initialization.

     

    THJ: We are not trying to make this difficult or confusing.  Unfortunately, these documents were written by different team members and their choice of words is not completely consistent.  If your customer is using example code provided as part of the MCSDK, this re-initialization should already be included and the required changes minor.  Similarly as I indicated previously, the GEL file does properly enforce all of the requirements from the Usage Note.

     

    First of all, your recommendation is referring GEL file and porting the related PLL initialization code to the application.  Yes, I understood this, but it’s initialization sequences does not match to the descriptions from errata and PLL user's manual:

     

    - As I mentioned in the previous post, it seems SECCTL.OUTPUT_DIVIDER might have to be configured BEFORE configuring multipliers in PLL, but your GEL file does not. If your answer is we can still follow the initialization sequence (To be more exact, run the code equivalent to Init_PLL() twice), please suggest the same here.

     

    THJ: There is no need to perform the re-configuration twice.  That is not what is meant by the word ‘after’.You are referring to the below note from Usage Note 9:

     

    Note—It is only after programming the SECCTL register to enable the

    divide-by-2 that the following equation can used to program the PLL as

    specified in the data manual.

     

    CLK = CLKIN × (PLLM+1) ÷ (2 × (PLLD+1))

     

    It is stating that the provided equation is only valid when SECCTL.OUTPUT_DIVIDER is set to [0001].  This issue arises because the default value for SECCTL.OUTPUT_DIVIDER is [0001].  It is assumed to always be this value.  Therefore, some routines and related discussion do not write this value while others do.  If a routine has previously written SECCTL.OUTPUT_DIVIDER to [0000], then the provided equation will not provide the expected results.  Therefore, this Usage Note suggests that all initialization routines set SECCTL.OUTPUT_DIVIDER to [0001] and that this must be done in the customer’s application code since the ROM Bootloader does not always use the optimum settings.

     

    - Also, the PLL user manual says "Do not re-program the PLLDIVn values if the PLL has previously been placed in PLL mode and is being re-programmed during this initialization" in initialization sequence 8. We can ignore this remark, right?

    The workaround (usage note) itself is that PLL initialization should be done in application code even if ROM Bootloader has done, so I believe we would have to configure PLLDIVn twice (The first initialization on ROM Bootloader --- it will enable PLL mode, and the second initialization on Application --- PLL usage note) . My understanding is that errata suggestions have higher priority than the PLL user guide for PLL usage. So I belive no problem in double initialization for PLLDIVn register. Please correct me if I'm wrong.

     

    THJ: The PLLDIVn registers and the SECCTL.OUTPUT_DIVIDER bit field are 2 different things.  Please see Section 8.5.2.2 on page 138 of the Data Manual for information about the PLLDIVn registers.  They are also listed in Table 8-14 and discussed in general at the beginning of Section 8.5.  The proper use of SECCTL.OUTPUT_DIVIDE is discussed in Section 3.6 and also in Section 8.5.2.1.  Figure 8-7 shows both OUTPUT_DIVIDE and the PLLDIVn blocks so that you can see their separate purposes.  Again, the GEL file shows the proper sequence for setting the PLLDIVn registers.

     

    - Further more, ROM Bootloader looks initializing reserved SECCTL bit field.

    PLL_REG_SECCTL_SET_POSTDIV(secctl,postdiv-1);

    where,

    #define PLL_REG_SECCTL_SET_POSTDIV(x,v) BOOT_SET_BITFIELD((x),(v),16,16)

    So the above code is assuming post divisor should be bit16 on SECCTL, but user guide says the divisor should be bit22-19 and bit16 is stated as *reserved*. This really makes me so confused for SECCTL configuration itself. Please clarify what is true , what is wrong.

     

    THJ: This code adds confusion by naming this macro …SET_POSTDIV.  This write is actually to bit 16 which is a reserved bit that is supposed to be set to a ‘1’.  This is not the same as writing to SECCTL.OUTPUT_DIVIDER which is in bits [22:19].

     

    THJ: Hopefully this clarifies your understanding.

     

    Tom