virtual module#

Virtual Connections#

User-declared assertions that two endpoints are electrically connected, without JITX routing the connection itself.

Warning

The API in this module is still experimental and may change significantly without notice.

class VirtualConnection(source, destination, *, source_layer, destination_layer, pin_model=None)[source]#

Bases: Structural

User-declared assertion that two endpoints are electrically connected. JITX does not route the connection; ratsnest visualization and unrouted-warning emission are suppressed for the affected endpoints.

Use cases include OverlappableCopper bridges, connections made manually post-fabrication (e.g., a soldered wire), and modeling electrically real structures invisible to the router.

Each endpoint must be a single electrical target: a single-pin Port, a Pad, or a Via. Bundle ports — including a combined differential pair — are rejected; name a single leg (pair.p / pair.n) instead.

Warning

Declaring an VirtualConnection does not automatically bridge nets This allows VirtualConnections to be used for pin-assigned connections An external connection that isn’t allowed will be dropped

Warning

Declaring multiple external connections between the same endpoint pair is not supported. If there are multiple pin models which one is chosen may be arbitrary.

Note

VirtualConnection can be used to override default models for other connections. e.g. If two features overlap and have an VirtualConnection defined, the VirtualConnection’s pin model will be used instead of the generated model for touching features. This can be used to override route models in cases where VirtualConnection and route are allowed at the same time. Though routes will need to be forced since autorouter will consider the endpoints already connected.

Parameters:
source: ConnectionEndpoint | Port | Pad | Via#

One endpoint of the external connection. Must be a single-pin Port, Pad, or Via.

destination: ConnectionEndpoint | Port | Pad | Via#

The other endpoint of the external connection. Same type constraints as source.

source_layer: int#

Copper layer at which the connection attaches to source. 0 is the top layer; negative indices count from the bottom (-1 is the bottom layer), like Python sequence indexing. The two endpoints may be on different layers.

destination_layer: int#

Copper layer at which the connection attaches to destination. Same conventions as source_layer.

pin_model: PinModel | None#

Optional electrical characterization of the connection.

If omitted, the endpoints still count as connected (ratsnest and unrouted warnings are suppressed), but the connection cannot satisfy a constrained topology: length-matching, skew, or insertion-loss constraints routed through a model-less external connection surface may be reported as a missing-route error. If this connection sits inside a constrained topology, provide a pin model.

Only the base PinModel delay/loss values are consumed; the port bindings of BridgingPinModel / TerminatingPinModel are ignored here, as the connection’s own endpoints determine what the model bridges.