Optimization/Use of DSP cache

[damiencourousse]

We use a Toro board for our project, with CCS 3.0
The application is some kind of a control loop, including acquisition and generation of analog signals from ADC & DACs of the Toro.
The DSP on the Toro has to perform intensive calculation every step of the control loop.
At last, the DSP communicates data to the host (i.e. writes in SDRAM some data) that indicate the current state of the computed model.
The host reads in SDRAM these values asynchronously (for visualisation purposes), and writes back parameters values of the computed model to the SDRAM of the Toro for the DSP. The parameters values are checked by the DSP during the control loop.

To ensure that the contents of the SDRAM viewed from host and from DSP side would correspond at any time, we had to move the cache settings of the DSP (6711). We moved the L2 mode from 3-way cache with 0x0300 MAR0-15 bitmask to SRAM cache with 0x0001 MAR0-15 bitmask.
That way, contents of the SDRAM are the same viewed from host and DSP sides, and the read/writes of data work properly; but it leaded to a severe performance decrease.
For example, we applied the same cache settings to the Servo example: the servo loop could not run above 20-30kHz.

Do you have an idea how to solve this problem?

Best regards,
Damien

[jhenderson]

Damien -

Disabling the cache is a very inefficient way to insure coherency between the Host and the Target, as you have observed.

The fastest technique is to allocate a buffer for use in communications between the Host and Target in onchip memory. OC memory operates at maximum speed and is not subject to cache effects.

If the buffer you intend to transfer is too large to allocate onchip, then use the Pismo buffer classes to allocate a buffer in external SDRAM (off the global heap). After writing to this buffer from the DSP, be sure to call Flush to insure the contents of the cache are written to SDRAM, so that it can be read by the Host (presumably via HPI).

[damiencourousse]

thank you Jim for your feedback.

My problem is partially solved: I configured L2 as 2-way cache (6711), enabling cache only for external SDRAM (MAR0-15 bitmask of 0x300).

As a first step, I moved my data buffer to onchip memory.
The data buffer is calculated by some kind of control loop, which can run at more than 10kHz (now.. , depending on the amount of calculation to be done.

The funny thing is that when I moved the functions for calculation to onchip memory, (using #pragma), the DSP was somehow "stuck", and did not run. These functions are run in the Interrupt Handler function. I use a program base don the Servo example.

Otherwise, when these functions are not onchip (in external SDRAM), my program runs OK.

Do you have an idea why?

Damien

[jhenderson]

Are you using Dsp/BIOS and the Pismo software libraries? If so, the supplied CDB already configures the MAR registers properly so that SDRAM is cached.

There are a number of potential reasons why that application might not work properly if you relocate routines onchip. For instance, you must be using a memory model supporting far calls and data.

I recommend that you use the debugger in order to characterize the failure. Does it successfully initialize and begin running main(), etc.

I need some additional info in order to diagnose.

[damiencourousse]

Jim-

The MAR registers are configured from the CDB file.
As the use of cache did not work properly before, I had tried a few other settings. Now we came back to the usual MAR configuration used for the Toro (i.e. a MAR bitmask of 0x300).

The project is built supporting far calls and data (-ml3 option).

When routines are relocated onchip, the problem is that the assembly code contains branches to fake addresses, for instance 0xCxxx0000... This occured in initialization routines, before starting the servo loop. I was however not able to reproduce this problem today (??). So let's say everything is OK!


Best,
Damien

[jhenderson]

[ajankevics]

Our application sounds nearly identical with yours. We need to communicate with a Toro while it is running a servo loop heavy with calculations. We thought a buffer in which we do Hpi block reads and writes would serve as a communications portal. We have noticed discrepancies between what the DSP thinks the contents of memory locations are and what the Host thinks the contents are, as viewed using HPI. As suggest by jhenderson, we wrapped our communications buffer in a CharBuffer object, however using Flush() on the CharBuffer after the DSP writes data to the buffer does not change the behavior of the memory discrepancies.

I am relatively new to DSP programming and the DSP memory model. My question is, how do you allocate a buffer that is guaranteed to be in external SDRAM, as jhenderson suggested. I thought that a large static memory array would automatically be assigned to external SDRAM. Either our buffer is not in SDRAM, or I am missing something else.

Andy

[jhenderson]

Unfortunately, the HPI bus is not entirely reliable. There are numerous errata published by TI, and even though the Pismo and Malibu code implements all possible work-arounds, HPI communications is not bullet-proof.

Using operator new will allocate a buffer in SDRAM, since the default memory map places the heap in SDRAM. You can verify this by inspecting the address returned. Pismo Buffer objects also allocate from the heap, so they can be used also.