-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chisel decoder #2836
Chisel decoder #2836
Conversation
e5befad
to
6bf257d
Compare
@jackkoenig Ask to merge this. |
9d22607
to
2376492
Compare
I bumped to 3.5-SNAPSHOT to show that this is still failing (at least for me locally) |
This is really weird:
The Rocket Decoder do have different output width... |
0d18cec
to
921b8fd
Compare
a9f595e
to
24baee5
Compare
bf87454
to
b48ddfe
Compare
b48ddfe
to
81355ac
Compare
When using new API, io.rw.addr << 20 would not match any entry in decode_table. e.g. When io.rw.addr[11:0] == "h102", after left shift 20 it would become "h10200000", which wont match SRET ("h10200073") as defined in Instructions.scala. Note, SRET is not defined with DontCare. Magically, old API can work with this case, which should not. In this fix the least significant 20 bits of decode_table keys are dropped to match addr.
ae002f5 fixed a legacy bug from original QMC decoder in RocketChip. Thanks debugging by @ZenithalHourlyRate |
@jackkoenig Ask for merge. |
It works with 3.5.1 now. After review, I'll rebase it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking with rocket-chip folks, it would be better to not need the explicit widths, let's get 3.5.2 released and bump to that which will make this work better.
This involves ensuring all BitPats that correspond to a particular portion of the decoded result are of the same width. BitPats with no "don't cares" can be zero padded to the common width. BitPats with "don't cares" that are too small are an error.
@sequencer I've pushed some substantial changes that remove the need for any explicit widths. Now |
Ignore my review / deleted comments, the |
For posterity who may hit the requirement about a BitPat having don't cares and needing padding, see #2949 for an example of the general approach. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ship it!
opps, I doubt this may blames to CSR addresses decoding. |
@sequencer I've restored one of your changes to the CSR in f2cbe12, do you think this is the issue? |
Yes, I have been thinking, I thought it used to be a bug, but I can't understand, why it worked before... |
I just |
in light of possible bug with CSR decoding
In chipsalliance/chisel#2387, I pad 0 to LHS, since I think it is intuitive.
It seems to pad RHS? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine with me. I was relying on QM doing the optimal thing (there should be no dependence on input bits 19..0 in an optimized circuit).
Partially reverts #2836, but in such a way that it works with the new QMC.
Partially reverts #2836, but in such a way that it works with the new QMC.
This PR use new chisel API to replace original RocketChip Decoder.
Chisel Decoder depends on the explicit width, so I adds explicit width for most usages. This will be a breaking change to RC.
Related issue:
Type of change: new feature
Impact: no functional change
Development Phase: implementation
Release Notes
Switch to Chisel Decoder