opentitan
                                
                                 opentitan copied to clipboard
                                
                                    opentitan copied to clipboard
                            
                            
                            
                        [tracking] Use ipgen to produce templated IPs
The following IP blocks are actually templates at the moment and need to be converted to be using ipgen (slides discussing motivation and general approach).
- [x] alert_handler: https://github.com/lowRISC/opentitan/pull/8513
- [ ] clkmgr
- [x] Create ipgen files: https://github.com/lowRISC/opentitan/pull/21202
- [ ] Transition to ipgen files and remove old files
 
- [ ] flash_ctrl
- [x] Create ipgen files: https://github.com/lowRISC/opentitan/pull/21170
- [ ] Transition to ipgen files and remove old files
 
- [x] pwrmgr: https://github.com/lowRISC/opentitan/pull/19801
- [x] rstmgr: https://github.com/lowRISC/opentitan/pull/21041
- [x] rv_plic: #8431
Blocks which need a closer look:
- [ ] ast ~~- [ ] padctrl~~
- [ ] pinmux
- [ ] otp_ctrl
- [x] sensor_ctrl (not templated)
- [ ] xbar
- [ ] xbar_main
- [ ] xbar_peri
CC @alphan
Triaging for flash_ctrl. This is a significant chunk of work and not required for M2.5, however it is likely useful for integrated.
Triaged for pwrmgr - agree
Triaged for 'rstmgr'
Triaged for pinmux - Same conclusion as above
Triaged for sensor_ctrl - Same conclusion as above
Should templated DIFs also accompany templated IPs? Or do we feel that the current mechanisms with C preprocessor macros are enough?
The alert_handler DIFs notably have static_assert() on the exact values of template parameters.
That is a very good question. I have the feeling that some level of customization could be useful and convenient. See also this related discussion regarding documentation: https://github.com/lowRISC/opentitan/pull/19149#discussion_r1266874045
Regarding difs, we had to develop templated difs for otp_ctrl.
I have also seen is asked what are the specific points of customization for some top-specific IPs. This is handled in topgen, but it is not black magic, meaning it could be extracted and documented.
Changing the milestone past M4.
M5 is okay if there are zero Earlgrey RTL changes coming from the open items (which should be the case anyway when the templating is done correctly, right?)
As just discussed with @matutem and @vogelpi, we are moving this to the Multi-Top milestone because it's not strictly needed for Earlgrey-PROD.