tmap1main- "Quick" take on mapping schematic symbols to footprints

create counter


Tutorial: Mapping Schematic Symbols to Footprints

I've written about this at greater length elsewhere. For instance there is my short page saying just what I mean by "map schematic symbols to footprints".

If you've stumbled directly to this page, perhaps through the services of a search engine, the links at the top of the page will take you to what I suspect are more useful pages.

But, as mapping schematic symbols to footprints is such a vital concept, right at the heart of all that KiCad is doing, I though a second tutorial would not be out of place.

In this version, I am going to skim over some elements of how the example PCB was designed, and concentrate on the matters most directly related to the mapping of the schematic symbols to the footprints.


Any KiCad project begins with a circuit, designed in eeSchema.

Circuit… Don't look at it too closely… while you could make it, no sparks would fly if it were powered, I doubt it would be Good For anything.

Once that had been designed, I ran CvPcb, dealing with device annotation along the way, as usual.

Here's what I had just after CvPcb finally opened.

The first column gives you the names of the libraries of footprints available. If you click on one of the entries, the list in the last column changes. (That tells you what footprints are available in the selected library.)

The middle column, so far, had just a list of the devices from my schematic diagram. Mostly, there will be one entry for each schematic symbol on our diagram. However there WON'T be entries for any Power Port schematic symbol, and for something like the 7400, which has multiple gates in one "package", you will have just one entry for all of the gates in one of the devices of that type. (It is "U1" in the example.)

Now we need to assign a footprint to each of the items in the list.

"Doing it" is one of those "you just have to struggle for a bit" things.

Beware the "filter buttons". They can help reduce "the forest", so you have fewer things to choose from… you don't want ALL the footprints on offer. Filtering by number of pins is a good bet, and "by library". But if you filter too vigorously, you may hide a suitable footprint from yourself.

What you're going to do is:

  • Click on a row in the middle column, to say "I'm going to assign a footprint to THIS"
  • Fiddle about with clicks in the other columns, until you find a suitable footprint. You can view a selected footprint's design with the "View Selected Footprint" button. And if you look at the bar at the bottom of that, you can see that moving the cursor lets you measure things.
  • When you have a good footprint for the currently selected device, double-click on its name in the right hand column, and you should see that name be filled in next to the device in the center column.

Whew. As I said, apologies for the sketchy help with this element.

When I was done, the center column on my screen looked as follows. DON'T BE ALARMED if you are trying this exercise, and didn't select exactly the footprints I did. Others are as valid.

