Naming devices in different packages

I’m creating a library of components. Assume I want to add a 74HC00 device. It is available in different packages (e.g. DIP-14, SSOP, etc.), so I need to create several devices. The problem here is that manufacturers use different suffixes for same package (e.g. SN74HC00N, SN54HC00J from TI, M74HC00B from ST, TC74HC00AP from Toshiba are all the 74HC00 device in DIP-14). Is there any best practice for such cases? I see several possibilities so far, but all have own disadvantages:

  1. add some “synthetic” suffix to device name, say, “74HC00 @DIP”; disadvantage - this name appears on schematic and board editor, and such naming will look ugly (and redundant in board editor)

  2. give same name for all package types (“74HC00” for DIP, SSOP, etc.); disadvantage - it’s not possible to find the right device in library editor:

Actually, solution 2 would work for me, if device package is displayed next to device name, like in board editor:

But of course I’m open to other solutions. Thanks!

In our libraries we create separate devices for each manufacturer, e.g. named “TI SN74HC00N” and “ST M74HC00B”. But that’s mainly enforced by the fact that we have a separate library for each manufacturer - for personal libraries one doesn’t require to follow this scheme.

Generally I think the best way is to also add parts (i.e. exact MPNs) to the devices and choose them in schematics. Then the device name is not that relevant anymore ({{DEVICE}} not visible in schematics) so you could name them like “74HC00 (DIP)”.

Or you could set the component value e.g. to {{MPN or COMPONENT}} (skipping or DEVICE) so that the schematic will show the component name instead of the device name. Or alternatively, it would even be possible to customize the value displayed in schematics with something like {{MPN or DEVICE_DISPLAY_NAME or DEVICE or COMPONENT}} and adding the attribute DEVICE_DISPLAY_NAME to devices. However, these approaches are very unusual so generally I don’t recommend that…

Thank you @ubruhin!

I personally don’t see any good reason to have libraries per manufacturer, because there are a lot of devices manufactured by different manufacturers, often having a different part name, but being in fact the same device. 74-series, 4000-series are a good examples. At least hobbyists rarely choose, say, 74HC00 from a specific manufacturer, because all devices from different manufacturers are basically the same (except, maybe, very rare edge cases). Same for CPUs, memories, etc. So I’m basically trying to create a library for 74-series devices, and that’s why I want to organize it the way I describe.

{{MPN or COMPONENT}} wouldn’t work because component name is something like “Quad 2-Input NAND Gate”. Having a custom attribute could work, as well as having a generic part number (“74HC00”), but both solutions are also not perfect.

What’s your opinion about showing package name next to device? I think it may be useful in general, especially considering that there’s no any standarts for part number suffixes and looking at SN74HC00DB it’s hard to say which package it is without looking into datasheet

Although there are some (from the perspective of a hobbyist maybe considered a lot) devices manufactured by different manufacturers, I claim >99% of the devices out there are manufactured by exactly one manufacturer, and the trend is going further away from generic devices to very specific devices. Thus it makes more sense to optimize the library organization for manufacturer-specific devices rather than generic devices.

In an ideal world, the library organization of course should be able to reflect the whole real world, i.e. being able to represent all devices of all manufacturers. But unfortunately this is not possible since there are so many different kinds of devices and manufacturers are doing so many ugly things (e.g. giving the same package many different names, giving multiple packages the same name although they are different, claiming a device to follow a standard but deviating from the standard in fundamental things, completely changing the package of a device without introducing a new MPN, …). As long as manufacturers are doing things like that, we’ll never be able to create clean and correct libraries.

To be honest, I don’t think it would solve the problem. Even in the board editor seeing the package name sometimes is annoying because the names are so long. Also for many devices the package name is clear anyway, for example displaying the package “RESC1608 (0603)” next to the device “Resistor 1608 (0603)” would be redundant, and I’m pretty sure sooner or later we’d get requests to remove the package name. So in the end it’s always a compromise. Something which I could imagine is to display the package name e.g. on mouse hover, to not cluttering up the UI by default but still allowing to determine the package name quickly.

I see the point, and, well, I should agree with it. And it’s good that there is so much flexibility in creating own libraries that better fit the one’s needs (mine in this case :sweat_smile:).

I did think about what I personally need from my library, and ended up with the following pattern:

  1. add package suffix to the device (74x00 @DIP-14)
  2. slightly abuse MPN list - I’m going to put generic part names there, but include different logic families (7400, 74LS00, 74HC00 and so on). It’s not exactly real part numbers, but it will work well for me. This will rely on fixing Board editor: {{MPN}} within {{VALUE}} is not substituted · Issue #1260 · LibrePCB/LibrePCB · GitHub , though.
1 Like

(following up to Long term feasibility of purely file-based libraries here to avoid sidetracking that thread)

My concept of MPNs (in relation to the LibrePCB Device) is like this:

  • A device is a collection of parts which share the same package and general function but differ in some intrinsic characteristic
    • Example: 0402 resistor
  • A part provides a specific functional specification. If I put this part on my design, to properly manage the supply chain problem, I expect to be able to have multiple sources that meet this specification.
    • Example: 0402 resistor, 1.27 kΩ, 1%, 1/16W
  • A part may have multiple MPNs from different manufacturers AND/OR the same manufacturer with different packaging types that meet the functional specification.
    • Example: CRCW04021K27FKED - Vishay

I think the last point is where my confusion comes from. In LibrePCB, it seems like you break down Device by manufacturer’s part series instead of breaking down Part by functional specification. MPN alternates are done per schematic instead of per device. As an engineer trying to create a manufacturable design, I care more about the functional specification. I explicitly don’t want to specify a specific manufacturer’s part series on my design, to the extent that a component is interchangeable between manufacturers (such as the case with commodity passive components, jellybean logic ICs, etc.). The current implementation is probably safer for circuit function (each design only calls out exactly which MPNs it can take) but pretty tedious if you want to support multiple resistor manufacturers.

If you had a specific spec you wanted to meet for an application (such as temperature coefficient), you could create a new part entry that captures this stringent spec. Some MPNs will be duplicated, but such is the world we live in.

In the OP’s case with a logic IC, I would propose (especially for a personal library) to use a primary/preferred manufacturer’s MPN with footprint to key the device, and add other manufacturer’s equivalents to the part list. In a world where LibrePCB supports MPNs like I imagine, you might add them as alternate MPNs of a single part if you really don’t care which one you order for your design, and continue to use the existing Part list for logic family variants as you are doing already. For example, if you would rather order TI by default, use all of their MPNs to name your device. This works well at my day job but I recognize it may not be correct for everyone.

Although I agree that 99% of parts are moving to proprietary/unique designs, I believe the model I am imagining can handle both of these cases equally.