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.

Link between asynchronous EMIF internal clock and performances

Other Parts Discussed in Thread: TMS570LS3137, HALCOGEN

Hello,

We have been running some benchmarks to evaluate the performance of the TMS570LS3137 RevD EMIF.

We ran a Dhrystone benchmark with the code located in the Flash memory, the stack in the RAM memory, and the data/heap in an external SRAM memory (35 ns speed grade).

We have trouble understanding the results we mesured.

The first thing is that we have not been able to make the EMIF working accordingly to the SRAM timings. We modified the EMIF asynchronous configuration to gradually reduce the timings, but it appears that our test fails under a value, which is around the double of our SRAM cycle time. We don't understand why we can't have the EMIF working in such a configuration. Is there some limitation on the interface ?

The second thing is that our results seem very depend on thefrequency of the EMIF VCLK internal clock.
We have measured a given performance while running at 80 MHz. Then, we have increased the EMIF internal frequency at 90 MHz, and we have measured a +50% increase of performance. This is strange, because when analysing the timings on the EMIF interface, the signals sequencing is more or less the same than at 80MHz. More puzzling, we have run a test at 45 MHz, and we obtained a performance slightly better than at 80 MHz...

To sum up :

performance @ 90 MHz >>> performance @ 45 MHz > performance @ 80 MHz.

We have of course checked our test, but everything seems fine. So, we would like to have more details on the behaviour we observed. What are the parameters that can have an impact on the EMIF asynchronous performance ?

Thank you in advance,

Best regards,

PGC

  • This does not look right to me either. Are all of these tests run with the internal flash using the same settings? If you are using HALCoGen to do the initialization it will run the internal flash in single cycle mode at 45MHz, but pipeline mode with wait-state above 50MHz.
  • Dear Bob,

    Thank you for your advice, we have been re-starting our project from scatch with a clean HalCoGen configuration and we could get more "normal" results. We got an almost linear increase of performance with the EMIF asynchronous frequency.
    By the way, tthe frequency I was talking about is not the internal Flash controller frequency, but  the EMIF interface frequency (VCLK3).

    However, our problem is that wa can't have the Read access on our SRAM working according to the part's timings. It appears that under 6 read strobes cycles (at 90 MHz, i.e ~66 ns), the read data is corrupted. The part is able to sustain up to 35 ns, so this could perfecly work with 60 ns and less.


    How can you explain this ? Is there some kind of limitation on the EMIF asynchronous interfaces for the hold time ?


    Best regards,

    PGC

  • This sounds about right.

    If your device has a 35ns access time, and according to table 6-27 www.ti.com/.../tms570ls3137 parameter 12, the 570 needs 30ns setup time before the end of the strobe period (nOE going high) then it stands to reason the minimum strobe time is right around 65ns so 66 makes sense and if you take a clock cycle out you'll be well under the min 65.

    Side note: The flash wait state answer by the way had to do with Dhrystone perfomance. If you run test code from internal flash, up to the point where there are zero wait states performance will increase. As soon as you increase the frequency slightly so that it cross from 0 to 1 ws it actually decreases because the effect of the wait state is more than the slight increase in frequency. You have to keep increasing the frequency to get past the effect of the added wait state in order to see your benchmark improve.