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.

TMS320C6746: EMIF interface

Genius 12760 points

Part Number: TMS320C6746
Other Parts Discussed in Thread: CODECOMPOSER

Customer asked:

We currently write data using an interface EMIF of the TMS320C6746 without DMA  and today need to pool the CE_EMIF in order to know when the next write operation can be send.

We haven’t found a better way to do and would like to know if there is one, or if a flag exists to indicate that CE_EMIF has switched from L to H indicating that the current EMIF write operation is finished.

 

Can you please advise?

 

Regards, Bernd

  • Hi,

    I've notified the team. Their feedback will be posted here.
    In the mean time can you share which SDK are you using?

    Best Regards,
    Yordan
  • BO,

    What do you mean by 'pool the CE_EMIF'?

    If you are not using the DMA then you are using the DSP/CPU. If the DSP writes to the EMIF, it will go into a buffer if I recall correctly. Then when the DSP writes again, it will again go into that buffer. If the buffer is full, the DSP will stall until the EMIF operation is completed, and that is your only indication that the EMIF operation has completed.

    Use the DMA. That is the best advice you can get. That is what the DMA is for. The DMA is much more efficient at moving data than the DSP is. So use the DMA for this.

    Regards,
    RandyP
  • Yordan, Randy,

    I have started this thread but let the customer follow up your questions.

    Regards,
    Bernd
  • Hi Randy

    Thanks for your feedback.

    We use CodeComposer 5.5.

    We don’t use the DMA in this case because it is few single words writing.

    What we observe is that we can write in the buffer while the CE_EMIF has not rised to 1, making several
    writing without the CE_EMIF set to 1 between writing, that is an issue for our driver that received the EMIF word.
    It is why we pool the CE_EMIF, i.e. we have a loop that check regularly if the pin is set to 1 before writing
    in the next data in the buffer.

    We have also used the C5009 DSP in our application and the behavior was different, i.e. the
    CE_EMIF is set to 1 between successively writing (we have no to check CE_EMIF to send the next
    word to write into the buffer).

    So in conclusion C6746 has different way to work than C5009 and for our particular case the only
    way is to check regularly the CD_EMIF before putting the next data into the EMIF buffer if we need
    to have CE_EMIF set to 1 between two consecutive writing.

    Best regards,

    Tristan

  • Tristan,

    Although I am not familiar with the C5009, I can certainly understand that some TI device families implement the EMIF timing differently. If the C6746 EMIF does not insert a wait state in between, then it will provide maximum throughput performance for your data transfers. This is certainly a design goal for the C674x family.

    When you say "pool the CE_EMIF", do you mean you poll the CE_EMIF? How are you doing that currently?

    From your description above, you have worked out a way to do exactly what you need to do. What is the problem you now want to solve?

    Regards,
    RandyP
  • Hi Randy,

    To poll the CE_EMIF, we put some wait time and check that the CE_EMIF has made a low to high transition. It is not so convenient but it works.

    According to the documentation that we have checked, there is no flag that indicates this low to high transition (or end of write transfert with CE_EMIF set to high)
    and we would like to double confirm with you that it is effectively  no flag for that purpose.

    Best regards,

    Tristan

  • Tristan,

    I was not aware of a way to poll CE_EMIF. How do you "check that the CE_EMIF has made a low to high transition"? How do you detect the current state of CE_EMIF?

    I am not aware of any flag that indicates a CE_EMIF low to high transition or end of write transfer.

    Since you have apparently worked out a way to do exactly what you need to do, what is the problem you now want to solve? Is this solution not working for you for some other reason?

    Regards,
    RandyP
  • Hi Randy,

    To poll CE_EMIF, we consider the pin in GPIO mode and check its state.

    Thanks for your feedback that no flag exists to do that check, so in conclusion we will keep using our current polling method.

    The case is closed in my side.

    Thanks again for your feedback,

    Best regards,

    Tristan

  • Tristan,

    If you can connect the CE_EMIF signal to another GPIO on the device using an external connection or wire, then you should be able to generate an interrupt when that GPIO state changes from 0 to 1. This would remove the need for polling but would require an external wiring change.

    Or if the performance can handle an occasional 2 EMIF cycles of CE_EMIF being high between writes, you could set a timer for the full delay needed. If the timer is set for the number of EMIF clock periods programmed in your EMIF timing registers plus 1 extra EMIF clock period, then the timer interrupt would occur when it is certain that CE_EMIF=1. A few extra timer ticks would add some margin but would increase the chance of having 2 CE_EMIF=1 cycles between operations. You could do some tests to determine the smallest possible delay that would ensure CE_EMIF always returns to 1. Or you can combine the timer with your polling method but have a much smaller polling time.

    Regards,
    RandyP
  • Hi Randy,

    Thanks very much for your suggestions to improve our system.

    Best regards,

    Tristan

  • Hi!

    If I got your issue right, you need EMIF to inactivate before subsequent write. If so, consider dummy read between your writes. As per SPRU266, clause 1.2:

    The C6000 EMIF has a one cycle command-to-command turnaround time. At least 1 data dead cycle is
    always included between commands so that read data and write data are never driven in the same cycle.