Embrace new world Chisel. about rocket-chip HOT 12 OPEN

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.

from rocket-chip.

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

from rocket-chip.

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

from rocket-chip.

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.

from rocket-chip.

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!

from rocket-chip.

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?

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.

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 (
#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 : #3545

from rocket-chip.

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

from rocket-chip.

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.

from rocket-chip.

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.

from rocket-chip.