Hello to all AHB experts,
I have some question about AHB-Lite interconnection.
If I want to build 2 masters share 1 slave systems. I add a arbiter in the interconnect circuit, so that only one master could access the slave at a time.
My question is how the slave response mux to the masters?
1. If (HTRANS1==NONSEQ) for master1, (HTRANS2==NONSEQ) for master2, only a master will see the HREADY response at data phase whose grant by the arbiter?
2. If (HTRANS1==ILDE ) for master1, (HTRANS2==IDLE ) for master2, two masters will see the HREADY response at data phase at a time?
3. If (HTRANS1==NONSEQ) for master1, (HTRANS2==IDLE ) for master2, two masters will see the HREADY response at data phase at a time?
Thanks a lot.
Hi Jacky,
This could be quite a confusing answer as your mention of an "arbiter" normally would suggest an AHB system where there is a physical "arbiter" block with HBUSREQ and HGRANT signals to control which of multiple masters is granted access to the single shared AHB connecting to the slaves in your system.
AHB-lite simplified AHB by removing all the multiple master features (so HBUSREQ and HGRANT, and the SPLIT and RETRY responses used by slaves), with the "interconnect" logic, or "BusMatrix" then handling systems where you have multiple masters trying to access multiple slaves.
So inside this "BusMatrix" logic there needs to be some "arbitration" logic deciding which of two or more master transfer requests is passed through to a destination slave port (I'll try not to use the word "arbiter" here to avoid confusion).
The first issue for a BusMatrix when connecting multiple masters requests through to a slave is that it cannot immediately stall one master request by driving HREADY low to that master, or at least it can't until that master has moved on to the data phase of that first transfer (when you can add wait states). So the BusMatrix needs to be able to register the first transfer from any master so that it can then add wait states if that master's transfer cannot immediately be passed through to the destination slave - when it fails to win the "arbitration" decision.
So to your questions...
1) it is likely that both masters would see an initial wait state added by the BusMatrix while it works out which slave is being addressed, and if there is any arbitration decision to be made, and after that point one master would see wait states from the destination slave while the other "stalled" master sees wait states added by the BusMatrix.
2) when both masters are signalling IDLE transfers, no slave is being accessed and the BusMatrix would just return the mandatory HREADY=1 responses.
3) where one master is signalling IDLE transfers it would receive the default HREADY=1 response from the BusMatrix described in Q2, while the other receives the initial wait state from Q1 while the BusMatrix works out which slave is being address, and then checks if an arbitration decision is required (not in this case).
All of those replies are based on how I would expect a BusMatrix to function, with the wait states described meaning that no initial combinatorial "address phase" path exists (with the associated timing issues), but I guess it could be possible to design a combinatorial solution if timing issues were taken care of.
Thanks for your description. But I still have some confusion.
1) "when both masters are signalling IDLE transfers, no slave is being accessed and the BusMatrix would just return the mandatory HREADY=1 responses." is mean all masters see the zero wait HREADY=1 respones from the BusMatrix at a time?
2)If a master continuously release undefined length transfers without IDLE transfer (NONSEQ->SEQ->SEQ->NONSEQ->SEQ->NONSEQ->SEQ......). Is the slave always see the NONSEQ command ? When another master request the shared slave between 1st and 2nd NONSEQ transfers. It's mean the slave never change the service to another master until those transfers are finish(when see IDLE state)?
3)Is below figure a legal AHB-lite diagram ?
1. (HTRAN_0, HADDR_0, HREADY_0), is master0 interface;
( HTRAN_1, HADDR_1, HREADY_1), is master1 interface;
( HTRAN , HADDR , HREADY ), is shared slave interface;
2. master0 and master1 use INCR4 transfer (defined length transfer). So I can predict the transfer will be last cycle. I can mux (HTRANS_0/HTRANS_1) to HTRANS at right time, so that the slave will not see the 2nd NSEQ transfer from the master that is lose arbitration.
Q1) Depends on the BusMatrix design.
The mandatory HREADY=1 HRESP=OKAY data phase response to an IDLE address phase must be given as soon as the data phase starts, so if the BusMatrix could not route this IDLE transfer through to a slave and get an immediate response from that slave, the BusMatrix logic facing the master would give this response. Something needs to return the mandatory response, and I would expect it to be the BusMatrix in most cases.
Q2) Again I think this depends on the BusMatrix or interconnect arbitration logic, when it decides to switch between requesting masters.
However if this arbitration logic does switch to a new master source part way through another master's access sequence, the arbitration logic then needs to modify the original master transfer characteristics to be legal for when that master is next selected. So the original master's "broken" sequence must restart with a NONSEQ access, and HBURST would need modifying if it had originally signalled a defined length burst.
The original master isn't aware that it didn't complete its sequence in one single sequence, all it saw was wait states while the other master was accessing the slave, so the arbiter that did the sequence breaking has to ensure the transfers the slave sees are legal (again the starting with a NONSEQ and HBURST being correct for the transfers remaining to be performed by this "new" sequence").
Q3) Don't see any issues with what you have described.
Just make sure that your burst tracking logic is aware that the HTRANS sequence could include BUSY transfers between the NONSEQ and final SEQ transfer of the INCR4 burst.
Thanks for your clear description.