-
Couldn't load subscription status.
- Fork 641
Create ChiselEnum1H where elements have one-hot encoding IDs #2261
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
base: main
Are you sure you want to change the base?
Conversation
0b4a873 to
b97dbd8
Compare
| * 2.U, | ||
| * 4.U, | ||
| * 8.U, | ||
| * 11.U, |
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.
I think we need add a sugar for Mux1H to consume a Enum type and return a Enum type.
These magic num is strange, while seems not correct: 11.U -> 16.U
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 can be done in future PR(just comment for recording)
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.
I think we need add a sugar for Mux1H to consume a Enum type and return a Enum type.
These magic num is strange, while seems not correct: 11.U -> 16.U
|
My further question to this is: how to design the encoding API? 1H API implicitly contains an assertion: |
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.
Generally LGTM.
I strongly depend on EnumOH, it is really good for code simplification.
The only thing we should do is to private the non-user api.
in the future, we should figure out a better api to integrate EnumOH to MuxOH.
| * 2.U, | ||
| * 4.U, | ||
| * 8.U, | ||
| * 11.U, |
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 can be done in future PR(just comment for recording)
dbb8601 to
1dc1c2d
Compare
|
@carlosedp would you mind adding some test to demonstrate the usage? |
e57bda4 to
9e66798
Compare
|
Ping... news on this? |
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.
a little nitpick.
| * 2.U, | ||
| * 4.U, | ||
| * 8.U, | ||
| * 11.U, |
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.
I think we need add a sugar for Mux1H to consume a Enum type and return a Enum type.
These magic num is strange, while seems not correct: 11.U -> 16.U
95ce9c5 to
4fb5693
Compare
|
In the sample below, I really don't like the line to set the selector width... object selector extends chisel3.experimental.ChiselEnum1H {
val s0, s1, s2, s3 = Value
}
val selectorVal = Wire(UInt(selector.getWidth.W)) // <--- don't like this
selectorVal := selector.s1.asUInt
val hotValue = chisel3.util.Mux1H(selectorVal.asUInt,
Seq(
2.U,
4.U,
8.U,
16.U,
))Any ideas on improving this? |
Some thoughts:
|
|
For 1, I could send another PR... ok? |
I would prefer to see everything work together in a single PR.
Yes. Can you try to change your example and see if it works?
Awesome |
|
There it go! Have Mux1H accept ChiselEnum1H and added the toIndex function. object selector extends chisel3.experimental.ChiselEnum1H {
val s0, s1, s2, s3 = Value
}
val selectorVal = selector.s1
val hotValue = chisel3.util.Mux1H(selectorVal,
Seq(
2.U,
4.U,
8.U,
16.U,
))
// hotValue is 4.U
|
b18724b to
515a2bf
Compare
Co-authored-by: Jiuyang Liu <[email protected]>
This PR adds a One-Hot encoded ChiselEnum where the elements have 1H instead of sequential IDs:
The PR is for discussion and in case of greenlit, I'll add test cases for it.
Contributor Checklist
docs/src?Type of Improvement
API Impact
The PR creates a ChiselEnum where elements have One-Hot IDs.
Backend Code Generation Impact
None.
Desired Merge Strategy
Release Notes
This PR adds a One-Hot encoded ChiselEnum where the elements have One-Hot IDs instead of sequential. This change pairs well with
Mux1H.Reviewer Checklist (only modified by reviewer)
3.3.x, [small] API extension:3.4.x, API modification or big change:3.5.0)?Please Merge?