[hw,alert_hander,rtl] Add support for uniquification

[Razer6]

This PR adds support for uniquification of the alert handler in case there are multiple in the design. The PR is split into multiple to make the review easier.

1. Rename alert_pkg to alert_handler_pkg. The rename is done to ease the uniquification of the alert handler. From alert_handler_pkg, alert_handler will be the module instance name.
2. Rename core and SV files to templates but without any change
3. Add the module_instance_name to the tpldesc file
4. Fix template control characters that would change the rendered results
5. Use module_instance_name within the templates and uniquify the alert_handler
6. Do not render module_instance_name into Bazel BUILD file templates.

This only modifies the templates. Rendering the alert_handler (without uniquification) does not yield any RTL or core file diff, which is a good sign.

[rswarbrick]

I'm interested to know what went wrong with this :-) But don't we want to move this commit to come before the change to using module_instance_name?

[Razer6]

The idea of the logic in this function is to unquify the filenames if it is a *.tpl file. So alert_handler_foo.sv.tpl becomes <module_instance_name>_foo.sv. Note, this only works if the file is correctly prefixed with default module name. In this case it is alert_handler. Otherwise, it would overwrite parts of the original file name or everything (due to to the indexing here filename[len(self.ip_template.name):]).

We have templated BUILD files, i.e., BUILD.tpl. Due to the uniquification (and the wrong prefix), BUILD.tpl is rendered to <module_instance_name>. To fix this, I exclude BUILD template files from the file uniquification at all.

But don't we want to move this commit to come before the change to using module_instance_name?

It does not matter. The OpenTitan code bases does not have a uniquified alert_handler that sets the module_instance_name.

[rswarbrick]

Ahah, I see. Thanks for the explanation.

[rswarbrick]

This looks very sensible to me. And thank you for breaking it into small(ish) commits: it made the review much easier!

[rswarbrick]

CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/data/alert_handler.hjson
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_accu.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_class.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_esc_timer.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_lpg_ctrl.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_ping_timer.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_reg_wrap.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/rstmgr/data/rstmgr.hjson
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/rstmgr/rtl/rstmgr.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

Although this looks like a lot of changes, it's essentially just making some names overridable. No risk to the design: the default values for the names are the ones we have been using.

[vogelpi]

I think we should probably first merge #25773. I fear merging one or the other will require some rebasing and this one here seems to be smaller to rebase. What is your view @a-will @Razer6 ?

[a-will]

I think we should probably first merge #25773. I fear merging one or the other will require some rebasing and this one here seems to be smaller to rebase. What is your view @a-will @Razer6 ?

Your analysis is probably correct (i.e. fewer commits to carry conflict resolution steps through), but no preference here. There will be some minor conflicts in the fusesoc core files, and one of us would have to deal with it either way.

[Razer6]

@a-will Is your PR ready? Happy to merge yours first and I rebase

[a-will]

@a-will Is your PR ready? Happy to merge yours first and I rebase

I believe so. I'm just letting it finish off the CI FPGA tests, and then we could click the merge button.

[Razer6]

I believe so. I'm just letting it finish off the CI FPGA tests, and then we could click the merge button.

That sounds good to me!

[Razer6]

@a-will @vogelpi I just rebased to the new changes. Can you take another look?

[rswarbrick]

@a-will, @vogelpi: Thanks for the reviews. This looks good now, but someone is going to need to explicitly authorize the changes.

[vogelpi]

Thanks for nicely splitting the changes into digestible commits @Razer6 . LGTM!

[vogelpi]

CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/data/alert_handler.hjson
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_accu.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_class.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_esc_timer.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_lpg_ctrl.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_ping_timer.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/alert_handler/rtl/alert_handler_reg_wrap.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/rstmgr/data/rstmgr.hjson
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/rstmgr/rtl/rstmgr.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

The only Earlgrey RTL changes resulting from this PR are related to renaming the alert_pkg to alert_handler_pkg. This is fine.