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

How AHB Arbiter should handle granting bus masters while performing only a SINGLE transfer?

Suppose A master wants to perform a SINGLE transfer.

Consider the waveform in fig below.

As depicted in the waveform. Master 1 is requesting bus at T1, arbiter samples request and drives the grant at T2. M1 samples the grant at T3 and de-asserts its request. Since M1 is performing only a SINGLE transfer so ideally grant should be changed after 1 transfer. But Arbiter will be able to sample that its a SINGLE transfer at T4 so it will grant the M2 at T4 which has been requesting from T2. M2 will be able to sample grant at T5 and can start its transfers.

So here M1 is getting the grant for 2 cycles though it has only a SINGLE transfer to perform. How this scenario should be handled with respect to both Master and Arbiter?

Or since M1 is getting grant for 1 extra transfer though its not needed, should M1 need to perform a IDLE in the 2nd cycle at T4?.

Is this the correct way to handle?

  

Parents
  • As I've suggested to you before, are you really using the original AMBA 2 AHB protocol with all the complexity of SPLIT and RETRY responses and arbitration question such as this one, or could you instead look at the later AMBA 3 AHB-lite protocol which is MUCH simpler to understand and avoids all the complexity of AHB ?

    I am concerned that you are wasting time learning a protocol you are unlikely to ever use in a real application !!!!!

    To answer your question, the pipelined and synchronous timed nature of AHB means that from an arbiter granting a master by asserting HGRANT, through that master being able to detect it is granted and remove HBUSREQ, to the arbiter seeing HBUSREQ de-asserted and itself deasserting HGRANT, is a minimum 2 cycle timing.

    There is no way the master can de-assert HBUSREQ in time to only be granted for one cycle (as it would need to de-assert HBUSREQ before it samples HGRANT high), without looking at combinatorial logic which gives rise to critical timing paths.

    So the correct diagram for your scenario is the second one, if the master only wants to perform one write transfer it should drive IDLE cycles for however many additional cycles it remains granted.

Reply
  • As I've suggested to you before, are you really using the original AMBA 2 AHB protocol with all the complexity of SPLIT and RETRY responses and arbitration question such as this one, or could you instead look at the later AMBA 3 AHB-lite protocol which is MUCH simpler to understand and avoids all the complexity of AHB ?

    I am concerned that you are wasting time learning a protocol you are unlikely to ever use in a real application !!!!!

    To answer your question, the pipelined and synchronous timed nature of AHB means that from an arbiter granting a master by asserting HGRANT, through that master being able to detect it is granted and remove HBUSREQ, to the arbiter seeing HBUSREQ de-asserted and itself deasserting HGRANT, is a minimum 2 cycle timing.

    There is no way the master can de-assert HBUSREQ in time to only be granted for one cycle (as it would need to de-assert HBUSREQ before it samples HGRANT high), without looking at combinatorial logic which gives rise to critical timing paths.

    So the correct diagram for your scenario is the second one, if the master only wants to perform one write transfer it should drive IDLE cycles for however many additional cycles it remains granted.

Children
No data