Unintended lines in MOSFET bulk-source connection.

[ArthurAdmiraal]

The line interpretation system automatically connects loops even when behind components. For instance, the MOSFET bulk and source get connected when drawn out.

Replication

Draw the following circuit.

Result

There is a line between the MOSFET bulk and source, because the wire automatically connects to itself.

On tighter loops, this causes a whole lot more unintended lines:

Workaround

The problem is only cosmetic. The problem can be minimised by drawing sufficiently large loops or drawing direct connections:

[pepijndevos]

So would you suggest that wires under components should never connect to adjacent tiles?

That would mean you can never draw a mosfet the way you did in the workaround, which is IMO the most common case and the neatest way to draw it.

Your tight-loop case is very ambiguous, the two source connections are topologically equivalent. It becomes a bit neater if you remove the bottom right tile. I can't think of any reasonable rule to resolve that case such that only the tall loop is connected.

What could be done is to have a "no under-component connections" rule plus a 3-terminal mosfet variant to make the common case neat.

I'm thinking, the mosfet has 4 ports, but if the 4th port is unconnected, it becomes a 3-port with the bulk implicitly connected to the source.

A related problem is the UX of connecting a two-port. In most software you can draw "through" a component to connect its ends, instead of hooking up each end individually. The "no under-component connections" would take care of this.

[ArthurAdmiraal]

I don't have a solid suggestion thought out. I had an idea that the lines should perhaps only connect when the user has explicitly dragged to connect them, but your proposal sounds much simpler and in line with the Mosaic philosophy.

I'm not sure the most common case for MOSFETs is like what I did in the workaround: in both logic gates (NAND for example) and analog circuits (long-tail diff pair), the bulk is often connected to the ground/supply rather than the source. It would therefore probably be nicer if the implicit connection of the bulk were to the appropriate supply net. Related UX suggestion: hide the bulk terminal by default, revealing it semi-transparently (on mouse-over?) in line drawing mode. Reveal when fully connected.

Could you elaborate on the ambiguity of the tight-loop case? Not sure what you mean there.

[pepijndevos]

Well so the wire under the source port has three neighbors. One to the top which is under the device, so you could make a rule that there are no under-device connections. The other two are to the right and to the bottom, not covered by the mosfet. Which of these is the desired connection? There is no topological difference that says the connection to the right is wrong, except that you did not draw it.

Yea I suppose the common case is that bulk is ground. I was thinking of some circuits where source=gnd but you're right that in a diff pair and such, the source is not ground. So yea implicit connection to ground makes sense. Except for PMOS it'd be VDD, do you just hardcode that or... make it a parameter... or...

In fact, it might even make sense to make any open terminal implicitly ground. Easy to implement, but might cause nasty surprises if there is no indication. A floating resistor is kinda UB.

Yea your UX suggestion was kinda what I was getting at with having an automatic 3 terminal variant, that becomes a 4 terminal when you connect the drain.

One thing I have to do better for this kind of stuff is fast lookup between devices and wires. Currently in the few places I need to check which port is connected to which wire, I just scan all the wires. But if components render differently depending on their connection you end up having to check this every time you render it, which could be a lot.

I could inverse the relation from "wire has a set of locations" to "map of locations to wire" but that doesn't play well with the CouchDB synch architecture I think. So maybe I should maintain that as a local cache.

[pepijndevos]

This is no longer an issue with the new wire system