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 question on emif clock to output enable delay

Can someone please explain the discrepancy between these two documents/access types (see details below)? I would have thought regardless if the interface is synchronous or otherwise, the clock to output delays of the EMIF interface should be similar.

The data sheet specs - ref :SPNS162B (see the table below) - for synchronous interface the EMIF_CLK is min = 50 MHz/20nsec.

and gives one set of delay numbers for output delays such as rising edge of EMIF_CLK to CS(0) 13 ns Max.

This is somewhat contradicted by the reference manual (SPNU499B - Chapter 17 example - SEE below) where for asynchronous interface the EMIF_CLK can be as fast as 100 MHz and has a totally different output delays (Td) 7 ns Max. It is also missing the output delay on the data bus for writes (I assume it is also 7 ns Max - please confirm!!!).

Thanks.

 

  • Dwane,

    The TRM chapter is out of date.  I believe it is using original target values, and so far up to rev C of this LS31xx product we've not been able to hit the targets due to a problem in the on-chip logic.

    Sorry about the confusion, but the Datasheet AC characteristics have to be used.  Treat the TRM chapter as an example calculation but you've got to plug in the new numbers from the datasheet.

    I think thats' the answer to 1 question but there's a couple more questions:

     1) The timing path is different for the async mode and sync mode on the EMIF, even though the pins are the same the data is captured in two different sets of on-chip registers depending on the mode and these registers have different clocks so the parameters would be different always.

     2) The async EMIF specifications are relative measurements, the timing difference between two outputs triggered by a clock.  For example WE\ and CS\ in async mode are two outputs.  The clock to their register happens to be related to the EMIF clock that's the same one used for SDRAM but that clock doesn't need to be turned on for the ASYNC interface to work, so we don't spec the timings relative to the clock... you might not be alble to measure that.  In this case there is internally some Clock to WE\ delay and a Clock to CS\ delay,  but the datasheet calculates the range and reports CS\ to WE\.     [note, I might be a little off on the CS\ to WE\, it might be WE\ to CS\ in the datasheet, I only briefly glanced at the diagram to refresh a minute ago... point though is that they're relative delays of two outputs.

        That long discussion in 2) also relates to the timing of the ASYNC data versus the timing of the SYNC data.

    Not only is the SYNC data being captured in a different register with a differently delayed clock,  the SYNC data setup/hold inputs are spec'd relative to the clock.

    Whereas for ASYNC, they're spec'd relative to OE\ or CS\ rising;  and OE\ or CS\ themselves have some delay to the clock.   So you wouldn't actually even expect SYNC and ASYNC numbers to be the same if they're based on different reference signals.

    3) the clock frequency if you're using only ASYNC can be faster because it doesn't use the path that is causing the SDRAM frequency to tank.   But even if you run at 100MHz in async, you likely will have to insert wait states (setup, hold, strobe) I think too that even if you program '0' for these you always get 1 cycle.  So the entire memory cycle time will still be slower with async mode by the time you add in these setup,strobe,hold times.

    Long winded explanation - hope it clears things up.  If not please post and we'll try to clarify.