mv fifo over from ip-contributions

[schoeberl]

Contributor Checklist

• [x] Did you add Scaladoc to every public function/method?
• [x] Did you add at least one test demonstrating the PR?
• [ ] Did you delete any extraneous printlns/debugging code?
• [x] Did you specify the type of improvement?
• [ ] Did you add appropriate documentation in docs/src?
• [x] Did you state the API impact?
• [x] Did you specify the code generation impact?
• [x] Did you request a desired merge strategy?
• [ ] Did you add text to be included in the Release Notes for this change?

Type of Improvement

• new feature/API

API Impact

ad to the future Chisel std lib (mv from ip-contributions)

Backend Code Generation Impact

Desired Merge Strategy

• Squash: The PR will be squashed and merged (choose this if you have no preference.

Release Notes

Reviewer Checklist (only modified by reviewer)

• [ ] Did you add the appropriate labels?
• [ ] Did you mark the proper milestone (Bug fix: 3.4.x, [small] API extension: 3.5.x, API modification or big change: 3.6.0)?
• [ ] Did you review?
• [ ] Did you check whether all relevant Contributor checkboxes have been checked?
• [ ] Did you do one of the following when ready to merge:
  • [ ] Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • [ ] Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[ekiwi]

When would someone want to use these FIFOs instead of the Chisel Queue? If there are QoR considerations, maybe there should be a way to change Queue implementations without changing the code that uses it.

[schoeberl]

Because it delivers nice implementation variations all out of an abstract class. There you can really change the implementation type without changing the client code. I don't think this can easily be done with Queue.

[schoeberl]

There was a decision to keep those FIFOs in ip-contribution.