You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Instead of a separate DigitalSingleSource, DigitalSource could model high_drive and low_drive, allowing for up to two DigitalSources. This would allow a common interface for devices that can be push-pull or open-drain, eg comparators. Could also simplify the DigitalLink definition slightly with less ports and constraints.
Modeling is that a DigitalSource is always driven (high, low, or both - as defined on the port) and must not conflict with another DigitalSource (at most one high DigitalSource and at most one low DigitalSource per Link), while DigitalBidir is optionally driven and may conflict with another Bidir or Source. Sources can also model pullup/down (?), which will not conflict with another Source. Sources may not read the line and do not model input thresholds.
Downside is that designs become less abstract, since where the IO is open-drain (depending on refinement part) it will need external resistors. But fundamentally you'd need that anyways, the alternative is perhaps the less clean e.g. ComparatorOpenDrain and ComparatorPushPull, or some weirdness of the above with mixins.
This could be implemented as DigitalSource.open_drain(...) and/or DigitalSource.open_drain_from_supply(...). The vanilla DigitalSource.from_supply(...) generates a push-pull IO.
Downside is that for single-sources, it would also need to model limits, so all DigitalSource may need to model limits (even if they're effectively nop/inf for push-pull devices)
The text was updated successfully, but these errors were encountered:
Instead of a separate DigitalSingleSource, DigitalSource could model high_drive and low_drive, allowing for up to two DigitalSources. This would allow a common interface for devices that can be push-pull or open-drain, eg comparators. Could also simplify the DigitalLink definition slightly with less ports and constraints.
Modeling is that a DigitalSource is always driven (high, low, or both - as defined on the port) and must not conflict with another DigitalSource (at most one high DigitalSource and at most one low DigitalSource per Link), while DigitalBidir is optionally driven and may conflict with another Bidir or Source. Sources can also model pullup/down (?), which will not conflict with another Source. Sources may not read the line and do not model input thresholds.
Downside is that designs become less abstract, since where the IO is open-drain (depending on refinement part) it will need external resistors. But fundamentally you'd need that anyways, the alternative is perhaps the less clean e.g. ComparatorOpenDrain and ComparatorPushPull, or some weirdness of the above with mixins.
This could be implemented as DigitalSource.open_drain(...) and/or DigitalSource.open_drain_from_supply(...). The vanilla DigitalSource.from_supply(...) generates a push-pull IO.
Downside is that for single-sources, it would also need to model limits, so all DigitalSource may need to model limits (even if they're effectively nop/inf for push-pull devices)
The text was updated successfully, but these errors were encountered: