ARM IHI 0033C:: Section 3.5.2 Write strobes rules: The first bullet point have 2 sub-points stated below:
The first one states that "Write strobes which correspond to an active byte lane can be HIGH or LOW. A transfer with LOW strobe bits for active byte lanes is known as a sparse write."; and the second one states that "Write strobes which correspond to an inactive byte lane can be HIGH or LOW. An interface must use HSIZE and HADDR to determine which byte lanes are inactive."
These two statements for the same scenario regarding Write Strobes bit for both active byte lanes and inactive byte lanes looks conflicting to me. Can anyone please help me clear my doubt?
Hi there, I have moved your question to the SoC Design and Simulation forum. Many thanks.
I think the clue to explaining the wording is in section 3.5.3 regarding interoperability, where if the manager does not support write strobes it should drive all HWSTRB outputs high. This would be the default driver value for a manager that doesn't actively drive strobes, and isn't in any way restricted by the HSIZE transfer width.
So going back to the two sub-bullet points in 3.5.2, HADDR and HSIZE determine the byte lanes that could be used for a transfer. Within the HADDR/HSIZE defined "active" byte lanes the corresponding HWSTRB bits can be high or low, and if they are not all high this indicates what is referred to as a "sparse" write.
And in the "inactive" byte lanes outside the HADDR/HSIZE defined range, we don't care what the HWSTRB bits are because they can't be used for transfers.
The wording in the two bullet points is a bit awkward, but not contradictory. If I was to reword it I would just say that each HWSTRB bit can be high or low, but only HWSTRB bits high within the HADDR/HSIZE defined range of byte lanes can be used for data transfers.
This is different compared to the use of write strobes in AXI, where only byte lanes within the AWADDR/AWSIZE/AWBURST defined area can be asserted. But the differing descriptions will be because WSTRB was always present in AXI, whereas HWSTRB is new to the later revisions of AHB5, so we need to have a simple default value for backwards compatibility.
Hopefully that's a bit clearer.
Thanks for the clarification, but ARM IHI 0033C:: Section 2.2 Manager signals: Table 2-2 Manager signals (Page 2-22): the description of HWSTRB signal states that "Deasserted to indicate when active write data byte lanes do not contain valid data."
I don't think that clashes with anything I've said.
When looking at "active write data byte lanes" (as defined by HADDR/HSIZE), when HWSTRB is de-asserted (low) it means that byte lane does not contain valid data.
The fact that it is referring to the "deasserted" values also then ties in with the default HWSTRB all 1's value. So you only need to de-assert HWSTRB bits for byte lanes you don't want to use within the allowed "active" range.
What you do with the HWSTRB bits for the "inactive" byte lanes is irrelevant as they cannot be used, so we don't care if they are high or low.
I'm always worried when trying to re-phrase something in a protocol document in case I do miss a contradictory statement, but hopefully on this occasion all I've said does still fully agree with each statement in the document, but maybe in a clearer fashion is the spec wording didn't make sense initially.
I have understood that Write_Strobes property in AHB-C is introduced only to consider the active data byte-lanes, and inactive data byte-lanes are irrelevant as they cannot be used in a transfer.Now, please consider the scenario when both Manager and Subordinate supports Write_Strobes property.
Then, in this case too, what will be the values of HWSTRB bits that corresponds to inactive data byte-lanes?I mean, how will the Subordimate recognise active data byte-lanes vs inactive data byte-lanes?
It knows that from the HADDR/HSIZE value for a transfer, so knows which byte lanes are in the active range it then needs to use HWSTRB to qualify.