Skip to content

Compositional Passive #114

@ducky64

Description

@ducky64

Currently, electronics ports like VoltageSource and DigitalBidir inherit CircuitPort, that is, they are-a CircuitPort. A compositional approach would instead have these be a bundle, containing a CircuitPort that handles the connectivity.

Note, this proposal would not affect existing Bundle types, eg UART would still be two Digital lines, but each of those would contain a CircuitPort inside

Pros:

  • Passive could be replaced with CircuitPort, removing that bit of duplication
  • Somewhat cleaner separation of modeled and unmodeled (CircuitPort ports) elements, and a cleaner boundary between them by exporting the internal CircuitPort into the inner port of the eg VoltageSource bundle
  • Netlister wouldn't need to look for subclasses, it can directly match on CircuitPort
  • .adapt_to(...) from Passive can be replaced with direct Port definitions, they just have their Passive exported internally
  • This means that using a package generator (eg, SOIC as a Block, much like the connector generators) is a bit more feasible, since it doesn't need adapt_to spam. Footprints can potentially be turned into a Block instead of a custom construct.

Cons:

  • Direct port definitions are only useful with the wrapper pattern (block wrappers and adds electronics modeling data on top of a underlying Passive port typed device, including generic package and connector generators). However, this is not useful for peer-level adapters (eg, passive-typed connector connecting to an opamp, where an ad-hoc adapt_to or dedicated wrapper block is still needed).
    • The dedicated wrapper block is cleaner, including for a consistent level of abstraction at any block level. However, more verbose.
    • Possible rule (to avoid "multiple ways to do one thing"): use .adapt_to for ad-hoc adapters only, as a shortcut for dedicated wrapper blocks. Use the .net direct connection for building wrapper blocks.
  • Another layer of indirection? But is a bit more explicit
  • A lot of refactoring.
  • Still needs conversions when interfacing modeled and unmodeled elements within a block (as opposed to on a boundary) - but shouldn't be any worse than it is right n#442

Related: #442, implicit init_from syntax using port redeclaration

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions