-
Notifications
You must be signed in to change notification settings - Fork 28
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
Missing specification of how bit numbers are determined #197
Comments
Thanks for the report. To be sure, we label the LSB as bit That's interesting to hear that PowerISA does it as it does. We can add verbiage to make the convention we use explicit. |
Just as a note to myself (or anyone who snipes the issue from me), this note is probably best given as a language-wide convention, rather than a footnote on |
And to be clear, this is a separate issue from endian, which refers to the storage (in memory) ordering of Bytes of a word. In-register operations do not depend on the endian. |
Which is to say, please don't use "endian' to describe the bit ordering in firrtl. Also, 1.3.2 of the Power spec for those curious to check and it's weird when numerically equivalent words of different sizes have their common bits in different numerical positions. |
I was under the impression that the One True meaning of "endian" was from which end you ate your boiled eggs. |
the FIRRTL specification doesn't specify how to determine if
bits(UInt<8>(0hF0), 3, 0)
returns0hF
or0h0
-- specifying this is needed because some significant specifications (the PowerISA specification in particular) counts bits starting from 0 at the MSB end and counting up to the LSB end, and most others count bits starting from 0 at the LSB end, though I expect some start counting at 1.The text was updated successfully, but these errors were encountered: