kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Thu, Sep 05, 2013 at 05:26:46PM -0700, Cirilo Bernardo wrote:
> > I think Tom's class is adequate. I don't think Brian S.'s idea about 
> > dynamically
> > assignable layer slots is optimal.  I think fixed layer slots are easier to 
> > code, but I
> > don't see why you have to limit the number of slots with Tom's 
> > approach.  You can have 300
> > layers if you want, but I think you need to pre-assign all of them, and chose 
> > not to use
> > but a subset of them on any board.

Exactly like my original approach.

> > I think fixed technical layer names are important, both to KiCad branding and to 
> > board
> > merging like JP mentioned.  Because these names are being indexed by google.

LOL... I've *never* tought about the google thing. However I agree with
JP (look in the past messages, I've already raised the issue) and also
proposed a solution (I admit is not simple) for the generic case.

> > This is part of why I don't want to mess with the technical layer names that 
> > are in place
> > already and why I yanked the international language translations for them.  

I think this is not correct for the user, at least in the UI he should
see its national names. I agree that it's better to handle the fixed
name for the special layers inside files.

> > a) specctra numbers copper layers from front to back, starting from zero.
> > 
> > 
> > b) in contrast, my most recent conversations with bare board houses in China had 
> > them
> > numbering layers from back to front, starting at 1 on the back.

And the problem is? Altium has separate numbering for signal and
coppers, for example... during fabrication for every not-trivial board
you have to submit a full stackup specification (with prepregs and so
on) containing the gerber names, anyway.

> > c) The internal copper bit masks for layers has always bothered me, the sequence 
> > that is.

Please elaborate on this. It's like the chinese numbering... what
bothers you in that?

> > d) Existing problematic code fragments should be identified early in the 
> > planning phase,
> > and any design change should be evaluated on its ability to handle the 
> > problematic code
> > collection.  Please start that problematic list with where I output the pretty 
> > layers, and
> > extend it by adding to it.

I haven't changed a line in the I/O routines since they pull names and
number from the layerset. The only problematic thing would be the .*
handling which is ad-hoc (and redundant anyway). Also the initial
stackup description obviously (*reading* it would be difficult)

> > If the result of the first implementation is that you do not depend on layer 
> > numbers
> > (much), but rather on names or range checking, then you can shift that 
> > enumeration at any
> > time in the future without causing the source code or existing data files any 
> > grief.

Mostly agree with that. It's the same as my proposal. However I think
that trying to fixedly enumerate all the possible layer from the start
is a lost battle. For non-special layers I think the Altium approach is
better if we want to 'fix' the number of layers.

> > These LAYERs and LAYER_SET are done using "Tom's 20 minute solution 
> > plus augmentation, as
> > needed".

I didn't look closely at that but why not simply use std::bitset then?

> > 
> > If you have based your files on concise English names for all but the Cu layers, 
> > but those
> > cu layers are also named, then I don't see any large grief to shift this 
> > conceptual
> > enumeration which runs from 0 - MAX_LAYER.  Not only can you make MAX_LAYER 
> > higher, but
> > you can also shift regions of interest within it without radically impact code 
> > or data
> > files later.

Inner1 and Inner2 are names, anyway... the new format always uses names
so it shouldn't be a problem; the layer numbering table at the beginning
would describe the bit allocation. AFAIK that change is already possible
(with the constraint of keeping copper layers adjacent); the only
nuisance is the ranging code in the layer selector (used *only* to
exclude the board borders) which would be a minor fix anyway.

In substance I think that if we can keep the things between
FIRST_COPPER_LAYER...LAST_COPPER_LAYER and
FIRST_NON_COPPER_LAYER...LAST_NON_COPPER_LAYER, nothing should break.
I would add a FIRST_USER_LAYER...LAST_USER_LAYER subrange reserved for an
Altium-like configurable range i.e. non special renameable user layers
(so adhesives, draw, comment, eco1, eco2 would fit in that as 'useful
defaults'). I already extracted all the pairing code so it only need
a way to store which user layer is paired with which (if it's paired).

Or, splurge another layer range number and have a range of front-back
front-back front-back user layers with fixed pairing and a range of non
paired user layers. That would be even simpler to handle.

-- 
Lorenzo Marcantonio
Logos Srl