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 draft] New pin management system #460

Open
whitequark opened this issue Oct 22, 2023 · 1 comment
Open

[RFC draft] New pin management system #460

whitequark opened this issue Oct 22, 2023 · 1 comment
Assignees
Labels
applet Component: applet gateware Component: gateware

Comments

@whitequark
Copy link
Member

whitequark commented Oct 22, 2023

[This issue contains a draft of an RFC. It is not actionable yet and is published only to promote discussion.]

The existing pin management system is extremely ugly and hard to use and should go. (This is the long-term maintainability goal number 4 from #234). At some point I thought this would be possible to address with a complete rewrite of our argument parsing system but at this point this is clearly infeasible and a more iterative approach is needed.

The requirements for a pin management system are:

  • Is declarative (with an additional imperative validation layer; answering the question of "is this pin config valid?" but not "which pin config do these options result in?");
  • Is based on Python code (at least for the time being, so far as we continue to allow implementing an applet as a single Python file);
  • Is built to integrate with Amaranth components from the lib.wiring library;
  • Allows the use of complex I/O buffering schemes (with clocked buffers, including tristate clocked buffers) while not requiring undue boilerplate for simple ones ("just give me this pin as an input/output/tristate");
  • Namespaced, allowing multiple applets to share pins without fear of name conflicts (for cases such as multiple simultaneous applets, or a single applet instantiating two SPI interfaces in parallel);
  • Composable and/or extensible, allowing an applet to instantiate another applet's subtarget with additional sideband pins (by far most common case of this being "SPI plus a bunch of other signals"), with minimal or no boilerplate requierd to hook up these sideband pins to the subtarget;
  • Introspectable, allowing to render the pin configuration as JSON or human readable text;
  • (Covered by the above goals, but an explicit goal in itself:) Possible to eventually use from a GUI configuration tool;
  • For the time being still relying on our existing argparse-based infrastructure.

[To be continued in the future.]

@whitequark whitequark changed the title = [RFC draft] New pin management system Oct 22, 2023
@whitequark whitequark added gateware Component: gateware applet Component: applet labels Oct 22, 2023
@whitequark whitequark self-assigned this Oct 22, 2023
@GlasgowEmbedded GlasgowEmbedded locked as too heated and limited conversation to collaborators Oct 22, 2023
@whitequark
Copy link
Member Author

whitequark commented Oct 22, 2023

(The issue is locked to allow edits by @GlasgowEmbedded/maintainers only, for the time being. It will be unlocked once the draft is finished. Feel free to discuss it on chat!)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
applet Component: applet gateware Component: gateware
Projects
Status: In Progress
Development

No branches or pull requests

1 participant