Hyper Edge Support

[nturley]

For digital circuits, all nets are guaranteed to have exactly one output port (the driver), and zero or more input ports (the riders). netlistsvg had a requirement that one or more riders were required on every net until #4 was fixed.

There are some diagrams that those requirements don't make sense. Ideally block diagrams should be able to connect any collection of ports, regardless of their stated direction. Edges with multiple sources and targets are considered hyper edges.

Klayjs couldn't even properly represent hype redges in the kgraph json. Elkjs can represent hyper edges in kgraph, but layered layout doesn't support it, it supports multi edges, which is where multiple edges can use the same port as a source or a target. Using multiple edges with orthogonal routing forces edges to be on top of each other so they usually look like hyper edges. They also emit joint points where the edges join or split which we draw black circles at. I've seen some ugly cases where the same edges will split and merge together again, which looks bad but isn't incorrect, just ugly.

UPDATE: The splitting and merging hyper edges issue is a known issue: eclipse/elk#234

Hyper Edge support from netlistsvg would look like the following

• Multiple ports can use the same net
  • addConstants, addSplitsJoins, and createWires need to be refactored or bypassed for this to work properly
• If there are no drivers or riders for a net, a dummy node should be created
  • dummy nodes would be invisible 0x0 nodes with one port

[nturley]

The trick with the dummy node is to have two ports, one going EAST and one going WEST. Connect one of the output ports to the east side, and all of the other output ports to the west side. The edges all should target the dummy node.

It also might make sense to also make a dummy node for the case where there are multiple sources and multiple targets.

[nturley]

I'm getting close.

This particular implementation works great for when all input ports are on the left and all output ports are on the right.

The dummy port sides need to be opposite to the port direction for one of the ports, and the same direction as the rest of the ports. By port direction, I don't mean whether it's an input or output, I mean like the actual cardinal direction of the port. So we need to be able to tell the difference between a NORTH output port and a WEST output port.

This kinda work really belongs in ELK. They have better access to the cardinal direction of the ports and dummy nodes, and the graph direction. So all of this is a hacky workaround of a limitation of ELK.