[alert_handler] Produce top_earlgrey instance of alert_handler with i…

…pgen

This rather large commit makes alert_handler an IP template, and then uses
ipgen to instantiate the block with the right parametrization for
top_earlgrey.

In contrast to the previous approach, `hw/top_earlgrey/ip_autogen` now
contains a full copy of alert_handler under a unique FuseSoC core name,
`lowrisc:opentitan:top_earlgrey_alert_handler`.

Unfortunately, doing so requires a fair amount of reshuffling, which
cannot be easily split into individual commits while keeping the whole
tree building. Here's what was done:

* Move `ip/alert_handler` to `ip_templates/alert_handler`.
* Remove the `reg_alert_handler.py` tooling, which is now replaced by ipgen.
* Change `topgen.py` to generate the toplevel-specific instance of
  `alert_handler` through ipgen.
* Adjust references in the documentation as necessary. Even though
  alert_handler is toplevel specific we still link to the earl grey
  variant only until a better selection mechanism is in place.
* Adjust references to the reg package in other core files as necessary.
* Adjust the software build as necessary.

Signed-off-by: Philipp Wagner <phw@lowrisc.org>

doc/rm/comportability_specification/index.md

@@ -231,7 +231,7 @@ See the section on [Interrupt Handling](#interrupt-handling) below, which define
 
 ### Alerts
 
-Each peripheral has the option of designating output signals as security critical alerts destined for the hardware [alert handler module]({{< relref "/hw/ip/alert_handler/doc" >}}).
+Each peripheral has the option of designating output signals as security critical alerts destined for the hardware [alert handler module]({{< relref "/hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}).
 These are differential signals (to avoid single point of failure) sent to the alert handler for it to send to the processor for first-line defense handling, or hardware security response if the processor does not act.
 The peripheral lists its collection of alerts with the `alert_list` attribute in the configuration file.
 For each alert in the full system, a corresponding set of signals will be generated in the alert handler to carry out this communication between alert sender and handler.
@@ -454,7 +454,7 @@ Specification of this control is defined in the rv_plic documentation of the cor
 
 Alerts are another critical and common implementation to standardize for all peripherals.
 Unlike interrupts, there is no software component to alerts at the peripheral, though there is at the hardware alert handler.
-See that [specification]({{< relref "/hw/ip/alert_handler/doc" >}}) for full details.
+See that [specification]({{< relref "/hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}) for full details.
 A general description of the handling of alerts at the hardware level is given here.
 
 ### Alerts per Module
@@ -530,7 +530,7 @@ Cause registers for recoverable alerts must either be clearable by SW, or the HW
 Cause registers for fatal alerts must not be clearable in any way and must hence be read-only.
 
 The `prim_alert_sender` converts the event into a differentially encoded signal pair to be routed to the hardware alert handler, as dictated by the details in the
-[alert handler specification]({{< relref "/hw/ip/alert_handler/doc" >}}).
+[alert handler specification]({{< relref "/hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}).
 The alert handler module is automatically generated to have enough alert ports to represent each alert declared in the different included peripheral IP configuration files.
 
 ## Inter Signal Handling

doc/rm/register_tool/index.md

@@ -618,7 +618,7 @@ The following aspects need to be considered when integrating shadow registers in
   It is thus **highly recommended** to use non-permissive reset values and use software for configuring more permissive values.
 
 - Error hook-ups:
-  - Storage errors signaled to the hardware in `err_storage` are fatal, and should be hooked up directly into the [alert system]({{< relref "hw/ip/alert_handler/doc" >}}).
+  - Storage errors signaled to the hardware in `err_storage` are fatal, and should be hooked up directly into the [alert system]({{< relref "hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}).
   - Update errors signaled to the hardware in `err_update` may be software errors and do not affect the current committed value; thus they can be considered informational bugs that are collected into error status or interrupts, and optionally alerts.
     They do not generate error responses on the TL-UL system bus interface.
 
@@ -675,7 +675,7 @@ The following features are currently not implemented but might be added in the f
   Depending on the design, the reset propagation **may** be multi-cycle, and thus it is possible for the shadow register and committed register to not be reset at the same time when resets are asserted.
   This may manifest as an issue if the reset skews are **not** balanced, and may cause register outputs to change on the opposite sides of a clock edge for the receiving domain.
   It is thus important to ensure the skews of the committed and shadow reset lines to be roughly balanced and/or downstream logic to correctly ignore errors when this happens.
-  Note that a module may need to be reset during operation of the system, i.e., when the [alert system]({{< relref "hw/ip/alert_handler/doc" >}}) is running.
+  Note that a module may need to be reset during operation of the system, i.e., when the [alert system]({{< relref "hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}) is running.
 
   Software-controllable resets should be avoided.
   If a single reset bit drives both normal and shadow resets, then the problem is simply moved to a different place.

doc/security/_index.md

@@ -106,7 +106,7 @@ alert policy assignments to handle alerts completely in hardware depending on
 the assigned severity.
 
 [aes]: {{< relref "hw/ip/aes/doc" >}}
-[alert_handler]: {{< relref "hw/ip/alert_handler/doc" >}}
+[alert_handler]: {{< relref "hw/top_earlgrey/ip_autogen/alert_handler/doc" >}}
 [comportable_ip]: {{< relref "doc/rm/comportability_specification" >}}
 [csrng]: {{< relref "hw/ip/csrng/doc" >}}
 [entropy_source]: {{< relref "hw/ip/entropy_src/doc" >}}

hw/Makefile

@@ -11,7 +11,6 @@ REG_OUTPUT_SW_DIR ?= ${REG_OUTPUT_DIR}/sw
 
 IPS ?= aes           \
        adc_ctrl      \
-       alert_handler \
        aon_timer     \
        clkmgr        \
        entropy_src   \

hw/dv/sv/alert_esc_agent/README.md

@@ -7,7 +7,7 @@ ALERT_ESC UVM Agent is extended from DV library agent classes.
 This agent implements both alert(alert_rx, alert_tx) and escalation (esc_rx,
 esc_tx) interface protocols, and can be configured to behave in both host and
 device modes. For design documentation, please refer to [alert_handler
-spec]({{< relref "hw/ip/alert_handler/doc/_index.md" >}}).
+spec]({{< relref "hw/top_earlgrey/ip_autogen/alert_handler/doc/_index.md" >}}).
 
 ### Alert Agent