-
Notifications
You must be signed in to change notification settings - Fork 52
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
Builder: rehome builder_util
#1665
Conversation
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.
Looks good! I'm really missing Rust-style trait
s here which can just add methods on structs without having to define them in the same file. I wonder if there is some sort of idiomatic way to do this in Python but if not, keeping these methods in the ComponentBuilder makes sense to me.
Thanks for taking a look. I've gone ahead and made this change all over, and as a result, the entire |
Looks like we have some failing tests! |
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.
Awesome. I definitely think this is headed in the right direction, i.e., adding higher- and higher-level stuff to the builder to make it easier to express the common case.
On @rachitnigam's question:
I'm really missing Rust-style traits here which can just add methods on structs without having to define them in the same file. I wonder if there is some sort of idiomatic way to do this in Python but if not, keeping these methods in the
ComponentBuilder
makes sense to me.
The way to do this in Python is with mixins. It would look like:
class ComponentBuilderBase:
# all the basic stuff
class ComponentExtra:
# high-level fancy stuff like `mem_write_seq_d1_to_reg`
class ComponentBuilder(ComponentBuilderBase, ComponentExtra):
pass
Multiple inheritance combines the two sets of members together in one exported class. Not sure it's worth it in this case, but we could consider it.
I'll keep this in mind and return to it in a separate PR! I just don't want to gunk up the works and create more merge conflicts than I can handle |
In #1637, we proposed finding a new home for many of the utilities that currently live in
builder_util.py
.In this PR have done that, experimentally, for one such helper:
insert_eq
. It now lives underComponentBuilder
and is calledeq_use
. I have piped the changes through to all the Python files, though you may want to look specifically atfifo.py
since it benefits from the cleanup of #1664.Note that I'm calling this utility
eq_use
to differentiate it from the existing methodeq
that is also declared onComponentBuilder
. The helpereq
just returns a StdEq cell, while this neweq_use
variant creates a cell, wires up its ports, and then returns the group and the cell that do all this.Say we have:
we used to use the utility via:
and now we can do it more directly via:
Please let me know what you think, and I'll propagate these changes all over, for all the other utilities.