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.

OMAP3530 GPMC Bus contention arbitration

Hello all,

I'm developing an OMAP computing cluster with multiple Gumstix Overo COMs and I'd like to connect a customized FPGA to the Gumstix cluster (via GPMC, hopefully) so that the FPGA can operate as a shared memory device among the Gumstixs.

 

I need help and hints in finding a rigth way to have the above system work. I saw several cases connecting an OMAP to a FPGA via the GPMC but couldn't find the case similar to mine.

Is it possible to connect multiple OMAP processors to a FGPA via GPMC? I've read the TRM but couldn't find what happen if multiple GPMC-host (i.e. OMAPs) access the bus simultaneously. Does GPMC include any contention arbitration mechanism? If not, do I need to totally change my approach from the scratch?

Thank you in advance.

Regards,

Jongwoon.

  • Jongwoon,

    I believe there is no arbitration mechanism in GPMC to support this use case. But you can try one approach. Here if I understand correctly, you need to protect the bus from simultaneous access. For that you can wire four lines from the FPGA to each OMAP's GPIO line. 

    When a transfer is initiated you pull all four GPIO and say that a transfer is on going. In the handler of the GPIO you manage the access using a mutex. The mutex will be locked for all of them. The the SoC which initiates the transfer will check for the mutex and find it unlocked in the beginning and it will get set during the transfer. From the data, the FPGA should be able to interpret from which SoC the data came from and release the GPIO for that SoC, so that he can continue his transfer.

    Also once the transfer is over, you can release remaining three lines to indicate that the bus is free for all.

    I'm not sure about your particular use case, but I think it should work.

    What is your opinion?

  • Renjith,

    Thank you for your answer and nice idea. I am not sure whether I correctly understand your suggestion or not. Your idea is:

    1. Make an OMAP check GPIO before it initiate a new transfer.
    2. If the GPIO value is low (means free to access the bus), the OMAP starts the transfer.
    3. Then, the FPGA sets all GPIO values except the sender's line to high (which means the bus is locked)
    4. Once the transfer is over, the FPGA sets all four GPIO values to low, allowing others can access the bus.

    If I understand correctly, I also need to consider the case that two or more OMAPs start transmission at about the same time. How can I manage this case? In I2C protocol which uses open-drain circuit, the arbitration among multiple masters can be achieved deterministrically by comparing the signal sent to the bus and the actual signal level on the bus, but, because the GPMC does not use open-drain circuits, I think an efficient way to handle such simultaneous starts.

     

    Jongwoon

  • Jongwoon,

    What you understood is partially correct. You might have to use mutex in driver to achieve it better in software also.

    I have one more idea. How about using Ethernet for the same? What is the required data rate for your application? Then you don't have to worry about access control. 

  • Renjith,

    Thank you for your suggestion but Ethernet is not applicable to my system because we are going to use it actively for external transfers, and also, the low latency is another critical requirement. So, I believe the GPMC is the best solution.

    Basically, however, do you think it is possible to connect the all GPMC signals from multiple OMAPs to a single bus as shown in the figure above? Some pins, such as gpmc_a or gpmc_ncs, are output-only and I'm worried about connecting these signals together would make collisions and the system unstable. As your suggestion, we can make only one SoC to have access to the bus at a time, but if other SoCs maintain their signal to output pins, it will cause problem. I'm carefully reading the TRM and datasheet but it is hard to find how these pins behave if they are set not to generate output. If the pins act as high-impedance, it will probably OK. But if the GPMC pins are designed to remain their state, it will cause collisions. Do you have any idea?

    Jongwoon

  • Jongwoon,

    Question is too good. But I am afraid that I don't know the answer for this question. I couldn't find anything related to the state from the datasheet.

  • Thank you, Renjith.

    I'll keep looking for solutions and let you know as soon as I get something :)

     

    Jongwoon