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.

DM3730, LPDDR, Performance

Other Parts Discussed in Thread: DM3730

Hello. I'm exploring capabilities of the DM3730 which I have on my BeagleBoard-xM, and currently I'm faced with the task of configuring and fine-tuning the SDRAM controller to achieve the best characteristics possible.

As a rough estimate of the pinnacle of performance, I'm assuming that, as I'm dealing with DDR, the maximum L3 frequency being 200MHz, and the data bus width set to 32bits, the fastest I could get with this configuration is 1.6Gbytes/sec. I'm using sDMA to funnel data from DDR to internal static RAM, so I'm trying to find optimal settings for both controllers to get as close as possible to 1.6Gbytes/sec.

However, the best I could achieve is barely one fifth of that (~300 Mbytes/sec). So my question is, what is the best the DM3730 can do in terms of data transfers inside the chip as well as between internal storage modules and external memories? What are the surest ways to attain this limit of performance?

Thank you in advance/

  • Hi Sergay,
    The measured speed of ~300 MBytes/sec seems very low for transfer between DDR and internal static RAM because the L3 interconnent is used and the expected speed is up to 1.6 GBytes/sec.
    I'm only can guessing about the reason for the low transfer speed but it should be due to software implementation of the copping method. Some of the high language functions like memcpy are not optimized enough and can cause decreased transfer speed. Assemblers function can optimize transfer speed.
    Also I suggest you to check the CM_CLKSEL_CORE[1:0] CLKSEL_L3 register value which selects the L3 interconnect clock (L3_CLK) and divider but the default value 0x1 means L3_CLK is CORE_CLK divided by 1 which is optimal.

    BR
    Tsvetolin Shulev
  • Hello Tsvetolin.

    Thank you for your suggestions. I'm not sure however that the problem has its roots in the unoptimized C-functions because the only C code that I employ to organize movement of data is updating registers. Basically the entire code consists of lines like {*pREG = Reg_Value}, and this is it. To move data, I'm using sDMA.
    Unfortunately, at this point I am no longer capable of finding the bottleneck which causes the system performance to drop that low. I'm beginning to suspect that the biggest troublemaker is sDMA but I have no idea how to check that or how to rectify it, how to increase the throughput.

    Can you give me some other ideas to that effect?

    Thank you in advance.
  • Hello, it's me again.

    Are there any suggestions yet?

    Thank you.
  • Sergey,
    The optimal performance could be achieved by reading or writing bigger blocks of data and using assembler code. In other case should be added some delay.

    BR
    Tsvetolin Shulev