[HW]: Add mem_multibanked_pwrgate for correct power management

[Lore0599]

Power Gated MutliBanked Memory

This PR introduces the mem_multibank_pwrgate.svmodule.

Goal

When designing power-aware systems, memory macro cells often include control signals dedicated to powering down/up the bank and entering retention mode. Additionally, when each bank in the memory is made of different cuts, the power control signals must be properly managed to maintain the memory’s interleaved addressing scheme..

Addition:

• mem_multibank_pwrgate.sv: In a memory system with multiple banks and applied power strategies, each bank must be correctly managed to avoid disruptions in memory interleaving. For memories with multiple cuts and interleaved banks, it is important to ensure that power signals do not disrupt the internal bank interleaving. This module is responsible for correctly addressing each internal bank and connecting the appropriate power control signals.
• mem_multibank_pwrgate_tb.sv: A testbench to verify the correct addressing functionality of the implemented module.

[niwis]

Hi @Lore0599, thank you for the contribution! I have one general question: would there be a point in generalising the module further? Specifically, I don't see the direct relevance of the deepsleep and powergate signals in the module implementation. They are "just" packed into the impl_i ports of the tc_srams. Would it make sense to expose the impl_i ports directly (instead of deepsleep_i and powergate_i) to make this module independent of the technology, perhaps even of the use case (power management), and pack them outside the module?

Other than that, I have added a couple of nitpicks inline. Furthermore, I would like to ask you the following:

• add the new testbench to .gitlab-ci.yml
• add a module description in the README.md
• add the new source files to common_cells.core
• fix the lint errors in the CI.

Thanks a lot!

[niwis]

could you change this to an assert macro? See here for an example

[Lore0599]

@niwis, sorry for noticing this only now. I implemented the changes regarding ASSERTION as you requested, and I tested them but I have the following concern.
When we use assertions, they are evaluated within an initial block, meaning they are checked only after the system has been compiled and elaborated. This means that any issues with design parameters might not be detected immediately, allowing the simulation to start normally, which can then cause the testbench to fail later.
In contrast, IF statements are evaluated at compile time. This means that, as soon as we build the system using vsim ..., any parameter errors are immediately detected, causing the build to fail right away.
Given this, I believe it might be more effective to retain IF statements for these types of checks.
Let me know whether I'm doing something wrong :)

[niwis]

Why the spaces before NumPorts?

[Lore0599]

done

[niwis]

I see you fixed bank_sel, but same for *_cut

[Lore0599]

sorry, it was an issue of my text editor.

[Lore0599]

Hi @niwis, thank you for your comments. I'll implement all of them ASAP.
Just one note regarding the impl_i port: this module is intended to be used with a Power Management Unit (PMU). The deepsleep_i and powergated_i signals will be driven by the PMU. The connection can be made through the SystemVerilog system description, but since the module’s goal is to enable power-aware simulation, the ports are likely to be floating initially and then properly connected using the UPF system description.
I don't have much experience with UPF, but over the past month, I discovered that complex types like structs can pose challenges, as UPF seems unable to recognize them effectively. This is the main reason I chose to keep these signals flattened at the interface.
That said, I can implement all your suggestions and try using the impl_i at the interface to see if UPF can handle it :).

[niwis]

I see. Otherwise, perhaps you could add another wrapping layer that packs the signals locally? I'm just thinking that feeding through the implementation ports might increase the reusability of this module.

[Lore0599]

@niwis Regarding the CI linting failure, the source of the error is the missing type specification for some parameters at the interface

common_cells/src/mem_multibank_pwrgate.sv

Line 28 in f374a5b

parameter SimInit = "none", // Simulation initialization

These parameters are of string type, and similarly, in the tc_sram module (https://github.com/pulp-platform/tech_cells_generic/blob/7968dd6e6180df2c644636bc6d2908a49f2190cf/src/rtl/tc_sram.sv#L62) their type is also unspecified.
Would you prefer that I explicitly specify the type as string, or should we consider suppressing the linting error as done here? On this forum it appears that not specifying the string type can serve as a workaround for compatibility with tools like Vivado.
Let me know :)

[niwis]

Sorry, I previously overlooked this. Can you also change this to an assertion macro?

[Lore0599]

@niwis (#246 (comment))

[niwis]

Would you prefer that I explicitly specify the type as string, or should we consider suppressing the linting error as done here? On this forum it appears that not specifying the string type can serve as a workaround for compatibility with tools like Vivado.

Good point. You can add a waiver for this line here:

common_cells/lint/common_cells.style.waiver

Lines 4 to 6 in 554ebbc

	# That is a known issue with string parameter in Synopsys DC
	waive --rule=explicit-parameter-storage-type --line=19 --location="src/stream_arbiter.sv"
	waive --rule=explicit-parameter-storage-type --line=19 --location="src/stream_arbiter_flushable.sv"