Recommended way of PeakRDL-regblock signal distribution across RTL hierachy

[philipaxer]

Hi All,

I am missusing this board to ask a question about PeakRDL-regblock. I dont want to create an issue, where there is no real bug. However I expect that this question also applies to various other CSR code generators.

In my design, I am using PeakRDL-regblock to generate a CSR bank. The way how this generator works is it outputs nested structs of the following form:

register_map__in_t hwif_in, // this is what goes into the CSR bank
register_map__out_t hwif_out // this is what comes out of the CSR bank

The user can access the register/fields the following way:

hwif_in.MY_REG.MY_FIELD.next = XYZ;

Here, MY_REG is a struct that contans all fields. and each field has some signals to read/write it (depening on directivity).

I am a lazy guy and I dont want to code a lot of boiler plate to wire of the CSR registers or fields to the respective destiations. So what i do is just connect the entire hwif_in and hwif_out to each possile target. Naturally the respective register fields are only driven by one process. I.e. lets say I have two registers REG_A and REG_B. Then I am currently doing it like that:
In module A i am writing REG_A

hwif_in.REG_A.MY_FIELD.next = XYZ;
// I am not touching REGB_B inside hwif_in whatsoever!

In module B i am writing REG_B

hwif_in.REG_B.MY_FIELD.next = XYZ;
// I am not touching REGB_A inside hwif_in whatsoever!

However some tools (e.g. Vivado) think that there is a multi driver issue as the struct seems to be an output from both modules. I am curious how others use this and if there is some intented way. I exect that there is no silver bullet, but I guess this is a common issue. Generally I am really surprised of much builder plate code HW engineers are willing to write...

regards
Philip

[amykyta3]

For hwif_out, it is definitely ok to fan that out everywhere with no issue. Any sensible synthesis tool will prune away un-referenced nets.

hwif_in is not as flexible. If you follow the standard strictly, the connections would indeed be multi-driven since the struct members are declared as logic which are var net types. So Vivado is indeed correct to report that you have multiple drivers.

What I usually do for hwif_in is split it apart and use the sub-struct definitions. In the register package, I intentionally declare the child structs as their own typedefs so that you can use them to distribute sub-trees of the hwif throughout your design.

That lets you do something like this:

// Top module
assign hwif_in.REG_A = reg_a_in;
assign hwif_in.REG_B = reg_b_in;

// Module A
assign reg_a_in.MY_FIELD.next = abc;

// Module B
assign reg_b_in.MY_FIELD.next = xyz;

This concept can be extended across other regblock hierarchies like regfile and arrays of components.
Hope that helps!

[philipaxer]

Thanks for your explanation. I excpected this response... System Verilog is really annoying wrt. that. I hoped there was some magic way (via tristate assigments or so) to make it work.

regards
Philip