[hw,otp_ctrl,rtl] Provide a DFT config and response port

[Razer6]

This port can be overwritten by the integrator with their tech lib. This allows to place custom DFT and response signals. In the future, existing status control and monitor ports should be incorporated to the cfg/cfg_rsp ports.

[vogelpi]

This looks good to me, thanks @Razer6 .

As you noted in an offline discussion, there are already the test_xyz signals for OTP. AFAIK, this are mostly used for the vendor test partition but I don't have any visibility into this so can't say for sure how this interplays with DFT. Adding a separate interface as you did now and inline with what we do for the SRAMs is very reasonable in my view. If really required, one could still combine the two interfaces later on.

@meisnere, @sha-ron , please note that you will have to add the same ports to your OTP macro wrapper.

[vogelpi]

Nit: siognals -> signals

[vogelpi]

CHANGE AUTHORIZED: hw/ip/prim_generic/rtl/prim_generic_otp.sv
CHANGE AUTHORIZED: hw/ip/prim_generic/rtl/prim_otp_cfg_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/otp_ctrl/rtl/otp_ctrl.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

This PR adds a new interface to the OTP controller and the generic macro. Earlgrey functionality is not altered but partners will have to align their macro wrappers.

[a-will]

LGTM

Someday, I think it'd be good to evict the macros from the controllers, though. The dependency of a so-called "prim" on ipgen cores seems backwards, and the controller's prim interface's CSR definitions don't make sense to any but one integrator.

[a-will]

CHANGE AUTHORIZED: hw/ip/prim_generic/rtl/prim_generic_otp.sv
CHANGE AUTHORIZED: hw/ip/prim_generic/rtl/prim_otp_cfg_pkg.sv
CHANGE AUTHORIZED: hw/top_earlgrey/ip_autogen/otp_ctrl/rtl/otp_ctrl.sv
CHANGE AUTHORIZED: hw/top_earlgrey/rtl/autogen/top_earlgrey.sv

[Razer6]

@meisnere, @sha-ron , please note that you will have to add the same ports to your OTP macro wrapper.

Similar changes where added to the SRAMs.

[Razer6]

Someday, I think it'd be good to evict the macros from the controllers, though. The dependency of a so-called "prim" on ipgen cores seems backwards, and the controller's prim interface's CSR definitions don't make sense to any but one integrator.

Yes, this definitively comes from a first product and requires some generalization. But an adventure for a different time :)