[jtag,dv] Keep TCK running a short time after a transaction #23747
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This handles a rather confusing situation in the DMI frontdoor. The problem is that a DMI request has to travel from dmi_jtag to dm_top (involving a CDC from TCK to the main clock) and then back again (involving a CDC from the main clock back to TCK). If we stop sending JTAG operations in that time, the CDC doesn't actually get anywhere. The wait is jtag_agent_cfg_h.vif.wait_tck(10), which ends up waiting based on elapsed time rather than clock edges. The result is that when we send another JTAG operation to find out the result of the operation, the "busy" status only makes it through the CDC *after* the JTAG operation has finished and reported that the dm is idle. Things then get rather confused when the "busy" status appears, which the agent interprets as a mysterious operation that has just come into being. Signed-off-by: Rupert Swarbrick <[email protected]>
|
The fact that this window exists at all seems like a design error (or maybe a misunderstanding on the part of me / the DV team!) I've raised a question about it on the Pulp project here: pulp-platform/riscv-dbg#166. |
8 tasks
hcallahan-lowrisc
approved these changes
Jun 24, 2024
|
Yep, that's exactly right. The propagation time is essentially measured in cycles of the two clocks. If one of the clocks stops, it takes a while :-D |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This handles a rather confusing situation in the DMI frontdoor. The problem is that a DMI request has to travel from dmi_jtag to dm_top (involving a CDC from TCK to the main clock) and then back again (involving a CDC from the main clock back to TCK).
If we stop sending JTAG operations in that time, the CDC doesn't actually get anywhere. The wait is jtag_agent_cfg_h.vif.wait_tck(10), which ends up waiting based on elapsed time rather than clock edges.
The result is that when we send another JTAG operation to find out the result of the operation, the "busy" status only makes it through the CDC after the JTAG operation has finished and reported that the dm is idle.
Things then get rather confused when the "busy" status appears, which the agent interprets as a mysterious operation that has just come into being.