kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Wed, Jun 04, 2014 at 03:35:05PM -0400, Wayne Stambaugh wrote:
> Backwards compatibility is not optional.  We should always be able read

Sorry my fault, I wasn't expressing properly. I meant "reading newer
file with older version". Of course newer versions must read older
files.

> This should be a good start to get the discussion moving in the right
> direction.

OK. Mmmh... first of all: do we introduce the concept of 'layer name',
as user visible/modifiable layer? In this way we could rid of the
'copper layer rename anomaly'. Layer 'tags' would remain F.Cu, B.Cu,
Inner1, and so on (I don't remember the default for inners, but that
should be the idea). These tags would be the same as the 'standard
english' names today, immutable.

New layer with behaviour would have significant tags (I have, for
example, B.Assembly/F.Assembly/B.Courtyard/F.Courtyard). The keepout
would have similar names *if* there were some special handling in pcbnew
for them, like DRC. Generic layers without pairing could be named
Custom1.User, Custom2.User and so on; generic paired layers would be
named F.User1/B.User1, F.User2/B.User2 and so on. I never get the
rationale behind the current names so it's just a proposal... these
would be simple drawing layers like Eco1 and Eco2; the name assigned
would be chosen by the user for the tag.

However, where would be the name decided? At board level, system level,
module level?

At the moment naming is done only at the board level. The modules always
uses the tag names. So even if I call in a board layer 15 'Front', for
modules it would be 'F.Cu'. However if I decide that F.User1 is,
maybe, peelable mask that wouldn't be seen in the module editor. This is
IMHO not good (it's the altium approach IIRC). A 'system level'
definition would be some kind of mapping in a config file. Too bad that
my colleague could use F.User1 for, like, plating information.

OK, then suppose we add the layer table to the module object. Quite
plausible. In my modules I have tag F.User1 with name 'Front Peel'. My
colleague would like to insert it in a board where F.User1 has name
'Front Plating'. What would happen?
Either a) it goes mismatched and you coat where you would have a peel or
b) it should go in another layer. Which one? A new one, or maybe in one
already called 'Front Peel', merging them?

Also my colleague is italian so it has named the layer 'Spellicolabile
Sup.'. Such a merge would fail and we would have both 'Spellicolabile
Sup.' and 'Front Peel'. Still a mess. As usual with localizable names:P

OK; change of plan. Custom layers have arbitrary tags (maybe with
a distinctive ".User" at the end, and the standard "F." or "B." for
paired layers, so they could be machine recognizable). *By convention*
this would be a common english name for them, like KeepOut or KeepOutZ.
Ideally, one would enumerate all of these in the world and make
a registry, but it's not plausible. However with common names for the
most used names conflicts would be reduced.

Mismatches simply wouldn't happen. I have a layer tagger F.Peel, he has
one tagged F.Plating. When he imports my module a new layer pair is
allocated. Fine. Everything works.

What about names? I think that these would only serve as a convenience
for the user, in the UI. By default they would be the *localized*
version of the tag name, if available (of course it will be available
only for the builtin ones). So the 'we want them translated' people are
happy. On import it would keep the existing name, if already present, or
otherwise use the one from the source. In the worst case I get the name
in the wrong language the first time, not too bad (ever received an
office document from another country? style names are in the 'wrong'
language, obviously). At least I have the tag and with a little english
(or simply asking the sender) I can fix the visible name...

Last thing of importance: how are these mapped to numbers? The little
table at the beginning would be useful only for the standard layers;
it's a starting point. The first 16 layers are always coppers, and the
other ones till 29 have a fixed meaning. IMHO there is way too much code
relying on this. I'd say that fixed layers are to be kept together at
the beginning. Now we have 29 of them. The #30 is the first custom
layer. They need to be dynamically allocated anyway to support merging.

Tomorrow we add courtyard and assembly as special layers. Ok, 33 layers
are fixed, #34 is the first custom one. It does *not* depend on the
file. Today I have my peel layers on 30/31, tomorrow is on 34/35. In
memory. Added bonus: no compaction needed for unused layer slots, it
happens the next time you load the file.

How to do layer slot allocation: first there would be some kind of table
mapping layer tags to number, and keeping layer names. Theorically more
than one: in the module editor, which table is in use? the current board
one or something local to the module? First thing to think really hard
about before implementation.

The only constraint to allocating slot numbers is the need to flip
layers, i.e. determine the paired layer number. For fixed layer it's
easy, they are enumerated. Single custom layers don't have the problem.
Paired custom layers need to be identified. Other operations are always
trivial IIRC.

Solution 1:
- Preallocate ranges:
  0-29 fixed layers
  30-37 single custom layers (8 of them)
  38-53 paired custom layers (8 pairs)

    Pros:
    - It's immediate to flip the layers, they always work that way
    - A reasonable number like this fits in 64 bits so no fancy bitvector
      is needed for the mask
    - Can get lazy in the UI since you know a priori layer allocation
    Cons:
    - Limited number of custom layers 
    - 'Wasted' bits in the bitmask (not really a problem, if they are
      few)

Solution 2:
- Dynamic 'layer descriptor':
  0-29 fixed laywers
  30-... free for all (the layer table must fully manage the associations)

  Pros:
  - No artificial limits  
  - More flexible allocation if we still limit to a total of 64 bits
  Cons:
  - Layer descriptor object (layer table) can get quite complex
  - Need to specify the layer descriptor each time you need to flip
    a layer, since you don't know otherwise where the pairs are

I don't think there would be performance implications in the choice
(flipping is not done often anyway). Also most of the time working on
a board is spent routing tracks and moving stuff, all of this layer
machinery only work when some kind of addition is needed (i.e. adding
a module). The custom layers are there only to be seen and plotted, in
fact!

This should be a start for discussing the requisites.

At last, I forgot: layer groups. I really have no ideas on these (simply
because I have no use case for them), I guess they could be another
structure in the layer table containing the tags (on file) or the
indices (in core) of the member layers. Defining behaviour on merge with
conflicting groups could be... interesting. Or maybe simply decide that
groups are a board-level only entity (i.e. layers simply starts
ungrouped if not already defined).


-- 
Lorenzo Marcantonio
Logos Srl