DEVSPEED register and the TSCL/TSCH registers

Anand,

There was a notice sent out recalling the units which had the issue due to an incorrect programming of DEVSPEED at test.  Your purchasing department should have received the notice.  This is only a very limited number of 2.0 units that had this issue.

May I ask what boot method you are using?

As for TSC registers, they are based of of CPU clock not VBUS clock (i.e. 1 tick per 1ns for a 1GHz clock, and it would be 1 tick per 0.833ns for 1.2GHz clocking.) Hence 1s = 1e9 ticks.

Please note that these device may not operate properly at 1.2GHz and the work around provided in the notice that was sent out should be followed.  Please contact your local sales representative if you did not receive this notice.  If you purchased it through a 3rd party distributor, please contact them.  They would have the notice.

Best Regards,
Chad.

Chad,

We are booting over PCIe. Should not the DEVSPEED register reading correspond to the TSCL/TSCH pair measurement?

The chips are already on our cards some of which are out in the field. So we are requiring a way to tell the boards with the problematic parts from the others. The timer result shows that this may  not be the way to tell the bad boards.

Regards

-Anand

That would depend.  If you main software is reinitializing the PLL manually, then it would be overwritting what the BootROM configured the PLL to from the beginning.

The TSC measurements vs time are going to be consistent with whatever the PLL is programmed to output.  The DEVSPEED is only there as an aid to let the BootROM automatically configure the PLL setting.  The TSCL litterally ticks once per CPU clock period (SYSCLK) no matter what the PLL is configured to, and no matter what the DEVSPEED says.

Best Regards,

Chad

Question: Have you found a device w/ the DEVSPEED programmed to 1.2GHz (i.e. by reading the register?)  If so have you loaded your code, halted it and check what the PLL settings were?  Also, you can probe SYSCLKOUT which is CPU/6 (SYSCLK/6) on this board. 

I'd suggest verifying if your code is overwritting the PLL configuration done by the BootROM.

If it's not reprogrammed and is producing 1.2GHz SYSCLK then you can work with this device to create a way to identify it on the other boards. 

That said, I'd highly recommend implementing the workarounds suggested in the notice that was sent out.

Best Regards,

Chad

Chad,

I the HW guy working on this.  we did get the notification. all of our prototypes, and our Mfg. Pilots were built with chips from the 'bad lots' list. We confirmed that these DSPs read 1200MHz in DEVSPEED on 5 boards so far.  We have a 100 MHz clock on the CORECLK pins.  BOOTMODE[12:10] was strapped to 0b011. On  a device where DEVSPEED reads 1000Mhz, looking at table 2-13 in SPRS691C, this would give us a 1GHZ core clock.  Instead of swapping out 40 DSPs, we changed BOOTMODE[12:10]  to 0b111 (122.88MHz) on boards with the bad lot code, but left the input clock frequency at 100MHz.      According to the core clock speed calculation, this sould give us core clk = 100MHz *625/(2x32) = 976.6MHz

the fuses for the DEVSPEED register directly affect the values for PLLD and PLLM, correct?

-Mike

Interesting. If we had bootROM code that only looks at the BOOTMODE[12:10] pins,  but ignores the DEVSPEED register, that would explain the behavior we are seeing.

How do we read PLLM and PLLD values?

Hi Chad, Mike

I am copying the Core PLL setup below & Core PLL initialization code. In our boot code that does platform initialization, we configure the PLL without reading the DEVSPEED register.

Does this completely explain why the core clock is at 1GHz despite DEVSPEED at 1200MHz?

Thanks

Arun

PLL init code:

/* PREDIV */
#define PLATFORM_PLL_PREDIV_val (1)

/* POSTDIV */
#define PLATFORM_PLL_POSTDIV_val (2)

/* Default PLL PLLM value (100/1*(20/2)) = 1.0GHz) */
#define  PLATFORM_PLL1_PLLM_val (20)

/* Default PLL PLLD value for 1.0GHz) */
#define  PLATFORM_PLL1_PLLD_val (1)

        memset(&pllc_hwSetup, 0, sizeof(PllcHwSetup));

        /* Setup PLLC hardware parameters */
        pllc_hwSetup.divEnable  = (CSL_BitMask32) (PLLC_DIVEN_PLLDIV2 |
                                                   PLLC_DIVEN_PLLDIV5 |
                                                   PLLC_DIVEN_PLLDIV8) ;

        /* Setup PLLC hardware parameters */        
        pllc_hwSetup.pllM       = PLATFORM_PLL1_PLLM_val - 1;
        pllc_hwSetup.preDiv   = PLATFORM_PLL_PREDIV_val - 1;
        pllc_hwSetup.pllDiv2  = PLATFORM_PLLDIV2_val - 1;
        pllc_hwSetup.pllDiv5  = PLATFORM_PLLDIV5_val - 1;
        pllc_hwSetup.pllDiv8  = PLATFORM_PLLDIV8_val - 1;
        pllc_hwSetup.postDiv  = PLATFORM_PLL_POSTDIV_val -1;

        /* set Pll */
        status = CorePllcHwSetup (&pllc_hwSetup);

Chad,

The software does modify the PLLs to set the chip to 1GHz - this is basically reference code from the C6678 PDK written for the 1GHz EVM (copied below in another response). This does explain the difference in behavior.

Thanks for the quick response & have a nice weekend

Anand