Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Power pin positioning #7

Closed
fruchti opened this issue Aug 2, 2018 · 5 comments
Closed

Power pin positioning #7

fruchti opened this issue Aug 2, 2018 · 5 comments
Labels

Comments

@fruchti
Copy link
Collaborator

fruchti commented Aug 2, 2018

Sorry that it has taken me so long to open this issue. Now, it's finally here for you all to discuss!

There should be a rule where power pins have to be placed in symbols. KiCad says that they must be on the top and bottom of a symbol. I already had started a discussion with @carrotIndustries about this question before I started this convention attempt.

In my opinion, the “always on top/bottom” rule isn't optimal, but finding a concise alternative isn't easy. In the issue linked above I proposed some, which I want to summarise along with some subjective pros and cons.

  • Positive on top, negative on bottom (the KiCad way)
    • Pro:
      • People are used to this convention.
      • Good usability for analogue ICs.
    • Con:
      • Symbols are unnecessarily large, because pin names get in each other's ways (I don't like the aesthetics of this one).
      • Placing bypass caps on the supply rails is awkward.
  • Use the alignment taking up the least space in the schematic, including external components used in most cases (e. g. for microcontrollers: bypass capacitors, crystal, etc.)
    • Pro:
      • Tidy and space-saving schematics guaranteed.
    • Con:
      • Not that objective and hard to check.
  • Separate power unit for all cases except where the power pins have more like an analogue function (e. g. voltage regulators)
    • Pro:
      • Having the power supply separate from the signal flow/main logic can boost readability.
      • Having a power schematic sheet gets straightforward and natural.
      • Supplying different voltage levels to an IC is easier. Putting a filter between VDD and VDDA of a chip is cleaner than ever.
    • Con:
      • Favours schematic fragmentation and might hinder readability.
      • More error prone: It's more likely to forget a power component than to miss an unconnected pin already on the schematic (although the ERC should check for this?).

I'd like to hear some more possibilities from you where the power pins could be and how we can boil that down into a rule.

@fruchti fruchti added the symbol label Aug 2, 2018
@carrotIndustries
Copy link
Member

horizon-eda/horizon@7c432b2 adds support for horizontal text on vertical pins

@fruchti
Copy link
Collaborator Author

fruchti commented Dec 2, 2018

TBH, I'm still a fan of keeping the top and bottom of a (rectangular) symbol pin-free. It plays along nicely with most schematics' signal flow from left to right and doesn't take too much additional space. Some examples from KiCAD:
2018-12-02-153450_2476x1488_scrot
2018-12-02-153127_1211x1496_scrot

But aesthetics are a matter of opinion, of course. With the perpendicular pin names of horizon-eda/horizon@c345cf4 a lot of the pain points for me of power pins on the top and bottom are addressed. If we want these pins on the top and bottom, I'd wager for having the same name orientation for all pins.

@fruchti
Copy link
Collaborator Author

fruchti commented Dec 22, 2018

As mentioned here, power pins on the top and bottom could look something like this:
2018-12-22-191326_1600x900_scrot
If you want to play around, you can check out this symbol via its PR.

@fruchti
Copy link
Collaborator Author

fruchti commented Mar 19, 2019

@carrotIndustries, @atoav: Any comments on this?

@fruchti
Copy link
Collaborator Author

fruchti commented Jan 18, 2021

With the recent input from @carrotIndustries in horizon-eda/horizon-pool#11 (comment) I’d consider this issue resolved for now. As always, I’m happy to re-open it if anyone has additional comments!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants