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.

SM320C6678-HIREL: Main PLL configuration Issue in DSP

Part Number: SM320C6678-HIREL
Other Parts Discussed in Thread: SYSBIOS

Dear Sir,

 

In our project, we are facing issues when Main PLL configuration is enabled i.e., when DSP working frequency is changed to 1GHz from Core Clock

 

In Setup: DSP Board : 1905006 and FPGA Board : 1905002

Observations:

  1. When Main PLL configuration is disabled i.e., (Core Clock Freq – 156.25MHz)
    1. Application is successfully executed and Waiting for packets from GMC (Core Clock Freq – 156.25MHz)
    2. When Main PLL configuration is enabled i.e., (Working at Freq – 1GHz)
      1. Application is crashed at NetworkStart() which initializes IP addresses and creates a task for GMC command handling
      2. Disabled SRIO configuration and Tested, Still the issue exists
      3. Ethernet Configuration:

                                                               i.      If QMSS is enabled and CPPI configurations are disabled, Application is executed successfully but task for GMC command handling will not be created

                                                             ii.      If CPPI is enabled and QMSS configurations are disabled, Application is executed successfully but task for GMC command handling will not be created, Debug is in progress

                                                            iii.      Disabled PASS PLL configurations, still the issue exists

 

In Setup: DSP Board : 1905004 and FPGA Board : 1905005

Observations:

  1. When Main PLL configuration is disabled i.e., (Core Clock Freq – 156.25MHz)
    1. SRIO ports are not operational, read/write are inconsistent and Ethernet switch configuration is inconsistent
    2. Application is executed successfully
    3. When Main PLL configuration is Enabled i.e., (Working at Freq – 1GHz)
      1. SRIO ports are not operational, read/write are inconsistent and Ethernet switch configuration is inconsistent
      2. Application is crashed in NetworkStart() which initializes IP addresses and creates a task for GMC command handling

 

Application crash Error:

