DJ Delorie <d...@delorie.com> 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user