Hi, AHB-newbie here.
For AHB-lite is there any way that the Slave may signal to the Master that it is not ready to accept any transactions?
Driving HREADY low only extends the data phase of the current transaction.
My understanding that the MASTER always expects the respective slave to always be ready to sample the Address on the Address Phase.
Is there also any way for the slave to tell the master that the current address phase needs to be extended?
Thanks.
Simple answer, no.
Sorry but the slave bus interface must always be able to accept a new transfer request (address phase), and only then once it is in the data phase of that request (if it is a NONSEQ or SEQ request) can it signal wait states to stall the master.
So even if internally your slave is busy with some other operation, the bus interface logic itself must be free to accept a request.
Thanks for the info.
Can I say that
1. Coming out of reset, all slaves must drive HREADY high
2. HREADY is only sampled by the MASTER on the data phase -- to check if wait states are needed.
For number 2, when HREADY has been detected low, can the Master continue to issue new transaction requests on the bus? Per my understanding, with HREADY low no slave will actually sample the HADDR
The coming out of reset case is a special one in that in theory there is no previous transfer address phase for the slaves to be responding to, but the requirement that the slaves all drive HREADY high just ensure that as soon as HRESETn is deasserted that any master state machine is free to move on to its first post-reset real address phase transfer, and then one further cycle later the first addressed slave can then respond to a real transfer data phase.
I suggest you to study the AHB wrapper RTL code, it would be helpful.
In fact, all AHB slave got both HREADY (input) and HREADYout port (output). And you can check with RTL code, the slave always sample the address and control signal but it will be active address phase when the HREADY is high.
In AHB-Lite, the bus will be occupied when the slave send WAIT request to the master. If your slave take a very long WAIT state, and you want to free the bus before the slave finish its work, maybe you should not make HREADYout to low, always make it Hi, and use the interrupt to inform the processor back to read the result of slave.
Just be careful for the data computing/processing dependence.
Another method is to build a multi-layer AHB bus.
Thanks for the recommendation.
I do know that driving HREADY low will occupy the bus until it is driven high again during normal operations.
My initial intention was to delay the bus operations coming out of reset. One of the slaves requires some startup time after reset release and I was wondering if pulling HREADY low coming out of reset will cause the address phase of the first transaction to be extended, but from what I gather it looks like it would not.
I think what you would have to do here is only pull HREADY low from your slave when it is in the data phase of the first NONSEQ access it sees after reset, and accept that this will stall the bus until the slave has finished its startup initialisation.
Presumably this would not impact on the system performance because the system can't do anything until this slave access can complete, and at least this solution allows the bus to be used for other slave accesses up until this slave is first NONSEQ accessed.
And importantly this doesn't then violate the bus protocol.
Alternatively if the master could perform other accesses to other targets, you could design the slave to return an ERROR response if it is accessed during this initial startup time, so that hopefully the master would be aware of why that ERROR response was returned and knows it should go away and perform some other transfers to other slaves, before coming back to retry this slave transfer again X cycles later (or as "sieg70" suggested, the slave could use an interrupt to tell the master when to re-attempt the transfer, but that might be overcomplicating the slave design for just an initialisation issue.).
Appreciate the followup info.
I did consider that, ie. stalling the entire bus with HREADY low until that particular slave device is ready but in the end I worked around the top level RESET sequencing such that access to this device is made only after X ms after RESET release to meet requirements. This was not to overdesign the slave controller for now.
This is a good improvement feature to have further down the road.
Speaking on slave ERROR response, is there a standard way that the Master would handle this? I'm working with the CMSDK Cortex M0 example system and I notice an ERROR on the AHB-bus will cause the processor to go in to a HardFault.
Are there any other examples on how ERROR is handled?
I'm not really sure there can be any good "example" of how to handle an ERROR response as the master behaviour will depend completely on the reason the slave gave the ERROR response.
If the cause of the ERROR can be fixed, the master's abort handler will I guess need to interrogate the slave if there were numerous reasons why an ERROR could be returned, and then in some way reconfigure the slave or change the master's access such that the transfer when repeated now completes correctly.
But if the ERROR just signals something went wrong, and the master cannot fix that, the master either has to ignore the error (nothing can be done but it wasn't critical), or it might have to reset the system.
Unfortunately I'm guessing as I'm probably not the best person to answer this as it's more of a SW question, so might be worth posting a separate question in the software forums, and maybe there someone might be able to give you some real examples.
Sorry :)
No problems, will have a look in to the other forums. Cheers!!