[Proposal] Rocketchip Release 1.7

[ZenithalHourlyRate]

Type of issue: other enhancement

Impact: no functional change

Development Phase: proposal

Other information

Since rocket chip has been refactored to chisel3, and we have added the support of Zb/Zk extensions, I think it is possible to tag 4ecc497 (or later commits) as v1.7

[sequencer]

Since Zb/Zk is merged, I think it's OK to release a new version of 1.7.
In the next dev-meeting, I'd like to discuss about mile stones of next releases: 1.8, 1.9, 1.10...

[michael-etzkorn]

We haven't finished the chisel3 port quite yet: #3025

My proposal is to finish that then update to v2.0. Enough change has happened to warrant a major release. It's a good break point for verification policy, and there have certainly been API modifications since version control was reintroduced. It's been a bit of a Theseus ship, and we shouldn't have an irrational fear of major version numbers.

[sequencer]

I don't think there is any reason to bump major versions. 2.0 should be left for releasing breaking changes, for example "PvP version schemes", standalone "rocket", "tilelink" etc.

[jerryz123]

I agree with Michael. Please wait until we finish the CY bump.

[michael-etzkorn]

left for releasing breaking changes

We don't need to support two packages. My reasoning for a major version release: because of the chisel3 porting and hardware updates, the new release marks a break in verification status. I'd like to anchor verification policies around major versions.

At least at my company, framing the chisel3 ported version of rocket-chip as "version 2" and the first tagged v1.4 release (before WG) as "version 1" rocket-chip is an easier discussion with management about adaptation than "version 1.4" and "version 1.7."

[sequencer]

Every rtl change will break verification status . I still feel not good with major bumping for this reason.
The CI in rocket chip is just sanity tests, and for each serious tape out should have a coverage based test or purchasing commercial SiFive U5 core rather than depending on the ‘verification status’ of RC.
We should wait for CY since it’s the largest custom of RC. For recently changes, I don’t think there are major breaking changes introduced by RC, since most of them are from chisel.

[michael-etzkorn]

Every rtl change will break verification status . I still feel not good with major bumping for this reason.

This is exactly WHY to bump the major version. It's not a stamp of verification. It's a stamp of "this is a newer and less verified version of the RTL." We make clear with this in the README that v2.x has a shorter history of tapeouts and verification and suggest alternatives like v1.4 for those who don't wish to be on the bleeding edge. This way users are more aware of verification history, and we don't hide the RTL changes behind minor releases.

We don't need to do this for every RTL change, but after 2+ years of a lot of small changes, they start to add up. A major version release helps with transparency for those who are reliant on open source.

[sequencer]

You can version your own fork of rocket chip.

[michael-etzkorn]

That's true. If we ultimately decide on "v1.7," I can refer to this as a "v2.0" internally. That said, it'd be nice to upstream my team's verification at some point and have a crowd sourced effort for verification on major versions (part of my reasoning for pushing to reintroduce versioning in the first place).

We're more likely to get a spread of users on "v1.7, v.1.8, v.1.9" than if we release a "v2.0.x" where we'd have more users centered around v1.6 and v2.0.

[michael-etzkorn]

I'll link the #2960 issue since I think regardless of if we elect for a major/minor release, a version policy and a verification policy on versions is needed.