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.

TMS570LS3137 EMIF performances in RevisionD

Other Parts Discussed in Thread: TMS570LS3137

Hello,

I have seen that the new revision D of the TMS570LS3137 fixes two bugs related to the EMIF

  • erratum DEVICE#B064: Incorrect Write to External Memory using Store-Multiple CPU instruction
  • erratum DEVICE#B071: CPU write to peripheral or EMIF may be lost

In the revision C, the workaround for these bugs were (roughly) to prevent the compiler to use the STMxx instructions. Especially in the case of the DEVICE#B064, it is stated in the message that for Revision D, the workaround can be deleted in order to re-gain EMIF performance.

I cannot test the EMIF performance gain for now because I don't have the RevD samples yet, but I would be interested in having information from TI about what I can expect. Being able to evaluate the EMIF performances as soon as possible is really important for our project.

Best regards

PGC

  • Hello,

    The performance gain will very much depend on your usage of the EMIF. The STM instruction would usually be generated if a larger amount of data will be accessed (greater than 32 bit at a time). Can you roughly describe your use-case of the EMIF?

    Please note, that you can sample revision D devices using our web page: 

    Best Regards,
    Christian

  • Hello,

    Thank you for your answer.
    We would want to use the EMIF either to execute software from it, or at least store the data sections of the program. We would use a SDRAM, or a SRAM, depending on the performances.

    Best regards,

    PGC
  • Please note, that executing code from EMIF will be very slow. You have to mark the memory region as "normal" type in the CPUs MPU, as described here: e2e.ti.com/.../396426

    Executing from the EMIF should also be possible with the Revision C of the TMS570LS3137, the errata you mentioned do only effect writes going to the EMIF.

    I'm wondering that you like to place code in a RAM isn't the internal 3MB of flash enough?

    About the second case, using the external RAM as data section. This means that the CPU will perform reads and writes to the memory, I expect that setting the memory region to "normal" will help gaining some performance. Please note, that this isn't possible on Revision C as described in DEVICE#B071.

    Best Regards,
    Christian
  • The reason we could use an external RAM for the code is related to the size of the program, indeed. We have a risk to exceed the 3 MB of Flash and we want to see what are the performances in such a case. Thank you for the links and examples of EMIF configurations by the way.

    For now we re using the HDK board for our tests, and in my knowledge, we can't procure yet a HDK boards in RevD. I have ordered some RevD parts, but I will have to wait for our demo board, which will not be available before weeks to test this revision.

    One last thing, is the workaround to disable the STM buried somewhere in the compiler ? With the TI compiler (v5.1.6), the -no_stm switch seems to have no effect on my test application (same size of binary). How do I make sure it is deactivated ?

    Best regards,

    PGC
  • If you look into the assembler code of a function compiled with the --no_stm switch enabled you should see a bunch of STR instructions instead of a STM instruction at the beginning of each function which uses the stack. Another thing you could check is, if you use memset or memcpy the call to these functions will be replaced with no_stm_memset or no_stm_memcpy.

    Just a side note, please consider updating your compiler. Version 5.1.6 is pretty outdated (May-13-2014), the current version of this branch is 5.1.14 (Dec-22-2015). Or even better switch to a newer branch like 5.2.x. Please refer to  for a list of the compiler branches and versions.

    Best Regards,
    Christian

    Edit: Clarified the what was meant with the first sentence, added link to the wiki for the compiler versions

  • Hello Christian,

    Thank you for these information, the memset function is a convenient way to validate the presence/absence of the flag.

    I will have a look to update the compiler,

    Best regards,

    PGC

  • Hello Christian,

    I'm back with an other question !

    A majority of the pins related to the trace interfaces are multiplexed with the EMIF on the TMS570LS3137, which means that the functionalities are disabled if the TMS uses some external memory through the EMIF. This is the case for the RAM Trace Port for instance.
    However, for the ETM, the control signals and the 8 LSB data signals are not multiplexed. I understand this allows us to continue to use the ETM trace feature with a reduced data rate.

    Do you confirm this understanding? Can we still use the trace features in "degraded" mode with the EMIF enabled ?

    Best regards,

    PGC

  • Yes, your understanding is correct. You can use ETM with reduced pins and thus reduced speed, so there is the possibility that you loose data. The needed bandwidth depends on your CPU speed and also on the code you are going to trace. So it is rally hard to predict how well or not it will work.

    With the XDS560v2 ProTrace you can choose the following settings regarding the pin count: 

    Same should be possible with any other trace receiver, like Lauterbach or iSystem once.

    Best Regards,
    Christian

  • Hello Christian,

    That's a good news !

    Thank you for your answer.

    Best regards,

    PGC

  • Hello,

    Were you able to characterize the performance of the EMIF rev D?
    I would be very much interested in your results!

    Mathieu