Re: gEDA-user: General Layers questions

[Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx>]

DJ Delorie <dj@xxxxxxxxxxx> writes:

>> > Except gerbers have special cases for thermals and pads, for example.
>> 
>> So there need to be attributes on shapes.
>
> No, the exporters really need to have access to the whole collection
> of shapes that means "pin" so they can do pin-specific things.  If the
> exporter doesn't need that high-level access, then the default action
> breaks it down into shapes and exports them individually.
>
> The gerber exporter needs to be given a whole "pin" because it has a
> command that means "put pin here, with this aperture and thermal
> settings".  If you wait until the core descends to "circle, arc,
> line", it's too late to look at the attributes and figure out what's
> happening.  CAM tools know about this, and can adjust thermals and
> pins as needed, but in PCB's case they can't do it because we break
> pins down into raw shapes.

I do not understand this.  The gerber exporter exports each layer
separately, no?  On some layer it finds a circle with a thermal
attribute surounded by a polygon.  What else does in need?

>> > and containing other layers as sub-layouts.  I have never disagreed
>> > with this!
>> 
>> Oh.  My understanding of composites is different.  I assume a composite
>> contains shapes that go on a global set of layers.
>
> This is part of the communication problem we're having, yes ;-)
>
> Consider these:
>
> * A footprint is a global resource, but an instance of a footprint (an
>   element) must be mapped to the physical layout.  When do you manage
>   the footprint as an element (indivisible) and when do you access its
>   parts (changing pad size)?

Is the footprint still part of the layout?  Wouldn't it's genereic
layers (top,inner,bottom) be mapped to the layout layers
(oben,innen1,innen2,unten) when imported?

> * A sub-circuit that's replicated N times on a board.

composites instances are objects inside other composites, next to
shapes.  You can do most operations to composites, that you do to shapes
(move, rotate, mirror, delete, ...).  Vias and elements are special in
the memory representation, as there are methods, or callback hooks that
allow access to some internals without explicitly decending into the
composit.  It should be possible to flag any composit as Element or vise
versa, to turn on and off this special access.  If you exlicitly decend
into an element, you can move its pins and pads.  But pads size, text
positions e.t.c. are still directly accessible for elements.  Maybe it
is not even necessary to have any special treatment and treat all
composites the same.

> * A flex cable that has 4 layers at each end, but only 2 layers in the
>   middle.  The extra layers on the end are on opposite sides of the
>   cable.

You want to describe the rigid ends as outlines of a composite?  That
attaches high-level semantics to a low level concept in an inapropriate
way.

Here you need outline layers with attributes that tell the autorouters
not to cross the lines on certain layers.

> * buried vias are limited to certain pairs of layers because of the
> way the fab is assembling the board.

A DRC problem.  With hole layers, the GUI tool to add/manipulate these
hole layers can provide a view on the layer stack that represents the
stacking and drilling order, just like you once proposed as an
underlying data structure.  The tool would refuse to configure holes
layers that cannot be drilled, unless you say "please".

> * 400 instances of a standard via, but the user needs to modify the
>   pad stack on just one of them, and only for one layer.

Vias may be COW by default, like they are now.  But you can decend in
non-copy mode into the composite, so they all change.  That composit is
also the master copy in the Via menu, so that future vias of that type
are affected by the edit.  When you edit the via definition in the Via
menu, you may need to answer a question if you want all existing
instances to change, of only new vias.

> These are all examples of a need for both a semantic and data
> heirarchy, where parts of your design are grouped together and treated
> as a single object, sometimes replicated, sometimes customized.  What
> we call them is not important.
>
>> Well, yes, it can, except that a via is not sufficiently special to
>> justify the distiction.  What would we have in a composite, the layout
>> being the top-level composite?
>> 
>>   Vias
>>   Elements
>>   Composits that are not Vias or Elements
>>   Lines
>>   Shapes outside of composits that are not Lines
>
> Consider: you can move a via, but for lines, you can move either the
> line or its endpoints.  For a polygon you can move its corners.  Ah,
> but a via can include polygons and lines - but when it's a via, you
> *don't* move their endpoints and corners, unless you specifically edit
> the via.  A pin is just like a via, except you *don't* move it - you
> move the element it's in.

shapes (lines and polys) in the current composite can be editied as
before, moved, endpoints moved, size, pcb:endcap attributes changed ...

Some internals of composites may be accessible, like clearances and
sizes, just as before. A composite attribute may define it its COW or it
all instances are changed.  Vias and Elemets are COW by default if past
behavious shall be kept.

When you want to change something inaccessibe inside a composite, you
can decend into it, either in copy mode or non-copy mode.  Everything
higher up than the edited instances may be grayed out on screen now. You
can also choose to only see the instance you are editing.  Now you can
manipulate, autoroute, ... the content of the composit.  There is your
footprint/via editor.

> Now consider a differential pair.  It's a line but you *don't* move
> the *line* endpoints, you move the *pair* control points.

That is a hard one.  You could define a composit of type "morphable" The
endpoints of shapes inside such a composite become pointable/selectable,
and a plugin can register callbacks to be called when such an endpoint
is manipulated.  The plugin would check to see if a "diffpair" attribute
is set, and decline the callback if not, so that the "magic_poly" plugin
has a chance.

> So yes, a via is special.  Many other composite objects will be
> special too, because the tools need to know what the appropriate way
> of interacting with them are.  PCB layout is *not* a paint program,
> it's a design tool.  It *must* understand "the design" if it's to be
> the most useful to the user.
>
>> When an how to map generic element layers to layout layers is
>> another good question.
>
> Yup.
>
>> Global layers can be mapped at load time.  Local layers inside
>> composits must be mapped a runtime, don't they?
>
> The mapping can be computed at load time, and just stored.  I suspect
> there'll be lots of "recurse through the data heirarchy" code.



... 21 new messages in my inbox

-- 
Stephan


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