Support generate structured decoder with DecodeTable

[OceanS2000]

DecodeTable is a structured approach to generate a potentially large decoder, which is usually found in CPU instruction decoder.

There is often an external spec containing structured information about instructions. This API provides a new method to generate corresponding decoder rules without too many hassle.

First, a class implementing DecodePattern trait encodes structured information (such as name of instruction, type of operation, etc) into its other data members. Then DecoderField trait can extract them by programmatically inspecting vale member of DecodePattern and generate output pattern as BitPat to be emitted by our decoder. The new DecoderTable generates such a decoder and allow all fields given to be retrieved as hardware values.

Contributor Checklist

• Did you add Scaladoc to every public function/method?
• Did you add at least one test demonstrating the PR?
• Did you delete any extraneous printlns/debugging code?
• Did you specify the type of improvement?
• Did you add appropriate documentation in docs/src?
• Did you state the API impact?
• Did you specify the code generation impact?
• Did you request a desired merge strategy?
• Did you add text to be included in the Release Notes for this change?

Type of Improvement

• new feature/API

API Impact

chisel3.util.experimetal.decoder API would be extended

Backend Code Generation Impact

Desired Merge Strategy

Release Notes

Reviewer Checklist (only modified by reviewer)

• Did you add the appropriate labels?
• Did you mark the proper milestone (Bug fix: 3.4.x, [small] API extension: 3.5.x, API modification or big change: 3.6.0)?
• Did you review?
• Did you check whether all relevant Contributor checkboxes have been checked?
• Did you do one of the following when ready to merge:
  • Squash: You/ the contributor Enable auto-merge (squash), clean up the commit message, and label with Please Merge.
  • Merge: Ensure that contributor has cleaned up their commit history, then merge with Create a merge commit.

[sequencer]

This API is basically derived from my vector core, Thanks @OceanS2000 for upstreaming this. After this is upstream, we can try to use this to simplify the rocket-chip Decoder.

I think it is a better API than traditional rocket-chip Decoder for these reasons:

1. For each instruction, they will get a trait to store it's metadata for decoding, and the control signals can reuse those metadata to construct the decode table.
2. For each control signals, originally they can only be accessed via UInt.apply(msb, lsb) or UInt.apply(x), which is hard to memories the location of control signals.
3. Adding new control signals needs to change every place, which is a bad practice.

Adding this API is a great thing to unify the Instruction Decode API, and there are things I have been thinking and which can be improved in the future:

1. Other than BoolDecodeField, trait EnumDecode[T <: DecodePattern, D <: ChiselEnum] extends DecodeField[T, D] can be considered.
2. Is possible to unify the design of Uop?

Finally, documentation should be improved for this PR, I suggest you adding the mdoc in doc folder for this decode API.

[sequencer]

I believe this is my "simple work around" which mentioned last year, cc @carlosedp
And this PR will close #2328 as well...
Time flies......