Seperate Supply Voltages


#21

It definitely does but needs to be done right. See how it is done in EAGLE for a good example. It makes the schematic much tidier and allows e. g. creating separated decoupling sheets with ease.


#22

Something as described in this tutorial?
In short: multi unit symbol with an extra unit for power pins. (Has drawbacks in the current library file format that will be fixed in future versions. We hoped it will be included in v5 but this seems very unlikely at the moment. Most likely in v6 or in the worst case even later.)
We library maintainers see this as the best option with the current symbol library format. In fact, new symbols are not accepted with hidden power pins. (Sadly nobody volunteered to fix the current 74xx lib. Are you prepared to do it?)


#23

Could it be scripted? A chance to practice my Python-fu…


#24

We need a new symbol name or risk havoc with existing designs


#25

old designs could use the rescue feature. (Or do i understand this feature incorrectly again?)

The library is also only rolled out with a new release (The next one would be 4.0.7). The current symbols live on in the commit tagged as 4.0.6.
This way one could download the old lib and use it to rescue old projects manually if the rescue feature does not work as intended.

If this rescue feature does not work as i think, we librarians might be screwed any ways. Especially after the recent major updates to the opto, regul and linear libs.

Of course. The lib file is text based, so one could write a parser for it and change the symbols in the desired manner this way.

I’m just not sure if it would be less work than doing it manually. Simply changing the visibility of the power pins does not correct these symbols.

  • The power pins need to be moved to a separate unit
  • The symbol needs to be given the property of “all units are not interchangable”
  • the unit count needs to be increased.
  • All graphical elements need to be copied to all units that are logical units. (the shared for all units property needs to be removed for them of course.)
  • This needs to be done for the normal and the de morgan representation. (or we romove the de morgan representation.)
  • The symbol body should be colored by the background color. (light yellow in kicad out of the box)
  • Maybe something else needs to be done to them such that they fulfill the current KLC. (I have very little experience as a maintainer. But i think if all the points listed above are done the lib will be a lot better already.)

#26

In short - yes. In a more elaborate way it is slightly more than only “extra unit for PWR pins”. It is also about making a subtle distinction between that “extra” unit and “regular” units. In EAGLE the supply units with their pins are hidden from schematics by default but automatically connected to their respective nets. Similar to what KiCAD does with power pins. Yet, unless I am mistaken now, the unused (not invoked in EAGLE terms) units are not automatically connected in KiCAD? Once this is solved I can imagine “fixing” the lib(s).


#27

Is this a new feature? I never knew this was possible in eagle. (I used version 6.5)

I’m personally not a fan of auto connecting anything. Everything should be explicitly shown in the schematic. (Everything else is too error prone.)
As stated above, currently we don’t have much options. What can be done with the new library format remains to be seen.


#28

[quote=“silverdr, post:26, topic:2208”]
In EAGLE the supply units with their pins are hidden from schematics by default but automatically connected to their respective nets. Similar to what KiCAD does with power pins.[/quote]

Is that true, for all components? I don’t think so, and regardless, it’s dangerous, as many here have noted.

If you have a two-unit component, and you place only one of the units on your schematic, the other unit is not connected to anything. (I’m of the opinion that a missing unit of a component should be flagged as a DRC error.)


#29

@jkriege2 had a suggestion which I think is better, rather than process the current library (I did that with the opto library to fix some graphics) which can get messy, and tends to be a one shot thing, write a script to generate symbols from a text file. This means the style can be altered in the script, and easily regenerate the components. Also, it should make adding new components easier, especially if data for these can be generated from somewhere.

I created a basic script, it generates components like this


from a text file like this

COMP 74xx574 IC
UNIT
2 D1 I L
3 D2 I L
4 D3 I L
5 D4 I L
6 D5 I L
7 D6 I L
8 D7 I L
9 D8 I L
SPC L
11 CLK CI L
1 ~OC I L
19 Q1 O R
18 Q2 O R
17 Q3 O R
16 Q4 O R
15 Q5 O R
14 Q6 O R
13 Q7 O R
12 Q8 O R
END
UNIT PWR
20 VCC P T
10 GND P B  
END

#30

No, it’s not a new feature. In fact I don’t remember it not being there.

To be frank, I never encountered any errors related to this feature. One needs to remember what kind of supplies are needed and used and if something’s forgotten or misconnected then ERC flags this out. It’s really useful and IMHO the way to do this kind of things. Littering the schematics with dozens of supply symbols and/or bypasses is definitely not a good idea. And currently KiCAD does this too. Although in a way that leaves open wishes.

[quote=“Rene_Poschl”]As stated above, currently we don’t have much options. What can be done with the new library format remains to be seen.
[/quote]
I find the “eagle way” very much the way it should IMHO work. Not that I am a great fan of EAGLE. Just seems to be noticeably better than what KiCAD offers now. And if the extra flag for units (“gates” in EAGLE speak) is implemented, then converting the lib(s) should be possible with a kind of script.


#31

What about adding a “_PWR” suffix or something like that?

