Update Instructions with riscv-opcodes

[ZenithalHourlyRate]

Related issue: riscv/riscv-opcodes#106

Type of change: other enhancement

Impact: API modification

Development Phase: proposal (waiting on riscv/riscv-opcodes#111)

There is tmply a workaround for CI (thus this PR is a draft now). Will be force pushed once the issue is resolved.

Release Notes

• Updated Instructions from riscv-opcodes
• Fixed legacy instruction name
• Separate RoCC instructions into CustomInstructions.scala

[ZenithalHourlyRate]

Before the new riscv-opcodes, we rely on SLLI_RV32 to make both RV32 and RV64 work in one Instructions.scala, however, in the new version we do not have such convenience as the API has changed.

One more bug to note here is that we currently do not have BINVI_RV32 (BINVI has different encoding for RV32 and RV64) so the current Instructions.scala in master does not work for RV32 Zbs extension (thus #2950 is affected). This actually is a bug from old riscv-opcodes (i.e. not generating BINVI_RV32).

So to use the new riscv-opcode and fix the BINVI_RV32 issue, we need two file Instructions64.scala (generated by make EXTENSIONS="rv_* rv64*" inst.chisel and rename object Instructions to object Instructions64) and Instructions32.scala (generated by make EXTENSIONS="rv32*" inst.chisel and rename to object Instructions32), and for IDecode.scala, it would import Instructions64._ globally and for class I32Decode it would use Instructions32.SLLI instead of SLLI_RV32.

[aswaterman]

I am just amused that, over the course of 42 minutes, we went from "I can not decide on this. This needs @aswaterman" to "click the merge button". 😆

[sequencer]

sorry @aswaterman I mean this PR
seems to be ok.(didn’t break any thing, but just bump the Instruction.scala.
The issue is about the removing custom instructions, I think this need your opinion to decide to keep as it is or we can remove it since it wont be generated from riscv-opcodes anymore.

[aswaterman]

I agree, it is fine; I just thought it was funny.

[sequencer]

Thanks for understanding, I just wanna speed up the developing procedure. If some PR do have some issues or you don't like it, we can at least revert them.

[michael-etzkorn]

Thanks for understanding, I just wanna speed up the developing procedure. If some PR do have some issues or you don't like it, we can at least revert them.

Ok with the speed of PRs so long as we start a versioning scheme (doesn't need to match how software usually does it) and a changelog that regularly keeps up. The git commit history is great and all, but if main heads in the direction of being more of a developer branch, we should definitely tag the most stable commits and document the PR changes. I'll lead charge on this starting with the last version tag up to the Chisel 3.5 bump PR.

[sequencer]

Ok with the speed of PRs so long as we start a versioning scheme (doesn't need to match how software usually does it) and a changelog that regularly keeps up.

We discussed in the working group meeting:

1. Currently we won't guarantee the master being API stable, since all APIs in RC is public.
2. The only versioning scheme currently is the commit-based version.
3. There won't be any bug fix to backport to a specific "stable" version.

we should definitely tag the most stable commits and document the PR changes.

How do we define the "most stable commits"?

For any companies/users, they are free to stick at any commits, or fork a branch to provide their own "stable" version, but I believe the RCW won't guarantee a specific commit/branch is "stable" enough for any usage.
For now, the only thing we can do is adding as much as possible tests to guarantee the commits on the master are more "stable". So since all commits on the master passed the test, they are equally "stable".