lowRISC / lowRISC/opentitan

[multitop] Tracking issue

Open
#26,116 4 comments 0 reactions 1 assignee View on GitHub

@pamaury is already working on this.

Since Feb 4, 2025.

Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

### Description

This issue track issues identified during the multitop work and that should be addressed in the future:

High priority:
- [ ] document devicetables: in `SUMMARY.md` and in Doxygen
- [x] Document `//hw/top` mechanism: [done](https://opentitan.org/book/hw/top/index.html)
- [x] Doxygen multitop: see #26753
- [ ] Document devicetables in /book/sw/ and point to DT
- [ ] Document dtgen: #27521
- [ ] Document top creation: #27354
- [ ] Cross-ref dtgen and top creation
- [ ] Improve multitop documentation, see #25721
- [ ] add a generic way to supporting per-top files such a linker files, see e.g. https://github.com/lowRISC/opentitan/pull/26038#discussion_r1940948885 This is already done for IPS, see https://github.com/lowRISC/opentitan/pull/26248/commits/e3db8214b1541c0b7a9c06a2b914d1be1c692085 and #26248 more generally
- [ ] find a better way to support per-top init code, such as in `test_rom_start.S`, see https://github.com/lowRISC/opentitan/pull/26038#discussion_r1941009139 and the testutils/test_rom more generally. Probably needs the previous item done first so we can have per-top libraries of helper functions.
- [x] Remove all hardcoded rstmgr constants, see [#26195](https://github.com/lowRISC/opentitan/issues/26195#issuecomment-2786156249)
- [ ] Restore english breakfast

Medium priority:
- [ ] add blzmod and out-of-tree support to `hw/top`, see https://github.com/lowRISC/opentitan/pull/25580#issuecomment-2546834568 Prototype in #26191
- [ ] make the build system more multitop aware: prototype work done by @pamaury , still far from complete
- [ ] fix `arch.{c,h}` to handle multitop, see e.g. https://github.com/lowRISC/opentitan/pull/26038#discussion_r1943348952
- [x] fix status code for DV #26335
- [ ] remove clock freq definitions when everything depends on the DT
- [ ] some DIF unittest don't run because they require `--//hw/top=darjeeling`. We need to make sure that every unittest runs on at least one top. Maybe figure out a better way to do that?

Low priority:
- [ ] we apparently do not have any test that makes sure that the mask ROM contains the `chip_info` data. Maybe we should create one.
- [ ] check if multireg name issue still exists, if so then fix reggen, see https://github.com/lowRISC/opentitan/pull/26038#discussion_r1943361774
- [ ] revisit the ROM scrambling script to avoid a hardcoded table, see https://github.com/lowRISC/opentitan/pull/26038#discussion_r1940323255 and #26332
- [ ] start thinking about to handle IPgen'ed IPs with several instances: how do we handle DIFs? different register layouts? different interrupts?
- [ ] Revisit DT IP extension mechanism, see #26133 for details
- [ ] `uart_init` is marked as `noinline` because some rv_dm tests want to set a breakpoint there. This potentially wastes some bytes in the binary. Instead, we could try to record "breakpoint" location in a note section. Suggestion by @luismarques is to use `breakpoint1: { __attribute__((section(".breakpoints"))) static void *bp = &&breakpoint1; }`

**Done**
- [x] Remove all hardcoded pwrmgr constants, done in #26441
- [x] document `hw/top` (done: #26328)
- [x] some pins are MIOs on EG but DIOs on DJ, like the gpios. We need to make the code aware of that and find a general mechanism to handle both in case where it makes sense. Update pinmux testutils done in #26504, users need to be converted
- [x] go through all code in DIFs/testutils/test_rom/silicon_creator and evaluate the use of top-specific names for the DT, e.g. `kDtUart0` or `kDtRstmgrAon`. See @a-will in https://github.com/lowRISC/opentitan/pull/26038#pullrequestreview-2591443706. Mostly done, we also have introduce a "first" entry in #26774

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.