Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
12 years ago

Arbitration problem with Tri-State Conduit Pin Sharer

Hi all,

I have two custom Avalon MM-Masters, accessing external devices over a TC pin sharer. If both masters want to read data at the same time, according to the Avalon Tri-State Conduit Components User Guide,

--- Quote Start ---

...the Tri-State Conduit Pin Sharer grants requesting masters in round-robin order.

--- Quote End ---

But what I experience, is that the first master keeps on reading as long as it likes, while the second master is stalled (waitrequest set)!

On the other hand, if the first master was writing, arbitration works as expected.

- Is anybody familiar with this problem?

- Can I somehow take influence on the behavior of the request signals of the Generic Tri-State Controllers?

- Is there a way of configuring arbitration shares for the TC Pin Sharer?

Thanks

Simon

2 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Sounds like the first master is not giving up the bus. IE it's trying to do LARGE reads, so it gets them once it's request is granted.

    The round robin logic doesn't limit the size of the transactions. That's a function of the master. To insure the bus is not stalled for any one slave, you need to limit the maximum transfer size per master request.

    This may or may not be an option in QSYS. (I don't remember anymore) But can be corrected with a custom module placed that converted the large transactions into smaller one if required.

    Pete
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Hi Pete,

    --- Quote Start ---

    Sounds like the first master is not giving up the bus. IE it's trying to do LARGE reads, so it gets them once it's request is granted.

    --- Quote End ---

    Yes, using Signal-Tap I can see, that the first master constantly assigns request signal. My problem is, that the master is a Generic Tri-State Controller, so I have no access to request/grant.

    --- Quote Start ---

    But can be corrected with a custom module placed that converted the large transactions into smaller one if required.

    --- Quote End ---

    Accessing the GTC via MM-Master I de-assert the read signal as soon as waitrequest is low and only assert it after readdatavalid goes high. So each word is read separately with 2cc where read is low, but this doesn't make the GTC de-assert the request signal!

    Of course I can make larger gaps between successive reads or write my own custom TC, but I was looking for a smarter way to get a fair arbitration :)

    Simon