kicad-developers team mailing list archive

[Chris Giorgi <chrisgiorgi@xxxxxxxxx>]

On Tue, Nov 13, 2012 at 7:57 PM, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 11/13/2012 05:33 PM, Chris Giorgi wrote:
> > Good afternoon,
> >
> > I've been glancing at this thread on&off for a while and have and have
> an observation
> > and suggestion.
> >
> > A board has a distinct set of lamination layers:
> >     Front
> >     Inner 1
> >        :
> >     Inner n
> >     Back
> >
> > Each lamination may have one or more physical materials or operations:
> >     Substrate, Copper, Adhesive, Solder Paste, Solder Mask, Silk Screen,
> Drill, Place
> > Parts, Probe, etc...
>
> A real board does, yes.  But in the software each of the above is a
> "layer", so the
> paradigm you are proposing does not match, nor does it help in the
> reduction of dope
> associated with pads, measured in total text length.
>
> In this thread, mostly we are trimming pad descriptions down with this,
> since we do not
> have padstack support.    This *.kicad_pcb and *.kicad_mod effort now is
> merely a file
> format conversion, to improved readability.  There is no change being made
> at this time to
> internal BOARD data structures as a result of this current work.


Dick,
  I was suggesting only a consistent naming scheme for the (logical) layers
based on the physical layering and materials. Internal representations
would not need to change at all, and the resultant names are similar, if
not identical to those suggested by Wayne in most cases. For conciseness
and clarity, I would suggest types labeled "Cu", "Adh", "Paste", "Silk",
"Mask", "Draw", "Cmnt", and "Edge". Symbolic layer positions include "F" or
"Front" for the first defined (0), "B" or "Back" for the last defined (N),
"I" or "Inner" followed by a number for 1 - (N-1), and "G" or "Global" for
items not residing on a specific physical layer.

"Front"     -> "0.Cu"    = "F.Cu"    = "Front.Cu"
"Inner1"    -> "1.Cu"    = "I1.Cu"   = "Inner1.Cu"
"Inner{n}"  -> "{n}.Cu"  = "I{n}.Cu" = "Inner{n}.Cu"
"Inner14"  -> "14.Cu"  = "I14.Cu" = "Inner14.Cu"
"Back"     -> "15.Cu"  = "B.Cu"   = "Back.Cu"
"Adhes_Back" -> "B.Adh"
"Adhes_Front" -> "F.Adh"
"SoldP_Back" -> "B.Paste"
"SoldP_Front" -> "F.Paste"
"SilkS_Back"  -> "B.Silk"
"SilkS_Front"  -> "F.Silk"
"Mask_Back"  -> "B.Mask"
"Mask_Front"  -> "F.Mask"
"Drawings" -> "G.Draw"
"Comments" -> "G.Cmnt"
"Eco1" -> "G.Eco1"
"Eco2" -> "G.Eco2"
"PCB_Edges" "G.Edge"

Parsing would be very straightforward and the format I proposed would allow
for very concise representations of more complex pad structures, such as a
thermal via connected to the front, back, and 2nd and 4th inner copper
ground layers in an 8 layer board -- eg. 0+I2+Inner4+Back.Cu .

Parsing (wild stab):
  - Split at "." as L, T ( L="0+I2+Inner4+Back", T="Cu")
  - Handle wildcards in L, T. ("*" -> Array containing all defined values,
skip tokenizer)
  - Tokenize L by replacing symbolic names with numeric identifiers (
L'="0+2+4+7" ) (First letter and number is unique)
  - If we have ranges, replace with included values (i.e. "0-2+4" ->
"0+1+2+4").
  - Dump into an array L'' = [0,1,2,4]
  - Treat T similarly (T' = "Cu") (i.e. "Eco1-3" ->
"Eco1+Eco2+Eco3", "Mask1+2+Paste" -> "Mask1+Mask2+Paste").
  - Lookup indices for T and dump into an array T'' = [5]
  - Iterate L'' and T'', marking each layer as a bit in a field, or however
it's represented internally.
(pseudocode: for (l in L'') { for (t in T'')
{ layers.setbit(layer[l][t]]) } )

In my opinion, the results would be concise, while remaining readable and
possibly allowing for forward compatibility. Looking back at the above, I
wonder if it might make more sense to reverse the order --
{Type}({Idx.})(.{LayerPosition}) -- giving us "Cu.F", "Adh.B",
"Silk.Front", "Cu.3", "Eco1", "Cu.In2", and "Draw", which I find slightly
more readable.

~~~Chris Giorgi~~~