• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 99 subscribers
  • Views 1437 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.

C6457 EMIFA external clock detection

Epikur Grekow
Prodigy 100 points

Hello.

I have a TMDSEVM6457L evaluation board and use EMIFA to interface it to FPGA.

EMIFA is configured for synchronous mode with usage of external 100 MHz clock on AECLKIN pin sourced by FPGA. This FPGA requires some time to start-up, perform self-test and lock the clock on its Digital Frequency Synthesizer. And I need to detect the moment when FPGA is finally ready. 

I could use a separate GPIO pin for "Ready/Busy" signal from FPGA, but that is not an option.

I could also perform some read or write operation on EMIF having my DSP hanged until EMIFA gets a valid clock, and that is not a very nice solution too. The best solution I have come to is to check periodically - have EMIFA already gotten a valid clock or not. But I didn't find a way of how to do it and need help.

It is O.K. for me to perform some read or write operation on EMIFA somehow without hanging the DSP and then to check periodically if operation is completed or not. But I don't know how to do it either.

Thanks in advance for your replies. 

  • 0
    TI__Expert 6815 points

    Epikur Grekow said:
    I could use a separate GPIO pin for "Ready/Busy" signal from FPGA, but that is not an option.

    Epikur, can you explain why this is not an option for you? That would be the easiest way to check if FPGA is ready in my opinion. You could have the GPIO pin mapped to an interrupt service routine. Your DSP can continue to execute other instructions and branch off to the ISR when FPGA is ready.

  • 0 in reply to Aditya
    Prodigy 100 points

    Aditya, that would surely be the easiest way, but...

    That is all because I use evaluation board, and this board has its own FPGA for some auxiliary purposes like access to NAND flash memory, leds etc. It uses all 16 GPIOs. There is only two GPIOs left (12 & 13)  that can be used, but that makes connected to FPGA NAND memory not available.

    Trying to use McBSP or others pins as GPIOs is not  that handy.

  • 0 in reply to Epikur Grekow
    TI__Expert 6815 points

    Epikur, thanks for the explanation. I was not familiar with the GPIO pin usage on the eval board.

    Another thing to try, you might be able to calculate the time taken by the FPGA to wake up and be in ready state from its datasheet. You can program this value with some margin into the timer period register and configure the timer to interrupt the CPU. When the timer count matches the timer period the CPU will receive an interrupt indicating the FPGA is up and running. You can then disable this interrupt. The CPU can continue its work while the FPGA is waking up.

  • 0 in reply to Aditya
    Prodigy 100 points

    Well, that's what I do now. But I don't like it and was hoping that there is a way to know the exact moment when clock on AECLKIN pin becomes valid.

  • 0 in reply to Epikur Grekow
    TI__Expert 6815 points

    The way I see it you can either route it via the GPIO pins which unfortunately is not an option due to the eval hardware or you can set a time window with sufficient margin for wakeup using a timer interrupt.

    So when you say you don't like it, is there any uncertainty in the wake up time that you are afraid might hit a real time deadline in your system? Unfortunately my knowledge of this device is limited to what I have already told you. Let me see if I can get someone more well-versed with this device to propose a solution that is more acceptable to you.

  • 0 in reply to Aditya
    TI__Guru* 84110 points

    Epikur,

    You and Aditya have given the two answers. Either route the correct BUSY signal to a GPIO, even if it is not easy, or wait a fixed amount of time and then start running.

    The AECLKIN cycle time specification in the datasheet has a Max value of 40 ns. Trying to run the EMIF with AECLKIN running slower than that would violate that specification and could lead to unreliable results. TI cannot guarantee the operation of the device when used outside the stated specifications, and in this case we do not specify the nature of failures when used outside the stated specifications.

    Regards,
    RandyP

     

    If you need more help, please reply back. If this answers the question, please click  Verify Answer  , below.

  • 0 in reply to RandyP
    Prodigy 100 points

    Adytia,

    There is some uncertainty in FPGA boot & test time, but with known maximum value. The point is, that current FPGA configuration is not final. I would like to have a mechanism to know exactly when FPGA is ready rather then guessing it by setting maximum delay value. And if FPGA fails to work for some reason I will not be able to detect this after the delay.

    Randy,

    FPGA doesn't source clock onto AECLKIN until the Frequency synthesizer is locked. So there is either nothing or 100 MHz on the pin.

    If there is no way to try somehow to operate with non-clocked EMIFA, wait for timeout, reinitialize and try again until success, then I will use constant delay time.