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.

OMAPL-138 to FPGA Set Up and Hold EMIF Clocks

Other Parts Discussed in Thread: OMAPL138, OMAP-L138

My customer has posed the following question:

This relates to interfacing TI DSPs to FPGAs using EMIF. We've done this a LOT in the past.  Specifically, we've hooked up Altera Cyclone III, IV, V, Arria I and II.  

My issue, specifically, is trying to understand the very high number of setup, and hold clocks that we have to configure to make it happy.  I'm wondering if anyone has done this at TI and really optimized it.  We currently have to run 3 setup, 3 hold and 3 strobe, for a total of 9 EMIF clocks per transaction.  If we go below that, data integrity is lost. That has always seemed excessive to me, but in past designs, it was always fast enough.  My current design (using the OMAPL138) is bringing in a LARGE amount of data, and a concern we have is that EMIF simply won't keep up when configured this way.

So, I'm hoping an FAE can tell us "Just flip this level, and it'll work" or "Do this and you'll get better throughput." 

Is there someone who has experience with this that can provide some guidance?

 

Thanks.

  • Hi Roland,

    I don't know if my message was clear or if I don't quite understand your message

    I believe the customer hooked up the FPGA through EMIFA bus of the OMAP-L138 and want to know the data through put and try to understand the setup/hold timing margins for wider operation.

    We don’t have any bench test for OMAP-L138 EMIFA to FPGA through put analysis .But we do have some example configuration for interfacing EMIFA to SDRAM and other asynchronous flash device and we have explained the timing requirements for each devices with respect to OMAP-L138.

    Please refer the OMAP-L138 TRM for more details

    Customer can substitute FPGA instead of SDRAM or other asynchronous flash device and start doing the analysis with the given timing parameter. Because basically they need to access FPGA the same way they access other memory devices connected to the EMIFA bus .So, they can use the same timing configuration steps explained for interfacing SDRAM and other asynchronous flash device to calculate the FPGA data throughput analysis and other timing requirements

    Regards

    Antony

    •  --------------------------------------------------------------------------------------------------------
      Please click the Verify Answer button on this post if it answers your question.
      --------------------------------------------------------------------------------------------------------
  • Hi Ronald,

    Thanks for your post.

    In my experience, i have never come across using 9 EMIF clocks per transaction but i believe that, there is no issue in doing this and obviously you shall get better throughput.

    In my suggestion, the EMIF timing parameters are mainly decided by the FPGA side, like FPGA code will require an timing parameters such as Setup, Strobe and Hold. Based on this input, we basically configure EMIF timing parameters. It is like, FPGA will require setup clock for detection, strobe clock for reading the data and so on.

    In my opinion, EMIF timing parameters can be configured in an optimum way to start from large value and then you shall scale down. This way of configuring would give optimum results.

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------
    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------