ti.sysbios.heaps.HeapMem: line 446: assertion failure: A_invalidFree: Invalid free xdc.runtime.Error.raise: terminating execution

  • Hi,


    What are the PLL configurations that you have done? Did you follow the settings done in evmc6678l gel file?

    Best Regards,
    Yordan

  • Dear Yordan,

    We are following the same evmc6678l gel file settings for configuring the DSP. Below are the PLL configurations for Input Clock Frequency = 156.25MHz. At 421.875, the DSP application executes successfully without any errors.

     1.     For 1 GHz:  PLL_M : 63 ;  PLL_D : 4

     2.     For 421.87 MHz:  PLL_M : 26; PLL_D : 4

    In Setup: DSP Board : 1905004 and FPGA Board : 1905005

    Observations:

    1. When Main PLL configuration is Enabled
      1. a.       Working Freq at 421.87MHz

                                                                   i.      SRIO Ports are operational and it’s consistent

                                                                 ii.      Ethernet switch configuration is consistent

                                                                iii.      Application is not crashing and it’s working fine as expected

    1. b.      Working Freq above 421.87MHz

                                                                   i.      SRIO Port’s operation and it’s read/write are inconsistent

                                                                 ii.      Ethernet switch configuration is inconsistent

                                                                iii.      Application crashed in NetworkStart() which initializes IP addresses and creates a task for GMC command handling

    1. c.       Working Freq below 421.87MHz

                                                                   i.      SRIO Port’s operation and it’s read/write are inconsistent

                                                                 ii.      Ethernet switch configuration is inconsistent

                                                                iii.      Application is not crashing and it’s working fine as expected

     Also please note that, we have designed 4 designs with this DSP processor. All other three are working consistently with  EVM PLL configurations.  We are facing  in this design only. 

  • Hi,

    Is that correct your core input clock is 156.25 MHz, then with PLL_M = 63 ans PLL_D = 4. How do you reach 1000MHz? 156.25 * (63+1)/(4+1)= 2000. Do you have OD?

    What is the input clock to PA? Do you have the PA PLL setup? 

    Regards, Eric

  • Hi,

    You mentioned several modules in the E2E, I'd like to know the input clock frequency to each of them:

    • DSP core: 156.25MHz?
    • PA
    • SGMII
    • SRIO

    Also, a snapshot of those by running the GEL file http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture#Debug: ===> C6678 Debug Gel Script:

    • Device_Config_State_Snapshot
    • C6678_papll_config
    • Sgmii_All_Serdes_Config_Snapshot
    • Srio_All_Serdes_Config_Snapshot

    Regards, Eric

  • Hi Eric,

    We have tested our software with 3 different versions of C6678 based custom board (all with same clock input frequency);

    • With 1GHz core PLL configuration, two versions of our custom boards are working fine but only in one board we are facing this issue i.e. in that particular board, all interfcaes of the board works fine until 421MHz core pll setting and beyond that (>421MHz to 1GHz) core pll setting DSP core hungs/crashes during ethernet interface initialization.

    The input clock frequency datails are as following,

    • DSP core: 156.25MHz
    • PA: Not Given
    • SGMII: 156.25MHz
    • SRIO: 156.25MHz

    Please find the attached gel file for the following details,

    • Device_Config_State_Snapshot
    • C6678_papll_config
    • Sgmii_All_Serdes_Config_Snapshot
    • Srio_All_Serdes_Config_Snapshot
    • evmc6678l_customBoard.gel

  • Hi Eric,

    We have tested our software with 3 different versions of C6678 based custom board (all with same clock input frequency);

    • With 1GHz core PLL configuration, two versions of our custom boards are working fine but only in one board we are facing this issue i.e. in that particular board, all interfcaes of the board works fine until 421MHz core pll setting and beyond that (>421MHz to 1GHz) core pll setting DSP core hungs/crashes during ethernet interface initialization.

    The input clock frequency datails are as following,

    • DSP core: 156.25MHz
    • PA: Not Given
    • SGMII: 156.25MHz
    • SRIO: 156.25MHz

    Please find the attached gel file for the following details,

  • Hi,

    Can you clarify:

    Version 1 board: how many in total? /0 failure?

    Version 2 board: how many in total? /1 failure?

    Version 3 board: ? /?

    Where your PA get the clock? PA needs to have 1050MHz input clock, then there is an internal divider /3, to get 350MHz clock. 

    If you have only 1 board had the issue, then I would think that is the hardware problem, not your GEL setting. Are you able to run the GEL we provided to collect the data?

    Regards, Eric

  • Hi Eric,

    We have 2 boards in each of our versions, in 2 versions all the boards are working fine with 0 issues. only in the 3rd version we are facing this issue at higher core clock PLL settings (>4210HHz).

    Please guide us in debugging the Hardware, we have the input clock and the voltages; all are fine as expected. Please let us know what all will be the possible reasons for this particular issue (Board not stable at higher core clock  frequency settings)

    With Thanks and Regards,

    Senthilkumar R

  • Dear Eric, 

    As Senthil said,  we are facing this issue only with 3rd version boards.  DSP core clock, and voltages are measured and they are within specified range.  Power sequence is also same as other two version of boards. 

    We have tried with both sequences as recommended in datasheet but no change in performance.  

    1. Core-Before-IO Power Sequencing
    2. IO-Before-Core Power Sequencing

    Also we have tried by increasing rail to rail delay. We wanted to try with same delay that you have implemented in EVM. Could you please share the power on rail to rail delay details.

    If any issues with hardware peripherals, DSP application should not get terminated. It should through the error that interface test failed.  What hardware parameter can degrade PLL speed? Please suggest what could be the route cause for this issue.

    Regards

    Nrupathunga.KS

  • Hi,

    1 out of how many board in 3rd version has this issue?

    It looked to me that you used a GEL to initialize board at the beginning, for a particular board, if CPU is set to > 420MHz, the application stopped working. Is this the correct understanding? Or, your application is changing CPU speed at run time?

    Regards, Eric

  • Hi,

    Also, what is your expectation for the test with different CPU speed? For operation of the core clock under 800MHz is not valid when using high speed interfaces.  I am not surprised that SRIO and ENET are unstable. 

    For this bad board, are you able to run the CPU at 1 GHz as other boards?

    1.   Working Freq above 421.87MHz =========> what is the results for running at 1GHz?

                                                                   i.      SRIO Port’s operation and it’s read/write are inconsistent

                                                                 ii.      Ethernet switch configuration is inconsistent

                                                                iii.      Application crashed in NetworkStart() which initializes IP addresses and creates a task for GMC command handli

     

    Regards, Eric

  • Any update?

    Regards, Eric

  • I am closing this E2E thread as no update, please open a new one if you have further information.

    Regards, Eric

  • Hi Eric,

    Thanks for your support. 

     It was an issue with PACLKSEL settings. PACLKSEL pin seting supposed to be low as CORECLK is used as the input to PASS PLL but CPLD was driving high. 

    CPLD code has been modified to set PACLKSEL is permanently low. System is working now. 

    Regards

    Nrupathunga.KS