Decouple restoring credits from dequeuing an Rx FIFO #22
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.
Dequeuing from a message FIFO on the device side means that the corresponding
credits
register should be incremented. This was previously done directly in thedeq
action. This resulted in mostly harmless, but annoying scheduling conflicts between thehandle_tx_*
rules in theMsgManager
(which read all thecredits
registers) and any rules in the user's design that make use of adeq
action (which writes to acredits
register.) Since thehandle_tx_
rules are dynamically generated inside theMsgManager
module, there was no way to specify a scheduling priority and make the warnings go away.Instead, use a FIFO to decouple writes to the
credits
registers from thedeq
actions.