Note the new information. For each device, we now know what footprint will be used for it. We even know what XX.pretty file it came from. For instance, for the resistors (Reference "R1" to "R4", the footprint is defined in R3.kicad_mod, which is found in "Discret". (Yes, "discret", not "discrete". Don't try to change that. It Just Is.)

The "R" between the "R1" and the "Discrete" comes from the schematic symbol's "Chip Name". It is a property of the schematic symbol. (As of KiCad 4-0-4, the dialog displaying the schematic symbol's properties remains one of the places you'll see "component" where the modern term is "schematic symbol".)

Once you've saved the work CvPCB has done, you will normally close CvPCB. (It needs to be "freshly loaded" from eeSchema when it starts, so close and re-start it whenever you come to the need to use it. (Which is after you added or removed schematic symbols to the schematic.)

Next, I generated a netlist. This is "the heart of the heart" of the magic. We'll look at that more closely later.

And started PcbNew.

Read the netlist into PcbNew, which resulted in the usual "heap" of footprints and rats' nest in the middle of the working area.

And here's what I had, after moving things about, and making tracks…

That's NOT supposed to be a "good PCB"!! But it will "do" for discussing the things I want to discuss. (By the way, the schematic passes the electrical rules test, and the PCB design passes the design rules test. Even if the circuit would have no use!))

Who cares? Why was this page written? Is it worth reading?

That's "the scene" set. Now I'll try explain what I think is cool; try to help you understand better what is going on "inside" KiCad. Why do you care? The better you understand these things, the better your chances of figuring out how to close the gap between what you wanted KiCad to do, and what it seems to be doing, when gaps develop.

Joined up PCB design

KiCad is a suite of programs. eeSchema does a great job of helping you prepare a schematic. PcbNew does a great job of helping you design PCB artwork. They are separate programs. (And there are other programs in the overall story.)

These programs come together to create a total package, to satisfy a bigger want, by "passing messages". Those messages are passed in data files.

The elements in the circuit example above were chosen in hopes of highlighting some of what is in the messages.

Schematic symbols and Footprints

You don't have to read many of my pages to get tired of hearing me go on about the central importance of schematic symbols and footprints.

But I go on about them for a reason.

In this essay, I am trying to get you to think about what they have in common, what the differences are.

The resistors in our design are pretty boring little things, so we'll start there, where there's little to confuse. And then go on to fancier devices.

In the schematic, we need "a picture" of a resistor. We pull a schematic symbol from the library. It tells eeSchema what one of these things should look like in the drawing. It tells eeSchema that there are two points of connection. We put as many of these as we wish in our diagram. eeSchema gives each a temporary, hidden-from-the-humans reference, so that as we do things to the resistor, even simple things like moving it to a different place "on the page", the program can keep track of where it is, etc.

Not later than before we try to run CvPcb, every device in the circuit must have a even-seen-by-the-humans unique reference. You can assign these by hand, by editing the reference field, or you can let the annotation tool take care of the job for you. In our example, C1, SW1, U1 are all "references".

PcbNew doesn't care what the resistor looked like in the schematic… but it does need a unique identifier for each device on the PCB, and it "re-cycles" the value in the reference field for this purpose. It is one of the properties of a device that are "passed on" from eeSchema to PcbNew via the data files.

PcbNew does need to know what holes to put in the PCB, what guides to put in the silkscreen for this resistor thing that you have made part of the design.

Now… you COULD have a PCB design package that dispensed with the "complications" of having schematic symbols and footprints. (But it wouldn't work very well.) You COULD have the "stuff" needed for a resistor by PcbNew in the same place as you keep the stuff for drawing the resistor in the schematic.

But that's not the way any sensible PCB design package works. The needs of the two programs are quite different, but, more importantly, having symbols and footprints separate allows very important flexibility.

When I think "resistor", personally, I think of 1/4 watt, axial lead resistors. Little cylinders (about 4mm long) with a wire out each end. But resistors come in many shapes, sizes, forms…. yet all can be shown on the circuit diagram with the same symbol. Why "burden" that with the information that only PcbNew will need?

That's where CvPcb comes in.

It is given a list of the devices which are going to be used. It gives you a way to go down that list, and say "for this device, use this footprint".

That much you have to do.

But in the background, the computer is doing other things for you, either during the running of CvPcb, or during the "Generate Netlist" process.

The schematic symbol has two places where the symbol has to be joined up to other things in the diagram.

Any footprint you use to create a place for a resistor to be soldered to the PCB must also have two points of connection… but this "connection" will be of a different sort. And instead of "point" connections, the connections will have pads. And during the PCB design process, care must be taken to warn the designer if things are touching which should not be.

So.. "inside" the system, the schematic symbol for a resistor has two "pins" . A resistor footprint has two "pads"

With a resistor, it isn't terribly important "which way around" it gets used… but as soon as we go to the also-simple LED, it does matter which way around it goes.

So… eeSchema must pass to PcbNew messages like "pin 1 of the R1 in the circuit design should be mapped to pad 1 of the resistor footprint". Only with that information can "things work", so that the "end" of the diode which was connected to the NAND's output in the schematic is the "end" that is connected to it in the PCB layout. (The resistor will also be connected "the right way around" just because it is easier to care about this with everything, than to have two sets of rules.)

Here's something to notice: The spacing of the pads might not be quite right, and it would be nice to have somehting in the silkscreen to tell us which way around to insert the LED, but, in a pinch, you could tell the system to use the same footprint for both resistor and LED. The heart of what you need is two pads.

So… when someone's great grandfather made the first footprint for an LED, what do you think he did? Yes, of course: He started with the footprint for a resistor, cloned that, and just tweaked the "new" footprint a bit.

More clever

So far, so good?

Now we come to the two "fancy" devices in the circuit, the 555 timer and the 7400 quad NAND (of which we are only using two gates).

A 555 timer needs 8 pads, two rows of 4. The 7400 needs 14. There are probably literally thousands of different sorts of chip that are sold in 8 pin DIL packages. And it would require thousands of schematic symbol definitions, if you wanted to design with all of them. But to use any of those chips in a design, you still only need one footprint definition! (A comparable paragraph could be written for the 14 pad device, of course.)

But it's not enough to just shove the 555 into an 8 pad footprint. KiCad has tools for testing the integrity of schematics and PCB layouts. And they will only work if we get smarter.

Part of what's in the definition of a schematic symbol is a list of what sort of signal is present on each pin. Is this an input? And output? A place to connect GND? Vcc? All the "good stuff" that electrical engineers care about.

So, besides "what connects where", the system passed more information on frim eeSchema to PcbNew. It passes on what "sort" of signal is on each pin (schematic symbol), and thus, on each pad (footprint). And while KiCad cannot promise you that there are NO faults in your design, it can catch a delightfully wide range of things… because the schematic symbol definition had information about what sort of signal was present, where, and this information was, in the computer's data tables for the PCB layout, added to the relatively dull, dump information in the footprint definition, which is mostly just about physical things, like how big pads are, how their arranged, what stuff should appear in the silkscreen.

Wrapping up

After all of the work creating this has been, I wish I could be happier with the result. Maybe I'll have another bash at some point. Maybe it has helped you grasp better what is going on as the process proceeds?

It is mostly of somewhat academic interest as long as you are only using "standard" schematic symbols and footprints. You could probably get by, without knowing much about what's going on internally.

But as soon as you start designing your own schematic symbols and footprints, you really do need to have a deeper understanding. And it isn't long before you do need to design them.

Even before you reach that stage, the understanding can be useful.

Stray odds and ends

The main points have been covered.

I wanted to mention that this little exploration hasn't been anything like comprehensive.

In what is above, I've barely touched on another area: Not only do some details of the devices have to pass from eeSchema to PcbNew, but also all of the "what's connected to what" information has to be passed. Hardly a trivial matter!

To bring the "must be passed" items into better focus, it may be helpful to think on what doesn't need to be passed. For example: PcbNew doesn't care if a resistor, in the schematic, was drawn with the long axis vertical or horizontal. What other eeSchema-important data is not needed by PcbNew?

Besides the things discussed, the values of devices can (and should) be designated while you using eeSchema. So, for instance, you fill in that a particular resistor needs to be, say, 10k. Or that the NPN transistor you have put in the circuit should be an 2N2222. (Value isn't always a simple "how big" datum.)

This essay has not assumed too much knowledge of other matters on your part.

As you learn more about schematic symbols and footprints, you will be more aware of the quite daunting range of properties and attributes inherent in each of them. And then you will be better able to see which of their properties are important only in either eeSchema or PcbNew, and which are important in both, and have to be passed on from eeSchema to PcbNew.

I don't want you thinking that everything that PcbNew needs comes from eeSchema. Remember, for instance, that you supplied further information during the execution of CvPcb. Which footprint to use for each device, for instance.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License