PCB design: laying out the board in KiCad

[Eagle vs KiCad part 9]

Once you’ve finished your schematic, creating a board in KiCad involves a number of steps.

First, while still in Eeschema, you need to ensure all your components are ‘annotated’. When you drop a component in the schematic, it will be shown with an identifier plus question mark – for example, an IC might have the label ‘U?’. The question mark needs to be replaced with a number. Generally, doing this is as simple as clicking a button and accepting a bunch of default settings. But having to do it at all is a little annoying. (Power users of KiCad will no doubt be able to say why this approach is useful, compared to Eagle’s one of annotating parts automatically as they are added.)

Then you need to associate each of your schematic components with a PCB footprint. You run a program called CvPcb to do this, and it can be slow work.

The three-column display lists available footprint libraries on the left, the components in your schematic in the middle and the footprints in the library you have selected on the right. Just click one item in each column. Easy, no?

Well, no. The frustration comes from trying to find which library contains the footprint you need. Over time, you’ll get to know this. And there are several ways of narrowing the search (for example, when creating a part you can specify footprint filter terms). Like everything to do with KiCad’s libraries, though, the search and filter functionality is clumsy and unintuitive in the extreme.

Finally, from Eeschema you export a netlist. This is a text file that you should save to your project directory. That’s simple enough, but there’s a slight gotcha, as we’ll see later.

Spreading out

Next, you switch to the Pcbnew program. When you created your project, KiCad most likely created a blank board file for you, so just open this. Then click on the button to import the netlist you just made.

One of KiCad’s quirks that so many people gripe about is the way that, when you import the netlist all of the parts are dumped in the middle of the screen on top of each other. There is a utility to spread them out, but you have to click on a button to make sure you’re in the right mode and then find the appropriate menu command. Why doesn’t it just do this automatically?

As is fairly standard in programs like this, connections between components are indicated with grey lines that make up the infamous ‘rat’s nest’. It shows what needs to be connected to what, although it isn’t always very clever. For example, if pins on several components are connected to the same net, KiCad makes a best guess as to whether the pin on part A should be connected to the one on part B or part C. As you move parts around the board, KiCad updates the rat’s nest in an effort to be as logical as possible. But the end result is that you can be confused into thinking two pins needs to be connected directly when they don’t. So always treat the rat’s nest with a modicum of scepticism.

By default, KiCad creates a two-layer board. And at my level of development that’s all I’ll need. Tracks on the top copper layer are shown (by default) in a kind of brown colour while those on the bottom are in green. In the default viewing mode and default settings, the tracks are rather hard to see once created. There two alternative modes – OpenGL and Cairo. OpenGL seemed much clearer to me (and, as we see, offers a major bonus). I couldn’t see the attraction of Cairo.

Moving, rotating and annotating components works in a similar (although annoyingly not 100% identical) way to Eeschema. It does make me wonder if there’s anyone on the KiCad team responsible for consistency across all these packages.

One major irritation for me was that KiCad would often select the wrong layer. This happened under the following circumstances: I’d start a track on the top layer; at some point I’d select to switch to the bottom layer by inserting a via, and I’d finish on the bottom layer. Then – even though I’ve still got the top layer selected in the right-hand panel, I’d start a brand-new track – except this would start on the bottom layer, not the top.

Looking at the layer selector in the main toolbar at the top of page would show the top layer, as expected. But when I hovered the mouse over the selector, it would flicker a few times between top and bottom payers and eventually settle on the bottom layer. I could then manually select the top layer. So clearly there’s a bug here.

Another weird issue arose when I did a copper fill on the back layer. A bunch of horizontal lines appeared, looking for all the world like tracks. I could find no way of removing them but they prevented me from laying any tracks across them. Weirdly, when I switched into OpenGL mode they disappeared.

Pushing and shoving

Talking of OpenGL mode, this is what you have to use to take advantage of the CERN-originated ‘push and shove’ routing. And I have to confess I love it. Indeed, for all of KiCad’s many annoying characteristics, this could be the one that sways me. It allows you to run tracks with the software shoving other elements (tracks, vias) out of the way if necessary, although always staying within design rules. It means you can run tracks very fast and tidy them up later.

