Hej,
in my SoC application I have an AHB Bus bridge behind a PCIexpress to AHB bridge. This is because the logic between the two bridges has to determine whether the AHB transaction from the PCIe/AHB bridge targets a local address in the module (MSI-X tables etc.) or should be forwarded to the external application logic. Depending on the way that the PCIe BAR is configured, the AHB/AHB bridge should read ahead on the downstream port (prefetchable BAR) or not read ahead (non-prefetchable PCIe BAR). For SINGLE, INCR4, INCR8, INCR16 the solution is trivial. For INCR this doesn't seem to be so easy.
I had thought of using the HPROT signals to indicate an access to a prefetchable target but strictly according to the AMBA specification HPROT[3:2] only seem to apply to write accesses. Is that correct? At the moment the upstream PCIe/AHB bridge just splits INCR accesses into a series of SINGLEs which is probably not strictly correct if HPROT[3] is not set.
I suppose another solution would be for the upstream PCIe/AHB bridge (Master) to set HTRANS to BUSY after every address cycle if HBURST is set to INCR and only set HTRANS to SEQ when read data have been returned if the the burst is intended to continue. The downstream AHB/AHB bridge could detect this on the slave side and use this information to suppress read ahead on the downstream (Master) side.
I don't want to introduce sideband signals as this makes the solution proprietry. It would probably be OK to use the HAUSER or or HRUSER signals but these seem to be AMBA 5 specific.
Is there an ARM recommendation on how to solve this? i.e. to pass information across the AHB/AHB bridge so that the downstream side recognises whether read-prefetching is allowed or not if HBURST is set to INCR.
Thanks.
HPROT[3] (cacheable/modifiable) does apply to both reads and write, HPROT[2] (bufferable) is more obviously just for writes.
Although you are not using AHB5, the AHB5 protocol attempts to describe some "memory types" using HPROT combinations, with specific behaviours for each type described in sections 3.9.3 to 3.9.5, and you can see that "Device" types do not allow any read data prefetching, whereas "Normal" memory types (anything not "Device") DO allow prefetching.
In 3.9.3 table 3-7 defines the different memory type encodings, and you can see that HPROT[3] low is "device", HPROT[3] high is "normal", and so could be used to indicate when prefetching is allowed, assuming your transfer source is driving HPROT[3] correctly for each transfer.