• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 100 subscribers
  • Views 335 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM5706: GPMC, async read mode, hold time for data valid

Oba
Genius 17295 points
Part Number: AM5706

Hello,

 

My customer has a question for GPMC async read access configuration.

 

The Technical Reference Manual(SPRUHZ7J) says that “This data hold time is one clock cycle(that is. RdAccess Time + 1)” on 15.4.P3636.

And according to Figure 15-102, the hold time is defined as from RDACCESSTIME to OEOFFTIME. It means OEOFFTIME has to be larger than RDACCESSTIME.

 

On the other hand, the datasheet(SPRS961F) specifies the hold time as gpmc_ad[15:0] valid after gpmc_oen_ren high on P203, Table 5-52, and it is only 1nsec.

It doesn’t say that 1 cycle.

 

Is this 1 cycle requirement for the hold time in the TRM just an example or the requirement that the user has to keep?

 

 

My customer’s current configuring is like the below.

 

RDCYCLTIME: 10

CSRDOFFTIME : 7

RDACCESSTIME: 6

OEOFFTIME : 6

 

Since the memory side has enough hold time(>1ns) after the rising edge of OEN, this configuration is not violate the hold requirement in the datasheet.

But RDACCESSTIME and OEOFFTIME are the same value. It looks like violating the TRM case.

They wonder if they have to modify this configuration.

 

Regards,

Oba

  • 0
    TI__Genius 16906 points

    I'm checking with our GPMC timing expert and will get back with you.

  • 0 in reply to B.C.
    TI__Genius 16906 points

    Here is the feedback from our GPMC expert:

    The GPMC READACCESSTIME is defined by # of FCLK cycles. It does not actually latch any data with the OEn output.

    OEOFFTIME can have an extra delay of ½ FCLK cycle. But the READACCESSTIME does not have any such delay capability.

    Enabling the OEEXTRADELAY it would invalidate the datasheet timings since READACCESSTIME would occur ½ FCLK cycle before or after OEOFFTIME.

    The recommendation is to set OEOFFTIME and CSRDOFFTIME to be greater than or equal to RDACCESSTIME+1.

  • 0 in reply to B.C.
    TI__Genius 17295 points

    Hello BC,

    Thanks for your answer.

    But, I'm not still cleary yet.

    I believe that READACCESSTIME is the latch timing. Is it correct?
    I can't understand why you mentioned 1/2 FCLK delay related thing.

    Let me explain again.

    The above is the timing I assumed. The GPMC latches the data at the timing defined by RDACCESSTIME.
    The memory side remove the data output at the OE rising timing. But usually it has some hold time.
    Now RDACCESSTIME and OE rising timintg are the same.
    So if it is over 1nsec, I think it is not a problem. What is the problemn in this case? Why OEOFFTIME havre to be greather than or equal to RDACCESSTIME+1?

    Regards,
    Oba

  • 0 in reply to Oba
    TI__Genius 16906 points

    The GPMC READACCESSTIME is defined by # of FCLK cycles. It does not actually latch any data with the OEn output. However, the GPMC_FCLK is not brought out to a pin to measure setup/hold against.

  • 0 in reply to B.C.
    TI__Genius 17295 points

    Hello BC,


    The datasheet specifies the setup/hold timing against gpmc_oen_ren, not GPMC_FCLK like the below.

    How to think about it?

    Regards,
    Oba

  • +1 in reply to Oba
    TI__Genius 16906 points

    Since the sampling FCLK is not available to observe on a pin, the OE signal is the closest proxy to measure setup/hold against, with the caveats and recommendations previously described in this thread.

  • 0 in reply to B.C.
    TI__Genius 17295 points

    Hello BC,

    I have an additional question.  I may be a little bit confused.
    When OEEXTRADELAY is disabled,  is the below recommendation still needed in addition to the datasheet requirement?

    >The recommendation is to set OEOFFTIME and CSRDOFFTIME to be greater than or equal to RDACCESSTIME+1.

    If OEEXTRADELAY is disabled and the setup/hold time is within the datasheet spce, I feel the additional "+1" to RDACCESSTIME is not required.
    Is this "+1" absolutely required? I feel OEOFFTIME can be equal to RDACCESSTIME in this case.

    Regards,
    Oba