Stitching layers between copper zones in KiCad

I’ve been working a bit with KiCad lately and have run into a problem in PCBnew with “stitching” (i.e., adding vias between) filled zones on top and bottom layers. This is something you typically do if you have flooded the unused spaces on both top and bottom of your board with copper and have connected the floods to ground or some other reference.

The KiCad FAQ outlines a process for doing this, and it works fine until you refill (i.e., re-pour) the zones — or the DRC refills them for you. When the zones are refilled, the vias you added for stitching become isolated from the zones and end up as little pads floating in space.

The problem and a workaround was discussed in a recent thread on the kicad-users mailing list. I wanted to summarize here the workaround in a slightly less terse way:

  1. Route the board and define your zones as you always have.
  2. Fill the zones as you always have.
  3. Select “Add tracks and vias” from the toolbar on the right.
  4. Click on an existing pad that’s connected to the zone’s net, drag the pointer a little bit to create a short track, then either (a) right-click and select “Place Via” or (b) type the ‘V’ shortcut.
  5. To add more stitching vias, continue to drag the pointer and type ‘V’ where you want to drop vias (or right-click and select “Place Via”).
  6. When you are done placing vias, hit the ‘End’ key on your keyboard (or right click and select “End Track”).

You can repeat this as many times as you want to create different clusters of stitches. When you refill zones, the vias will retain the connectivity information and work as expected.

Poor man’s code generator

A short time ago, I wanted to find a simple code generator that would run on Windows for helping me to maintain hand-rolled SPICE models files. I was a bit surprised to find none that were no-brainers to install or use. However, I did figure out that OpenOffice‘s mail merge feature can be used as a poor-man’s code generator. There’s more than one way to do it, but the process described at Worldlabel.com is the most straightforward for my brain. The key is to “print out” to several files or a single file–depending on what you are generating.

SPICE library management

The following post is all geekspeak. You have been warned.

I am trying to keep my SPICE modeling as platform and vendor-neutral as possible. To help with this, I have come up with the following structure for managing libraries. The idea is to have a file system, e.g.:

- models
    - diodes-inc
        - diodes
        - transistors
        - zeners
    - fairchild
        - transistors
    - onsemi
        - transistors

and in each category (i.e., subdirectory) store your individual model files. The file system, in addition to providing a structure to manage different kinds of parts from of different places, also helps to differentiate models for the same part from different sources.

Now here’s the fun part. So that I don’t have to have a million different .inc or .lib commands in the SPICE simulation’s source (one for each part I use, e.g.,

.lib C:\SpiceDev\models_raw\fairchild\transistors\MMBT2907A.lib

), I aggregate all the models in a given subdirectory into a single library file. Thus, C:\SpiceDev\models_raw\fairchild\transistors in addition to having several individual model files also has the file C:\SpiceDev\models_raw\fairchild\transistors\transistors.lib in it that is an aggregation of all the other files ending in .lib, .mod, or .sp3. So now if I want to use a Farchild transistors, I only need to include a single file:

.lib C:\SpiceDev\models_raw\fairchild\transistors\transistors.lib

Of course I don’t maintain the aggregate library file by hand. Instead I have written an AutoHotkey script that does the job. I place the script in a fixed place and then create links (i.e., shortcuts) to it from the directories containing the model files; but it will also work if you drop the script itself into the directory in which you want to make an aggregate library.

The script goes through each file in a directory (non-recursively) and if the file has a .lib, .mod, or .sp extension it appends its contents to a file named {directory-name}.lib . Both the extension of the output file and the list of aggregated input file extensions can be easily changed in the source code.

One important note: If you want to call the script using a shortcut, make sure the SetWorkingDir command in the code is commented out (as it is below) and also make sure the ‘Start In’ field for the shortcut is blank or points to the desired directory. Enjoy.

;
; AutoHotkey Version: 1.x
; Language:       English
; Platform:       WinXP
; Author:         Copyright (C) 2009 Mithat Konar
; License:        GNU/GPL2
;
; Script Function:
;	Copies contents of all files with extensions specified below into {directotyname}{outFileExtension}
;

#NoEnv  ; Recommended for performance and compatibility with future AutoHotkey releases.
SendMode Input  ; Recommended for new scripts due to its superior speed and reliability.
;SetWorkingDir %A_ScriptDir%  ; Ensures a consistent starting directory.

; To use with a shortcut, make sure SetWorkingDir command above is commented out and
; make sure the 'Start In' field for the shortcut is blank or points to the desired dir.

;===============================================================================
; user-set constants
;===============================================================================
outFileExtension=.lib	; the extension for the output (with dot!)
inExtList=lib,mod,sp3	; list of valid model file extensions (without dots!)

;===============================================================================
; "Main"
;===============================================================================
SplitPath, A_WorkingDir , outFile	; get the name of the active directoty. 

; use %outFile% as working file, then move to %outFile%%outFileExtension%
FileDelete, %outFile%					; just in case, we delete any old version now
FileDelete, %outFile%%outFileExtension%	; just in case, we delete any old version now

FileAppend, *======================================================================*`n, %outFile%
FileAppend, * Generated by %A_ScriptName% on %A_NowUTC% UTC from`n, %outFile%
FileAppend, * %A_WorkingDir%`n, %outFile%
FileAppend, *======================================================================*`n`n, %outFile%
Loop, *.*
{
	if A_LoopFileExt in %inExtList%
	{
		FileAppend, *** File: %A_LoopFileFullPath% ***`n, %outFile%
		Loop, Read, %A_LoopFileFullPath% , %outFile%
		{
			FileAppend, %A_LoopReadLine%`n
		}
		FileAppend, `n`n, %outFile%
	}
}
FileMove, %outFile%, %outFile%%outFileExtension%, 1
FileDelete, %outFile%

LTspice and tube models

Linear Technology’s LTspice is becoming quite popular among audio circuit designers, both professional and amateur. There is a lot to recommend it, but there is at least one issue that is crucial to be aware of if you are planning to use vacuum tube or other third-party models based on arbitrary behavioral voltage or current sources. And that is: LTspice’s implementation of arbitrary behavioral voltage or current sources is not completely SPICE 3 compatible.

In particular (from the LTspice help files),

LTspice uses the caret character, ^, for Boolean XOR and “**” for exponentiation. … This means that when you import a 3rd party model that was targeted at a 3rd party simulator, you may need to translate the syntax such as x^y to x**y or even pwr(x,y).

I ran into exactly this issue when experimenting with SPICE 3 versions of my own tube models.