Skip to content

[RFC draft] New pin management system #460

Open
@whitequark

Description

@whitequark

[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

Labels

appletComponent: appletgatewareComponent: gateware

Type

No type

Projects

Status

In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions