Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rocket-Chip Splitting Progress and Notes #3037

Open
sequencer opened this issue Sep 9, 2022 · 1 comment
Open

Rocket-Chip Splitting Progress and Notes #3037

sequencer opened this issue Sep 9, 2022 · 1 comment
Labels

Comments

@sequencer
Copy link
Member

This issue is used to record how I try to split RC into small different repositories, get rid of the cyclic dependencies, make modules as small as possible to make sure they are able to be reused and even upstream to official chisel standard library.

Build System & Dependency problem

The first important issue for RC is the build system, depending on RC means force the chisel version to be the RC chisel version, which might be old. This reveal the fact that: if user wanna use some functions from rocket-chip, like Rocket Core, Diplomacy, TileLink or other small utilities, without forking a new repository, they are not allowed to depend on the new binary incompatible version of Chisel, thus each projects use their own fork of RC. So I don't think it's possible to establish the ivy publish flow recently. Actually this is the biggest block for RocketChip and other Chisel downstream project to provide a reasonable flow to do the Maven publish(same thing happens in the Chipyard and ip-contrib)

Solution

Solution to this issue, might be two:

  1. The rocket-chip upstream maintain and publish all cross version of Chisel(like the cross version of Scala), It's the burden for upstream maintainer, I hate this.
  2. Invent a new build-from-source feature like what SiFive did with the wake build system or my mill scripts.

Anyway, splitting projects makes the build system issue even bigger, and which is not impossible to resolve with the SBT(override the dependencies). Thus in my splitting work, my decision are:
0. I won't touch the chipsalliance/rocket-chip repo, there might be some pitfall in the on-going splitting flow, I must grantee this huge refactor won't infect other projects.

  1. I'll use mill, and maintain the the common.sc for other projects to source-depend on this project, and use a build.sc for standalone build, the build.sc will import submodules from dependencies folder, but this is only for CI and reproducible build.
  2. for new split projects(cde, tilelink, amba, rocket, diplomacy), they will firstly depends on the origin rocket-chip, but will eventually get rid of the rocket-chip dependency.
  3. The project splitting will include all git history by git filter-repo, I will manually cherry-pick the new patches from current rocket-chip project, and keep all meta-data as it is. This should keep the credit of all rocket-chip contributors.

Progress

TileLink

The new tilelink project will be created at https://github.com/chipsalliance/tilelink

# clone the origin rocket-chip project.
git clone git@github.com:chipsalliance/rocket-chip.git tilelink
cd tilelink
# use the git-filter-repo to filter out the related sources
git filter-repo --path src/main/scala/tilelink/ --path-rename src/main/scala/tilelink/:tilelink/src/
# set remote to new tilelink repository
git remote set-url origin git@github.com:chipsalliance/tilelink.git
git push -u origin master
@jerryz123
Copy link
Contributor

Seems like chipsalliance/tilelink already exists.

Wouldn't it be better to split out diplomacy first?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants