Open
Description
[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.]
Metadata
Metadata
Assignees
Type
Projects
Status
In Progress