Re: gEDA-user: next PCB release - 1.99za vs 4.0

[Steven Michalske <smichalske@xxxxxxxxx>]

   On Sep 12, 2010, at 12:29 PM, Andrew Poelstra <[1]asp11@xxxxxx> wrote:

   On Sun, Sep 12, 2010 at 01:56:43PM -0400, DJ Delorie wrote:

     Alright, we'll allow a "top and bottom" layer group.

     With flex cable, "top" and "bottom" aren't limited to one layer
     each.

   Aren't they? All layers except the top-most and bottom-most are
   considered "inner" layers. This whole top/inner/bottom thing is
   convienence for mapping footprints, and footprint mapping can
   be changed after-the-fact for weird use cases.
   What does it mean to have two "top layers"?

     I think that if we want components on multiple layers (or all

     layers), that should be a property of the component, not a layer

     group/physical layer thing.

     What's the difference?  It has to be implemented somehow.

     Well, I'm trying to implement this, so "somehow" matters to me ;).

     Either we have one loop that filters layers by need, or a nested
     pair

     of loops.  Same complexity.  How do you handle layers that aren't

     assigned to physical layers?  Like documentation layers?  What about

     layers that apply to more than one physical layer, like outers or

     inners, or all?  A tree structure ties you down to a specific
     physical

     structure, a list does not.  What about buried vias?  Do they go on
     a

     special layer that spans physical layers?

   It's not the same complexity. Filtering layers by need requires
   filtering
   through all the layers - a tree structure is much more efficient for
   accessing specific layers.
   "Outers" is a special case. "Inners" and "multiple layers" should be
   handled on a per-element basis; vias (or anything) can be assigned to
   more than one drawing layer, which in turn map to physical layers.
   What use case is there for layers that map to multiple physical layers?
   I did not consider layers that are not mapped to physical layers,
   except
   the rats layer. I think the best way to do this would be to have
   another
   class of layer group:
    Top, Bottom, Inner, Outers, None

   None is a bad name,  Documentation

     I disagree. If physical layers can contain multiple drawing layers
     (and

     they must, to keep silk and copper layers separate), it makes sense
     to

     have a rigid structure. Then we can display the layer selector in a
     tree-

     like display and it is clear to everyone what is what.

     Internal structure and what we present to the user are two different

     problems.  Yes, we need to keep track of the physical stackup.  No,

     that does not need to dictate our internal structure.

   They are different problems, but they are closely related. If our
   presentation
   layer is obscenely inefficient because our backend isn't appropriate,
   that is
   a problem.

     [2]http://download.wpsoftware.net/code/pcb/layer.h

     I would add a LayerPos to each Layer, and store the Layers
     separately.

      1. At the top level, each PCB has a layer stack. This is the
     ordered

         list of physical layers, plus one "internal" layer that is never

         saved out or edited. (For now, this will contain the ratsnest
     layer

         and nothing else.)

     Why one?  Why not save it?  We already save rats to file.  What
     about

     layers that don't correspond to a physical layer?

   Why have a different number than one? I could not think of a good
   reason
   for this.

      3. Each drawing layer has a type associated with it - one of COPPER

         (conductive), SILK (non-conductive) or INTERNAL (not saved out:

         DRC highlights, etc, will be on such a layer).

     paste mask keepout fab drill notes

   Noted.

   Not all layers will be copper.  Use conductor and the conductor then
   has the metal type attribute attached.  As I think of silver ink
   flexes.

     Why not save DRC highlights?

   You're right, we should be saving everything.

      4. TODO: There is no way to do keepouts. I have heard arguments for

         allowing global keepouts, per-layer keepouts, per-function-block

         keepouts, etc, and I don't know how it should be structured.

     keepouts are just another layer.  Let DRC worry about what to do
     with

     it.

   Ah, but what happens when you want a keepout on all layers? On one
   layer?
   For only HV lines? For footprints but not traces? All these have been
   mentioned on the list, and don't work well with "keepouts are just
   another
   layer".

   Layers with attributes here are a solution.  The drc reads in the
   attribute and decide what to do.  Oh this drc layer says Blah, another
   says foo.

   Andrew
   _______________________________________________
   geda-user mailing list
   [3]geda-user@xxxxxxxxxxxxxx
   [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

References

   1. mailto:asp11@xxxxxx
   2. http://download.wpsoftware.net/code/pcb/layer.h
   3. mailto:geda-user@xxxxxxxxxxxxxx
   4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user