All VCC becomes GND when going from eeschema to pcbnew


#21

One can easily add a field to a decoupling cap and call it something like “Association” and add the ref id of the IC the cap is associated with. It could also be displayed and appear directly below the capacitors ref id, possibly in brackets.


#22

I do not know of any way to create a rule that says “capacitor C123 is for decoupling U25 pin 3.” Altium doesn’t have any way of doing this, either. Maybe @1.21Gigawatts’ suggestion is reasonable?


#23

The issue wasn’t with the end layout, the person doing the layout was very experienced, and put decoupling caps in meaningful places. The issue was that we had two MCUs on the board, and he swapped a couple of the caps when placing them. Of course, as suggested, if he had taken the time to follow the schematic explicitly, then it wouldn’t have been an issue. I tried using separate connections and other things, but in the way that decoupling caps work, it ended up coming through as VCC and GND at the end of the day in the layout. Which is how it relates to this thread (at least in my head).

This only became an issue when we removed one of the caps because it wasn’t really needed and it ended up disappearing from the wrong MCU.


#24

I admit it is easy to lose track of which decoupling cap needs to go where.

Well I suppose a workaround in current release is to create a net for each MCU VCC, and use a net tie to connect it to main VCC. Then when you are placing a cap, the ratsnest at least shows which MCU VCC it associated with. That could in principle be done for each pin, but would get a bit tedious.

In principle, you could add a field which means “must be close to” and specify a footprint and pin. Then KiCad could display a line showing the distance (similar to rats nest), and the DRC could even check the distance.

I think this is a very specific use case, which only applies to decoupling caps. KiCad devs tend to prefer enhancements that are generally useful, so I’m not sure you would get much interest with this. Actually, this might be a good use case for a plugin script…


#25

Excellent idea, wish I thought of something like that! :wink:

Any idea that requires changes to KiCad is pretty much a non-starter. Besides layout directives are intended for the person doing the layout, not DRC. But if we’re going to change KiCad then why not just implement layout directives properly. The ability to specify differential pairs without specific naming requirements, specifying a group of signals that should be length matched, specifying impedances, etc.

Not at all, switching power supplies often have parts that need to be close to an IC’s pin to reduce parasitics, Same goes for some precision analog circuits.


#26

So if KiCAD is going to display distances between two components (or two pads), why can’t DRC compare the distance to some pre-set requirement? Actually, I’d rather see efforts directed at having DRC check silkscreen parameters before it checks component separation.

Which emphasizes that the layout guy needs to have his feces amalgamated, and the team he works in needs to communicate within itself, to produce quality products.

Dale


#27

If layout directives were implemented properly then DRC probably could check for violations. Its the “preset requirement” that might be problematic for some things. Exactly how close does a component need to be to the pin before DRC stops complaining? The general answer would be as close as possible although it might also depend on the type of circuit.

I would have no problem with having DRC flag violations of layout directives where possible but from what I understand any such change to KiCad would be years away. A more immediate solution might be to convey such information within the schematic, as suggested above, for the layout engineer.

Adding a field to a component that could be displayed on the schematic was just a suggestion, it may not suit everyone.