Re: gEDA-user: General Layers questions

[Steven Michalske <smichalske@xxxxxxxxx>]

On Mar 18, 2011, at 4:02 PM, DJ Delorie <dj@xxxxxxxxxxx> wrote:

> 
>>> 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.
> 
>>> 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)?
> 
> * A sub-circuit that's replicated N times on a board.
> 
> * 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.
> 
> * buried vias are limited to certain pairs of layers because of the
>  way the fab is assembling the board.
> 
> * 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.
> 
> 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.
> 
> Now consider a differential pair.  It's a line but you *don't* move
> the *line* endpoints, you move the *pair* control points.
> 
> 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.
> 

I read this as groups in the memory model should have a sort of locked flag,  so that tools like move don't dig deeper to move the individual parts of a group,  unless forced (unlocked).  And that groups need group control point(s)


>> 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.
> 
I see a load time generated list of objects in a layer.  That gets added to and removed from doubly linked to the composites the objects belong to.  This would allow the object to manipulate the list and for the list to get right to the object.

> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> 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