TMS320F28075: Timing of Multiplication in C

Keyur,

You're basically saying that it is taking 120 clock cycles to execute the code (1 uS at 120 MHz is 120 cycles).  OK, so something is off here.  The instructions are basically single cycle as you said.  We need to just figure out what is going on.

Are you sure you are running at 120 MHz?  Did you test this using XCLKOUT pin?

Are you running from flash or RAM?  If flash, do you have the flash wait-states set?

Try this: get rid of your multiply code, and place a bunch of NOPs in between the GPIO set and clear, like this:

       GpioDataRegs.GPASET.bit.GPIO31 =1 ;//to profile code timing

       asm(" RPT #198 || NOP);      // 200 cycles

       asm(" RPT #198 || NOP);      // 200 cycles

       asm(" RPT #198 || NOP);      // 200 cycles

       asm(" RPT #198 || NOP);      // 200 cycles

       asm(" RPT #198 || NOP);      // 200 cycles

       GpioDataRegs.GPACLEAR.bit.GPIO31 =1 ;//to profile code timing

This should take roughly 1000 cycles to execute (plus a few more for the GPIO setting and clearing).  It will eliminate flash setting problems because the RPT will only have to fetch the NOP once.  If it is still too slow, that means your clocks are not 120 MHz.  If it is correct timing, then I'd look at the flash (and probably there is something else too as I don't think the flash wait-states alone would account for everything).

Regards,

David

Hi David

Thanks for the response.

1)      I checked out the clock frequency using  XCLKOUT pin. It is 120MHz.

2)      I am running my code from flash I have not copied it to ram during power on time.

3)      I tried executing your code and it takes 8.4uS that is near by 1000 clock cycles at 120MHz.

4)      I tried running the code from ram and the problem solved!!!  It runs around 10 times faster. The multiplication which was earlier taking 1uS time now takes only 95nS time. I know that moving code to RAM makes executing faster but didn’t know that it makes execution 10 times faster.

Regards,

Keyur

Hi David,

I want to ask another question regarding copying the code to RAM.

I have read this https://e2e.ti.com/blogs_/b/toolsinsider/archive/2015/12/11/helpful-tips-executing-code-from-ram and i am using this to move function to ram.

I am using the linker file (2807x_FLASH_CLA_lnk_cpu1.cmd) which is given in control suite at

C:\ti\controlSUITE\device_support\F2807x\v210\F2807x_common\cmd

As I have mentioned in the above linker file both CLA and CPU ram functions are placed in RAMLS4_LS5. But if we want to run CLA code from this ram we have to share this memory between CLA and CPU using

MemCfgRegs.LSxMSEL.bit.MSEL_LS4 = 1;  

This will result in problem of Access Arbitration as per the technical reference manual(SPRUHM9B) section 2.11.1.5.

So is it recommended to do this?
Should I use same RAM for CLA and cpu programs?

Or I should use separate RAM blocks for both the codes?

Right now I am using differnt ram bocks.

Thanks

Regards,

Keyur

Keyur,

On the original issue of running your multiply code, I suspect you do not have the flash wait-states configured properly.  Running from RAM vs. flash does not make that much of a difference.  At 120 MHz, you would likely not notice much difference at all given the flash pre-fetch buffer.

On your new question of sharing LS RAM between the CPU and the CLA, if you intend to put CLA code in the memory then you cannot access that memory from the CPU.  The sharing is for data access from CPU and CLA.  See spruhm9b section 2.11.1.2: "CPU access to all memory blocks, which are programmed as CLA program memory, are blocked."  My suggestion would be to keep CPU and CLA code in separate blocks.

Regards,

David

Keyur:
(From the Piccolo Multi-day workshop)
FlashRegs.FOPT.bit.ENPIPE = 1;
This is used to "enable the flash pipeline." For some reason, it is defaulted to 0. If it is not turned on, the flash will not run at a faster speed.

Hopefully, this helps.

Hi David and Todd,

Here is the Flash configuration which I am using.
mostly  it  is taken from the device specific demo code.

    Flash0CtrlRegs.FPAC1.bit.PMPPWR = 0x1;
    Flash0CtrlRegs.FBFALLBACK.bit.BNKPWR0 = 0x3;

    //
    // Disable Cache and prefetch mechanism before changing wait states
    //
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.DATA_CACHE_EN = 0;
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.PREFETCH_EN = 0;

    //
    // Set waitstates according to frequency
    //
    //      *CAUTION*
    // Minimum waitstates required for the flash operating at a given CPU rate
    // must be characterized by TI. Refer to the datasheet for the latest
    // information.
    //
    Flash0CtrlRegs.FRDCNTL.bit.RWAIT = 0x2;
 
    //
    // Enable Cache and prefetch mechanism to improve performance of code
    // executed from Flash.
    //
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.DATA_CACHE_EN = 1;
    Flash0CtrlRegs.FRD_INTF_CTRL.bit.PREFETCH_EN = 1;

    //
    // At reset, ECC is enabled. If it is disabled by application software and
    // if application again wants to enable ECC.
    //
    Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0xA;

I could not find anything like

 FlashRegs.FOPT.bit.ENPIPE = 1;

in the datasheet or TRM of 28075.

Thanks for correcting - sorry 'bout that. Why was the name changed on flash pipeline enable?

Hi Todd,

Todd Anderson78572 said:

Thanks for correcting - sorry 'bout that. Why was the name changed on flash pipeline enable?

Hi David and todd
You two are really “Guru” of the community.
Actually InitFlash(); was the problem.
Initially, when I measured time with flash this function was not present.
But when I moved the code to ram I also introduced this function. So when you asked me about the flash configuration I gave you all the register details about flash wait stat.

I consider this issue solved now.

Sorry for the silly issue.

Thanks for the help, both of you.
Regards,
Keyur