This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why does an AHB slave require HBURST signal?

HBURST specifies the type of the transfer, but what exactly does the slave/(interface) do with the HBURST signal?

  • Most slaves will probably ignore HBURST and just look at HTRANS to see when a data transfer is required (NONSEQ or SEQ).

    However more complex slaves might use the HBURST information to either prefetch data for a longer known length burst, or buffer up write data before writing it out to slow memory.

    The usual example of this is a DRAM slave controller, which has a high initial access latency while the "row" and "column" addreses are decoded, but subsequent accesses to an already open "row" can then be performed with fewer wait states. If the DRAM controller instead interpreted each access as unrelated to the previous one, it would have to decode both "row" and "column" for each access, so probably much more latency.

    Note that the slave can determine some "burst" information by simply noting that HTRANS=SEQ for subsequent transfers in a burst, and in the DRAM example this could be used to keep a "row" open, but knowing exactly how many transfers will be in the burst allows the slave to prefetch or buffer a known quantity of data.

    As with most AHB inputs, the slave can choose which inputs to use and which to ignore if they are not of any benefit to the slave function. Signals like HADDR, HSIZE and HWRITE are fairly essential to all transfers, and HBURST can be used by burst aware slaves. Possibly less commonly used slave inputs are HMASTLOCK which can be used by slaves with multiple ports, and HPROT by slaves wishing to implement some sort of access type restrictions.