Component Development best practices - Part 1

Hi Everyone,

For a little while now I’ve been asked to provide some details about how Altium develops our content and more importantly, what do we consider ‘best practices’.

From the beginning, I thought we’d provide this as app notes or wiki pages, but after some consideration I figured a good first port of call was as blog posts. This way I can cleverly record your feedback and ideas, and then incorporate them into said app notes claiming them as my own.

Big thanks in advance for helping me with this ;)

Jokes aside, the truth is really that Altium builds printed circuit board component libraries for a big audience. I would assume that while we’re driven by pretty much the same principals, the way these are applied is different because we need to make circuit board components that work for everyone. To that end, any documentation about ‘best practices’ needs to be in a context that makes sense for each of you.

My hope is that we can create a set of documents that describe what really are the best practices - a combination of both Altium and our customers perspectives.

To explain why I’m writing this post; about 2 years ago I was involved in setting up Altium’s Shanghai Content Development Center. At the time I was taking care of Altium’s Asian application engineering team, and had figured I knew PCB assembly and components for Altium Designer^®. Boy was I mistaken. I was lucky enough to be working with people who had 15 years experience in developing component libraries to learn from.

So let’s get started.

What are the guiding principles to building good content;

• Quality
  As the building blocks of a design, a simple or subtle mistake can have wide reaching, hair pulling consequences. Above all else components need to be accurate and reliable. By far the largest amount of time in developing a component is checking that it is correct.
• Organization
  At first I figured this was trivial, but I quickly learned that the key word for development was . Like a we need to be able to find what we’re looking for, quickly and efficiently.
• Usability
  It’s one thing to make a symbol that is technically ‘correct’, it’s quite another to make one that allows a to draw a nice, neat and readable schematic. This is so important that in Altium we built this requirement into our development flow and our standards.
• Predictability (conformity)
  In a way this really a combination of good organization and usability. To make both of these objectives possible there must be consistency in almost everything. Consistency makes reuse possible, it also makes things like browsing and searching possible.
• Quantity
  Perhaps this one is debatable outside the context of the Altium Content team? I’m not entirely sure. At the least, we all need to be efficient and productive at our jobs. Quantity is really the outcome of this when a team is solely focused on developing content.

What I wonder is do these principles align with your own understanding of component development? are there things I’ve missed or understated?

In order to give everything reasonable coverage, I’ve decided to do this as few blog posts and hopefully I can deliver them in quick succession. For now I’ve decided to divide up the topics like this:

1. Naming standards, why and how.
2. component parameters,
3. generic vs vendor specific,
4. developing good symbols,
5. how Altium builds footprints,
6. PCB development processes and infrastructure.

Along the way, I really want to be guided by your feedback. So please chime in with any comments and thoughts.