Atomic or Not? What are you DOING with KiCad?

Okay, so I’m in a bit of situation where KiCad is causing me a little bit of grief in BOTH cases.

Me, I am:

  1. Working on a start up company where I need control of the parts AND part numbers used; sometimes the same part is used but in different quantities depending upon the packaging!

  2. Working with members of a Maker Group that has any level of skill set with the members. Being able to just draw a 2 wired device on the schematic, then later to choose a lithium battery holder, or a coaxial connector, or a mini-USB connector FOOTPRINT, allows the schematic to remain the same for ALL of the above physical designs.

It seems that “I” currently need “ALL OF THE ABOVE”.

Share what YOU are doing, and which way the work flow works best for you.

This topic comes up a lot. Mostly if some thread gets derailed. Now we finally have a dedicated thread for this.
(The last thread that got derailed in this direction was: Eescheema GUI feature request - basic device button)

Now to answer your question:

Well your example in point 2 is a bit extreme. I would not use the same connector symbol if it is a battery holder or a usb connector. (Doesn’t the usb connector have more than 2 pins?)
But i understand what you meant.

I currently use a mixture of both these approaches. (Atomic for everything except resistors or capacitors.)

I don’t use manufacturer information in my atomic parts but a house part number. The connection between house part number and order information is done outside of kicad. (Currently a large libre office calc file)

For resistors i have one semi atomic part per “series” (0603, 1%; 0805, 1%; 0603, 0,1%; etc.)
The house part number for these devices consists of a prefix followed by the value. (The combination of the two is done either by hand or using a python script.)


Well, you don’t know the quirky lot of people that are in the group! Every example has a high probability of actually being used in the future.

Yes. And, I have not figured out the best way to deal with differing pin count. I haven’t played around in KiCad to see which method might be preferred. I do know that KiCad doesn’t mind extra unconnected pins.

The people that I will be working with won’t know the difference between the symbols on the schematic sheet anyways. And I can choose key words so that every type of actual part shows up in CvPcb.

I hope none of the board members of the space read this post…

I’ve also seen a lot of these discussions and it’s quite controversial, so…
I use a similar system. I also use a “Database” (LibreOffice Calc spreadsheet) that maps a Manufacturer and Part Number to a “Unique Part Number” or “House Part No.” (e.g 8903:6N137, where 8903 is “Fairchild” and 6N137 is an Opto-Isolator). Using a 4 digit code just makes the UPN shorter - it has no real-world meaning, it’s just unique for each manufacturer.
Each row of the spreadsheet contains things like Footprint, datasheet etc. In fact any information can be added like sourcing etc.
The spreadsheet also has another tab which uses the UPN and Footprint to form data for an equivalence file (yes i’m using that :grinning:). e.g. ‘4633:CPH5512’ ‘IPC-7351_SOT23:SOT95P280-5N’. (each row in the database = a row in this tab). So all rows in this tab are copied to the .equ text file (i.e there is a 1:1 mapping).

So, my symbols have no information except some contain a “Characteristics” custom field (Default “?”) e.g for Resistors, Capacitors.
The idea is that the Schematic can be 90% laid-out without thinking about footpints(another possible taboo). Before using CvPcb, i replace each symbol value with the correct UPN (the UPN is the “Part”).
So using the Equivalence file (if the UPN is in the database, it will have a Footprint), and automatic footprint association, footprint association is done automatically.

It’s in it’s early stages but i see the advantage of maintaining all information outside of Eeschema.

  • No. of Symbols reduced (e.g Logic Family is determined by the value of the UPN, not the Symbol (the Symbol is generic accross the applicable Logic families). One Symbol per Resistor/Non-Polarized Capacitor/Polarized Capacitor etc.).

  • The UPN determines the Footprint. Here it is assumed that the Part No. is the Orderable Part No. (i.e when a part has multiple footprints, it is reflected in the Orderable Part No.).

  • Only a UPN can map to a Footprint via automatic assignment/Equivalence file in CvPcb. If the original Symbol value has not been replaced with a UPN it isn’t mapped (an obvious prod to go back to the schematic).

I also use a LibreOffice Calc tool to take the generated BOM from Eeschema and input the Ref and UPN (Value) that does a lookup in the “Database” and populates all the relevant data for each UPN (key) to produce a “Finished BOM”.



