• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 2 replies
  • Subscribers 349 subscribers
  • Views 13111 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

HRANT assertion and deassertion in combination with HLOCK and HREADY

Kavita Bhagnani

Hi,

Regarding the HGRANT signal have following queries

1) When Master has requested  for the bus access; arbiter has provided it the grant; When the arbiter can pulls out the HGRANT

    a) For Non-locked transfer: When another master requests for bus access; arbiter will check the granting algorithm (priority or other) and provide/change the grant acc.

    b) For Non-locked transfer: For an ongoing fixed length burst transfer;  arbiter will pulls the HGRANT when penultimate address has been sampled. Is this case is valid even if there is only a single master on the bus and what if Master drives the busy before the putting last beat on lanes than as HGRANT is lowered this will be case of EBT.

From Spec:The arbiter changes the HGRANTx signals when the penultimate (one before last)
address has been sampled. The new HGRANTx information will then be sampled at
the same point as the last address of the burst is sampled.

c) For the locked transfer: The arbiter can pulls out the grant only when complete burst has been received? This still be possible to check based on the number of beats in the fixed length burst transfer; how the case of Undefined length burst is handled

d) Transfer-> Undefined length burst with lock possible and handling? 

  • +1

    The arbiter is free to change HGRANT at any time other than when a LOCKed sequence is ongoing. So for each of your scenarios...

    a) for an undefined length burst the arbiter can look at all the requesting masters and select which master to next grant, regardless of what the current master is doing.

    b) for a defined length burst the arbiter is still allowed to change HGRANT at any time as there is nothing in the protocol that states defined length bursts must be allowed to complete. However it is usually more efficient to allow a defined length burst to complete before changing HGRANT, so the arbiter would then need a counter monitoring HTRANS and HREADY to detect when the master is about to end the defined length burst.

    c) if the currently granted master is performing a LOCKed sequence, the arbiter cannot change HGRANT ***. The protocol also requires that the arbiter keeps the same master granted for an additional transfer (this could be an IDLE) to ensure that the final LOCKed data phase transfer completes before a new master possibly takes control of the bus. For LOCKed bursts the HLOCK signal assertion is what is critical, not the burst types being used, so there would be no predicting by the arbiter when to change HGRANT, it must follow what HLOCK signals.

    d) undefined length LOCKed bursts are handled exactly the same way defined length LOCKed bursts are handled, it is HLOCK that is the critical signal, not the HBURST type.

    *** the only time the arbiter must change HGRANT during a LOCKed sequence is if the master receives a SPLIT response to one of the LOCKed transfers. SPLIT states that another master MUST be selected, so in this scenario the arbiter must select the "dummy master", a component that will only perform IDLE transfers until such times as the slave that signalled the SPLIT response indicates on HSPLIT that the original master can be regranted to hopefully complete the LOCKed sequence.