-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add higher level explanations of RoCC + more resources #1486
Conversation
|
||
At a high level, you must tag requests that you send across this interface using the ``io.mem.req.tag``, and the tag will be returned to you when the data is ready. | ||
Responses may come back out of order if you issue multiple requests, so you can use these tags to tell what data came back. | ||
Note that the top two bits of the tag are reserved, and MUST be set to zero, or the interface will exhibit undefined behavior. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh. I think that might actually be a bug somewhere.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's been a minute but from what I recall:
What happens is SimpleHellaCacheIF puts the entire tag into its replay queue, but the actual memory IF drops the top two bits... so when the data returns the tag is missing the top two bits and SimpleHellaCacheIF won't remove it from the nack queue (since it sees that it got a message with a different tag). This leads to the nack queue filling up and simplehellacacheif permanently asserting not ready.
If you look at the two rocc accelerators in chipyard they both set the top two bits to zero presumably for this reason. That's why I mentioned SimpleHellaCacheIF-- even if it should be an implementation detail you may need to inspect it to have working code 🥲
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the actual number of tag bits available to use? Is it 6?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it's
(coreParams.dcacheReqTagBits + log2Ceil(dcacheArbPorts)
so maybe the top log2Ceil(dcacheArbPorts) bits of the tag are supposed to be the port that the request came in from and that's why they need to be zeroed(?)... I'll try to figure this out again 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might just be dcachereqtagbits
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated this so we can get these docs in. Let me know if this still seems unclear.
Small PR based on feedback from EE194 (tapeout) to explain what RoCC is at a higher level, and some resources for actually using the RoCC interface.
Type of change:
Impact:
Contributor Checklist:
main
as the base branch?changelog:<topic>
label?changelog:
label?