• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 875 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.

Questino about using SDRAM via EDMA

wanseung yang
Intellectual 350 points

Other Parts Discussed in Thread: TMS320C6747, TMS320C6748

Hi there

 

i want to use SDRAM via EDMA

 

but i think something has been wrong

 

After Writing 8 Cycle, there is a two idle cycle(EMIF CLK)

 

i want to eliminate the idle cycle

 

what should i do?

 

look at attached image please,

 

Channel 3  is one bit of data of sdram, and Channel 4 is the EMIF_CLK 

 

  • 0
    TI__Guru* 84110 points
    Wanseung Yang,

    Which TI device are you using?

    To follow what is happening on an SDRAM EMIF, the traces needed are CEn, RASn, CASn, WEn, although the names may vary from one device to another.

    The EDMA will have a burst size that it can handle in a single command to the memory bus. This will be described in the EDMA User Guide for your device. The memory bus will also have a maximum that it can handle which may be described in the EMIF UG. In some cases these can be modified under program control to make them larger.

    The DMA operation programmed by the PARAM or other means, depending on your device, will establish a transfer size. This can also affect the memory command sent to the EMIF.

    The width of your memory bus on the EMIF is also important to know for this.

    It will also depend on the nature of the DMA commands to determine the bursting or overlapping of SDRAM commands.

    Regards,
    RandyP
  • 0 in reply to RandyP
    Intellectual 350 points

    Hi RandyP

    Thanks for your response

    Which TI device are you using?
    >> I'm using TMS320C6747

    The width of your memory bus on the EMIF is also important to know for this.

    >> i'm using 16 bit of them


     Actually, i connected DAC(Digital to Analog Converter) through EMIFA

    So i don't need any Access Sequence

    if the Data written on every single rising edge, it will be enough for me

    I Modified the burst size of the EDMA Transfer Controller (from 16 byte to 64 byte)

    and now

    after writing 16 times, there are some idle cycle

    i think this phenomenon is about the data burst

    Could you help me more?

    Regards
    Wanseung Yang

  • 0 in reply to wanseung yang
    TI__Guru* 84110 points
    Wanseung Yang,

    The SDRAM interface was defined by the someone a long time ago to provide a powerful and flexible interface to memory devices. It is not intended for driving a fixed, continuous sequence like what you appear to desire for your DAC. There will be gaps at some points in time no matter what you do. You have managed to minimize those gaps, but if your design is not tolerant of periodic gaps then you will need to do something differently.

    The asynchronous memory interface is not as fast as the SDRAM but it is more predictable and should be able to support a consistently repetitive sequence of data writes to a DAC. The highest possible data rate is EMIFCLK/3, and it might be slower than that depending on board and system constraints.

    The C6747 does not have a uPP Universal Parallel Port, but the C6748 does. The uPP was designed for working with streaming peripherals such as a DAC.

    You may wish to provide a complete description of what you require or intend for this design. But, there is no help beyond the advice above that I can offer at this point.

    Regards,
    RandyP
  • 0 in reply to RandyP
    Intellectual 350 points

    Dear RandyP

    Thanks for your Reply

    i understood that the SDRAM could not apply to my DAC

    i have two more question

    i also tried Async Memory Interface

    you mentioned like below

    >> The highest possible data rate is EMIFCLK/3, and it might be slower than that depending on board and system constraints.

    the 3 of EMIFCLK/3 means 1 cycle for Setup, 1 cycle for Strobe, 1 cycle for Hold Right?

    So i think a data should be written after every 3 clock

    sometimes but it need more clock than i expected

    please attached image

    Channel 3 is a bit fo the EMIF and Channel 4 is EMIF CLK

    and Also

    after writing about 2000 times there is a unexpected delay

    Please refer to the below Image

     

    if above phenomenon could not be solved

    maybe i will use TMS320C6748 or something support Universal Parallel Port

    But actually both TMS320C6747 and TMS320C6748 could be over performance for me

    So, Could you recommend other DSP(support the UPP) for me?

    a cheaper one is better for me 

     

  • 0 in reply to wanseung yang
    TI__Guru* 84110 points

    Wanseung Yang,

    I suspect the gaps you see using the asynchronous interface are due to either the SDRAM controller's refresh cycle or delays when the EDMA moves to a new transfer. But those are only guesses. My recollection is that SDCR.SR needs to be written to 1 to avoid the refresh even if SDRAM is not actively used. You could search the forum for SDCR to see, but I think I have discussed this on other EMIF's having a similar problem in the past.

    wanseung yang said:

    the 3 of EMIFCLK/3 means 1 cycle for Setup, 1 cycle for Strobe, 1 cycle for Hold Right?

    So i think a data should be written after every 3 clock

    Both of these are correct. But there may be no guarantee that an extra cycle never slips in between the writes. The EMIF was not designed for that purpose.

    wanseung yang said:

    maybe i will use TMS320C6748 or something support Universal Parallel Port

    But actually both TMS320C6747 and TMS320C6748 could be over performance for me

    So, Could you recommend other DSP(support the UPP) for me?

    a cheaper one is better for me 

    I doubt I can design your system for you, but I can suggest ideas. Some are hard, and some are easy.

    The easiest is to move to the C6748. I consider this to be a low cost processor. We have customers buying multicore processors for several hundred dollars and they feel they are getting a very good price for the performance and features they get. Using the UPP should be the easiest path for you. And there are inexpensive development kits available for it.

    We have lower cost processors, but most do not operate as fast. Their I/O speeds would be similarly slower. Unless they have special I/O like the UPP to provide the functionality you need, they might not be able to put out the data as quickly. You can search for exactly what you need across several TI processor families by going to the various Product Selection Guides. Start at TI.com, click Products then DSP (C67x and up) or Processors (high-performance ARM-based) or MicroController (low power, lower cost).On each of those pages, there will be a Products tab to click. After clicking the Products tab, you can scroll down to see the product selection filters to look through for the features or price or speed or I/O you need. It looks like UPP is not included in the criteria, so you may have to do a raw TI.com search for UPP.

    Some of the MCUs might work if you just want to bit-bang the data & clock out to the DAC. But I do not know what speeds you can achieve that way.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Intellectual 350 points
    Dear RandyP

    Thanks for your detail information

    i have no more question

    Thank you Again

    Best Regards
    Wanseung Yang