• State
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 1688 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM335x GPMC cycle2cycle delay

Stefano Bisi
Intellectual 460 points

Other Parts Discussed in Thread: SYSBIOS

Hello all,

we are testing GPMC interface in multiplexed address data, asynchronous mode.GPMC_FCLK is 100 Mhz.

 We have a static RAM on CS0 and we tried some different  access with fixed patterns to verify overall performance whit oscilloscope.

We try to make read and write access at 8 bit 16 bit and 32 bit .

We set 2 for both cycle2cycle delay and busturnaround parameter, so we expect 20 nS between accesses (plus some nanoseconds for the execution of few machine instructions, of course ).

But we found that the minimum delay between two accesses is 200 nS; the only way to get 20 nS is moving 32 bit ( that is two 16 bit move ).

We can't understand the reason of such long interval.

Thank in advance

Stefano & Mario

  • 0
    TI__Guru**** 393215 points
    Hi Stefano & Mario,
     
    What software are you running?
  • 0 in reply to Biser Gatchev-XID
    TI__Guru**** 393215 points
    Since you are talking about only one CS signal, section 7.1.3.3.8.3.7.2 of the AM335X Technical Reference Manual Rev.I is relevant about CYCLE2CYCLEDELAY. Check also section 7.1.3.3.8.3.7.1 for the conditions when BUSTURNAROUND is valid.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 460 points

    Hi Biser

    we are running a small piece of code that read and write memory . GPMC configurations rutines are from AM335x_sysbios_ind_sdk_1.1.0.1 .

    We are debugging board whit Code composer studio V5.5 connected through XDS100 V2.

     

    Thank in advance

    Stefano & Mario

     

  • 0 in reply to Stefano Bisi
    TI__Guru**** 393215 points
    Are you executing code from internal RAM? Also there is the L3 interconnect which adds some delay, although it should be small. Then there is also alignment. Have you tried to aligh everything on a 32-bit boundary?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 460 points

    Our code runs from DDR3; stack and most of data are located in internal ram. GPMC accesses are only for external sram and I/O.

  • 0 in reply to Stefano Bisi
    TI__Guru**** 393215 points
    Have you tried to write/read large amount of data on the GPMC? Do you have ARM caches enabled?
  • 0 in reply to Biser Gatchev-XID
    Intellectual 300 points

    Hi all,

    I have the same issue described here when I do consecutive accesses in code to a FPGA connected by GPMC. The delay between accesses is 200 nS. I think the reason of this delay is the L3 Slow bus and the AM335x peculiar architecture.

    But when I have implemented the data transfer between DDR and FPGA by EDMA, the throughput that has been achieved is about 43 Mword/s, 688 Mbps.

    I think that we can improve this transfer rate by enabling the burst feature of the GPMC, to activate the chip select for each burst only, and do each burst transfer at maximum clock rate, 100Mword/s. But when I have tried to activate the burst WRITEMULTIPLE bit of GPMC, the DMA transfer does not work. Could you explain me if I can activate simultaneously DMA and GPMC burst. Is there any tutorial or source codeof this?

    Thank you and best regards,

    Gilen

  • 0 in reply to Biser Gatchev-XID
    Intellectual 360 points

    Hi Biser.

    If you I move just one 32-bit integer, the two 16-bit accesses are very near (2x10 nanoseconds, as set by cycle2cycledelay).
    If I loop moving a vector of 16-bit integers one integer at each loop, interval between to 16-bit accesses is 200 to 400 nanoseconds. And the loop code generated by CCSV5 compiler consists of very few machine instructions ...

    Yes, cache is enabled; at least, Cache_getEnabled() function always returns 0x000F (both L1 and L2, both data and instructions). "Always" means: both at the very beginning of function 'main' and after calling MmuInit function (in main) and at the very beginning of the first task created after BIOS_start.
    I was afraid cache is disabled during debugging, but released application acts as debug application.

    I read about L3 interconnect slowness; is there some special way to configure L3 in order to achieve high throughput?
    We are designing a kind of general purpose PLC and cannot ensure application programs will fit into on-chip ram; our customers just want to be free of writing big application which can be run in ddr3 and take profit of L2 and L1 caches.

    Please let us know.

    Mario and Stefano

     

  • 0 in reply to Mario Giovanni Casali
    TI__Guru**** 393215 points
    Possibly DMA transfer would speed things up, but I'm not a software expert and cannot say how this can be done.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 300 points

    Anyone else in Texas Instruments that could answer to this issue?

    Regards,

    Gilen