| Thread Previous • Date Previous • Date Next • Thread Next |
Hi, On 15.06.2016 08:53, jp charras wrote: > I do not understand why net ties are related to schematic cleanup. > They are 2 separate features. For the "net ties as special junctions" implementation, the cleanup code needs to be adjusted -- that's where they come together. > Although no decision was taken, inside a schematic, the best way for a net tie is a virtual > component with 2 (or more) pins connected to each net and a specific footprint put on the board (to > control the location of nets connection, the connected layers ... I'm not totally opposed to creating magic components, but I think completely special-casing net ties through the entire stack is easier to use, easier to implement and easier to maintain over the long term. If it were a special component, we'd have to extend the component edit dialog, which already has a lot of properties that do not really apply to net ties. There are no sub-units, there is no De-Morgan style, no value or reference. So the UI would basically have two modes for the dialog, one where a check mark is set and all other widgets are disabled, and one that behaved as before. The library would allow us to support several graphic styles, which is kind of a bonus, but the disadvantage is that there would have to be components for different numbers of connected nets and graphical layouts, and placing a tie would require the full component selection process and creation of new components if the particular variant the user needs doesn't exist yet (which is already annoying with power symbols). For three and more connections, the most common symbol in datasheets seems to be a thicker junction with an arrow pointing to it, although that is by no means universal. Most people just draw normal junctions and assume the layouter knows what they mean, it seems. I personally like the junction-like appearance, because it takes up relatively little space (see attached image). An arrow pointing towards it would probably resolve the ambiguity. For ERC, the nets are connected, so we'd have to implement support for internally connected pins (which would be useful either way, so that's not a huge disadvantage). The main problem I see here is that we'd have to touch precisely the most complex bits of ERC here -- the pin-vs-pin handling. Netlist generation would be easier, but so far I've needed only ten additional lines and a bit of shuffling around other code. On the pcbnew side, I think completely special-casing net ties would make sense, too, because ties can be incident with pads (SMD or THT) or vias, or placed on their own. Modelling them as pads would require special rules for pad-pad and pad-via interaction, so I'd rather see them modifying the behaviour of items they are attached to instead of creating copper on their own (basically, the modified object becomes part of multiple nets). This should also make zone generation a bit easier. My current use case is a current sensing shunt, which should connect two zones, and have a single trace leave each pad separately towards the instrumentation amplifier used for measurement. I think using the net tie to modify the existing pad is the easiest implementation here, as it doesn't introduce conflict resolution requirements if the pads are different sizes. > This is also the way used in other ECAD tools. Yes, but that doesn't work universally. The approach in Alti*m is that they use a footprint to introduce copper that is not checked in DRC. However, their approach still requires that the pads in the footprint are wide enough apart to not cause a DRC conflict when the traces are connected, and placing pads on top of each other is also a DRC violation unless special rules are in effect. Their white paper simply doesn't address the use cases "current sensing shunt" and "decoupling capacitor", which both are better served with a point-like item that creates DRC exemptions in the components it touches than a clever way to trick DRC into thinking that two points aren't connected. One thing they cannot represent for example are three nets meeting in a blind via, but this can be useful e.g. for length-matched clock lines. I'm not sure how to proceed here since I'm not entirely familiar with the codebase yet, so my assessment of the effort required may be way off. I'd in any case like to cover at least the use cases - connecting AGND and DGND in a single place - decoupling capacitors (ratsnest connecting power pins and capacitors) - current shunts - lenght matched clocks and ideally allow net ties to be placed so that they do not take up extra board space. Simon
Attachment:
net_tie_sch.png
Description: PNG image
Attachment:
signature.asc
Description: OpenPGP digital signature
| Thread Previous • Date Previous • Date Next • Thread Next |
