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?
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.
No problems, will have a look in to the other forums. Cheers!!
View all questions in SoC Design forum