[Proposal] Nextgen rocket-chip planning thread.

[lordspacehog]

Type of issue: other enhancement

Impact: API modification

Development Phase: proposal

Other information
Rocket-chip next gen planning thread

Lets capture ideas on how we can improve rocket-chip going forward.

[lordspacehog]

@jerryz123 @sequencer Lets try to capture ideas for improving re-usability of rocket components, as well as improving the ergonomic experience of using the existing APIs.

[jerryz123]

The two most immediate items from my perspective are:

1. Splitting rocket-core into a separate repo. A common use case is to modify some component of the rocket core. Splitting it into a separate repo will make it easier for users to modify rocket without having to fork the rest of rocket-chip.
2. Splitting out core utils into an independent rocketchip-utils repo+package. Many users want to use utilities in their own standalone projects, without having to depend on the rest of rocket-chip. Self-contained utils which depend only on chisel should be split out.

[sequencer]

for the rocket-chip and related repos under chipsalliance we need to maintain I think we can group them into these packages, and we may deprecate and fpga-shells or move to chipyard?

• rocket-tile
  • core(the 5 stage pipeline)
  • core utilities(CSR, TLB, PTW, HellaCache, Frontend)
  • tile(diplomatic & non-diplomatic)
• busip
  • TileLink
  • AXI
  • to be add in the future: e.g. CHI
• riscv subsystem ip
  • plic
  • clint
  • dm
  • to be add in the future: e.g. trace, clic
• periphery ip
  • uart
  • spi
  • i2c
  • iic
• utilities
• subsystem

Unlike diplomacy, I propose firstly splitting them into a separate build target(a different jar), gradually sort out the dependencies.

Another goal for splitting is creating a stable IO and serializable parameter for all these public modules. It may change a lot, but for a more DV and PD friendly flow.

[lordspacehog]

yeah, i generally agree with these ideas. Probably the best plan is to just start by cleaning things up, splitting out rocket core as a tile implementation, and splitting out whatever utils we can. That'll at least reduce what people downstream need to pull in to make changes to rocket of use the more useful utils we've made.

after that probably bus ips and consolidate the periphery devices into the rocket-chip blocks repo which we should also do an overhaul to.

That would put us in a pretty good position to start making more structural changes to the API and parameter flows to get them into a more ergonomic state that could be stabilized more easily.

[poemonsense]

Is it possible to publish Scala packages routinely with necessary dependencies, especially for the reusable parts? That would greatly simplifies other repos dependent on rocket-chip submodules.

[sequencer]

Is it possible to publish Scala packages routinely with necessary dependencies, especially for the reusable parts? That would greatly simplifies other repos dependent on rocket-chip submodules.

We plan to publish diplomacy regularly, but for rocket-chip, I'm still hesitating, because the API of which is still a mess.

[jerryz123]

A goal of this work should be to enable more published sub packages, not just diplomacy. But I agree diplomacy should be the first place to start

[sequencer]

Yes, I'm also working on chipsalliance/chisel#3999 to provide a clear hardware interface among different projects recently. it won't be too long to finish. After finishing it, I think we can decouple provide the hardware generator with concrete parameter, and IO interfaces. At that time I think we can publish more sub-packages.