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.

Write cycle delay to external device interface with EMIF

I use the EMIF of C6713 to interface to external device - TL16C752B from TI.

This device has a timing requirement for Write cycle delay of 90 nano seconds between IOW or AWE becomes inactive till it becomes active for the next writing.

When i access to this device i write sequentially to the same address and it takes a few system cycles clocks between each writing - ~20 nano.

How can i control or programme the Write cycle delay between sequential writing in the EMIF?

The attached file is a screen image from a scope of the CE (signal #2-blue) and AWE (signal #4-green) signals of the EMIF interface to this device when i access with a fast sequential writing to the device.

My ECLKOUT is 80MHz = 12.5 nano seconds, and the SETUP, STROBE and HOLD are programmed to 2,8,2 cycles respectively.

I see that after the CE becomes inactive after the first writing and before it becomes active for the next writing the CE stay inactive for ~40 nano seconds so with the HOLD time of 25 nano ( 2 cycles) and with the SETUP time of 25 nano ( 2 cycles)  i get a write cycle delay of 90 nano seconds as required by the device timing requirement.

Do'es the EMIF allways puts a delay of 40 nano seconds between sequential writing?

Can it guaranteed?

Thanks

Alex Shultz

  • Alex,

    We have turnaround time to which controls the minimum number of ECLKOUT cycles between a read followed by a write (same or different CE spaces), or between reads from different CE spaces. But i doubt we have control over Write cycle delay between sequential writing in the EMIF.

    I will check on the delay that you are observing between writes and confirm you.

    Regards,
    Senthil
  • Alex,

    No, there is not the guarantee that you are looking for, at least not based on what you are seeing now.

    As Senthil explains, there are some situations that can be lengthened from the minimums, but that does not include back-to-back writes to the same CEx space. Please see Figure 1-10 of the EMIF User's Guide:

    From this, you can see that it is possible for there to be 0 delay between the end of the first write cycle's HOLD time to the beginning of the second write cycle's SETUP time.

    The only guarantee for your situation is making the sum of the HOLD and SETUP times to be 90ns. Otherwise, it is possible to get two back-to-back writes that will be closer together than what you are trying to get.

    Regards,
    RandyP

  • RandyP,

     

    Thank you for your answer.

     

    I understand that to guarantee the write cycle time of 90ns between back-to-back writes i must change the setting of HOLD and SETUP time to be together more that 90ns.

     

    I also understand that if I write two or more WORD’s, sequentially or back-to-back, to the same CEx space the EMIF start the SETUP time of next data immediately after the HOLD of the current data and even without setting the CE signal to inactive state and then to active state as we see in Figure 1-10 of the EMIF User’s Guide.

     

    But I wonder why I see in my situation of back-to-back writes to the same CEx space of the EMIF a different behavior of the EMIF as you see in the attached image?

    We work with the C6713 DSP for over 10 years in a lot of boards with a lot of asynchronous interface to peripheral types, most of them have the same timing requirement of minimum 90ns Write Cycle delay and we used the EMIF with the same setting of HOLD and SETUP and there was no problems  and the behavior of the EMIF in the back-to-back writes to the same CEx space was as the attached image and we didn’t find the behavior of the EMIF as see in Figure 1-10 of the EMIF User’s Guide.

    Is it an undocumented behavior of the EMIF? Doe’s the EMIF have a behavior that undocumented?

    Are there situations or conditions that the EMIF behavior in asynchronous write is differential from the EMIF Asynchronous Write Timing Diagram? 

    Is it possible to ask the TI C6000 EMIF engineers about this behavior?

     

    Thanks

     

    Alex Shultz

  • Alex,

    You seek a different answer that we cannot give you.

    alex shultz said:
    Is it an undocumented behavior of the EMIF? Doe’s the EMIF have a behavior that undocumented?

    No undocumented behaviors are documented to me. Our documentation gives you what you can use to guarantee your design behaves in a given way. If you have circumstances that result in different behavior, we still provide the documentation to guarantee your design behaves in a given way, only. If you are asking if there is a list of things that we are hiding from you, the answer is 'no'.

    alex shultz said:
    Are there situations or conditions that the EMIF behavior in asynchronous write is differential from the EMIF Asynchronous Write Timing Diagram? 

    Since you have shown that your code displays behavior that appears to consistently have longer delays, together we can safely say that there is at least that situation that can behave in the way you have shown. TI will not guarantee that behavior. How you proceed with the results from your testing will be a business decision on your part.

    alex shultz said:
    Is it possible to ask the TI C6000 EMIF engineers about this behavior?

    The TI C6000 EMIF engineers provided the documentation that we have been discussing in the EMIF User Guide. Please use that information for the most reliable design.

    We can loosely compare this to the timing parameters that are specified in the datasheet. If a given parameter is noted with a maximum 10ns delay in the datasheet, TI guarantees that over the full voltage and temperature range of the device as well as for the stated life of the device. We have customers who will test these devices outside of those voltage or temperature ranges and measure different behavior on some devices; they will then use those devices at their own risk in ways that are not guaranteed or tested by TI. Although your situation is discussing sequential operation and not combinatorial operation, you are still looking for a way to justify using the device differently than how TI documents and tests the behavior. Our recommendation is to use the device within the behavior that we document the device.

    Regards,
    RandyP