Is there a way to flatten hwif_in and hwif_out ?

[tusgargmsft]

I don't want to use hwif_in and hwif_out at the generated SV RTL. Is there a flag I can use to skip generating the interfaces?

[galaviel]

second that.
I might need that as well.
sometimes it's needed to to remain compatible to a legacy/previous regfile that had a flat interface.
Also, interfaces may generate a LINT warning when you drag them into a verilog module but use only part of the interface's members.

[amykyta3]

This is not something that is planned at the moment. See: https://peakrdl-regblock.readthedocs.io/en/latest/faq.html#why-isn-t-there-an-option-for-a-flat-non-struct-hardware-interface

[davekeeshan]

I have been working on a non struct version of regblock for a while, the goal is that it must compile in the verilog compiler icarus, which does not have much systemverilog support.

I have been using it in some small projects, and it has been used inside FPGA design successfully.

https://github.com/daxzio/PeakRDL-etana

There are some areas that are still not working great, but it does the basics. It is not meant to be used as one monolithic block, more like you have individual apb interfaces for sub blocks of your design. Arguably it could work, but it becomes unweildly, if regblock works for you, stick with it.

[amykyta3]

Nice. Is this integrated as a change to the same module or does it generate a separate wrapper module that maps flat->struct?

I'm not actually against providing a flattened hwif layer. My main hesitation is that flattening signals scales very poorly with designs that have large arrays of elements, and especially poorly with multiple levels of arrays in the RDL hierarchy. Preservation of arrays in these cases gets very clunky and confusing to the user. If flattening at the hwif layer, that would be tolerable, but I am strongly against such flattening in the internals of the regblock code (address decode, field logic layer, etc.)

All that said, I would support a feature-add of an optional wrapper module that performs the conversion. This would satisfy this relatively common request from users, and also provide a decent way of isolating the feature that makes maintenance and testing sensible.

[amykyta3]

Curious which strategy have you been using for arrays in your implementation? Are you unrolling arrays completely? Or pseudo-preserving arrays by aggregating array compositions into a final multi-dimensional array?

[galaviel]

The flattening is integrated into the same module, replacing the hwif input/output structs (or, SystemVerilog interfaces in my case, which I've initially modified the code to emit, since those support parametrization).

I've added a new flag --hwif-flat to enable this flattening.

The suggestion for an external wrapper that does the flattening sounds great though, and we're actually using this approach in other parts of the design. Interesting.

[galaviel]

Also - I didn't flatten anything other than the HWIF. Obviously flattening the internal structs makes no sense and completely looses the goal of abstraction and code compactness.

The only goal for flattening for us is maintaining compatibility with existing code (drop-in replacement for our old register implementation, little integration effort required...). Also, if you use structs/SV interfaces, you might get lots of LINT warnings, when this struct is used as an input to some module but you in actuality use only a few of the regs in that struct or interface.

The HWIF emitted is at the field level, however array dimensions are not unrolled.

Meaning, if the field has C bits and resides in a register which is is a 1D array of size B, and the entire regfile is a 1D array of size C inside the addrmap, then the port definition for this field will look like:

output     [A-1:0][B-1:0][C-1:0] fld_value,

[galaviel]

"Or pseudo-preserving arrays by aggregating array compositions into a final multi-dimensional array" - so I guess the answer is yes, that's exactly what I'm doing..