Using push & shove in KiCad. Note how possible destinations are highlighted.

Eagle has a ‘push obstacle’ option, but I understand it won’t push vias, which seems a bit of an oversight. I’ll find out more when I come to create this board under Eagle.

Without using push & shove, in the normal graphics mode, I found it difficult to put the track exactly where I wanted it. But I can’t see why I’d use anything but push & shove. One nice feature, for example, is that KiCad nicely highlights which connection you need to get to with the track.

One flaw with OpenGL mode is that, as far as I can see, there’s no ‘drag’ option. You can move components, tracks and vias, but then connections get broken and you have to redo them. Drag is available in the normal mode, but flipping between modes is time-consuming.

Back and forth

And given that we’re back to griping, a big weakness in KiCad, I feel, is the lack of integration between Eeschema and Pcbnew. I’ve mentioned before that KiCad feels like a loose collection of programs rather than a consistent package. This is a classic example.

If you’re working on your board layout and realise you need to make a change in the schematic – perhaps to make routing easier – the process is clumsy at best. Once you’ve changed the schematic, you have to re-export the net list, switch to Pcbnew and then re-import that list. It doesn’t sound like much, but after you’ve done it the third or fourth time it gets tiresome. In Eagle, so long as you have both schematic and PCB editors open at the same time, changes are automatically reflected. In this day and age, that’s how it should be.

Another problem is the way Pcbnew – and to a slightly lesser extent, Eeschema – draws the screen. Or rather, doesn’t redraw the screen. Let’s say you’re laying down a track in Pcbnew and decide to abandon it for some reason. Hitting escape achieves that, but most of the time the part of the track you’ve drawn so far will still be on the screen. The track itself isn’t there – it just looks like it is. You have to redraw the screen to remove the phantom track. It got to the point where I was hitting Cmd-R almost as a reflex action.

Same goes for when there’s a copper fill. You put down something like a track or via and expect to see the fill withdraw a safe distance. But it doesn’t do that until you hit B to redraw the fill. Move a part and there’s a big gap in the fill until you redraw.

Why? Would it be so hard to flag some actions as requiring redrawing and do that automatically? Back in the dark ages when such operations might take some time and appreciable processor power I could understand this reticence to redraw until commanded. But with today’s computers, all the memory and power you could want is there for the asking.

On the plus side, you don’t have to wait until you’ve finished placing parts and laying tracks and vias before adding the copper fills. In fact, it’s better not to. It’s common to use these fills for power nets – in my case I used the top copper fill for the 5V VCC and the bottom one for GND. You can then easily make all the VCC and GND connections for your components without running tracks.

If you want a clearer view of your layout, you can switch off the rendering of the copper fills. Alas, it seems you can’t do this individually – all the fills are either on or off.

The PCB without the copper fills shown (although they are there).

Overall, the process of creating the board wasn’t that difficult, although I frequently found myself having the deal with part-drawn tracks and tracks that split into pieces when you try to drag them to re-route. But I have to confess that the experience was much easier than I expected.

The final board, with copper fills.

Gerber output

For fabrication, you’ll probably want to output Gerber and drill files. There are plenty of guides for this online and the process involves little more than a few clicks. I zipped up the files and uploaded them to GerbLook.org which found no problems.

In fact, I was so encouraged by this result that I sent the Gerbers to a fab house.

This is a circuit design that I haven’t prototyped or tested. And for someone of my level of non-expertise that could be viewed as very, very bad. And it probably is. But I decided that, for the cost of about $12 for 10 boards (delivered on a slow boat from China) it’s actually easier just to get the boards made than spend hours wiring up a breadboard.

Well, okay, I’ll almost certainly have to do the breadboard thing anyway when the board doesn’t work. But if so, I’ll simply use the boards to practice my surface-mount soldering techniques.

Now to do the same thing in Eagle.

» See all Eagle vs KiCad posts »



» See all Eagle vs KiCad posts »

Leave a Reply

Your e-mail address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.