• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 2044 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

GPMC bursts with SDMA - concurrency

laurent poyart
Prodigy 180 points

Hi,

I'm using a logic analyser to check the GPMC signals on a DM37x target. I simulate transfers from ARM & DSP towards a FPGA. I'm able to get bursts on the ARM side and also on the DSP side. I'm making simultaneous SDMA transferts on ARM (SDMA channel 0) and DSP (SDMA channel 1) from SRAM internal memory to GPMC address space. I use CS1 for the DSP and CS6 for the ARM and my SDMA transfers size is 128words long.

On the analyser , I can see that each SDMA transfer is divided in several bursts (I think it depends on the ATTACHEDDEVICEPAGELENGTH GPMC parameter). Then the Chip Select goes high several times during the DMA transfert. Because the SDMA transferts is divided in several burst, I can see that some ARM and DSP transfers are interleaved (I get 1 burst on CS1 , then 1 burst on CS6 and so on until the end of both DMA transfers).

I would like to know if there is a way to configure arbitration so that DSP transfers are no delayed by the ARM transfert. I would like to control DSP transfer latency and to avoid the ARM to disturb DSP transfers?

Best regards.

Laurent

  • 0
    TI__Guru 65405 points

    Hi Laurent,

    According to the TRM Bursts larger than the memory page length are chopped into multiple bursts transactions. Due to the alignment requirements, a page boundary is never crossed.

    Therefore could you check and share what is the memory page size of your system and could you check the value of the GPMC_CONFIG1_i register?

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 180 points
    Hi Tsvetolin,
    My GPMC configuration on CS1 is the following:
    • Start address : 0x20000000
    • GPMC_CONFIG1_i = 0xF9001002
    ATTACHEDDEVICEPAGELENGTH :0x2 = 16Words . Is it the maximum configurable page length for GPMC ? Can I use 0x3 (reserved) to set my own interface size?
    My DMA transfer (128 x 16bits) is larger than the ATTACHEDDEVICEPAGELENGTH parameter.

    My GPMC is not connected to a real device on my EVM (Mistral Board DM37x), I only use an expansion connector to check the GPMC signals. I try to simulate transfers with an FPGA.Can I expect greater bursts in a single transaction?

    Regards.
    Laurent
  • 0 in reply to laurent poyart
    TI__Guru 65405 points

    Laurent,

    The max allowed value of the ATTACHEDDEVICEPAGELENGTH field is 0x2: 16 words which you are already set. The value 0x3 is reserved and not recommended to set this value. I don't expect greater bursts in a single transition with this configuration.

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 180 points

    Hi Tsvetolin,

    So it explains what I observe on the analyser. My DMA transfer is made of several transactions which depends on the ATTACHEDDEVICEPAGELENGTH parameter.

    Then when I test concurrency between ARM on GPMC CS6 and DSP on GPMC CS1 (they both have the same GPMC configuration and use separated SDMA channels), when the transfers start  more or less at the same time, I get:

    . DSP SDMA Transfer - CS1 Transaction 1 (x Words depending on ATTACHEDDEVICEPAGELENGTH parameter)

    . ARM SDMA Transfer -CS6 Transaction 1

    . DSP SDMA Transfer - CS1 Transaction 2

    . ARM SDMA Transfer - CS6 Transaction 2

                .....

    The SDMA transfers alternate between DSP & ARM transaction. I didn't set the same priority for the SDMA. DSP is configured with High Priority and ARM is configured with Low Priority. Is there a way of favoring one CPU so that it completes its SDMA transfer before the other CPU grant the bus?

    Regards.

    Laurent

  • 0 in reply to laurent poyart
    TI__Guru 65405 points

    Hi Laurent,

    The set priority does not takes effect on the chopping of the bursts. Therefore I think it is not possible to cheat the configured burst length value and to use longer bursts.

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 180 points

    Hi Tsvetolin,

    Thanks for your answer.

    Laurent