[reg, rtl] create field and csr arrays in uvm reg module, rtl IOs in parameterized modules about opentitan HOT 10 CLOSED

I think this could still be very beneficial for DV, and given that we have to update the FPV and DOC backends, it probably makes sense to rework the DV backend as well.

Let's revisit this once we have an initial working RTL prototype (on an integration branch, as @eunchan suggested). I think the new multireg structure should be compatible with what @sriyerg had in mind here...

from opentitan.

I agree with it. Having a way to define register modules parameterized is quite beneficial. But generating the html doc may cause problems. We might end-up to generated based on the top configuration if we go forward to have parameterized register blocks.

I remember the datasheet from Synopsys also has some similar concept in their IPs. If a register is dependent on the parameter, it uses an alphabet letter to show the offset following the register. It makes quite hard to understand but if we generate the combined top-level register docs for IPs, we could show exact address in the doc too.

from opentitan.

As far as I understand, the need for regenerating the regfile and all other artifacts (like html) is not so much of an issue here, but the actual way of how you plumb it in SV (no matter whether in DV or RTL) is a bit cumbersome for parametric registers at the moment.

It looks like part of this issue could already be solved by having the regfile generator output multiregs as a single packed datastructure whose name is the multireg basename, instead of creating new structs for each multireg word.

This solution is already partly there: a multireg is output as a packed struct with subfields, which means that you can access the multireg content by indexing instead of using its subfield names. However, if the combined width of the subfields surpasses the register width, this currently creates separate and differently named structs for each multireg word, which kind of impedes this solution.

Let me explain what I mean using an example from the alert_handler regfile wrapper.
I have a templated part that basically stacks subfields of a multireg:

  assign reg2hw_wrap.alert_en = { reg2hw.alert_en.en_a3.q,
                                  reg2hw.alert_en.en_a2.q,
                                  reg2hw.alert_en.en_a1.q,
                                  reg2hw.alert_en.en_a0.q };

As long as the number of enables is below 32 bit, I could also write this as

  assign reg2hw_wrap.alert_en = reg2hw.alert_en[0:3];

I just need to account for the fact that multiregs are currently stacked big endian.

Now, if the number of alerts is greater than 32 (say 64), this is not possible anymore, since the multireg fields are distributed across two register structs named alert_en0 and alert_en1. However, it would be possible if the multireg were still output as a single packed struct alert_en, even if it comprised several words. We would not have to change the html output, just the datastructure splitting of multiregs...

Does this make sense :)?

from opentitan.

from opentitan.

Yes exactly, but I would just keep the basename without any index. I.e., a multireg is currently already partially nested as ipname.multiregbase<idx0>.field<idx1>.q. By partially I mean that we always group them according to the register layout and pack 32 bits into one nesting level. What I am suggesting is to just use "multiregbase", and nest all fields under that name. The fields are still uniquely enumerated up to whatever the maximum is.

It is not pretty, and the indexing is a bit awkward since fields are stacked big endian, but at least we could plumb it in SV without templating. I still need to check the code, but I believe it could be a good intermediate workaround until Eunchan's overhaul of reggen/topgen (#30) is implemented.

from opentitan.

from opentitan.

from opentitan.

Yeah, it is only a partial solution and we would still have to generate the package using the template flow. But we could avoid having to write additional templated breakout wrappers to plug the registers into RTL.

from opentitan.

@eunchan or @msfschaffner has the status on this been refreshed based upon current multireg thinking?

from opentitan.

already supported multi-reg/field in RAL mode. Closing this

from opentitan.