[ip,macros] Move otp and flash macros out of prim*
@qmn is already working on this.
Since Apr 23, 2025.
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
### Description
In OpenTitan we treat some macro cells as prims, but that is problematic as explained below. We intend to treat them as ip blocks instead. The main reason is that we would like to expose them at the top level to ease future integrations.
## Current Approach
Currently the otp and flash macros are nested within the corresponding controllers and are considered prims. These are unlike other prims since they have a CSR register block, and need to connect directly to the crossbar. In addition, they have many vendor specific interfaces typically connected to either JTAG or chip specific blocks, like earlgrey’s AST block. For the most part these vendor specific signals simply pass through the controller and connect directly to the macro.
## Some Problems
- These macro specific interfaces are problematic for the controller since they may require RTL changes in case the macro is replaced by one with a different interface.
- The macro depends on the controller for the creation of its CSR block which creates an awkward dependency for fusesoc.
- The macro could be used independently of the controller but with the current approach they become harder to use.
## Proposed Approach
The proposed approach to deal with this is placing these macro cells directly at the top level, which means adding them as a module in the top config. This means all vendor specific interfaces will be routed directly to the macros, and the interface between the macro and the corresponding controller will only deal with reads and writes.
We intend to avoid changing the controller’s API, which means any errors or alerts triggered by the macro will still be handled by the controller and recorded in the controller’s CSRs.
### Physical Impact
This change is not expected to have significant impact on synthesis and place and route, since the controller and macro can be considered part of one bounding block for the backend tools. We expect some impact on annotations that rely on the path to the macro, but the change will be in the path leading to the macro which can be globally substituted in the relevant scripts.
### DV Impact
The DV environment for the controllers affected will need to instantiate both the controller and the macro in the testbench. The existing interface in the testbench can be kept as is, but some macro-specific signals will connect directly to the macro, since the pass-through via the controller are removed.
## Deciding which Macro to Instantiate
Models built to be generic would instantiate the generic macro provided in open-source for simulation and some emulation. But building models that contain specific macros should be easy to generate. The approach we expect to take is to use fusesoc features that allow replacing some specific cores, so for example we could instruct fusesoc to replace the generic otp_macro by some macro that wraps a TSMC OTP macro, for example. This fusesoc feature is already available in upstream fusesoc, and we expect it to be available in OpenTitan shortly.
### Dealing with Vendor-Specific Interfaces
This approach removes vendor specific interfaces from the corresponding controllers, but we still need to wire these at the top-level. The generic macro provided in open-source needs not attempt to match the vendor macro, which means the actual macro ports can differ between them. We intend to address this via structs that will capture these interfaces. These structs will be placed in packages, and the corresponding fusesoc cores providing these packages can be also chosen using the fusesoc features referred to above. The structs can contain very different signals, but their name and package will be named the same to minimize the impact on the top config.
It is obvious different integrations will need to connect their macros depending on their technology and specific choice of macros. This change will facilitate that customization by reducing the number of components affected.
## Tracking changes
- [x] Move OTP macro --> https://github.com/lowRISC/opentitan/pull/27001
- [ ] Move FLASH macro
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.