Skip to content
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

[RFC] Support bytes in Value.cast #673

Closed
Lunaphied opened this issue Jan 3, 2022 · 1 comment
Closed

[RFC] Support bytes in Value.cast #673

Lunaphied opened this issue Jan 3, 2022 · 1 comment
Labels

Comments

@Lunaphied
Copy link
Contributor

Lunaphied commented Jan 3, 2022

Background

It is frequently useful to directly assign byte string constants to a Signal or otherwise use them in a context where ValueCastables are expected. This RFC proposes supporting this pattern in Amaranth by handling bytes values in Value.cast.

Implementation

These values would be "lowered" to a Const containing the entire value of the bytes packed in little-endian byte order. This would thus produce a Value of 8*len(bytes) bits. The goal here is not to use the minimal space for each value but to encode them in a useful way for debugging.

Why?

One significant use for this is for debugging, allowing values that are easily recognized in traces or in printouts to be used directly. Currently each project desiring this capability has to implement it locally; this leads to a lot of replicated code. Otherwise it is simply a feature we have encountered the desire for on multiple occasions when dealing with ASCII constants in protocols and testbenches.

Why not?

  • Some users could theoretically find this confusing
  • Not useful enough to justify
  • Concerns over how the bytes end up packed (ordering)
@whitequark
Copy link
Member

Thank you for filing this RFC, @modwizcode.

We discussed this RFC at the weekly meeting. We reached a rough consensus that while potentially convenient, the alternative (using int.from_bytes(x, byteorder="little")) doesn't bother anyone and the value of this addition to the language seems insufficient to justify the added complexity of adding another implicit conversion.

Therefore, I'm closing this RFC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants