[Proposal] Nextgen rocket-chip planning thread. about rocket-chip HOT 8 OPEN

@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.

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.

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

from rocket-chip.