• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 33 subscribers
  • Views 898 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.

EMIF - Delay between cycles

Petr Burian
Prodigy 70 points
Other Parts Discussed in Thread: TMS570LS3137

Hi,

I writing to ask you what is minimal delay between individual emif read/write cycles.

I used the EMIF (async.;16bit; emif clock 90MHz). I exploit an access through 64-bit pointer.

If I perform two emi read/write cycles immediately successive,

emif produces four read/write 16-bit cycles but afterwards the delay approximately 170 ns  

before a next emif cycle is detected. This dealy reduces data throughput.

I would like to know, whether this behaviour is correct.

Thanks......

  • 0
    TI__Intellectual 1125 points

    Hello Petr,

    Sorry for the delay, I have forwarded your question to our EMIF expert. Can you let us know the device you are working on?

    Best regards,

    TI Forum Team

  • 0 in reply to Luc Baudoin
    Prodigy 70 points

    Hi Luc, 

    I work on the TMS570LS3137. You can see the waveform of /CS signal - 64-bit. read cycles. 

    Best regards,

    Petr.

  • 0
    TI__Guru**** 196776 points

    Hi Petr,

    The minimum turn-around time (CS becomes high) is determined by TA. The default TA value is 3, so the period is 4*EMIF_Clock cycles. My test shows:

    1. EMIF=40MHz, the turn around is 98ns (4*25ns)

    2. EMIF=80MHz, the turn around is 50ns (4*12.5ns)

    This value doesn't include any data processing time between the EMIF read/write request. 

    Regards,

    QJ

  • 0 in reply to QJ Wang
    Prodigy 70 points

    Hi,

    Thank you for your answer. 

    However, I think my problem is not related to turn-around time.

    Quote from datasheet:

    "Minimum turnaround time.
    This field defines the minimum number of EMIF clock cycles between asynchronous reads and
    writes, minus one cycle."

    But, I can detect delay even between two read cycles (or between two write cycles).

    By the way, I use TA paremeter set to 0.

    Regards,

    Petr Burian.

    EDIT: Could It be caused by resynchronization between internal buses(clocks) ?

  • 0 in reply to Petr Burian
    TI__Mastermind 22715 points

    Petr,

    What you observed is the expected behavior. For each burst read (single 16 bit read can be considered as burst size of 1), there is a 12 VCLK internal delay between burst. The same is true for reading from the peripheral control registers. This 12 VCLK internal delay is also true for writing if the peripheral/external memory space is configured as strongly ordered by R4 MPU. This internal delay is reduced to 2 VCLK in writing when the memory is configured as device. When you calculate EMIF throughput, it  should be EMIF timing plus this internal delay.

    I would suggest using burst access to minimize the effect of internal delay. The burst size of EMIF is 8x16 bits. You can consider using DMA for burst access.

    Thanks and regards

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    TI__Expert 6985 points

    Hi Zhaohong,

    Do I understand you right, that if the MPU is configured to Strongly Ordered we will have 12 cycle delay on the buses plus 12 cycles delay in the EMIF for burst access, which calculates to a total delay of 24 cycles?

    Thanks,
    Christian

  • 0 in reply to Christian Herget
    TI__Mastermind 22715 points

    Christian,

    Yes. It is the time for CPU to complete the instruction.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    TI__Expert 6985 points

    Zhaohong, Petr,

    are you aware of the silicon errata DEVICE#179?

    From this I would read that it might not be the best to configure either the EMIF or the Peripheral address space to "Strongly Ordered".

    Best Regards,

    Christian