Why does APB4 require the byte strobes to be driven low during read transfers?
Hi Colin,
Yes. This is what I meant to ask: "if it has no meaning during reads, why mandate that it is driven low".
An alternate mandate could have been to ignore PSTRB for read transfers the same way PWDATA and PWUSER should be ignored in a read transfer. Would prevent additional gates in managers to gate the signal based on the transfer.
Thanks
I'm not sure you can really compare these two examples.
Write data and write transfer user information can't have any possible use during read accesses as these signals already have active equivalents for reads, whereas write strobes asserted during reads could possibly be misused to imply which read byte lanes are active (there are no read strobes).
So the protocol avoids any possible misunderstanding or incorrect use of PSTRB by mandating that it is driven to zero during reads.
Hello Colin,
I was trying to draw a parallel between AHB and APB. AHB also has write strobes. And AHB spec requires the write strobes to be valid only for write transactions (i.e. it should be ignored for read transactions).
alinx said:An alternate mandate could have been to ignore PSTRB for read transfers the same way PWDATA and PWUSER should be ignored in a read transfer. Would prevent additional gates in managers to gate the signal based on the transfer.
It would not be misused if the spec does not say that these signals are only valid for writes and they are invalid for reads.
But I'm sure there would have been some historical reason why it is required the way it is for APB.
Because of this, unlike AHB where the write strobes can be tied HIGH on the subordinate if a manager does not generate those, the subordinate needs to connect it to the {4{PWRITE}}.
It's a valid point to make, comparing the requirements on write strobes in the APB and AHB5 specs, and not one I've considered before now.
So AHB5 describes that it is "recommended" that HWSTRB is de-asserted for read transfers, but actually later on states that HWSTRB can be tied high on a subordinate interface when the connected manager does not generate strobes, so clearly this is a lot less strictly defined when compared to APB.
The only justification I can think of for this difference is that the AHB5 part of a system is more likely to be implemented by more experienced designers (I'm trying not to be disrespectful to designers using APB) who might have a better system understanding of when and why HWSTRB is being used and so less likely to misunderstand what perhaps HWSTRB being asserted (or deasserted) during reads might imply, whereas the APB is meant to be a simple protocol with more strictly defined requirements, and which is more likely to be the protocol used as an external expansion port on a micro-controller for example to allow less experienced users add their own APB peripherals, so we would want to leave less open to interpretation.
However that is quite a weak argument, but is all I can come up with.
But in the end, each protocol clearly states what is and is not allowed for write strobes, and the different protocols have slightly different requirements. This would be something a bridge between AHB5 and APB would need to consider, but otherwise anyone using one or the other protocol knows what they can do with the strobes on their chosen bus.