riscv-debug-spec
riscv-debug-spec copied to clipboard
riscv
Stored value availability to TM in case of AMOs
[5.5.1. A Extension] states:
- Each AMO instruction is a store for the write portion of the operation. The address is always available to trigger on, although the value stored might not be, depending on the hardware implementation.
And almost immediately after that.
Whether data store triggers match on AMOs is UNSPECIFIED.
My question is:
When it is known that the value stored is available on this particular HW implementation, can it be derived that data store triggers do match on AMOs?
If not, maybe it would be better to drop the although the value stored might not be, depending on the hardware implementation. part to avoid confusion.
This section reads a little awkward to me. Why is there a numbered list, and then another statement that should just be another item in the list? I'd be included to drop the "Whether data store triggers match on AMOs is UNSPECIFIED." statement, but maybe there's some nuance here I'm missing.
@pdonahue-ventana, what are your thoughts?
First, the background: The idea is that if you do AMOADD with rs2=1 and the implementation does far atomics then the hart sends data=1 to some remote entity that adds 1 to the memory location. The trigger module doesn't know whether the final value written to memory is 1 (if the original memory value was 0) or the final value is 100 (if the original value was 99). It's not really feasible to have the trigger module know what the remote entity is doing. However, the implementation could decide to do near atomics where it pulls the memory location into a local cache and uses the normal ALU pipeline to do the add. In that case, the hart has all the information locally so it could support a store data trigger. The spec allows the far atomics implementation to not support store data triggers for AMOs and it allows the near atomics implementation to support store data triggers for AMOs (if they want to).
I don't see a conflict between saying "the value stored might not be" available and "Whether data store triggers match on AMOs is UNSPECIFIED." They both seem to say the exact same thing. But perhaps the redundancy could be eliminated, the text below the list could be hoisted into the list, and we could say: 5. Each AMO instruction is a store for the write portion of the operation. The address is always available to trigger on. Whether data store triggers match on AMOs is UNSPECIFIED. 6. If the destination register of any load or AMO is zero then it is UNSPECIFIED whether a data load trigger will match.
I don't see a conflict between saying "the value stored might not be" available and "Whether data store triggers match on AMOs is UNSPECIFIED."
AFAIU, ... value stored might not be, depending on the hardware... means HW dependent -- one can ask the hardware through some other mechanism (e.g. Unified Discovery or similar) and then it can be expected that the triggers will match.
On the other hand, UNSPECIFIED means general information (e.g. hardware specifies value stored is always available to trigger on for AMOs) still does not mean that it can be used with standard trigger mechanism (this should be explicitly specified by HW that the triggers will match).
"value stored might not be, depending on the hardware" means that hardware can match or not match.
UNSPECIFIED means "the architecture intentionally does not constrain implementations" (from the unpriv spec). "Whether data store triggers match on AMOs is UNSPECIFIED" means that the debug architecture doesn't provide constraints so the implementation can match or not match.
Both seem equivalent to me. Under either sentence, there's no requirement that there's a discovery mechanism for this. The UNSPECIFIED definition says that "implementation documentation may provide normative content to further constrain cases" which means that implementations can optionally declare what they do. Therefore, I think that UNSPECIFIED is better because it explicitly allows a discovery mechanism whereas the ad-hoc "value stored might not be" doesn't address that question.
But perhaps the redundancy could be eliminated, the text below the list could be hoisted into the list, and we could say: 5. Each AMO instruction is a store for the write portion of the operation. The address is always available to trigger on. Whether data store triggers match on AMOs is UNSPECIFIED. 6. If the destination register of any load or AMO is zero then it is UNSPECIFIED whether a data load trigger will match.
I've implemented it in #1024. @pdonahue-ventana, please take a look. Is it what you've had in mind?