One problem I have discovered, is that if I forget to place the power unit, there are no DRC errors, and nor does pcbnew flag any errors. We could really do with a “mandatory/auto place” flag which is what @silverdr may be referring to. I never used EAGLE long enough to figure out how it handles units.


#32

(Emphasis mine.)

I agree. In general it’s considered questionable practice to simply leave all unused pins completely disconnected. In many (perhaps the majority) of cases, the manufacturer cautions you to terminate unused input pins in some way. Placing only one section of a multi-unit part goes against that guideline.

If the suggestion by @Andy_P was implemented it would force you to place ALL sections of a multi-unit part, and either connect the pins or mark them with the “Unconnected” flag. If one of those sections happened to be the “power unit”, you’d be forced to deal with it - either make connections, or explicitly mark it as unconnected.

OK, I’ll concede that this “clutters” the schematic a bit. In practice there is almost always some white space along an edge of a schematic sheet where you can tuck a few “power units” along with their associated bypass capacitors, and maybe some of the ancillary power stuff (switches, fuses, pilot lamps, current sense resistors, divider networks to sense rail voltages, etc).

Dale


#33

This is precisely what brought me to this topic. I am currently forcing myself to migrate everything to KiCAD and this was one of the major things that hit me. Currently one can create a pretty complex schematic, manufacture the board, populate it etc. only to discover that [some] power lines are missing. A thing that should never happen when using ERC/DRC!

If there is e.g. a logic chip with interchangeable gates (“units”), one mustn’t be forced to use all the units. Unconnected/“missing” units should not be flagged as an error. It’s the unconnected supply “units” that should be flagged, even if neither “invoked” nor visible. That’s the difference I wrote about when writing about making a distinction between “regular” and “power” units. Power units should be connected automatically to their respective nets, similar to what KiCAD currently does with hidden pins but if their nets do not exist (i. e. there is nothing to connect them to) this should raise the error flag. Those units probably don’t have to be called “power” as in EAGLE nor “supply”. It could be called something like “required” for example.


#34

I agree that you shouldn’t be forced to use all of the units in a component. I’ve seen plenty of designs that use dual op-amps everywhere, and some of the chips used only one of the two units. And that was for layout reasons, mostly. “But you wasted an op-amp!” goes the cry, but it costs more money to have to buy both the single and the dual op-amp chip, and it costs more to have that extra slot in the pick-and-place machine.

My reasons for requiring that an unused gate get put on the schematic are two-fold. One is as @dchisholm notes, sometimes unused inputs need to be terminated or both things happen. The second is just so the human technician who’s looking at a board can go, “Oh, U26, only A is used, B is not.” It’s made explicit.

I find the arguments against “littering” a schematic with “dozens of supply symbols and/or bypasses” tiresome. We need to be explicit, so that there are as few mistakes made as a result of unstated assumptions as possible. (My earlier comment about “tribal knowledge” regarding bypass caps notwithstanding, of course.) I want my techs to know that +5VA and +5VD are separate nets. I want my technicians to know which bypass caps are associated with which chips. Schematics convey intent, and if that means text blocks, then add them. If that means circles and arrows, add them.

Remember that the engineering notebooks aren’t archived with a design, and sometimes the original engineer isn’t around to explain what was done – and why.


#35

I usually draw all of the spare units and power units on a special page. This makes it easier for someone else to figure out if there are spare gates etc for a modification.
Drawing the power units together makes it simple to figure out if there is enough decoupling


#36

+1 I was once told I over documented code. I rarely code. Go back after a year and tell me I over documented my code. What is obvious today is a head scratcher tomorrow.


#37

Unfortunately, KiCAD makes it difficult to simply add a page where you collect unused sections, place your general notes, summarize revision history, etc. (Especially that Note saying, "Last Ref Des used . . . . Unused Ref Des . . . . "!)

Dale


#38

So very much true!

Personally I usually place all the “units” on the dedicated portion of the schematics anyway. I consider this to be one of the so-called “best practices”. Similarly to you I guess. One reason for that is that I may not want to leave them “floating” in the end. Another is that I can always quickly check and see what units I have still available in case I want to do some changes to the design that would require additional units. The same applies to “power” units. I usually place them if not for any other reason then because most of the time I need to add bypasses anyway. So - all of those are very much in line with your views and I fully agree with you. Now, having said that - I still believe that while “best practices” should be encouraged, they must not be enforced. That means that it is not an error if I don’t put an unused unit on the schematic (for any reason). It is not an error as long as I know what I am doing and it doesn’t break things. It might generate a warning at best but I certainly wouldn’t like to be forced to do things I know I don’t have to in order to have a working design. Summing up: warning - fine, error - please no.


#39

You both probably misunderstood my intentions. Littering happens when the schematic has lots of symbols / units and the designer still needs to place the obvious supplies and/or bypasses right among them. This obscures the intentions rather than documents them. We should be able to dedicate a separate area or sheet for things, which are important for some reasons but are not telling the actual story about what the design is trying to achieve. Unused units, power pins, bypasses, etc. all fall into this category.


#40

No worries. My intention was only to +1 the idea of proper documentation. Whatever form that takes.