When using the Kicad the first time, I was designing a fairly complex board (BGA, 8-layers, differential traces). I jumped right in the schematic with the idea I would would assign footprints later in CvPcb, which I did. It sucked. However, I still do not have fully atomic parts in my libraries. My end goal is to make the PCB assembly manufacture as straight forward as possible and allow future board revisions to be as painless as possible.

It is like source code: I do not want a bunch of external dependencies (databases, spreadsheets, etc.) when exporting a board to fab. I want my Kicad project and my Kicad Library only. As such, here is my process:

  1. Place all schematic and footprint parts in a common library you control (you are not beholden to Kicad Git Lib changes when to go rev the board later)

  2. Setup a common library path so it is easy this to share the Lib with others

  3. When placing a schematic part, go ahead and define the footprint, MFG name and MFG Part number
    Note: I am not using fully atomic parts here, but it is easier to do this now rather than later. Waiting means you can’t remember what voltage that cap should be or what pitch the associated IC is.

  4. Do your Layout, no CvPcb needed

  5. Export the BOM from Eeschema, it has all the info you need now

If I do this, everything is contained within my project file and library. No extra items needed. If I go back a rev the board two years from now, I should not need anything else to fab the board.

As for revising that board from two years ago MFG parts not defined in Eeschema and a mix of custom and Kicad Git libs: KiField is your friend.


Thank you for your excellent post; and for the time you spent to share your wisdom.

I personally see the benefits of both methods. I’m curious if there is a way to sorta mesh them together, so that is is not an either/or situation.

I suppose that if you really KNOW your stuff, an Atomic part would make sense right from the time of placing the symbol.

However, if one has to FINISH the drawing of the circuit, to run SPICE on it, how would an individual KNOW what parts to assign before the SPICE was done. This is a Catch-22 situation. Running CvPCB should make this easier to assign footprints based on the SPICE data provided after the symbols were drawn, which is before the power requirements can be calculated.

For recent example: In my “commercial” design, I had to decide on a linear regulator. I can easily draw the symbols and SPICE the results. With the bean-counter hat on, I had already decided upon a few manufactures for the part. After SPICE, I was able to determine that the D-PAK footprint met the designs thermal with overhead, while the SOT-23 part would not.

Anyways, I’m not trying to cause any argument; just trying to share my own experiences.

I don’t think there is any “right” or “wrong” way - you should find and use any system that works for you.
That’s one of the advantages of KiCad, You can make all parts atomic, you can make all parts require CvPcb to assign footprints or you can have a mix - You are not constrained.

But, that means you have to maintain your own libraries to fit with the methods you use, simply because there is that flexability in KiCad.

1 Like

[quote=“Andy_P, post:10, topic:5673”]
I’ve found it mostly impossible to have the same schematic for the SPICE simulation and for the layout. All of the specialist things needed to make a simulation work aren’t anything you can lay out. The converse is that all of the stuff needed to make your design work in the real world (connectors and whatnot) can’t be simulated.

Most people I know just use LTSpice to simulate the bits of the design that can be/need to be simulated. Here is where substitutions for different op-amps or transistors might happen, where cap and resistor values are tweaked, etc. And once the simulation is complete, the engineer has the final parts chosen, and then it’s a matter of re-capturing the schematic in whatever EDA package and going from there. . . . [/quote]

That’s essentially how I work. It’s satisfying to dream of one Grand Unified Tool that performs all of the design tasks, selects and orders the parts, builds the assemblies, and writes the marketing materials, etc, etc. But the attempts I’ve seen to perform two or more functions with a single tool usually create a tool that does neither function well.

And the manufacturing guy doesn’t care who made the part or what it costs, he only wants to know where he can get a fistful of the things to do a production run. Design, purchasing, and manufacturing all have information requirements that are inter-related, but ultimately different from each other. Simultaneously satisfying all of the requirements is a complex task, and I hope KiCAD doesn’t get sidetracked into either the world of circuit simulation, or MRP systems.


My unsubstantiated impression is that LTSpice is the de-facto standard for day-to-day circuit simulation, especially among small-time users like hobbyists, freelancers, garage shops, etc. (Has anybody else been to one of Mike Englehardt’s seminars?) Yes, the code is (very) proprietary and no, LTSpice is NOT integrated with any other EDA tool. It’s probably a little embarrassing to the open-source community that such a capable and high-performance product is available as a no-charge giveaway from a major corporation. It would take a LOT of convincing to make me switch to anything else.


