From here, the documentation says:
“Annotation of symbols with multiple units will assign a unique suffix to minimize the number of these symbols.”
However, this is not what seems to happen. Placing 5 nand gates similar to this example and annotating them even when specifying to reset all existing annotations generates 5 IC’s all using part A instead of using parts A-D for one IC and part A of a second one.
Is the documentation incorrect, or am I simply doing something wrong?
This is only true for symbols that are marked as “all units are equal” (symbols that don’t have “all units are different” set)
However such symbols made that way rely on the power supply being made via invisible power input pins. This has way more downsides than i care to elaborate and is the reason why we do not allow symbols to be made that way for the official libary (some symbols are still made that way but well we don’t have the manpower to fix everything)
This means if your symbol has a separate unit for the power pins then the anotation algorithm can not automatically assign a unit to it. You as the designer must therefore select which placed unit represent which unit. See Tutorial: Introduction to PCB design with KiCad version 5.1 (Getting Started) section “multi unit symbols”
So the documentation is incorrect for official components, and the example given is obsolete?
Yes and no. Maybe a better description of the state of the documentation would be incomplete because it doesn’t include @Rene_Poschl’s caveat.
But for a multi-unit that has multiple identical parts without any shared pins (power pins are an example of shared pins) like an isolated resistor network, then the documentation is correct. Granted, if you are using multiple resistor networks (or multiples of similar multi unit parts) one should really make sure that after annotation they are grouped into individual packages sanely.
So the documentation is correct in some circumstances, but the specific example it happened to give (a 74LS00, which has invisible shared pins) is an incorrect example?
I am wondering, is there any way for KiCAD to automatically assign the part number for parts with shared pins, or must each part always be manually specified? I would think that being restricted to the latter is problematic if one does not want to necessarily think about how many parts there are per package during schematic design and symbol placement, whereas having to go back and manually edit the part numbers for each symbol that belongs to a multipart component requires already knowing, or having a general idea at least, how you are going to be laying out the components on the PCB which one might not necessarily have at the stage where they are still working with the schematic.
It is certainly a depreciated example, but more to how the standard library is structured instead of how the code is written. It used to be true, but the mechanism used to allow it to be true (the hidden pins automatically connected to the net that matches the pin name) cause more problems than it solved. For example, if you had two CMOS hex buffer chips (or quad NAND, or any other other discrete logic chip) and wanted to power one from the 5V rail and the other from the 3.3V rail, there would be no way to connect the hidden pin named “VDD” on one chip to the 5V rail and the other chip to the 3.3V rail.
Currently they all must be manually specified. The schematic (and symbol library) file structures (and presumably internal data models) are undergoing significant changes for v6. I also know that the devs are aware of this issue for pin and unit swapping. I haven’t referenced the milestone list recently enough to know if the pin/unit swapping is targeted for v6 or pushed off to v7 at the moment. But tl;dr, the issue is known and will be resolved somehow at sometime in the future.
I’m glad to hear that it’s a known issue that the developers would like to address in an upcoming version.
I would have imagined that could at least be partially mitigated by having two variations of the multipart CMOS chip, one which connects to Vdd (3.3v), and the other to Vcc (5v). This would also mean that you would have to double the number of symbols that belonged to packages which could be safely connected to either and you just select the version of the package that you want to use when you are placing the symbol, but at least it would be possible.
Although I’m unsure how practical or versatile that would be in practice, and it’s very possible that the designers have an even better idea for the next version.
Not a problem - do your library element with all units the same (use DeMorgan for power pins).
I think it is impossible to not think about it. I use not a lot simple gates so I prefer to use 1G or 2G (for example LVC2G14).
It is better to do it knowing the layout idea (it is you who knows) then to do it don’t knowing the layout idea (it is automatic annotation who don’t knows).
Don’t doing unit assignment don’t disturb your working with schematic. You can finalize unit assignment long after schematic is finished.
I am not sure this works to be honest. At least not in all instances so be very careful when using this undocumented behaviour.
I am using it. To test at that moment (V 5.1.6) I placed (at my current working schematic) my LVC2G14 twice. Both were U?A. I selected in one DeMorgan. Then I annotated. I got U5A and U5B.
I didn’t supposed it will be not working.
Better way than doing separate symbols to be used with 5V, 3V3, 3V, 2V7,… 1V8 is to have DeMorgan and connect to any voltage you need.
The current (new) idea in library is to have the separate symbol just for connecting the power for IC. That symbol is of course different than gate symbol so can’t be assigned just as one of gates. The annotation is not prepared for such idea so can’t do it but I suppose shortly (in KiCad time scale) the symbol file format will be adopted to tell annotation which units can be replaced between them and which not.
I know that mixing de morgan and non de morgan works in the same schematic. I would however be supriesed if it is possible to have a different number of pins on the two versions. (which would be necessary for what you suggest above)
My standard symbol has 2 pins and DeMorgan 4 pins (for supply). It works. I have designed PCB with it using 5.1.5. I don’t think it not works in 5.1.6. Will check probably tomorrow as I have the schematic (this time using LVC2G17) ready.
I see at least two features which might not fully work with such a hack. One is the pin count filter for assigning footprints and the other will be import to v6 as you use something unexpected and might therefore do something that is not covered by the converter. (Devs do not need to continue to support something undocumented)
As far as I’ve been able to tell, switching a gate to DeMorgan changes its appeance to use negated inputs. This isn’t always desirable.
My opening point remains, I would have liked to have some way to add quickly add a bunch of standard components to a circuit, some of which may be multi-part, and have it optimize IC usage for me without my having to select each part manually, and using the minimum number of chips necessary.
This is what the original idea of this feature was. And to be honest it is the only documented use of it so any other use is something that is allowed to be broken in the future (i personally would argue even within a minor release but i think the devs are not that mean).
As with all things there are tradeoffs. You can make your multi unit symbols in a way that supports this but at the tradeoff of either using something undocumented or relying on shared power pins which also have their issues.
I generally hope for v6 to have a way to define a subset of units to be interchangeable which would improve the behaviour here but right now we must live with the limitations of the current file format.
Didn’t know it is undocumented. I use such symbols since over 20 years.
In Pin properties you have flags: ‘Common to all units in symbol’ and ‘Common to all body styles (DeMorgan)’. It seems being impossible those flags were used without being documented.
If you seeing both symbols and pin flags are able to imagine how many pins the device has then the computer also can count it.
If it is unexpected than what for are these flags?
Where I can check what is documented and what isn’t?
You are speaking about user documentation or some other library file format documentation?
By definition, everything that is specified is documented and everything that is not specified is undocumented. The notion having documentation for what is not documented is a logical impossibility.
I think you’ve broken my brain. 
All that i wrote above is in part an assumption that was formed when we discussed how to implement multi unit symbols in a more robust way. The thing is that the current file format is not well specified so a lot of its features are left for interpretation.
The feature you use is designed to allow for creating the same symbol but transformed to the equivalent presentation as per the rules of de-morgan. To be honest i kind of assume that the existence of this feature will be a pain in the … for transferring to the new file format. I assume that it will be continued to be supported but it will surely create some challenges. I further assume that taking any conceivable use of this ill defined feature into account would make it even harder to handle the transfer to the new file format. So be prepared that your stuff might break (start to test the file format transition early to give the devs time to find solutions to your particular use of the old file format).
The reason why i am advocating this hard against such a use is that while it is ok for one self to use features in a not really intented way i would rather not push others towords it. After all i know the risks and i know that i might need to redo stuff once v6 comes. But i would never want others to have extra work just because they followed my advice. Which is why i am very conservative when deciding on a way forward for the official lib and when giving advice here on the forum. This is in part influenced by the many discussions i had when i tried to get edge cuts allowed in footprints. (Another thing that works with current kicad but is not officially supported for possibly good reasons -> allowing it will make some future development harder)