Decouple restoring credits from dequeuing an Rx FIFO

[krame505]

Dequeuing from a message FIFO on the device side means that the corresponding credits register should be incremented. This was previously done directly in the deq action. This resulted in mostly harmless, but annoying scheduling conflicts between the handle_tx_* rules in the MsgManager (which read all the credits registers) and any rules in the user's design that make use of a deq action (which writes to a credits register.) Since the handle_tx_ rules are dynamically generated inside the MsgManager 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 the deq actions.

[quark17]

If you can fix the whitespace (see the code-cleanliness check), I'll merge this.

Note that alternatives to using a FIFO would be to use mkCReg for the counter, which would provide two separate register interfaces that schedule in sequence. This would force a scheduling order between the rule that incremenets and the rule that decrements, so there'd be no warning. It would allow them both to execute in the same clock cycle, although it would be done by bypassing the write of one to the write of the other. Alternatively, you could use a special counter module that has incr and decr, and internally it decides whether to increment, decrement, or do nothing, depending on which is called; but I guess you would also need two separate ouputs (for the increment and decrement sides), so you'd need to compute the intermediate value, too, not just the final value, and I don't have a sense of whether that'd lead to any better logic that mkCReg.

Either way, those alternatives would allow incrementing and decrementing on every cycle. The current version and the FIFO version have a conflict between the increment and decrement sides, so there have to be pauses in one to allow the other. Is that OK? Is it known that the two sides wouldn't be able to run that fast anyway?

[krame505]

Yeah, mkCReg would probably be a more elegant fix. However

• The way the counter Regs get instantiated is a bit convoluted due to the use of generics, so this would be slightly annoying to refactor. Mostly a bunch of Vector rxCount (Reg (UInt 8))s turn into Vector rxCount (CReg5 (UInt 8)), I think.
• Every message is 2 bytes at minimum, so in my use it isn't possible to receive a message every clock cycle. Although I suppose there are ways you could receive multiple bytes per cycle, if you had a serial port operating on a faster clock or something.
• I'm going on vacation tomorrow, not sure how soon I'll have time to poke at this more.

So for the moment let's just merge this - I added a TODO comment.