1 Like

That’s true, but I think there’s more to it than simple meddling by the company’s manglers. Analog seems to have a history of sane, technically-oriented people in senior positions. LTSpice is supposedly Linear’s internal simulation tool so there’s justification for keeping it going as long as Analog continues to employ engineers from Linear, and it just might gain favor with the technical staff at Analog. On the other hand Mike Englehardt has been the driving force - perhaps almost a one-man show - behind LTSpice since its inception, almost 20 years ago. I’d fear for its ongoing viability after Mike Englehardt retires regardless of what company’s flag it flies.

In the meantime, I’m not looking into the mouth of a gift horse.



Love your comments guys. :+1:

1 Like

in practice, is that get difficult to keep track of during the design phase? I mean, while you’re laying down several resistors in an 0805-1% family, they all have the same ‘value’ on the page, all the same 'house PN" property (prefix), and they dont yet have a reference designator to identify themselves from each other. So the Ohm value of the resistor isnt depicted at all in the KiCAD app? I suppose you mean that after the design is done and annotation completed, you make an offline decoder ring of resistor values and reference designators… then create the real house part number with a suffix that finishes the definition. I’m not trying to throw stones, just want to understand as i am in the process of starting to roll my own libraries and trying the atomic paradigm out, but having figured it out just yet.

Since the Analog takeover, the AD devices have been modeled in LTSpiceVII, a good sign.

Unfortunately building an opensource simulator is a lot more work than a PCB CAD package as the modelling is much more complex than a new footprint and symbol

Probably just added “equivalent” (or close enough) part numbers to see how it affects their sales. <-- - Would be the first thing that I would think to do.

But, on the other hand, with computers today, adding extra part numbers with more specific values to the actual AD parts would not be overly cumbersome to script; and then see how that affects AD specific part sales.

When you put such a resistor down, you change it’s value field to 680, 1k or 2.2M.
You can do that anytime - those fields aren’t carved in stone.
This will then be depicted in the schematic (and Layout, if you have those fields over there) and visible to you.

KiCAD still has got the same house partnumber for all of them, and never differentiates those parts by it anyway.
The part number field is something KiCAD doesn’t care about (you have to add it), but keeps it for your convenience, while itself not doing anything with it.
KiCAD differentiates parts by it’s Reference designator and timestamp of placement.

Now, when you create the BOM (either from the schematic or layout) you’ll get those reference, value, house partnumber fields into some sort of list.
And that’s where you need to go in (via script) and modify the house partnumbers.
Your tool will recognize - from the house partnumber - that resistor XY is a 0603 1% type and from the value field it will know it should be 680 Ohm. So the tool then modifies your BOM and replaces/changes the house partnumber to reflect an actual orderable (manufacturer) partnumber for that particular resistor.
That’s how that system works.
Very flexible - as you can - with a few changes in lines of code - apply any manufacturer partnumber to your internal house partnumber (change source of resistors on the fly).

You could also have - for example all the E96 series resistors for 0402, 0603, 0805 in the schematic symbol library - defined as atomic parts, complete with the correct manufacturer partnumber.
Little less flexible and somewhat more work upfront… I run it like that atmo, a script created my libs.


That’s the key bit i didnt catch in my research. I was thinking i couldnt mess with it.
Thanks a bunch for the clear explanation.

Hmm, this sounds quite promising. I would much rather write and debug code than clickity click thru making libraries. Thanks for the idea.

I don’t think you even need a modern computer to create a usable opamp macromodel from datasheet parameters. The seminal 1974 paper by Boyle et al has enough information to create models for opamps used in common applications. The later (1990’s) additions by Baker and Alexander should let you program a spreadsheet or VBA macro to create models as good as most of the published commercial models.


1 Like

Well, that is a good way to keep me honest!

I still hold to my original premise that if these changes positively affect sales, LTSpice will probably be around and supported for some time longer.

If I might weigh in here. This is the method I’ve used since the mid '90s with the one difference that I have a mapping table which is just an ASCII text file. If I need to output a BOM for a different company I can just use a different mapping table. As that table is plain ASCII any semi-non-techy person can add parts to it or even create a whole new table.

I originally did this with Borland C for DOS, but now also use Python which is a piggin’ awesome language for this kind of thing.

1 Like