• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 97 subscribers
  • Views 804 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.

[C6747] Narrow mode in EMIFB/SDRAM

yl
Expert 1215 points

Hi,

Have anyone tried to benchmark EMIFB/SDRAM on EVM6747? I did 

    val +=*pdata; *pdata++ = val;

through the entire SDRAM and found that whether "narrow mode" is on or off made no difference. Any idea?

Thanks

 

  • 0
    TI__Mastermind 18130 points

    This is a pretty subjective test. What are you trying to prove with it? What size data are you passing through the EMIF (32-bit, 16-bit?)? The NM bit only determines the size of the bus and should have little performance difference aside from this. With that said, if you are trying to send 32-bit values out through the EMIF you should see some improvement with NM=0 (bigger bus width means more data out per transfer).

  • 0 in reply to TimHarron
    Expert 1215 points

    Because my program on C6745 runs at half of the speed I can achieve on EVM6747. I am not aware of a way to perform a benchmark on code excution from SDRAM. So I figured writing/reading data from SDRAM can give me some idea.

    My goal is to find out the overall throughput of SDRAM with or without NM. I am not 100% sure that my test is valid and that is why I asked if anybody had done similar things.

  • 0 in reply to yl
    TI__Mastermind 18130 points

    There is no reason the C6745 should inherently run 50% as fast as the C6747. Both devices use the same DSP core and have the same amount of on-chip memory. Both are capable of running at 300MHz. Despite the small peripheral reduction these parts are virtually identical.

    This leads me to think that there is something specific to the C6745 board or that board's software (assuming they are not the same) that is causing the decreased performance. Can you confirm that you are using the appropriate PLL configuration? If using EMIFA is the value of SYSCLK3 any different between the two boards?  

  • 0 in reply to TimHarron
    Expert 1215 points

    The main difference between 6745 and 6747 that concerns us is the data bus width. Because the code is executed from SDRAM, so narrower bus could mean it takes longer to load the code into cache, and in turn degrade the performance.

    The PLL settings are the same on both boards, the xtal frequency is a little lower though. 

    see http://community.ti.com/forums/t/6577.aspx

  • 0 in reply to yl
    TI__Mastermind 18130 points

    Yan said:
    The main difference between 6745 and 6747 that concerns us is the data bus width. Because the code is executed from SDRAM, so narrower bus could mean it takes longer to load the code into cache, and in turn degrade the performance.

    I think this is the answer to your question. If you are running code from external memory then the C6747 has a 2x advantage due to the bus width. Note that if you are configuring L2 as cache that once the code is cached each processor should run at the same speed (assuming there are 0 or very few cache misses). The SDRAM interface is EXTREMELY slow compared to L1 and L2 on-chip memory, and furthermore cripples the performance of the CPU because of the 256-bit bus width capability from L1 to CPU.

    *edit* You may want to browse this app note which discusses improving code performance. This document discusses heavy optimization (including the performance hits of off-chip memory) so this may be a good reference.

  • 0 in reply to TimHarron
    Expert 1215 points

    No, I don't think this is the answer because my program for EVM6747 configures EMIFB in narrow mode (SDCFG = 0x00014421). So in theory, there should be no difference.

    That is why I went on to see if a NM on EVM6747 is for real, by comparing the throughput with and without NM.

  • 0 in reply to yl
    TI__Mastermind 18130 points

    I think I have a better answer for you now [:)] FYI, here are some numbers I saw based on my testing.

    When using the CPU and writing 5000 32-bit values via pointer in a for loop (this is the test you used), here are the completion numbers I saw. Note there was NO OTHER system traffic (GIE off, EDMA3 unused):

    16-bit data bus took 32198 cycles
    32-bit data bus took 32181 cycles

    After offloading this transfer to an EDMA3 channel here's the cycle count I received:

    16-bit data bus took 15099 cycles
    32-bit data bus took 13323 cycles

    My test is probably still far from perfect, but this behavior is more in line with what I was expecting anyway.

    To add to this, the CPU is not able to keep the EMIF port continuously fed with data, so while the CPU is getting ready to send the next value the EMIF is performing both transfers. This is why the two cycle counts are almost identical between 16- and 32-bit writes via CPU. Once I offloaded this to the EDMA engine we see an ~11.7% increase moving to the 32-bit bus as the EDMA engine is far better at keeping the EMIF fed with data.

    *edit* After some tweaking to my EDMA3 configuration I got much better numbers:

    16-bit data bus took 2820 cycles
    32-bit data bus took 2072 cycles

    In this example the 32-bit bus is ~26.5% faster than the 16-bit bus.

  • 0 in reply to TimHarron
    Expert 1215 points

    Thanks a lot, Tim.

    I wonder if you could send me your code. I'd like to run it on my 6745 board.

  • 0 in reply to yl
    TI__Mastermind 18130 points

    I'll post it here so it's public.

  • 0 in reply to TimHarron
    Prodigy 10 points

    I have some thing confused, If I use 8Mb nor flash, in order to boot arm core, I need to put dsp-ubl (~ 4k)in 0x0 offset address then put arm-ubl (~16).. u-boot (128k)-kernel ... filesystems

    where should put the dsp application code .ais(~1Mb) and how to boot it, which boot mod I should  use.

    the legcy mod need to copy the file to L2 Ram, there is no room to store the whole code(~1Mb),

    The ais bootmod doesnt mention how to boot up the arm core

    The direct bootmod is to boot u-boot directly without mention how to boot .ais file.

    If I copy .ais file to flash, then I can copy it to sdram, however, I dont know how to execute this file by dsp core.

    I think i misunderstand some thing, could anybody tell me how to solve this problem. 

     

    Thanks