Enrich ShiftRegister with SyncReadMem-based implementation.

[milovanovic]

Contributor Checklist

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

Type of Improvement

• backend code generation
• new feature/API
• performance improvement

API Impact

This feature extends the current API preserving full backward compatibility.

Backend Code Generation Impact

If SyncReadMem-based Shift Register implementation is selected this will impact the generated Verilog code.

Desired Merge Strategy

No preference.

Release Notes

Supplement ShiftRegister with SyncReadMem-based implementation.

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.

[sequencer]

After taking a look at the implementation of new ShiftRegister with use_sp_mem = true, I think this is simply adding a new instance of mem to increase ShiftRegister to multiple bank?

Besides the nitpick on names and the usage of null, I think this PR is actually "adding multiple banks support to ShiftRegister."? if so, I think the new banks to add should be 2,4,8..., rather than only being 2.

[sequencer]

How about using name: Option[String]? null in Scala is a bad design choice.

[milovanovic]

Actually the whole idea is summarized in a recent issue. In other words, please have a look at slide 34: for larger (i.e., wider and deeper) shift registers it is much more power and area efficient to implement them using SRAM than with flip-flops. If dual-port SRAM is available (i.e., if such memory compiler exists) that is a straightforward path. If you want to be even more power and area efficient, or if dual-port memory compiler isn't available in the target technology, you can alternatively use two half-size single-port SRAMs in ping-pong configuration. This is well explained in, say, Chapter 9 (pp. 208-211) of the textbook OFDM Baseband Receiver Design for Wireless Communications by Tzi-Dar Chiueh and Pei-Yun Tsai. Even though it is certainly possible to have any number of banks, just as you've said, there is no real gain in power and area for anything larger than two due to (control) logic overhead.

By the way, thanks on the suggestion how to eliminate null. You can review it again.

[sequencer]

Thanks for the clear explanation! Would you mind renaming the arg to useDualSRAMPort and default to false or something similar and provide a documentation to which? That will be much clear to users.

[mwachs5]

Looking good! Please consider my suggestion on the parameter name