1.) In AHB, When early burst termination is occurred, HRESP should be OKAY and HREADY should be high?
2.) Is there any possibilities that if write transaction is in progress and if burst is not completed then HWRITE will be low after some clock. i.e. if HWRITE is high and size is 32 and burst is INCR8, ADDR is 0x30. Then it is possible that after 4 cycle HWRITE will be low means when address is 0x40, HWRITE will be low. and if possible than what is the slave respose and HREADY?
3.) It is necessary for the master to complete the transfer completely. Master is providing address and control at each clock cycle then it is possible that master give address that is not in the range of the burst? if so than how slave respond?
Hi Ajoo,
1.) What caused the early burst termination ?
If it was a non-OKAY response from the slave being accessed, HRESP won't be OKAY.
If it was arbitration logic switching between masters in the middle of a burst, HRESP will be OKAY (unless that transfer coincidentally also had a non-OKAY response).
But in both cases HREADY has to be high before the next transfer (in the current burst, or the next one) can start.
2.) During bursts all master control signals (HWRITE, HSIZE, HBURST, HPROT, HMASTLOCK) MUST remain constant, so no, HWRITE could not go low after 4 transfers of an INCR8.
Unless of course, going back to your first question, early burst termination has occured.
As for the slave response in this early burst termination scenario, if it was the slave that cause the termination, HREADY/HRESP will be driven according to the non-OKAY response timings, and if it is a change in HGRANT, the slave will simply respond to whatever transfer is being requested of it. Note the the spec says slaves must be able to support early burst termination (see section 3.6.1 "Early burst termination").
3.) If the master breaks the protocol in any way (for example signalling an incorrect address), the slave's response is undefined.
You don't want to have to design every master and every slave to be able to safely respond to ANY possible illegal input sequence as that will massively increase the system gate count, will add latency as you then struggle to meet timings for the larger designs, and will give you a validation nightmare as you try to test every possible illegal scenario.
So the fundamental requirement is that all masters and slaves MUST fully comply with the requirements of the protocol, responding correctly to ANY possible legals input sequence, and then you don't have to worry about "what if...".
Hope that answers some of your questions.
JD
Almost correct.
The slave could just sample all the control signals at the NONSEQ start of a burst, and then just monitor HTRANS to ensure the burst continues as expected (burst termination would be seen as an IDLE or NONSEQ access). The slave then needs to have an address incrementer that steps up in HSIZE increments (observing WRAP boundaries in WRAP bursts). I guess you might want to do this if perhaps the HADDR bus timing from the master was a critical path.
Not until this burst ends (naturally after the HBURST defined number of transfers for a defined length burst, or as a result of early burst termination seen on the HTRANS sequences, or seeing a NONSEQ or IDLE transfer in an undefined length burst), can a new burst start, possibly then HWRITE changing.
Thanks Jd,
I have one more question that master sends address and control signals at every clock then slave has to only sample it and don't bother about address for same burst as address is given by the master and master generates the address by taking account the HBURST and HSIZE and address will always continuous and burst will never terminated till arbiter changes the master and for slave there is no need to calculate the next address in the burst.
and It is not possible that once write transfer is running than in between that read request never come i.e. HWRITE should high till burst is completed.Is my understanding right?
Thanks again.
It means that if slave is designed than it also includes address calculation block and at every clock edge that address should match with the address come from master i.e. HADDR ??
Yes. If the slave monitors HTRANS then it should always have the correct calculated HADDR value for all SEQ and BUSY transfers, matching the incoming HADDR from the master. Only when HTRANS is NONSEQ would the slave need to sample a new HADDR value from the master.
Thanks jd,
It means that slave only monitor HTRANS and also generates the address internally and match it with HADDR. If HTRANS is NONSEQ then only slave sample the HADDR and other control signal. Slave will not sample address and control signal at every clock edge. Is that so?
That wouldn't be the normal way for the slave to work; it will see HADDR for every transfer driven by the master, so it saves logic in the slave if it just uses the supplied master address, and doesn't have an address incrementer duplicating what the master does.
However if you see some benefit to the slave design if it calculates the next HADDR value rather than sample the HADDR value the master will be driving (the master MUST always generate an address for every cycle, so you are not saving master logic by calculating a local address), it should be a relatively simple state machine to track SEQ and BUSY transfers to increment the local address counter. I wouldn't think it necessary to then check this calculated value against the actual HADDR from the master, unless you were just testing your slave design. If you think the master isn't following protocol, that is somethnig the master designer should fix.
Looking ahead to later AMBA protocols, AXI has tried to reduce the traffic on the address channels by only issuing a start address for bursts, and leaving it to the target slave to then increment the address for each subsequent transfer in a burst. So more logic in slaves, less in masters, and lower bandwidth requirements for the address channels. As there is no "early burst termination" in AXI, calculating the AxADDR value for each subsequent transfer in a burst is a simple block for the slave to implement.
Thanks a ton jd.
Hiiii,,,
I have implemented a slave but when error response come, it will assert for one cycle only.
Can you help me how to implement two cycle error response?
Unfortunately I think this would be simply down to redesigning your slave state machine to go through 2 states while returning the ERROR, the first of which has HREADY low, and the second with HREADY high.
If your slave isn't state machine based, you'll need to implement a simple state machine to handle when it is returning ERROR responses.
Probably not something that can be easily described on this type of forum, and the answer too dependent on how you have currently written the slave.
Thank you JD.