Embrace new world Chisel.

[sequencer]

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.

[jerryz123]

The value in rocket-chip is as much from the quality of the implementations, as it is from the quality of the APIs and dev-experience. We cannot sacrifice the former to improve the latter.

Can you describe more precisely what you want to do? I agree with basically all of the problems you've outlined, but this is still broadly the same directions we've been discussing for a while.

, any other codes as well as RTLs should be private and subject to change

This is not acceptable. Part of the "API" of these generators is the RTL they emit, and that RTL needs to be stable.

[lordspacehog]

Hey yall,

We've started using using this project internally and would like to contribute to the effort to move up to the latest chisel release. What's the best way to start helping with this. We're down to assist in updating/breaking out diplomacy, writing documentation, tests etc. Just don't want to show up out of nowhere and start submitting unhelpful PRs.

Thanks!

[jerryz123]

Working towards Chisel5/6 is orthogonal from breaking out diplomacy. I believe the dev branch of this repo is already tracking chisel5/6, master will be updated soon as well, ideally by the end-of-the-year.

Work on splitting out diplomacy can begin now, if desired. We can move diplomacy to a standalone repository under chipsalliance.

For documentation, I'd be happy to review anything. Is there a particular area you are interested in documenting.

As for tests, this again depends on what you want to test. Building up better regressions for Rocket has been an ongoing task, but all the bus IP deserve better tests as well. What are you interested in?

[lordspacehog]

awesome, thanks for the info. I'm mostly just looking for input on useful starting points for y'all. Happy to take on anything really, just want to be useful and contribute back.

Also happy to join any other chat systems y'all use to plan/execute on this work, and we plan to start attending the meetings as well.

Most immediately digging deeper into diplomacy/TileLink is well aligned with work we're already doing internally.

[jerryz123]

Great! I'm glad to hear that.

We have regular meetings Mondays 10AM PST. Chat is through the Chipsalliance Slack, which you should be able to join. We have a public channel there.

[lordspacehog]

perfect! We're in oakland, so that's easy!

[sequencer]

Thanks for interesting!

Splitting diplomacy is already happened in #2741, you are free to take over and rebasing, sorry i don't have enough time working on it recently.

FWIW, Diplomacy provides such functionalities, and we should consider how to do the migration, as well as new diplomacy implementation.

• implicit parameters(CDE) for hierarchical configurations.
• DAG based parameter negotiation framework(Edge), but notice Bundle construction is coupled with Parameter(Edge), an important part here is the resolveStar function in LazyModule. I'm not so sure about is it still useful, after there is some real world NoC framework in Chisel, see, github.com:ucb-bar/constellation. @jerryz123 can provide more insights to us.
• Linker For LazyModules, you can refer to the instantiate functions in both LazyModule and Node, it provides functions in how to connect LazyModules and auto-negotiated bundles.

The diplomacy provides a bunch of new features for complex SoC designs, but because of the flexibility, it also introduce some problems for verification and physical designs.

The goal in new diplomacy is: be able to decouple Declaration and Implementation in two phases for ECO and hierarchical design/verification flow.

As you may see Chisel is providing these new features step by step, in Chisel 6, we provide important new features for Probe(Cross Module Reference), Object Model(Property in Chisel, SystemRDL in old-school world), Public Module(For linking purpose). These are perfect upstreamed features for big SoC designs.

Question comes to: "How to design a new diplomacy framework based on these". I'm not so sure, but I have some idea to share:

• CDE should be purged, since its impossible to serialize and deserialize, the Turing Complete configuration file is anti-pattern, we should provide a serializable configuration as the input to the hardware generator.
• Diplomacy parameter negotiation is basically depending on a common fact: Physical channel is coupling to SoC parameter. These are perfectly suit for XBar-based designs. But for Mesh designs, it might be another story @jerryz123 can talk about.
• As for linking, I think we should provide a better way to use Diplomacy in real dual-phase elaboration:
  1. For each LazyModule, negotiate the Parameter, and resolve its interface(including IO, Probe, Property), generate the linking script for these public Modules.
  2. Then for each LazyModuleImp, implement it in another phase, even in another Chisel Builder? I'm not so sure about it.

[lordspacehog]

Thanks for all the info! I'll dig into that PR later today and get familiar with it.

[michael-etzkorn]

I believe the dev branch of this repo is already tracking chisel5/6, master will be updated soon as well, ideally by the end-of-the-year.

Could we update to v2.0-RC0 with that? I've internally been doing some tracking of the repo (though mostly only the Bus RTL and APIs) and think rc's overdue for a major release (by semver 2.0 standards).

Don't let perfection be the enemy of the good. That's what stalled last version proposal ( https://github.com/chipsalliance/rocket-chip/issues/3231). IMO, we don't have to wait for this idealistic packaged out version of rc to do a major version release.

Would help with small issues like : https://github.com/chipsalliance/rocket-chip/issues/3545

[michael-etzkorn]

I'll link #3025 since many talking points are similar to the last time there was a chisel migration change.

I'd be in favor of v1.7 for 3.6 #3354 and v2.0 for chisel 5

[lordspacehog]

That's pretty reasonable to me, i think the limiting factor is mostly around time available to most of the maintainers of this project. I'd be down to to handle helping implement and manage a more regular release schedule starting in 2024 after the holiday break.

[lordspacehog]

also the dev branch is currently updated to the 5.x.x chisel release, i've been using it in my own projects that use chisel as a library.