chipsalliance / chipsalliance/rocket-chip
Embrace new world Chisel.
- Dominant language
- Scala
- Stars
- 3.9k
- Forks
- 1.3k
- Avg merge
- 5d 13m
- Merged PRs (30d)
- 1
Description
**Type of issue**: feature request
**Impact**: API modification
**Development Phase**: request
Chisel 6 has supports a lot of new feature that is necessary for better Verilog
emission(`typeName`, `group`), better metadata(`Property`, `OM`) and better verification(`LTL`, `Probe`). I wanna use these feature for better dev/user experience.
However there are too much dependencies for Rocketchip, while no one dares to touch most part of RocketChip. This is the main blockage that stops the envelopment of this project. It has a lot of problems, for example:
## Diplomacy
Diplomacy is good, but out-of-date, and couple dozens of features together, diplomacy is basically
- a Parameter negotiation framework;
- an interconnect connection solver;
However it also comes with some shortage:
- leaks support to `Property`, `Probe`
- `LazyModuleImp` depends on `LazyModule` rather than a concrete parameter
- CDE is not a good idea for `LazyModuleImp`
## RocketCore
RocketCore is a mature uArch but also with problems:
- Couple Verification logic with RTL;
- there are no usage for Multiple Port `IBuf`;
- `NBDCache` does have some bugs;
- `CSR` has tones of unused and undocumented IO;
- `RoCC` PTW syncing is always broken;
- dead signals from `RocketCore` to different tiles.
- `trait` with `trait` mixin...
## Any other bus IPs
No test and may even no usage, and may depend on the entire project because of CDE.
So the basic idea of this is burn it down
==
IMHO, the basic idea of resolving this is, tear it apart and rebuild:
## Diplomacy
- Decouple it from RocketChip, making a standalone project(I used to try)
- Add tests.
- Support Property and Probe
- Decouple Node and LazyModule
- Remove strict dependency of CDE
## Rocket
- providing general documentation for `RocketCore` configuration API
- stabilize Interface definition: `IO`, `Probe`, `Property`
Other than these two things should be stable, any other codes as well as RTLs should be private and subject to change without any compatibility concerns, any other projects depending on RocketChip can only rely on such ABI.
## Any other IPs
- live in what they should be, w/o dependent by or dependent to R/C.
This will be a giant work, which I proposed to do years ago, but due to compatibility issue I has been always fail to work on it. But after Chisel 6 releasing, we may need to seriously consider do the migration w/o and back pressure from any other projects.
Contributor guide
Research direction
Start by surveying the Diplomacy, RocketCore, and other bus IP areas named in the issue, along with their existing tests and dependencies. Break the proposal into a scoped migration before changing anything; done would require the agreed Chisel 6 support, decoupling, tests, and stable documented interfaces described here.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- scala
- Domain
- embedded-iot, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 12/100