4_Net_Highlighting
Net highlighting in bleepsix/MeowCAD is done differently than in most EDAs and it's worth giving a brief overview of how it works here.
It should be mentioned that any 'classic' workflow that always starts with the schematic and uses the board layout to match remains unchanged. These features are purely in addition to and don't restrict the classical workflow.
Most EDAs have a 'waterfall' approach whereby the schematic is 'truth' and the PCB layout is meant to reflect that truth. In terms of part placement, this means parts are placed in the schematic, are associated to a footprint and then placed in the PCB layout.
In terms of networks KiCAD will not let you place tracks connected to pads that aren't connected in the schematic.
As an experiment, bleepsix/MeowCAD is trying a different philosophy and trying to make the workflow more symmetric. This means footprints can be placed in the board layout and then have an 'unknown' part show up in the schematic. Conversely, parts can be placed in the schematic and show up as 'unknown' parts in the board layout. Both can be associated at any time with a component/footprint by dragging and dropping the appropriate element over the unkonwn part.
Track placement is allowed even if the schematic nets that the pads/tracks map to do not connect in the schematic. The hope is that this will encourage an iterative workflow whereby tweaking locations in the board layout can be easily done and then can be fixed up by going back to the schematic, instead of forcing work to happen in the schematic and flow into the board.
'Airwires' show up in the board layout as implied by the schematic.
Confusion can happen when net highlighting occurs, both in the board layout and cross tab network highlighting. For example, two pads could be connected in the board but not be connected in the schematic.
This is still a work in progress, but an initial board net highlighting has been implmented and works as follows:
- If the mouse hovers over a pad, use the pad as the basis for determining the implied schematic nets.
- If the mouse hovers over a trace with many pads connected, sort them and use the first to find the implied schematic nets.
All pads that are mismatched show up with an unhighlghted region in the center of the pads.
Here is a small example:
Cross tab schematic highlighting occur but without any differentiator as to which highlighted pins are mismatched. Once implemented, this should be a similar policy for the schematic nets.
In the end, this highlighting might be too confusing. The main goal is to give an indication of which pads (or pins) are connected via a network. Mismatches need to be differentiated lest they be confused as being part of networks they aren't. The main issue with this approach is to understand which pads should be highlighted as normal and which should be differentiated.
Picking which is the 'correct' default net and which is the 'mismatch' is impossible without some deeper insight into the design (and even then, it might not be clear). Instead, a reasonable policy has been implemented: take the pad as the default correct and work out the implication from there. Otherwise take the first pad in some normalized list and use that as the 'correct' default.
If this still proves too confusing, this logic can be ripped out in favor of how every other EDA does it.