← Back to team overview

kicad-developers team mailing list archive

Re: PCB Layer Stackup UI


jean-pierre.charras@... wrote:
Dick Hollenbeck a écrit :

Dick Hollenbeck wrote:

One idea to put on the table is an actual layer stack up sequence,

would be a modifiable data structure which defines the order of layers
within a board. The current notion of layer mask would stay, it's just
that a person could not assume that a layer with a mask of (1<<0) is
next to a layer with a mask of (1<<1) unless the layer stackup

says it is.


I rarely settle on the first idea, so here is another one to put on the
table. We make the BACK layer mask dynamic, not fixed. Its value would
depend on the copper layer count. If the copper layer count is 2, then
the BACK mask would be (1<<1), and the FRONT mask would be (1<<0). For
a four layer board the back mask would be (1<<3), etc.

Bit# Layer#
0 0 Front
N N Back

Advantage: no dynamic stackup sequence, but does have the dynamic

BACK mask. The order of the bits in the mask set would be reversed. I
do not think this one is hard to implement, the drawing code would
simply walk the mask in reverse from what it is now, starting at
position GetCopperLayerCount ()-1. We could fix existing board files
at time of first load, once and for ever after.

Eventually we can go to a 64 bit mask and expand the number of copper
layers quite easily, using a datatype of uint64_t.

For a single layer board, the notion of back or front is moot, because
the user can name the layer anything he wants.

Oops, I guess this is not a true statement since text is reversed, but
maybe a 'side' flag in this case is needed, or we make this kind of
boards simply have two sides, with one side being empty. All boards
actually have two sides anyways if you think about it.

For a single layer board
the layer mask would always be (1<<0)


Well, i am very interested to see a board that has really just *one* side...

Here are some thoughts:

I am not sure the layers mask is a good idea (well, i am sure this is a stupid idea).
This is rather a legacy of the early times of pcbnew.

Layers mask is used mainly for pads.
Vias use an other way: there handle a layer pair: the first and the last layer number.
And all others items uses just a layer number
Pads could use the same way to handle the copper layers they use. (SMD pads will just use the same first and last layer) The method IsOnLayer() could be used everywhere instead of the layer mask test. Others cases that use layers masks are mainly plot and print functions to know what layers must be plotted. In this case, this is easy to use an array of layers id to do this instead of a layer mask.

Removing the layer masks has some advantages:
- an unlimited number of copper layers
- no need to handle both layers masks and layers numbers (or layers id) (and no need to calculate layer mask from layer number and layer umbers from layers masks). And of course, solves your problem (the first layer and the last layer in all vias and pads instances in board could be easy to update when the layer could is modified)

I believe this could need less work (and could create less bugs) than changing the layers masks handling.

Remember also in the footprints libraries, the number of layers is not know, and therefore using a layer mask that depends on layers number is a problem.

In fact, we just must think about the way to handle non copper layers used in pads (solder mask, solder paste...) (a non copper layer id array ?) but i am pretty sure the work to code the layer pair handling in pads is less than changing layers mask handling, and remove bugs due to this change...

Having said this, I am thinking the best is to keep the current layer mask handling until the next stable release is done, and remove the layers mask from the pcbnew and the gerbview code after this release (and to give an unlimited number of copper layers handling in pcbnew and gerbview).
(of course, this also involves changes in pcbnew files format).

What are you thinking about this ?


I am thinking about it, and will study the code some more in the next couple of days/weeks. I am a little concerned about delaying the major changes. I have some time now, I and want to finalize the UI elements that I have committed to. I often do most of my contributions to Kicad over Christmas. I am not intimidated by the prospect of breaking something. It happens, but it happens not so much when I write the code. You might actually be surprised to learn about the software I write in my day job. One can argue that the purpose of a beta test cycle can be to wring out these problems (if any) and that we should use a release beta test cycle to our advantage in this regard. So I am not in favor of waiting for the changes, which would likely cause all the pending UI changes to have to be re-done. Besides, any remapping is no more complicated than what we already do in the specctra import and export. Having said that, I am not in favor of rushing to a solution either. I just want us to agree on a solution, then we should code it, done.

If we go this way, instead of committing to an unlimited number of layers, lets limit it to some number <=255, that way we can hold your layer numbers in a uint8_t byte array. Specctra DSN has a limit of 255 layers also. Maybe we could use bit 7 of the layer number as the non-copper flag. This way we could handle 128 non copper layers and 127 copper layers.

BTW, I do have some SMD footprints that have heat sinking copper pads on internal layers (all copper layers), complete with through holes to give the heat a pathway. Can something like this be done with layer numbers, without explicitly reserving *fixed* values for the starting and ending layer numbers and still maintain layer count independence? That is, if layer number for 'back' is non fixed, can a footprint like this truly be layer count independent? In specctra you'd have to give all layer numbers in the "padstack", and this inherently makes the footprint layer count dependent. Currently I believe these footprints may in fact be layer count independent, as you seem to suggest.

These are the kinds of things to sleep on. Maybe we should make a list of questions, and play devils advocate for a day.


Follow ups