What's the best way to make a library searchable? Parameters - Component Development Part 3

Looking at the discussion spawned from my first two blogs, I’ve a feeling this one might answer some questions and raise a few new ones.

Component parameters serve many purposes in Altium Designer^®, but really they represent a set of text data about a component. Some of you might have noticed that over time, the Altium Content team has been putting more and more effort into including parametric data within our component content.

The main reason for this? Search.

We want to live in a world where designers can search for (and filter results) components based on parameters like; ‘Vs MAX’ or  ‘Control Interface’.

Or

Right click a component on schematic sheet, and choose ‘find similar component in libraries’ and get a sensible list of alternatives.

To make this eventually happen one day, we decided to capture more and more component parametric data.

I humbly admit, we’ve still quite a way to go ;) both in terms of making the parameters search friendly and making the tools for search itself. But the motives are pretty awesome.

Standard Parameters

Firstly, let me get some book keeping out of the way. At Altium Designer we have a handful of a standard parameters we usually include with every component:

ComponentLinks - These are a set of parameters to link the datasheet, manufacturer and product website addresses (Learn more here)

DatasheetVersion - This is version number / date code for the datasheet we used to build the component library. We prefer to follow the vendor’s versioning system, but dates are format normalized as month-year (eg ‘Mar-2011’).

PackageDescription - The description of the package (as Altium Designer describes it)

PackageReference - The vendors name / code for the package.

PackageVersion - The version number of the datasheet we used to draw the package.

Mounting Technology - Surface Mount or Through-hole

Code_JEDEC, Code_IPC - If the package fits a JEDEC or IPC standard, we name it here.

Part Number and Generic Part Number - The full order code and the component generic code respectively (see my previous post about this).

RoHS - If the vendor marks a device as compliant to some extent with RoHS we include this parameter. Very often a vendor will mark components as ‘lead-free’ or  ‘RoHS: Yes!’ in which case we standardize this to ‘Pb-Free’. But occasionally the component vendor has their own way to label RoHS (eg ‘eco-friendly’, ‘green’) which might have a slightly different meaning to simply being lead free. In these cases, we use their terminology directly.

Packing - This would show what kind of packing a component is delivered in (if it is specified by the vendor), for example Tape & Reel, Tray, Bag, etc.

Normalizing parameters names and values

All other parameters we take from vendor data, and we take them directly. That is, we (at Altium Designer do very little parametric normalization.  What do I mean about normalizing parameters?

Parametric normalization means using a single set of parameter names, with a single set of units, for the entire set of components.

Basically, when we looked at component data between different vendors all things were not equal. VIN MAX for one vendor might have a very different meaning as the same parameter from another vendor (for example absolute MAX vs typical MAX, or MAX at certain temperature) and we found very quickly, that we couldn’t effectively normalize this information without making assumptions - some of which were dangerous.

Therefore it is useful to remember, that when you place a component from the Altium Vault^®, the parametric data included might have conditions attached to its value and you should check the datasheet to confirm it means what you think it means.

Parameter Values

For normalizing parameter values, we do have a very simple system. Dates and temperature ranges are usually standardized;

• Dates should use MMM-YYYY format,
• Temperature Ranges should use -XX to +XX degC

We also convert most text ‘symbols’ into plain ascii text;

What do you do for component parameters?

Personally, I think normalization IS a good idea. But it’s simply not practical for Altium Designer’s own content. I’d love to hear feedback about how / if you all are doing that for components?

The most obvious way is to define component classes and subclasses and then a set of important parameters for each. Defining the standard parameters could be approached in a few ways;

• Industry Standard; for example IEC 61360 (have fun: here).
• Commercially practical; for example the structure used by your favorite online component distributor.
• Informal: Just make a list of standard parameter names with rough definition of what each one means.

Very early on we tried each of these, but as mentioned, they were simply impractical for us to implement. But I think for a company wide it would be extremely beneficial.

Collecting Parameters

For the Content Development Team, component parameters are extremely important because they very often represent the first major step in a new project. We gather a list of components, links to the datasheet and parametric data from a vendors website and then import it into a spreadsheet;

Most vendors have a handy download xls / csv button, but we’ve resorted to copy / paste before too.

It’s from this spreadsheet that we build up our initial list of components complete with the parametric data.

We do a lot of cleaning up and a little normalizing for our standard parameter set. We also use this as an opportunity to assign symbol, Altium Designer package names using the naming conventions outlined in my previous blog (here). Since this is usually teamwork, we use a Google docs spreadsheet and build up the names using formulas, vlookups and perhaps a script.

I’d happily give Google docs a plug for this kind of work - the scripting and multiplayer mode for spreadsheets is great for pulling together this kind of data quickly and easily.

For our purpose we call this a ‘scope’, it defines the components we’re going to work on for a project and a starting point for component data. Key phrase here is ‘starting point’, we don’t consider this data to be validated. But from this we begin the more formal component development process.

I’ll share this example (here, and xls here), which will no doubt spawn some interesting questions ;)

The nice part about this approach is that it is reasonably simple to take this tabular data and enter it (copy / paste) into a dblib table or .cmplib component libraries. (Explanation of this is in the wiki, here)

It’s pretty easy to get unique list of packages and symbols from a scope, and set about building those in an organized fashion, ultimately arriving at a completed set of sources for a .

Next port of call is going to be symbol development and standards.