What's in a Name - Component Development Part 2

April 12, 2016 David Read

In this blog I outline how Altium Content Team names components, symbols and footprints. Why we’ve chosen these naming conventions.

This seems like an eminently boring place to start, but something I’ve noticed is that figuring out a way to name things in engineering land often makes for animated discussion.

We build components for distribution in a , the way components are realized in a is slightly different from how they exist in an integrated . There is a lot of rich information about the differences in our wiki: here and here, but for the purpose of this blog - the differences amount to this:

Parametric information about the component is elevated to the row in the cmplib. This gives us the freedom to name the component separately from the symbol, and much better re-use opportunities for both the parametric information and the symbol itself.

Naming the component

Allow me to define some terms;

Generic Code: This is the name of a group of devices that likely do the same thing, but have some differences between them (package, temperature / speed grade, RoHS). Some vendors call this code a ‘part number’

Order Code: This is the name of a single kind of device. It is very specific. Some vendors, unfortunately, call this a ‘part number’.

As an example, looking at the generic code LT1720, you’ll see 24 possible order codes. eg, LT1720CDD#PBF is a lead-free LT1720, in a DD8 package.

To avoid inconsistency, we’ve settled on ‘Part Number’ (for order code) and ‘Generic Part number’ (for generic code). From here, I’ll refer to part number and generic code.

You’ll find in (most) Altium components, we’ve included parameters for each. We also have a tradition of populating the component Comment field with the order code. The idea is that searching for either kind of code will yield a useful result.

I didn’t think I’d need to air dirty laundry so soon :( To be honest, this naming standard wasn’t formalized until mid last year and you will find components that were built without those parameters. We’re slowly, but surely, fixing that.

Package and Footprint names

Internally we define a difference between package and footprint. A package in the set of dimensions that describe the physical package - using formula derived from IPC we can use these package dimensions to calculate footprint (land pattern) dimensions. Using the IPC footprint builder (see here), you enter package dimensions and it generates those footprints.

I have to say package naming for electronic components in general is kinda a mess. Through acquisitions and different departments creating their own package naming scheme, package naming within a single vendor can be quite inconsistent. To combat this we distinguish between a vendor package name and an Altium package name.

The vendor package name is exactly as the vendor calls it in the device datasheet. An example would be DDA8. This is an 8 lead SOP from Texas Instruments.

If you look through a few TI datasheets you’ll find a number of variants of this package. The key difference is the size of the thermal pad.

Actually almost anytime you find a thermal pad drawing separate from the main package drawing, you should go looking for variants.

If you were to name your footprints for a component ‘DDA8’. Then later, some innocent and unsuspecting is putting together a component will see there is already a set of footprints for DDA8  and use them without a second thought. Much later, the same will be scratching their head as to why components didn’t solder properly or keep overheating.

I’m not singling out TI here for any purpose other than an example, as a big big component vendor with a lot of different packages and variants they actually do well at documenting and describing them. Actually, overall vendors are getting much better at this kind of thing.

So, the Altium package name includes some details to ensure that all variants of vendor’s package have a different name. This usually comes in 3 flavours; thermal pad (TP), body size (DE) and height (A).

We append the details to the vendor package name, and we only do this when we have to:

DDA8-1775X1775TP is a DDA8 package with the 1.775x 1.775 mm thermal pad variant.

For body size we use the suffix DE:  YFF20-2172X1598DE

For component height we use the suffix A:  324-UBGA-1500A is the 1.5mm height variant of 324-UBGA.

We sometimes find that body size and height variants happen for the same package code, in that case we use DEA:  PC-64-8000X10000X1200DEA 

This can make for some long package names, but not many of them. What is more important is that package names are unique.

To make searching easier, we publish the vendor’s package name in the component (and the link to package drawing) as a parameter.


Footprints are the synthesis of package dimensions, and are named by the package. We add a suffix to package name to describe the IPC level we’ve used to generate that footprint. Details about what this means are here.

In some situations we find it isn’t appropriate to have IPC L, M and N variants for a footprint and then we either omit a suffix entirely (BGAs don’t come in L, M and N) or we add a V.

V is for Vendor recommended, this means the datasheet or our contact at the vendor told us to use a specific land pattern. We draw these directly and don’t use the package dimensions and the footprint generator.

We have a some legacy libraries that still use IPC or IPC-like naming for footprints. We won’t do this any longer for vendor specific , they’ll always be named according to the Altium package name. That said, we’ll likely release the generic IPC footprints one day down the track.

Schematic Symbols

Because symbols can be extremely reusable, symbol naming is more complicated. Our basic standard is to use a combination of the generic code and package name. For most non-generic components this provides enough ‘uniqueness’. Because we’re building components in the 1000s in a single batch we need to get all the reuse opportunities we can upfront - this naming scheme does the trick.

Following this, the symbol for LT1720CDD#PBF might be called LT1720-DD8

Occasionally we’ll find a wider group of components will have the same symbol. In that situation we consolidate symbols, and place an ‘X’ in the symbol name where the generic codes would be different.

A symbol that is the same for REG102-AD8 and REG101-AD8 would be called REG10X-AD8.

In a more generic situation, Op Amps for example, we’ll upfront define a number of standard symbols for that vendor, then begrudgingly name them LT-OAMP-A, LT-OAMP-B, LT-OAMP-C, etc.

I have to admit we avoid this situation as much as possible, since it ultimately ends up with us having an LT-OAMP-Z and we have to maintain a list of names vs pinouts.

Previous attempts to come up with a truly generic naming scheme for symbols hasn’t really worked out for us in the long term. When applied to real world component development the scheme always breaks and we find ourselves adding more rules or exceptions. I’ll share some of these in a coming blog.

Vendor Codes

You’ll also notice that we prefix symbol and footprint names with a ‘vendor code’, TI for Texas Instruments, LT for Linear Tech, etc. We do this for a few reasons, most importantly is preserving name space for footprint names. LT-QFN20 will probably be slightly different from TI-QFN20, if they both land in the pcb editor as QFN20 defining design rules by name will be difficult. I’ll make the vendor code list publically available here.

Check out Altium Designer® in action...

Component Placement System

About the Author

David Read

David Read was appointed General Manager, Altium Greater China in October 2015, and he has worked at Altium since 2001. Originally serving as a Technical Support Consultant for the Australian region from Altium’s office in Hobart, Tasmania, later he moved to the Global Customer Care group at Altium Headquarters in Sydney as an Application Engineer and was later appointed R&D Director in Shanghai Content Center, and from 2013 to 2015, he worked as Product Marketing director. Prior to Joining Altium Mr. Read studied Computer Sciences and worked in the electronics industry.

More Content by David Read
Previous Article
Component Development best practices - Part 1
Component Development best practices - Part 1

During the coming weeks, we’d like to post details about our library development standards, practices and p...

Next Article
A cloudy focus
A cloudy focus

There’s been some discussion on our new Forum about our plans for “all this cloudy stuff”. Some of you have...