Re: gEDA-user: PCB suggestion

[DJ Delorie <dj@xxxxxxxxxxx>]

> PCB is not a drawing tool;

Actually, it kinda is.  Its drawing tools are flashes and traces, and
it uses them to make copper, silk, masks, and other datum.

> it understands things like design rules, connectivity etc. It makes
> no sense to have software to trace connectivity on the silk, mask,
> keepout, etc layers or to not be able to understand that metal layer
> DRCs are different from the silk layer, or to deal with elements
> having various "grouped" metal, mask, and silk features if all
> layers were arbitrary.

I think the overhead of things like DRC and connectivity selecting
layers with an is_copper flag is going to be less than the overhead of
dealing with a large number of special-cased layers for the common
cases of drawing, printing, and managing the data.  It's not much
different than having to deal with layer groups anyway.

And yes, we'd need a way of associating layers with coppers, or at
least marking them "top, bottom, inner, or other" (inners need
keepouts, for example, and "outline" is an "other").  We already have
layer groups and the component/solder flag, what I'm proposing isn't
that different.  I mentioned this privately before; I'm attaching my
original email here now that this discussion is here.  We were talking
about file formats, but layers were talked about too.


-------------------- archived message --------------------

> - >8 layers

I'm working on a patch to redesign the way we track layers internally,
so that we can support far greater than 8, and plenty of non-copper
layers.  Time is against me :-P

The resource format can handle any number of trace layers, even named
layers and layer groups, and still allow for arbitrary attributes on
each.  It's just a matter of choosing a schema and writing a loader
for it.

layergroups = (
  ("top" "topvcc" "topgnd" silk="topsilk" mask="mask4")
  "inner1"
  "ground"
  "vcc"
  ("inner2" keepout="ko2")
  ("bottom" "bottomvcc" "bottomgnd" paste="bpaste")
  keepout = "globalkeepout"
  outline = "outline"
  fab = "drawing"
)

layers = (
  top = ( ... )
  topvcc = ( ... )
  inner2 = ( ... )
  bpaste = ( ... )
  ...
)

(This example is far more flexible than what my patch would
accomplish).

> - some non-copper layers (keep-out, 1 per copper layer, 1 per silk),
> explicit soldermask relief layer, assembly layer

The patch covers that.  Each layer has a set of attributes (type, etc)
that tell you what it's for.  We'd need three keep-outs: top, bottom,
and inner.  Two each of the other outer layers (silk, mask, paste),
plus outline, fab, and annotations.

> - polygons in elements

No reason why elements can't be as robust as a PCB (silk, traces,
keep-outs, polys, etc).  Probably best to use the same data format.
Heck, use PCB as the component editor (not just "save buffer as
element" either).  Elements should have the pick-n-place info as part
of the element.

Elements can be defined similarly to PCB layers, relative to a "top
upright" placement:

(elements
  (R41 value="47k" description="foobar"
    units = mil
    centroid = (56 17)
    pins = (
      (1 x=0 y=100 square)
      (2 x=10 y=100)
      (3 x=20 y=100)
    )
    text = (
       (%value 14 17 size=10 rot=90)
       (%description 34 17 size=10 rot=90)
       (%refdes 54 17 size=10 rot=90)
       ("some text" 74 17 size=5 rot=90)
    )
    layers = (
      copper = (...)
      silk = (...)
      keepout = (...)	  (top side copper)
      bottom = (...)	  (copper on other side of board, like heatsinks)
      inner = (...)	  (copper inside, likewise)
      botkeepout = (...)  (er, keep traces out from inner/under)
      fab = (...)         (extra stuff for fab drawing)
      outline = (...)     (extra cutouts needed for component)
    )
  )
)

We'd have to, of course, map the named layers to the
layergroup-defined layers, and the logic for enumerating "things on a
layer" would get more complicated.  Probably want to switch to an
iterator type to hide the mess.

> - storing a rotation (helps the centroid data maybe work a bit nicer)

Arbitrary attributes are trivial in resource format, and forward and
backward compatibility is assured as it's free-form.  The rotation
attribute fits nicely with the next problem's solution...

> - do-not-modify flag (different from locked).  This would say "this element
> is critical, don't modify it internally but allow it to move".

I always wondered why we didn't already have that.  Elements should be
idempotent unless you specifically ask to edit the element itself.
Kinda like a composite - you either treat it as a single unit, or edit
it separately.  An "element" should have three attributes - location,
side, and orientation.  You don't touch the rest until you're editing
the element itself (well, except for the obvious connections-to-pins,
pin-info, etc.)