Well, the title says it all.
Everything was working fine when I used several hierarchical sheets with global labels. I simply didn’t know how to use hierarchical labels or busses between sheets. I do know that now so I was quite pleased with the design of my little computer. So I saved everything, generated the net list and clicked on the PCBnew toolbar icon. When I looked at the pads for the ICs the VCC net was gone and replaced with GND! I don’t know what I did wrong nor how to rectify it. I really don’t want to start from scratch again.
The project is here PLUTO and the KiCad project is under HW/SCB.
In sheet /CPU, ROM and RAM (cpu_rom_ram.sch) you connected vcc and gnd via the RAM label.
(Black text is a local label. Two local labels are always connected!)
Warning: I did not check any further. (There might be other problems.)
That was it. After I removed the cap, the label and the connecting wires PCBnew sees the VCC label on the correct pads. The reason I had that cap was to decouple VCC and GND.
Thank you very much!
The symbols by @Johan_Groth have invisible power input pins.
In general this is a bad idea because invisible power inputs are global labels. (In fact this is how the power symbols like gnd and vcc work. Yes we know this is a dirty hack.)
I personally would not use hidden power pins. They cause more problems than they solve. (In my mind it is always a good idea to state everything explicitly.)
One problem with hidden power pins is that you will never be able to use multiple power supplies if you use hidden power pins.
OK. I wondered about that but wasn’t sure. Given the RAM marking I guessed the purpose was to decouple at the chip level. If that’s the case then the pins would need to be ‘unhidden’ and drop the capacitor across them. My guess was either the chip wasn’t being powered or it wasn’t being decoupled the way that was expected. Some forums have decouple police to enforce caps on all chips.
Nope the only problem is the ram label.
Or better: The ram label on both the gnd and vcc side. (the ram labels are like invisible wires. Every label with the same identifier is connected. The resulting net gets the name of the label with the highest priority. If two labels with the same priority are connected, the net name can be any of the two.)
If @Johan_Groth would have used for example the labels GND_RAM and VCC_RAM everything would be ok.(In that case the resulting nets would still be called gnd and vcc because global labels have a higher priority than local labels.)
Where you place your cap in the schematic does not make any difference on the net list. (It’s just helpful to the human who reads the schematic.)
I guess I had had trouble reconciling the same person that hid pins (presumably for neatness?) then added that capacitor circuit. But at least I learned something. I’ve been blindly using globals because I’m used to seeing the little ‘tags’ they are enclosed in. Not that it would make a difference in anything I’ve done so far.
The power pins were hidden by the library creator. A decision that seemed sensible back in the boards full of TTL days, but not now when you have several power supplies on a single SOC chip
A reason to hide power pins could be the posibility to focus the schematic more to a representation of the function. It helps to simplify a schematic by the costs of the posibility to forget the supply.
Often the power pins of operational amplifiers and comparators are also hidden, allowing a higher density for connections and other components near the devices.
The use of the labels in the schematics of Johan_Groth above is quite interresting. It could be used to connect the hidden power pins if they are named differently from GND or VCC, like RAM_GND and RAM_VCC or in my case OP_VSS and OP_VDD to the correct corresponding supply level needed. It covers the case of the presentation for the connection to the right supply level and the need to place the associated capacitor near it. It removes the necessity to add a separate illustration of the connection of the supply signals to the hidden pins. If also a graphical frame is drawn arround the signal names, it will clarify the intension of positioning it and brings the whole schematic to a simpler but more complex level.
We often create multi unit symbols with one special power unit, just to avoid power wire clutter and to clearly show association of decoupling capacitors. The problem is that the current schematic and symbol library software makes symbol creation clumsy and doesn’t handle unit swapping well when you do this
This has been an issue I’ve run up against with decoupling caps and I wondered if there is a good solution. It is kind of related to the original post but might be suitable for a new one. If you make the typical block of decoupling caps going between VCC and VSS/GND for an MCU, you wind up with a bunch of caps related to power and ground, but not the pins on the MCU they physically should be nearby. I’ve tried to do things to make the nets unique, but haven’t found a good solution. Anyone else have this issue or a solution?
What I was asking for is if there is a way anyone has come up with to programmatically enforce relationships between components when following the tribal customs that leave the monkey in the middle to enforce. We have great DRC for enforcing other tribal knowledge, I don’t see why this should be an exception.
From a practical standpoint, yes, I agree, if I’m doing the layout, I manually enforce this. But, if I have someone else doing the work, I end up having to double check this as well. On more complex boards, it is tedious and not necessary if we have a straightforward way to have the design intent captured in the schematic and enforced programmatically in the layout tools.
If you have people doing layout who don’t understand the need and use of decoupling caps, your problem is not with the tools, I am certain of that. This is not “tribal custom”, but basic electronics knowledge.
If you really need to convey layout information in the schematic, then you could add text notes. But I think you might also need to tell the soldering “monkeys” which end of the soldering to hold!!
We’ve pulled this thread quite a bit off course already, so why not wander into unknown territory?
The decoupling caps are sort of like the note on a mechanical fabrication drawing that says, “Break all corners and deburr all edges.”. We all learned that in Junior High School shop class, right? But we still put the note on drawings, and we still lacerate our fingers while handling newly-manufactured parts.
KiCAD has not yet matured to where it has an easy, integrated feature for handling drawing notes, or tabular information in general. (A few days ago we were discussing how to handle assembly variants where some parts are fitted to some manufactured assemblies but not to others. A table is a natural, efficient, way to convey this information to other humans.) I know this is a “Wish List” item, and I can live without it while other features are improved.
A related wish is a way to communicate information from one KiCAD application (e.g., EESchema or Symbol Editor) to another (PCBNew). In many (perhaps most?) commercial organizations of more than a dozen technical people, the circuit design (schematic) and PCB layout are done by different people. In my experience, a significant amount of details are passed by informal, face-to-face conversations. This is often significant stuff, but not things you want to clutter a drawing with formal notes. Even when only one person is involved, the notepad that lives beside my keyboard typically contains several “Notes to Myself” about how something should, or shouldn’t, be done. It could be useful to have a mechanism, perhaps at the top Project level, where the various participants in a design effort can leave messages. Such as, “C2, C7 and C9 to be located near U1, U4 and U7.”.
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.
