Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote: > And your kind of bottom-up design never gets done at all, because of > impossible-to-meet requirements for unlimited flexibility. "My kind" of bottom-up design is precisely what Ritchie did when he invented C. Contrast C with PL/I, the language it replaced (at least in my world). C is designed to economically reflect the capabilities of the hardware on which it is based. PL/I was designed from "use cases" derived from existing programs in Fortran, Algol, and Cobol. The designers of PL/I were the world's leading experts on programming languages. PL/I was a conceptual mess, loaded with "features" that seemed useful and plausible, but which in real programs caused (at best) miserable inefficiency, and (at worst) seriously unpredictable behavior. These "features" included many kinds of high level constructs like string manipulation, I/O, and multitasking. In contrast, C represents the common features of the hardware in an open-ended way that allows programmers to extend the language by composition. So "PUT" is a language feature in PL/I, while printf() is a library function in C (itself written in C). That's good factoring, yielding unlimited flexibility. That good factoring also made C much easier to implement than PL/I. Proper bottom-up design *never* results in "impossible-to-meet requirements" because it starts from capabilities. What can a layered description of tame plane geometries (no fractals ;-) actually represent? Not so hard. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> Still, I do not see a need for outline layers anywhere, except as an >> attribute on a graphical layer that tells an exporter where to stop >> drawing. > > Hmmm... so you think PCB should let the user place an element in a > physically impossible location, because it doesn't care about the > outlines? currently it does, and I need that functionality. When I import a new batch of components from gsch2pcb, they get disperses in a big area outside the outline, because inside there is half the layout already done. In the end, it's a DRC problem, so yes, the DRC may look for a layer with an outline attributes. That layer shall have a separate attribute for the placement wizard plugin, although the message is almost the same. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie 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,
gEDA-user: [gschem] netname refactor?
hi, Is there any way in gschem (or gattrib) to refactor netnames in a given set of schematics? Thnaks, Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
On Sat, 2011-03-19 at 00:41 +0100, Stefan Salewski wrote: > > LMBD + LMBU over hot pin end: start new net segment > I mean: LMBD + LMBU over hot pin end or existing net end: start new net segment For starting a new net segment from void area we will have to activate net mode. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
> Of course I will support selection with a rectangular bounding > box. Does your "select-region" mean an arbitrary shaped area? No, I mean select rectangle. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
On Fri, 2011-03-18 at 19:47 -0400, DJ Delorie wrote: > > > Don't forget about select-region, select-touching, > > > select-touching-line, etc. > > > > I guess that is not too common in schematics? > > select-region is *very* common. > Of course I will support selection with a rectangular bounding box. Does your "select-region" mean an arbitrary shaped area? > select-touching-line would be really handy to select a group of angled > lines, without selecting the non-angled lines they're connected to. > Basically, you draw a line with the select tool, and anything that > line touches is selected. > Sure, this is a MODE we can implement -- currently I consider the most common actions, which should be accessible very easy, in best case only with the mouse, or with mouse and a modifier key. My goal is to prevent many mode switches. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
> > Don't forget about select-region, select-touching, > > select-touching-line, etc. > > I guess that is not too common in schematics? select-region is *very* common. select-touching-line would be really handy to select a group of angled lines, without selecting the non-angled lines they're connected to. Basically, you draw a line with the select tool, and anything that line touches is selected. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Hi all, I appreciate the discussion. There we nearly no objections to my layer concept, just to the via/footprint/composite. I have updated the page (http://geda.seul.org/wiki/geda:pcb_layers) and I hope it not reflects the 'opinion of majority'. So again. Coments are welcome, the discussion was a bit fast so I may have missed something important again. Thank you all for participating, Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 5:39 PM, DJ Delorie wrote: > >> It is the exporter's job to understand drilling. For geometry >> capture, all you need to know is the shape. Modules with no "need to >> know" should not know. > > The autorouter needs to know not to run traces across unplated > holes... Whether they are molded in, drilled, punched, ... A hole is a hole. It's part of the geometry. A drill is a drill. It's part of the fabrication machinery. These are distinct things. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
On Fri, 2011-03-18 at 19:17 -0400, DJ Delorie wrote: > > shift-leftclick on object > > Don't forget about select-region, select-touching, > select-touching-line, etc. > I guess that is not too common in schematics? Here is my current draft for my gschem clone: Peted intended user interface behaviour -- first draft -- LMBD: Left mouse button down (press) action LMBU: Left mouse button up (release) action MMBD: Middle mouse button down (press) action MMBU: Middle mouse button up (release) action RMBD: Right mouse button down (press) action Our intention is to have a smart AUTO mode which will allow to do the most common actions fast with minimal effort (beside traditional special modes like "Move", "Net", "Erase", "Line", "Arc", "Text", ...) These action include: Select, move, copy, delete, rotate, start new net. LMBD over element: Start moving element, LMBU will terminate action, element is unselected LMBD + LMBU over element (no motion): select element, unselect all other SHIFT + LMBD + LMBU over element: add element to selection CTRL + LMBD + LMBU over element: toggle element, leave other unchanged LMBD over unpopulated area: start selection rectangle No modilier: elements in rectangle will become selected, other unselected SHIFT modifier: add elements in rectangle to selection, other unchanged CTRL modifier: toggle state of elements in rectangle, other unchanged MMBD: put a copy of selected element(s) to position of mouse pointer special case: MMBD over selected element: detete it if nothing is selected or SHIFT modifier is used: panning RMBD: Context sensitive menu open Scroll wheel: rotate selection or element under mouse pointer If nothing is selected and mouse pointer is over unpopulated area or SHIFT modifier is used: Zoom in/out LMBD + LMBU over hot pin end: start new net segment Missing: Zoom into rectangle For element properties we will not use a popup window opened by double click, but a separate area at the left or right of the main window. Properties of selected elements are displayed in this area and can be modified. This area can be used for various other purposes, i.e. symbol library preview, color selections, ...It should be possible to fully shrink this area. At the bottom of the main window we may have an area for log messages. We should try to allow multiple instances of our GUI window, showing different or the same content. For the last case, we can display an overview in one window, while we work on details in a different window, maybe both windows can reside on different monitors. Of course it should be possible to use only one window, and switch between different content. Have I forgotten common important actions? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> It is the exporter's job to understand drilling. For geometry > capture, all you need to know is the shape. Modules with no "need to > know" should not know. The autorouter needs to know not to run traces across unplated holes... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 5:25 PM, DJ Delorie wrote: > You don't drill through ink. You drill through what the ink is *on*. > It's a semantic issue. If you want a spot where ink is missing, you > add an anti-circle there. It's different than a physical hole. It's > still a circle that removes things, but since we're designing a pcb > layout program, the semantic difference matters. It is the exporter's job to understand drilling. For geometry capture, all you need to know is the shape. Modules with no "need to know" should not know. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Still, I do not see a need for outline layers anywhere, except as an > attribute on a graphical layer that tells an exporter where to stop > drawing. Hmmm... so you think PCB should let the user place an element in a physically impossible location, because it doesn't care about the outlines? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> I do not like the concept of composit outlines. Does each layer >> have its outline? How does it do partial vias? > > In the case of flex cables, each layer *does* have its own outline. > The tool needs to know that vias go only across layers that actually > exist at that spot. I am the one who did flex cables with pcb, with six copper layes, three different outlines, four surface layers. It is going to fly to Mars later this year. http://www.ieap.uni-kiel.de/et/people/stephan/msl/eda/TFlex/TFlex.pdf http://www.ieap.uni-kiel.de/et/msl/pictures/photos/rsh/FM/TFlex/index.html To support such a beast in PCB you need multiple pairs of surface layers. Elements with pads on explicit layers is what fills this role, so that the pads of the flex edge connectors get connected to their (inner) copper layers. The outlines are just any graphical layers that can be exported without vias and pins. But the boardhouse had no problems ignoring the holes in the outline layers. Still, I do not see a need for outline layers anywhere, except as an attribute on a graphical layer that tells an exporter where to stop drawing. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Would and an 'outline' layer do for you? We can rename it so 'assembly' > layer or so. "assembly" has a specific meaning in CAM - it's a reference drawing, either to help the CAM engineer understand how your board is assembled, or to help with assembling the components to it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Sat, Mar 19, 2011 at 12:17:36AM +0100, Stephan Boettcher wrote: > But that's why I argue for hole layers. A hole is a shape on a hole > layer. The layers attributes define what needs to be drilled. > Actually, they only define to which layers they electrically conduct. > That is all the tools needs to know until checkout. DRC checks if all > shapes are circles, unless the shape has a DRC overide attribute. Would and an 'outline' layer do for you? We can rename it so 'assembly' layer or so. It will contain outline and holes, and via is just hole here(probably marked conductive). Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> > As general as neccessary, but not as general as *possible*. > > But we cannot know what is necessary. Well, we start by asking people who do pcb layouts what they need :-) "My point exactly. Do customers *want* portable fire?" > >> On top of that is a memory representation, that introduces the concepts > >> of elements, vias, surface-layers (layer sets: copper, mask, silk, > >> courtyard, keepout), connectivity, > > > > This is the part I wish we were discussing. > > As John said, bottom up works better in the long term :-) WE ALL AGREE ON THE BOTTOM! Gah! This is so frustrating! WE AGREE! Can we move on to the next step PLEASE? > Why not? The tool can move it arount and not much else, like with all > objects on a sliklayer. You don't drill through ink. You drill through what the ink is *on*. It's a semantic issue. If you want a spot where ink is missing, you add an anti-circle there. It's different than a physical hole. It's still a circle that removes things, but since we're designing a pcb layout program, the semantic difference matters. > I don't think that the concept of vias and elements shall be fully > implemented in plugins, for efficiency, > At least some callback hooks need to be specific to elements or > vias, that a plugin can register. So that a plugin can intercept > composite methods (e.g., move) for elements or vias. *That* is my point. "For efficiency" and "composite methods" means that we need some semantic middle-layer to our internal data. We can't say "it's just shapes" because that's not how the user interacts with the design. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 5:05 PM, DJ Delorie wrote: > >> Yes, sadly gEDA is a high productivity toolkit for spaceflight >> hardware, ASIC design, merging tabular design data with graphical >> design data, symbolic circuit analysis, and even hydraulics. > > No matter what I say, you'll find a way to disagree with me. Eh? I've already agreed with you on a couple of occasions just today. I only disagree with you when you're wrong ;-) > > I *meant* sadly, the results are THE ONES YOU NOTED - that each tool > interprets the data differently, leading to all sorts of > incompatibilities and assumptions about what the core data means. And to a degree this is inevitable across such a wide range of applications. The important thing for the future is to avoid *forcing* a limited interpretation of the data in the core functions. The problem, for example, with slotting in layout and simulation is that the common assumption in the core doesn't fit all cases. It would be easy to make it work compatibly if that common code didn't exist. It's exactly the opposite of what you're expressing here: spice-gdb can't handle slotting because it *cannot* apply the correct assumptions about what the core data means in its context. The core code forces an interpretation that's only valid for layout, not simulation. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> > I expect the plugin mechanism to be the way to write *all* the core >> > bits, though. >> >> The more important it is, that what is below the plugin mechanism is as >> general as necessary, and since that is difficult to judge up front: as >> general as possible, without compromising the final goals. > > As general as neccessary, but not as general as *possible*. But we cannot know what is necessary. >> On top of that is a memory representation, that introduces the concepts >> of elements, vias, surface-layers (layer sets: copper, mask, silk, >> courtyard, keepout), connectivity, > > This is the part I wish we were discussing. As John said, bottom up works better in the long term :-) >> It provides basic operations on these concepts. The implementation of >> these concepts builds on the objects of the storage data layers. It >> must not be an error if a via has two holes, a polygon shaped hole or >> silk in it. DRC may flag such things, but it must not be an error. > > There must be *some* limits, however, or the tools cannot be written. > Defining a "hole" in a silk layer is nonsensical, if you wish to > support it, we cannot define what the tools would do with it. Why not? The tool can move it arount and not much else, like with all objects on a sliklayer. But that's why I argue for hole layers. A hole is a shape on a hole layer. The layers attributes define what needs to be drilled. Actually, they only define to which layers they electrically conduct. That is all the tools needs to know until checkout. DRC checks if all shapes are circles, unless the shape has a DRC overide attribute. There would be one hole layer for each drill pattern, i.e., one, unless there are partial vias. John's insulating layers will be mentioned in the attributes, so they get drilled too. A via with variable hole size for different layers must be built as a composit with multiple holes on as many hole layers. Inefficient but appropriate for such an obscure case. >> The attributes that this memory representation and it methods >> understand shall be in namespace "pcb:" and unknown attributes in >> that namespace shall emit warnings. > > You assume that attributes are the way to organize groups of things. > Why? So that everything is just shapes on layers. Very simple, very powerful. >> Higher level parts of the concepts "element", "via", "surface layer" >> may be implemented in plugins. > > How does a move tool plugin interact with an element plugin, then? The memory core representation provides methods to move, rotate, mirror shapes and composits. (Element composits may have an attribute that forbids mirroring.) To bring an element to the other side od the board is method of the Element plugin, relying on attributes of the relevant layers how they map to the other side. I don't think that the concept of vias and elements shall be fully implemented in plugins, for efficiency, and since most other plugings may need refer to these concepts. At least some callback hooks need to be specific to elements or vias, that a plugin can register. So that a plugin can intercept composite methods (e.g., move) for elements or vias. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
> shift-leftclick on object Don't forget about select-region, select-touching, select-touching-line, etc. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multi-Select with SHIFT, CTRL...
Stefan Salewski wrote: > Is there a guide how multi-select should work for tools like PCB and > gschem? I have done a short google search and some test with PCB and > gschem, but I am not really sure that I fully grab it. > > I think we should have these actions: > Select leftclick on object or left_mouse_lasso > Add_To_Selection shift-leftclick on object > Subtract_From_Selection leftclick on selected object > Toggle IMHO, not implemented in PCB. In gschem it is control-left_mouse_lasso ---<)kaimartin(>--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Except that we'll argue forever if we can't agree on the words. I don't care about the words. I care about the ideas, the concepts, the use-cases. You throw "factored design" around like it's the solution to everything, but it's a meaningless term without a specific solution behind it. Unfortunately, PCB layout is a much more complex task than schematic layout, because the result *does* mean something in the physical world *as well as* meaning something in the symbolic world. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 5:02 PM, DJ Delorie wrote: > 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. Yes. Factored design. > What > we call them is not important. Except that we'll argue forever if we can't agree on the words. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> I do not like the concept of composit outlines. Does each layer > have its outline? How does it do partial vias? In the case of flex cables, each layer *does* have its own outline. The tool needs to know that vias go only across layers that actually exist at that spot. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Yes, sadly gEDA is a high productivity toolkit for spaceflight > hardware, ASIC design, merging tabular design data with graphical > design data, symbolic circuit analysis, and even hydraulics. No matter what I say, you'll find a way to disagree with me. I *meant* sadly, the results are THE ONES YOU NOTED - that each tool interprets the data differently, leading to all sorts of incompatibilities and assumptions about what the core data means. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> > 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. > 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. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Friday 18 March 2011, John Doty wrote: > Yes, sadly gEDA is a high productivity toolkit for > spaceflight hardware, ASIC design, merging tabular design > data with graphical design data, symbolic circuit analysis, > and even hydraulics. ROFLMAO ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
John Doty writes: > On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote: > >> Except, I see no need to specify any insulating layers here. > > "I see no need" is exactly the kind of thinking that produces an > inflexible, limited tool. I see *every* need to base the description > on geometry, so that the tool's limits are defined by necessity and > not by the limited imagination of any particular group of developers. Nothing prevents that you define insulator layers, and include shapes on these layers in your vias and elements. But for simple layout work its not needed. I did not miss them, yet. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> As someone proposed, it is possible to have different hole size on >> different layers. So I think the best would be to have special 'hole' >> object on each layer. And that object will always be in composite >> container, and all of them will be forcebly aligned to the same center. > > What I suggested before is that each composite itself have "outline" > type layers, which contains any holes, cutouts, or physical outline > shapes that need to be applied to all of the layers therein. composit instance overlap with other composits and shapes. I do not like the concept of composit outlines. Does each layer have its outline? How does it do partial vias? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote: >> >> In your sense, you have no idea what the "space of the possible" is >> for the integers. > > Of course I do. It's aleph null, the set of counting numbers. That's not the space of the possible, that's only the range of the abstraction. To know the space of the possible, in the sense you're arguing, you'd have to know every *application* of the integers. You can't know that. But still, you can represent the integers used in those applications as strings of digits. You don't need to understand the "space of the possible" *at all* to cover it! John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 01:18:16PM -0700, Steven Michalske wrote: > Embedded resistor and capacitors are in holes in the separating layers. > > Some separating layers are more like a solder mask and sprayed down > rather than FR4 and prepreg. > > Just because standard FR4 Fabs don't usually use any drawings on that > layer, should not preclude it. > > Now the exporter may barf if it finds something it can't cope with, > like a line drawn on a separator layer. As someone already proposed. We can fake it for now and do better when it becomes more common. You can define it as another 'physical layer' and have special footprints for it with. With fake pads in copper layer for example. I will try to take in mind that 'physical layer' can actually be a separation layer. But I hope the concept is flexible enought so I can add new typed layer easily later. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> > I expect the plugin mechanism to be the way to write *all* the core > > bits, though. > > The more important it is, that what is below the plugin mechanism is as > general as necessary, and since that is difficult to judge up front: as > general as possible, without compromising the final goals. As general as neccessary, but not as general as *possible*. > On top of that is a memory representation, that introduces the concepts > of elements, vias, surface-layers (layer sets: copper, mask, silk, > courtyard, keepout), connectivity, This is the part I wish we were discussing. > It provides basic operations on these concepts. The implementation of > these concepts builds on the objects of the storage data layers. It > must not be an error if a via has two holes, a polygon shaped hole or > silk in it. DRC may flag such things, but it must not be an error. There must be *some* limits, however, or the tools cannot be written. Defining a "hole" in a silk layer is nonsensical, if you wish to support it, we cannot define what the tools would do with it. > The attributes that this memory representation and it methods > understand shall be in namespace "pcb:" and unknown attributes in > that namespace shall emit warnings. You assume that attributes are the way to organize groups of things. Why? > Higher level parts of the concepts "element", "via", "surface layer" > may be implemented in plugins. How does a move tool plugin interact with an element plugin, then? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 4:34 PM, DJ Delorie wrote: > The problem with geda is that the lower leves are *so* flexible, that > there was no semantic consistency, no intrinsic model for the upper > levels to follow. The results were sadly predictable. Yes, sadly gEDA is a high productivity toolkit for spaceflight hardware, ASIC design, merging tabular design data with graphical design data, symbolic circuit analysis, and even hydraulics. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> Hide all composites with attribute "type=via". The GUI probably >> maintains an extra list of those, as well as a list of elements, for >> performance. > > Why the GUI? Why can't the core maintain that list, since a lot of > things will need it? I care a lot about performance. Sorry, yes, that's what I meant. But it's not in the disk file. >> Exporters can only export what they know about. All layers can be >> turned into gerbers. > > Except gerbers have special cases for thermals and pads, for example. > If you use the special cases, other CAM tools empower their users to > do more things (like auto-generate paste stencils when you forget the > paste mask, which does NOT work with pcb's gerbers). But for the > exporters to offer these special cases, they need to know more about > the data they're given than just "draw circle here". So there need to be attributes on shapes. >> At the bottom, a layout is a set of layers with attributes, >> containing shapes, maybe with attributes. > > 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. > What I disagree with is using this "at the bottom" information to > re-produce the semantic information inherent in a "pcb layout". I see > no reason why there can't be a semantic heierarchy to the data, so at > a high level we have a collection of "all vias" that's a child of > "this layout", so that the tools can find them easier and deal with > them as a group. 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 How the layers fit in here depends if they are global or local to a composit. I did not think about non-global layers yet. The set of global layers is the union of layers referenced in the hierachy of composits. When an how to map generic element layers to layout layers is another good question. And how to treat conflicting attributes of layers. I'd flag those as errors. Or define for each attribute lookup if the precedence goes from outside to inside, or from inside to outside starting at some shape. Global layers can be mapped at load time. Local layers inside composits must be mapped a runtime, don't they? >> The semantics of those attributes is what encapsulates the builtin >> knowledge how to make PCBs, and the tool must fully exploit that >> knowledge when presenting a layout to the user. > > Forcing tools to "fully exploit" data at too low a level makes it very > difficult to create such tools in the first place. The move tool > needs to know the difference between an element, a via, and a trace, > so it can function properly. We need to consider these types of > issues when designing the internal data structures, or it will be so > difficult to write the software that it just won't get done. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> The right kind of flexibility is even more important > to the developers than to the users. Since you're not a pcb developer, how can you know what the right kind of flexibility is? > In your sense, you have no idea what the "space of the possible" is > for the integers. Of course I do. It's aleph null, the set of counting numbers. Possibly the set of whole numbers, if you don't count negation as a separate operation. Plus or minus zero. > Yet all integers can be represented by strings of two digits. Not > much of a developer burden. It is if you're designing a watch. Offering the user a string of ones and zeros doesn't make a usable product. > Ales did an incredible job of representing the "space of the > possible" for schematics with a very clean bottom level. The > troublesome issues in gEDA come from upper levels that fail to > respect its generality. But there are far fewer issues there than > there are with pcb. The problem with geda is that the lower leves are *so* flexible, that there was no semantic consistency, no intrinsic model for the upper levels to follow. The results were sadly predictable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> If you mean 'physical layer' by 'composite', than yes. Each of those > will have it's 'outline' layer. I meant sub-assemblies. This is hard to describe because of the near-impossible list of things we want to support, but... There are two types of sub-assemblies. First, composite objects which are mapped to the physical board, and second, the physical board itself. So, a footprint is a composite sub-assembly that includes some holes, copper, cutouts, etc. It needs to be mapped to the physical board on-the-fly as we want to maintain it as "an object". But the PCB itself could have different numbers of layers at different locations, such as flex cable assemblies, and you could describe the stackup itself in terms of how the layers are put together (i.e. buried vias are drilled through a subset of layers, that subset has its own "holes" layer). In both cases, there's information about holes that applies to some subset of the layout. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> ... I think the tool we have is pretty good already. Very good. Thanks! > > The tool we have already is nearly impossible to maintain, though. > >> Please do not expect that users write plugins. The tool is already too >> good as it is to make is worth the effort to learn how to do that. > > I expect the plugin mechanism to be the way to write *all* the core > bits, though. The more important it is, that what is below the plugin mechanism is as general as necessary, and since that is difficult to judge up front: as general as possible, without compromising the final goals. I'd propose a very basic, very general storage data representation. Just layers, shapes, and arbitray levels of composites, the layout implicitly being the top level composit. Everything with arbitrary attributes. On top of that is a memory representation, that introduces the concepts of elements, vias, surface-layers (layer sets: copper, mask, silk, courtyard, keepout), connectivity, It provides basic operations on these concepts. The implementation of these concepts builds on the objects of the storage data layers. It must not be an error if a via has two holes, a polygon shaped hole or silk in it. DRC may flag such things, but it must not be an error. The attributes that this memory representation and it methods understand shall be in namespace "pcb:" and unknown attributes in that namespace shall emit warnings. The plugins define their own attributes. Attributes shall not be overloaded. If a plugin operates on attributes of the memory representation, it shall do that via methods of that representation, if possible. Higher level parts of the concepts "element", "via", "surface layer" may be implemented in plugins. I cannot keep up, there are 15 new messages in my inbox, lets see what what new arguments come up :-) I cannot make up my mind if I should continue to argue for hole layers, or if holes shall be shapes with hole attribute on layers. > The fact that the *user* can write them *also* is a side-effect :-) > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-85660 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 4:07 PM, DJ Delorie wrote: > >> That's the kind of "top down" design that produces a tool that meets >> today's requirements in the minimum amount of time, but produces an >> inflexible tool limited to those requirements. > > And your kind of bottom-up design never gets done at all, because of > impossible-to-meet requirements for unlimited flexibility. Absolutely not. The right kind of flexibility is even more important to the developers than to the users. > >> But if you start from a data representation that spans the space of >> the possible, it drives you toward flexibility and extensibility in >> the upper layers. > > The problem is, "the space of the possible" is infinitely large, and > we have a very small finite set of developers. Unless we know how the > tool is going to be used, we don't even know what "the space of the > possible" *is*. In your sense, you have no idea what the "space of the possible" is for the integers. Yet all integers can be represented by strings of two digits. Not much of a developer burden. Ales did an incredible job of representing the "space of the possible" for schematics with a very clean bottom level. The troublesome issues in gEDA come from upper levels that fail to respect its generality. But there are far fewer issues there than there are with pcb. Good, clean, simple, highly general foundations can *drastically reduce* the burden on the developer (been there). The most common cause of bad foundations, in my experience, is limited vision. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 05:58:29PM -0400, DJ Delorie wrote: > > > As someone proposed, it is possible to have different hole size on > > different layers. So I think the best would be to have special 'hole' > > object on each layer. And that object will always be in composite > > container, and all of them will be forcebly aligned to the same center. > > What I suggested before is that each composite itself have "outline" > type layers, which contains any holes, cutouts, or physical outline > shapes that need to be applied to all of the layers therein. If you mean 'physical layer' by 'composite', than yes. Each of those will have it's 'outline' layer. But I didn't wanted to have the 'hole' here, but now I don't see why. We can probably do that. The problem here is: How to recognice board 'outline' from cutouts? I don't want to draw the actual 'outline' to all physical layers if it is the same. So I cannot take 'the biggest one' as outline. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 10:40:02PM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > > On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote: > >> > >> > But if I am doing that (just to extend this silly example too far), I > >> > would want the DRC checker to ensure that it obeys both the rules for > >> > copper _and_ for silk. > >> > >> Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on > >> the other side of the CAM job? I.e. make DRC an exporter, so it gets > >> the layer mappings you want, and can apply rules based on the *mapped* > >> layers, not the *design* layers? > >> > >> That also lets us code the DRC rules in the CAM job file, so different > >> "jobs" check different rule sets. > > > > I am sorry, but I don't think this is a good idea. > > The DRC should work on the hierarchy. While the exporters will receive > > somewhat 'flattened' stackup. > > Absolutely not. The DRC shall check the final flat result. And yes, the > DRC should be a separate tool examining the CAM output. > > OTOH, some DRC functionality inside the layout tool is at least nice to > have, if not required, for doing life checks when editing. These will > probably never reach the coverage that a final checkout DRC should > provide. But that is a problem to write such a tool in the first place. The problem here is that it have to be possible to point out the problematic parts. So I guess it have to be able to flatten the hierarchy by itself and so I knows where the problem comes form. But I want to talk about DRC later.. DRC lives on top of layers and will need nearly no support from it. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> That's the kind of "top down" design that produces a tool that meets > today's requirements in the minimum amount of time, but produces an > inflexible tool limited to those requirements. And your kind of bottom-up design never gets done at all, because of impossible-to-meet requirements for unlimited flexibility. > But if you start from a data representation that spans the space of > the possible, it drives you toward flexibility and extensibility in > the upper layers. The problem is, "the space of the possible" is infinitely large, and we have a very small finite set of developers. Unless we know how the tool is going to be used, we don't even know what "the space of the possible" *is*. So I can grant you your wish right now - delete your pcb tree and you have the result of your design process. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 3:11 PM, DJ Delorie wrote: > >> But if I am doing that (just to extend this silly example too far), I >> would want the DRC checker to ensure that it obeys both the rules for >> copper _and_ for silk. > > Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on > the other side of the CAM job? I.e. make DRC an exporter, so it gets > the layer mappings you want, and can apply rules based on the *mapped* > layers, not the *design* layers? > > That also lets us code the DRC rules in the CAM job file, so different > "jobs" check different rule sets. Now you're talking! John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 3:31 PM, Stephan Boettcher wrote: > Except, I see no need to specify any insulating layers here. "I see no need" is exactly the kind of thinking that produces an inflexible, limited tool. I see *every* need to base the description on geometry, so that the tool's limits are defined by necessity and not by the limited imagination of any particular group of developers. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 3:09 PM, DJ Delorie wrote: > I feel that the data layer is easiest to implement, but it seems to be > what we're arguing about the most. I say we should ignore that > problem for now, until we have a better understanding of what we want > at the other two layers. That's the kind of "top down" design that produces a tool that meets today's requirements in the minimum amount of time, but produces an inflexible tool limited to those requirements. But if you start from a data representation that spans the space of the possible, it drives you toward flexibility and extensibility in the upper layers. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> As someone proposed, it is possible to have different hole size on > different layers. So I think the best would be to have special 'hole' > object on each layer. And that object will always be in composite > container, and all of them will be forcebly aligned to the same center. What I suggested before is that each composite itself have "outline" type layers, which contains any holes, cutouts, or physical outline shapes that need to be applied to all of the layers therein. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> I do not agree with the term high level here. I agree that there > may be layers of different types, that require special treatment. > These are low-level types, like "conductive" for layers that > electrically connect things, or "holes" for connections between > layers, and "other" for anything else. We're talking about the same thing, but what you call "low level" I call "high level", since I'm considering their place in the heirarchy of categorization (conductor -> copper -> 1oz copper, or drawing -> assembly -> courtyards), not the data structures they're implemented with. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 09:23:20PM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > Actually what I am trying to do, is to have concept so layers don't > > interract with layers of different type. The composits are a bit > > problem, because I would need to consider more layers when performing any > > action, but I think that it can still be interaction with object on the > > same layer. > > I do not understand what problems you see with composits. A layer > consists of the union of all shapes on any level of the composits > hierarchy. Composits may be referenced at multiple positions, so those > shapes appear multiple times. When a shape is modified in a composit, > it may affect all copies simultaniously, or the composit will be > duplicated (copy on write), depneding on an attribute or explicit user > action. I don't see problems, just need for special care. And I am glad that you mentioned the 'copy on write' and multiple reference. > > > So, i.e., If we would have 'hole' layer. I would have check, that holes > > on hole layer are not intersecting. And also check the intersection of > > attached shapes on each layer. But all what can happen is that some > > layer will yell that something bad happend and I should cancel my > > action. > > Where do you want to attach holes. To layers, like John proposes? To > shapes on a layer? Or as independent entities, like they are now? As someone proposed, it is possible to have different hole size on different layers. So I think the best would be to have special 'hole' object on each layer. And that object will always be in composite container, and all of them will be forcebly aligned to the same center. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> I don't want to end up with the current state that some 'specialy >> named' layers receive special treatment. > >>From a practical standpoint, I think it makes sense to have a fast way > to scan for layers of some high-level type, as well as further typing > them by name. I do not agree with the term high level here. I agree that there may be layers of different types, that require special treatment. These are low-level types, like "conductive" for layers that electrically connect things, or "holes" for connections between layers, and "other" for anything else. What kind of high-performance processing is needed in addition to that? Well, when you figure out that there is something else, it's a good justification to add anothe type. At the storage data level they are still all layers with attributes. When loading the layout, they are collected into separate lists, or get a binary attribute attached, by enumerating known values of the attribute "pcb:type=" > My original design had an enumerated type for each drawing layer, that > was one of (for example) "copper, silk, soldermask, paste, outline, > other" with flags for "normal, inverted" and an assignment to a > physical layer (1..N). > > That way, when you're doing something compute-intensive like > connectivity checks for "auto-enforce drc clearance" you aren't doing > a bazillion string compares. > > Actions that are performed less often, like mapping a footprint to an > element, can use a more open-ended string-attribute with more complex > rules. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec writes: > On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote: >> >> > But if I am doing that (just to extend this silly example too far), I >> > would want the DRC checker to ensure that it obeys both the rules for >> > copper _and_ for silk. >> >> Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on >> the other side of the CAM job? I.e. make DRC an exporter, so it gets >> the layer mappings you want, and can apply rules based on the *mapped* >> layers, not the *design* layers? >> >> That also lets us code the DRC rules in the CAM job file, so different >> "jobs" check different rule sets. > > I am sorry, but I don't think this is a good idea. > The DRC should work on the hierarchy. While the exporters will receive > somewhat 'flattened' stackup. Absolutely not. The DRC shall check the final flat result. And yes, the DRC should be a separate tool examining the CAM output. OTOH, some DRC functionality inside the layout tool is at least nice to have, if not required, for doing life checks when editing. These will probably never reach the coverage that a final checkout DRC should provide. But that is a problem to write such a tool in the first place. > And I want represent the resulting layer mapping somewhat in the > stackup, so the exporters will receive how are the layer ordered. > This should brink some code from the exporters to the core => less code. This kind of information shall be in the layer attributes. Ben-mode image export will need to know that. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> ... I think the tool we have is pretty good already. Very good. Thanks! The tool we have already is nearly impossible to maintain, though. > Please do not expect that users write plugins. The tool is already too > good as it is to make is worth the effort to learn how to do that. I expect the plugin mechanism to be the way to write *all* the core bits, though. The fact that the *user* can write them *also* is a side-effect :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes:
>> We are talking about different thinks, I guess.
>
> Probably.
>
>> The tool shall be very focussed on traces, elements, vias.
>
> To be this kind of focused, it needs to have some understanding of
> what a via is. You wouldn't want to invoke the via editor on a trace,
> but you wouldn't want the "move" option on a trace to not be able to
> move either the endpoints or the whole trace. Regardless of how the
> underlying data is stored, the tools need to organize the data in a
> way that helps them serve the user, and be aware of various levels of
> semantics that need to be applied to what would otherwise be
> meaningless groups of composites.
>
> For example:
>
> User level - a via is a connection between layers that I can add,
> remove, edit, and move around.
>
> Tool level - a via is an anonymous (i.e. not part of an element) hole
> between layers electrically connecting copper pads on each layer.
>
> Data layer - a via is a collection of N shapes on M conducting layers,
> with a collection of one or more shapes penetrating the insulators
> between those layers.
Except, I see no need to specify any insulating layers here. The data
does not care. It's the exporter that may care. If, for some
technology, the data does care, there will be a very special layer of
type "other" to make it care.
> I feel that the data layer is easiest to implement, but it seems to be
> what we're arguing about the most.
Yes. because ...
> I say we should ignore that problem for now, until we have a better
> understanding of what we want at the other two layers. The tool layer
> is going to be the hardest to design,
... I think the tool we have is pretty good already. Very good. Thanks!
> because that's where we blend flexibility with ease of use. Picking
> the right tool-level design will give us both flexibility and ease of
> use ("use" includes both the user and the plugin writer).
Please do not expect that users write plugins. The tool is already too
good as it is to make is worth the effort to learn how to do that.
It's good to know that is is possible when a real need arises, but that
will not be often the case.
--
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Hide all composites with attribute "type=via". The GUI probably > maintains an extra list of those, as well as a list of elements, for > performance. Why the GUI? Why can't the core maintain that list, since a lot of things will need it? I care a lot about performance. > Exporters can only export what they know about. All layers can be > turned into gerbers. Except gerbers have special cases for thermals and pads, for example. If you use the special cases, other CAM tools empower their users to do more things (like auto-generate paste stencils when you forget the paste mask, which does NOT work with pcb's gerbers). But for the exporters to offer these special cases, they need to know more about the data they're given than just "draw circle here". > At the bottom, a layout is a set of layers with attributes, > containing shapes, maybe with attributes. and containing other layers as sub-layouts. I have never disagreed with this! What I disagree with is using this "at the bottom" information to re-produce the semantic information inherent in a "pcb layout". I see no reason why there can't be a semantic heierarchy to the data, so at a high level we have a collection of "all vias" that's a child of "this layout", so that the tools can find them easier and deal with them as a group. > The semantics of those attributes is what encapsulates the builtin > knowledge how to make PCBs, and the tool must fully exploit that > knowledge when presenting a layout to the user. Forcing tools to "fully exploit" data at too low a level makes it very difficult to create such tools in the first place. The move tool needs to know the difference between an element, a via, and a trace, so it can function properly. We need to consider these types of issues when designing the internal data structures, or it will be so difficult to write the software that it just won't get done. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 05:09:09PM -0400, DJ Delorie wrote:
> User level - a via is a connection between layers that I can add,
> remove, edit, and move around.
>
> Tool level - a via is an anonymous (i.e. not part of an element) hole
> between layers electrically connecting copper pads on each layer.
>
> Data layer - a via is a collection of N shapes on M conducting layers,
> with a collection of one or more shapes penetrating the insulators
> between those layers.
>
>
> I feel that the data layer is easiest to implement, but it seems to be
> what we're arguing about the most. I say we should ignore that
> problem for now, until we have a better understanding of what we want
> at the other two layers. The tool layer is going to be the hardest to
> design, because that's where we blend flexibility with ease of use.
> Picking the right tool-level design will give us both flexibility and
> ease of use ("use" includes both the user and the plugin writer).
All I am right now trying to figure out is how to do the "Data level"
in the right way, so the "Tool level" has no obstructions in it.
And it seems that we got some kind of agreeament in that.
Martin Kupec
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 05:19:10PM -0400, DJ Delorie wrote: > > > I don't want to end up with the current state that some 'specialy > > named' layers receive special treatment. > > From a practical standpoint, I think it makes sense to have a fast way > to scan for layers of some high-level type, as well as further typing > them by name. The types I am trying to introduce are quite 'high-level' ones. And futher typing will be by attributes, and I can convert the most used ones to some nice internal representation. > > My original design had an enumerated type for each drawing layer, that > was one of (for example) "copper, silk, soldermask, paste, outline, > other" with flags for "normal, inverted" and an assignment to a > physical layer (1..N). > > That way, when you're doing something compute-intensive like > connectivity checks for "auto-enforce drc clearance" you aren't doing > a bazillion string compares. I don't want to use the names (strings) internaly at all. Just at import/export to file. Internaly it should all be pointer based structures. > > Actions that are performed less often, like mapping a footprint to an > element, can use a more open-ended string-attribute with more complex > rules. This will have to use names, but that should be 'less often' as you say. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 05:11:01PM -0400, DJ Delorie wrote: > > > But if I am doing that (just to extend this silly example too far), I > > would want the DRC checker to ensure that it obeys both the rules for > > copper _and_ for silk. > > Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on > the other side of the CAM job? I.e. make DRC an exporter, so it gets > the layer mappings you want, and can apply rules based on the *mapped* > layers, not the *design* layers? > > That also lets us code the DRC rules in the CAM job file, so different > "jobs" check different rule sets. I am sorry, but I don't think this is a good idea. The DRC should work on the hierarchy. While the exporters will receive somewhat 'flattened' stackup. And I want represent the resulting layer mapping somewhat in the stackup, so the exporters will receive how are the layer ordered. This should brink some code from the exporters to the core => less code. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> I don't want to end up with the current state that some 'specialy > named' layers receive special treatment. >From a practical standpoint, I think it makes sense to have a fast way to scan for layers of some high-level type, as well as further typing them by name. My original design had an enumerated type for each drawing layer, that was one of (for example) "copper, silk, soldermask, paste, outline, other" with flags for "normal, inverted" and an assignment to a physical layer (1..N). That way, when you're doing something compute-intensive like connectivity checks for "auto-enforce drc clearance" you aren't doing a bazillion string compares. Actions that are performed less often, like mapping a footprint to an element, can use a more open-ended string-attribute with more complex rules. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> That is up to the HID to find the composits with attribute >> "type=via", and present them in a via toll selector. > > I disagree with this. > > The HID is the Human Interaction Device - how the information is > presented to the user. GUI, printer, etc. > > The HID is the wrong place to be assigning *meaning* to the data. > That is still in the core. The fact that some composites are "vias" > is something intrinsic to the pcb design, independent of what color > you make it on the screen, and independend of how vias are implemented > at the lowest internal levels. Physical meaning is "here is a hole in the board", "here is a copper circle on layer 1". Those meanings appear in elements, vias, whatever. That a hole with concentric pads is a via has no meaning except for how those came to be. DRC does not care about vias. It cares about hole diameters and copper annulus. Connectivity also does not care about vias. Only the human in front of the screen cares about vias. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 01:52:38PM -0700, Jared Casper wrote: > On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote: > > At the design/edit level, that layer is a copper layer. Note to John: > > > And DRC freaks out because it has two separate incompatible sets of > > rules to apply to it. That is one of the things that causes me nightmares. I know that is should cause nightmares just to the DRC, but I can imagin that the set of rules will be even incompatible 'inside' the DRC checker. Like: This type of element is not considered in this layer, so just drop it. And add that same element to each of those elements because they are just there and it is not needed to draw them. This kind of thing can REALLY happen inside DRC checker. > > > > But if I am doing that (just to extend this silly example too far), I > would want the DRC checker to ensure that it obeys both the rules for > copper _and_ for silk. If those are incompatible sets then I have to > deal with the failed DRC for one of them because I am asking the tool > to do something that doesn't agree with with the DRC rules I have > asked it to check, but I would still like to know that is what I'm > doing. I can provide some 'copy on write' mechanism for copying one layer into another. But I still don't want to have two types in one layer. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> But if I am doing that (just to extend this silly example too far), I > would want the DRC checker to ensure that it obeys both the rules for > copper _and_ for silk. Hmmm... DRC is already fab-specific anyway. Maybe DRC should be on the other side of the CAM job? I.e. make DRC an exporter, so it gets the layer mappings you want, and can apply rules based on the *mapped* layers, not the *design* layers? That also lets us code the DRC rules in the CAM job file, so different "jobs" check different rule sets. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> But at the core, they work all just the same. > > The "core" includes the autorouters, optimizers, DRC, exporters, > reports, and even simple editing - we have a "hide vias" button. How > does that work if you no longer have "vias" as an inherent type? Hide all composites with attribute "type=via". The GUI probably maintains an extra list of those, as well as a list of elements, for performance. The autorouter is told to route on all enable conductive layers, and choose from a set of selected vias to go between those layers. Exporters can only export what they know about. All layers can be turned into gerbers. More complicated exports may need a technology description, like an advanced concept of the current layer groups. An exporter shall define a set of attibutes it expects to find on layers and objects to do its special deeds, and those attribute shall not be overloaded attributes that the core tool needs. > PCB has a lot of tools that know a lot about how PCBs are designed. > These tools are essential to making PCB a viable layout editor. The > input we need at this stage is from people who design a lot of PCBs, > so we know what kinds of abstractions make sense to expose and what > kinds need to be hidden behind other data structures. At the bottom, a layout is a set of layers with attributes, containing shapes, maybe with attributes. The semantics of those attributes is what encapsulates the builtin knowledge how to make PCBs, and the tool must fully exploit that knowledge when presenting a layout to the user. When we morph the current pcb towards such an abstract layer concept, the user shall not see the difference unless she activates the new features that become available with these concepts. > Maybe to the rendering engines they all work the same, but saying > "they all work the same" *in general* just isn't applicable here. > They don't. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 1:32 PM, DJ Delorie wrote: > >> But at the core, they work all just the same. > > The "core" includes the autorouters, optimizers, DRC, exporters, > reports, and even simple editing - we have a "hide vias" button. How > does that work if you no longer have "vias" as an inherent type? > Via the via tag attached to the generic composite that the via tool made. Sorry had to use the pun. > PCB has a lot of tools that know a lot about how PCBs are designed. > These tools are essential to making PCB a viable layout editor. The > input we need at this stage is from people who design a lot of PCBs, > so we know what kinds of abstractions make sense to expose and what > kinds need to be hidden behind other data structures. > > Maybe to the rendering engines they all work the same, but saying > "they all work the same" *in general* just isn't applicable here. > They don't. > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> We are talking about different thinks, I guess.
Probably.
> The tool shall be very focussed on traces, elements, vias.
To be this kind of focused, it needs to have some understanding of
what a via is. You wouldn't want to invoke the via editor on a trace,
but you wouldn't want the "move" option on a trace to not be able to
move either the endpoints or the whole trace. Regardless of how the
underlying data is stored, the tools need to organize the data in a
way that helps them serve the user, and be aware of various levels of
semantics that need to be applied to what would otherwise be
meaningless groups of composites.
For example:
User level - a via is a connection between layers that I can add,
remove, edit, and move around.
Tool level - a via is an anonymous (i.e. not part of an element) hole
between layers electrically connecting copper pads on each layer.
Data layer - a via is a collection of N shapes on M conducting layers,
with a collection of one or more shapes penetrating the insulators
between those layers.
I feel that the data layer is easiest to implement, but it seems to be
what we're arguing about the most. I say we should ignore that
problem for now, until we have a better understanding of what we want
at the other two layers. The tool layer is going to be the hardest to
design, because that's where we blend flexibility with ease of use.
Picking the right tool-level design will give us both flexibility and
ease of use ("use" includes both the user and the plugin writer).
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 2:55 PM, Stephan Boettcher wrote: > DJ Delorie writes: > >>> Inflexible wired-in behavior >> >> ... is MANDATORY if you're going to produce a tool that's usable. >> >> That's the difference between a pcb editor and, say, inkscape. >> >> Inkscape gives you complete flexibility, and it's absolutely useless >> as a pcb layout tool. >> >> You seem to be totally blind to the theory that you can have >> inflexible wired-in behavior *and* options for flexibility through >> alternate mechanisms. We need both - they are not mutually exclusive. >> We need a tool that's easy to learn and use *and* has options for >> power user. Your maniacal lobbying for "factoring" and "abstraction" >> would leave us with a tool that nobody would *want* to use. > > We are talking about different thinks, I guess. The tool shall be very > focussed on traces, elements, vias. But the engine at the bottom shall > be flexible. The user shall see this flexibility deep down in the > advanded options section of the via editor, where he will be told to go > when he asks for square via holes in this mailing list. Yes! John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 09:49:08PM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > Ok. We probably don't understand each other, so I will just state my fears. > > > > I would like to know about each drawing layer where it belongs to. > > > > So when I am performing DRC check, I will know, that it is conductive > > layer and I should consider it. I can take care of special DRC rules for > > some conductive layers later. > > So we do need layer specific DRC rules. Silk layers get the silk rules > attached. Copper layers get copper rules attached. Yes. That is not a problem. And later we can easily add 'drc rules' as layer attributes, so different layers of the same type will get a bit different DRC treatment. > > That is why I insist on 'typed' layers, not 'tagged' layer. > > As long as the user can define arbitrary types, the type becomes an > attribute. If the user cannot define new types, then there shall be > only very few very abstract types, connected to basic properies, e.g., > "conductive", "hole/via", "other". Partly. User will not be able to define new types. Because each type get's a different treatment in different parts of code. But I want have 'close to zero'(TM) inter layer interaction, so I will be easy to add new type. What I want to allow the user to do, is some 'tweaks' of layer types. Like 'silk:refdefs'. But this 'tweaks' will have to be coded in advance, the user will add just 'parameters' so it will start working. So 'silk:refdefs' is still commong 'silk' typed layer with special attributed 'refdefs' causing that 'refdefs' will magicaly go here and not to common 'silk'. We cannot stick with just the 'basic' layers. As i.e. countryard layers is basicaly non-conductive layers, but there are some special DRC check added. And those needs to be coded. I don't want to end up with the current state that some 'specialy named' layers receive special treatment. Internaly it will be probably just 'common' layer on most places and will receive special treatment on special places like now. But it should be a bit more 'obvious' what treatment and where it receives. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> Inflexible wired-in behavior > > ... is MANDATORY if you're going to produce a tool that's usable. > > That's the difference between a pcb editor and, say, inkscape. > > Inkscape gives you complete flexibility, and it's absolutely useless > as a pcb layout tool. > > You seem to be totally blind to the theory that you can have > inflexible wired-in behavior *and* options for flexibility through > alternate mechanisms. We need both - they are not mutually exclusive. > We need a tool that's easy to learn and use *and* has options for > power user. Your maniacal lobbying for "factoring" and "abstraction" > would leave us with a tool that nobody would *want* to use. We are talking about different thinks, I guess. The tool shall be very focussed on traces, elements, vias. But the engine at the bottom shall be flexible. The user shall see this flexibility deep down in the advanded options section of the via editor, where he will be told to go when he asks for square via holes in this mailing list. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:44 PM, DJ Delorie wrote: > >> But what if I want a silk layer to just be a copy of a copper layer? > > This is a different category of problem - the CAM job. Typically, > you'd have a file that describes how to map design layers to output > layers. In that file, you'd say "this copper layer should be output > as a silk layer also". Such a file could also say "copper objects > with the also-paste attribute should be drawn on the paste layer" etc. > Okay, but you are just moving the layer/object tags out to a separate file and process, the layers are still "tagged" so some extent somewhere. But I get your point. > At the design/edit level, that layer is a copper layer. Note to John: > And DRC freaks out because it has two separate incompatible sets of > rules to apply to it. > But if I am doing that (just to extend this silly example too far), I would want the DRC checker to ensure that it obeys both the rules for copper _and_ for silk. If those are incompatible sets then I have to deal with the failed DRC for one of them because I am asking the tool to do something that doesn't agree with with the DRC rules I have asked it to check, but I would still like to know that is what I'm doing. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> You can always tell the board house to use copper minus soldermask as > silk. That sounds like fun... Now I want to make a pcb plugin that copies all copper to the silk layer, but only where there's soldermask. You get a picture of your circuit in white-on-green, that actually works :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Jared Casper writes: > On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec wrote: >> If layers types would be defined by attributes, someone would be able to >> declare one layer both as conductive and as silk for example. That could >> cause me a nighmares. That is why I insist on 'typed' layers, not >> 'tagged' layer. >> >> That example is probably silly, but someone would probably come up with >> something more realistic, but still giving me nightmares. >> > > But what if I want a silk layer to just be a copy of a copper layer? > That may be just as silly, but I'm sure someone could come up with a > use for it. Why would such a layer cause nightmares? When the code > is worried about connectivity etc., it sees this layer is tagged as > conductive and includes it in whatever its doing, ignoring the fact > that it is also silk. When the code is putting out the silkscreen, it > notices this layer is tagged as silk and puts it out, ignoring that it > is also a conductive layer. You can always tell the board house to use copper minus soldermask as silk. > > Jared -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec writes: > On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote: >> Martin Kupec writes: >> >> > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: >> >> The file format need not know about these distictions. Both are >> >> graphical layers, with different attributes. The one has attributes to >> >> tell DRC to flag overlapping components, the other has attributes to >> >> tell some autorouter not to put copper there, and attributes to tell DRC >> >> to check for intruding copper. Future plugins need more layers to tell >> >> about different constraints. >> >> >> >> Ideally, any layer type is fully defined via attributes. The most >> >> common attribute may be "net:conductive" for normal copper layers, so >> >> that the HIDs know that the layer contributes to the implementation of >> >> the netlist. Copper layers need a second attribute "gbr:layer=inner5" >> >> to tell the (gerber) exporter where to put it. A third attribute >> >> defines the DRC rules that apply "drc:rules=default", plus per layer >> >> override "drc:minwidth=6mil". >> >> >> >> "drc:courtyard=front" >> >> "drc:keepout=front" >> >> "route:keepout=front" >> > >> > >> > That is a bit complicated. I need a clean definition of layer types, so >> > one can pick the right layer when needed. But some attributes in >> > addition to layer type are possible. >> >> I do not understand that argument. > > Ok. We probably don't understand each other, so I will just state my fears. > > I would like to know about each drawing layer where it belongs to. > > So when I am performing DRC check, I will know, that it is conductive > layer and I should consider it. I can take care of special DRC rules for > some conductive layers later. So we do need layer specific DRC rules. Silk layers get the silk rules attached. Copper layers get copper rules attached. > If layers types would be defined by attributes, someone would be able to > declare one layer both as conductive and as silk for example. That could > cause me a nighmares. Well, that would be a DRC violation :-) The DRC tool shall not suffer from nightmares if it finds positives. > That is why I insist on 'typed' layers, not 'tagged' layer. As long as the user can define arbitrary types, the type becomes an attribute. If the user cannot define new types, then there shall be only very few very abstract types, connected to basic properies, e.g., "conductive", "hole/via", "other". > That example is probably silly, but someone would probably come up with > something more realistic, but still giving me nightmares. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> But what if I want a silk layer to just be a copy of a copper layer? This is a different category of problem - the CAM job. Typically, you'd have a file that describes how to map design layers to output layers. In that file, you'd say "this copper layer should be output as a silk layer also". Such a file could also say "copper objects with the also-paste attribute should be drawn on the paste layer" etc. At the design/edit level, that layer is a copper layer. Note to John: We just call them copper. You can assume we mean "any conductive substance" but people get the idea more reliably if you use terms they're familiar with. > When the code is worried about connectivity etc., it sees this layer > is tagged as conductive and includes it in whatever its doing, > ignoring the fact that it is also silk. When the code is putting > out the silkscreen, it notices this layer is tagged as silk and puts > it out, ignoring that it is also a conductive layer. And DRC freaks out because it has two separate incompatible sets of rules to apply to it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 09:29:04PM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > > On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote: > >> > >> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: > >> > >> > Generaly you are proposing that there should be a special type of > >> > footpring called 'via' and it should receive extra care. > >> > >> Why single out "via" and "footprint" when they are merely members of > >> an open-ended list of possible composite objects? > > > > We need to single out 'via' so someone who want's simple board can find > > 'via' tool as everywhere. And under word 'footprint' I mean any other > > composite object. > > That is up to the HID to find the composits with attribute > "type=via", and present them in a via toll selector. > > And to maintein an in memory list of composits of "type=element" and akt > on those when the users asks for elements. Yes. With 'special care' I just ment in the GUI. Inside it will be a compsoite object like any other. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:32 PM, DJ Delorie wrote: > The "core" includes the autorouters, optimizers, DRC, exporters, > reports, and even simple editing - we have a "hide vias" button. How > does that work if you no longer have "vias" as an inherent type? > You go through and hide all the composites marked as a "via". For pcb to deal with vias differently doesn't mean that vias needs to be something fundamentally different than a footprint. On Fri, Mar 18, 2011 at 1:38 PM, DJ Delorie wrote: > The HID is the wrong place to be assigning *meaning* to the data. > That is still in the core. The fact that some composites are "vias" > is something intrinsic to the pcb design, independent of what color > you make it on the screen, and independend of how vias are implemented > at the lowest internal levels. >From my reading of this conversation there is a disconnect between what people are talking about w.r.t. words like the "core". Some are talking about the "lowest internal levels" where a via can just be another composite object. Some are talking about everything in pcb besides the gui, where do you need to distinguish a via from a footprint. While others seem to be using "gui" as everything but the "lowest internal levels" Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Steven Michalske writes: > On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote: >> On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote: >>> >>> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: >>> >>> >> Ok. So "via" should be a circle element on "hole" typed layer. >>> > >>> > No. A Via is a composit, consisting of a circle on the hole layer, and >>> > various circles on copper layers, and circles on mask layes, and >>> > thermals. >>> >>> The "layer" concept should be physical, not a metaphysical abstraction. >>> Objects in a layer may contain holes, but a "hole layer" is nonsensical, a >>> toxic conceptual shortcut. An "outline" layer is similarly bad: the >>> insulating layers may all have the same shape sometimes, but not always. >> >> The outline layer will be part of 'physical' layer. So if you have 2 >> 'physical' layers with different shape, it will play nicely. >> >> What I am prosposing is 2 level concept. There will be 'physical' >> layers, so you can add properties to them. And than there will be >> 'drawing' surfaces. And 'outline' is just drawing suface telling the >> 'physical' layer it's edges. >> >> But I am not convinced that we need special 'hole' typed layer. Maybe we >> can things like 'holes' which are not part of any specific layer just >> float in space. I thing that it would work. >>> >>> Trying to model things that aren't layers as if they were layers is one >>> common mistake in this kind of tool. Equally common is leaving out layers: >>> the insulating layers in a PCB are just as important as the copper, and >>> have their own properties (shape, thickness, material, etc.). They're a >>> critical part of the layer stack. >> >> The problem I see with the insulating layers is that there is nothing on >> them...So you don't need them as 'drawing' layers. But I agree that >> there should be a way how to add some attributes to them. > > > Embedded resistor and capacitors are in holes in the separating layers. > > Some separating layers are more like a solder mask and sprayed down > rather than FR4 and prepreg. > > Just because standard FR4 Fabs don't usually use any drawings on that > layer, should not preclude it. > > Now the exporter may barf if it finds something it can't cope with, > like a line drawn on a separator layer. If you have a foundry that does such things, probably you send them a gerber layer and tell them that those are the embedded resistors between copper 2 and 3. And that other layer are those between copper 5 and 6. No special exporter required. But you must keep the drawing layers a bit more abstract, else you confuse the tools that have invalid assumptions. The embedded resitors will be elements in a process specific library. Not top/inner/bottom layers, that get mapped to the layer present in the layout, but footprints with explicit layers. Including a shape on the resistive layer, and pads on the adjacent copper layers. The pcb layout tool will not need to know anything about those embedded devices. They just emerge and work. All you need is layers that are not marked conductive. And if those strange embedded deviced become common, somebody needs to add some DRC rules, which at that time are just a few boolean ops on some layers in a config file. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 01:20:43PM -0700, Steven Michalske wrote: > On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher > > The GUI must present footprints, vias, and hierachical sublayouts, both > > in copy on write and in truly hierachical fashion. But at the core, > > they work all just the same. Then there will be no more question if some > > feature is supported in elements or not, or how convoluted a via may be. > > > > I have had some convoluted vias for high speed signals. different > diameters on different layers, with different clearances from the > surrounding planes. And we really could have udes a DRC that checked > if the blind via ended on top of another signal trace. High speed > noise coupled on to that trace. That is still ok, to consider it as 'composite object'. There are just 2 problems. 1. The composite will really need different hole size on different layers. 2. There should be some clever DRC check added. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> That is up to the HID to find the composits with attribute > "type=via", and present them in a via toll selector. I disagree with this. The HID is the Human Interaction Device - how the information is presented to the user. GUI, printer, etc. The HID is the wrong place to be assigning *meaning* to the data. That is still in the core. The fact that some composites are "vias" is something intrinsic to the pcb design, independent of what color you make it on the screen, and independend of how vias are implemented at the lowest internal levels. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:23 PM, Martin Kupec wrote: > If layers types would be defined by attributes, someone would be able to > declare one layer both as conductive and as silk for example. That could > cause me a nighmares. That is why I insist on 'typed' layers, not > 'tagged' layer. > > That example is probably silly, but someone would probably come up with > something more realistic, but still giving me nightmares. > But what if I want a silk layer to just be a copy of a copper layer? That may be just as silly, but I'm sure someone could come up with a use for it. Why would such a layer cause nightmares? When the code is worried about connectivity etc., it sees this layer is tagged as conductive and includes it in whatever its doing, ignoring the fact that it is also silk. When the code is putting out the silkscreen, it notices this layer is tagged as silk and puts it out, ignoring that it is also a conductive layer. Jared ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> But at the core, they work all just the same. The "core" includes the autorouters, optimizers, DRC, exporters, reports, and even simple editing - we have a "hide vias" button. How does that work if you no longer have "vias" as an inherent type? PCB has a lot of tools that know a lot about how PCBs are designed. These tools are essential to making PCB a viable layout editor. The input we need at this stage is from people who design a lot of PCBs, so we know what kinds of abstractions make sense to expose and what kinds need to be hidden behind other data structures. Maybe to the rendering engines they all work the same, but saying "they all work the same" *in general* just isn't applicable here. They don't. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec writes: > On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote: >> >> On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: >> >> > Generaly you are proposing that there should be a special type of >> > footpring called 'via' and it should receive extra care. >> >> Why single out "via" and "footprint" when they are merely members of >> an open-ended list of possible composite objects? > > We need to single out 'via' so someone who want's simple board can find > 'via' tool as everywhere. And under word 'footprint' I mean any other > composite object. That is up to the HID to find the composits with attribute "type=via", and present them in a via toll selector. And to maintein an in memory list of composits of "type=element" and akt on those when the users asks for elements. >> > I am ok with that, I just need to figure out how to handle mapping from >> > footprint layers to layout layers. I don't want concept of 'top', >> > 'inner', 'bottom' layer at all...that is too naive for me. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 09:00:04PM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: > >> The file format need not know about these distictions. Both are > >> graphical layers, with different attributes. The one has attributes to > >> tell DRC to flag overlapping components, the other has attributes to > >> tell some autorouter not to put copper there, and attributes to tell DRC > >> to check for intruding copper. Future plugins need more layers to tell > >> about different constraints. > >> > >> Ideally, any layer type is fully defined via attributes. The most > >> common attribute may be "net:conductive" for normal copper layers, so > >> that the HIDs know that the layer contributes to the implementation of > >> the netlist. Copper layers need a second attribute "gbr:layer=inner5" > >> to tell the (gerber) exporter where to put it. A third attribute > >> defines the DRC rules that apply "drc:rules=default", plus per layer > >> override "drc:minwidth=6mil". > >> > >> "drc:courtyard=front" > >> "drc:keepout=front" > >> "route:keepout=front" > > > > > > That is a bit complicated. I need a clean definition of layer types, so > > one can pick the right layer when needed. But some attributes in > > addition to layer type are possible. > > I do not understand that argument. Ok. We probably don't understand each other, so I will just state my fears. I would like to know about each drawing layer where it belongs to. So when I am performing DRC check, I will know, that it is conductive layer and I should consider it. I can take care of special DRC rules for some conductive layers later. If layers types would be defined by attributes, someone would be able to declare one layer both as conductive and as silk for example. That could cause me a nighmares. That is why I insist on 'typed' layers, not 'tagged' layer. That example is probably silly, but someone would probably come up with something more realistic, but still giving me nightmares. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Inflexible wired-in behavior ... is MANDATORY if you're going to produce a tool that's usable. That's the difference between a pcb editor and, say, inkscape. Inkscape gives you complete flexibility, and it's absolutely useless as a pcb layout tool. You seem to be totally blind to the theory that you can have inflexible wired-in behavior *and* options for flexibility through alternate mechanisms. We need both - they are not mutually exclusive. We need a tool that's easy to learn and use *and* has options for power user. Your maniacal lobbying for "factoring" and "abstraction" would leave us with a tool that nobody would *want* to use. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec writes: > On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote: >> >> Trying to model things that aren't layers as if they were layers is >> >> one common mistake in this kind of tool. Equally common is leaving out >> >> layers: the insulating layers in a PCB are just as important as the >> >> copper, and have their own properties (shape, thickness, material, >> >> etc.). They're a critical part of the layer stack. >> >> >> >> The description language needs to be able to express "feature p in >> >> layer x is aligned with feature q in layer y" in order to build up >> >> composites. This is the geometrically sensible way to describe the >> >> result of drilling through several layers. But the geometric >> >> description language should not be tied to any particular fabrication >> >> procedure. >> > >> > This is all too physikal for my taste. >> >> I assert that if you do it any other way, you wind up with the >> following catastrophe: the code for every layer type needs to >> incorporate a specific definition of its interaction with the code >> for every other layer type. A total collapse of factoring, poisoning >> flexibility and maintainability. But if layers correspond to actual >> geometric layers, this can be avoided, I believe. What I like with PCB is that there is very little interaction. Only when special actions are called, the interactions are invoked. E.g., when I hit the O key, the connectivity is evaluated. For that I only need to know which layers are conductive and what vias connect which layers. > Actually what I am trying to do, is to have concept so layers don't > interract with layers of different type. The composits are a bit > problem, because I would need to consider more layers when performing any > action, but I think that it can still be interaction with object on the > same layer. I do not understand what problems you see with composits. A layer consists of the union of all shapes on any level of the composits hierarchy. Composits may be referenced at multiple positions, so those shapes appear multiple times. When a shape is modified in a composit, it may affect all copies simultaniously, or the composit will be duplicated (copy on write), depneding on an attribute or explicit user action. > So, i.e., If we would have 'hole' layer. I would have check, that holes > on hole layer are not intersecting. And also check the intersection of > attached shapes on each layer. But all what can happen is that some > layer will yell that something bad happend and I should cancel my > action. Where do you want to attach holes. To layers, like John proposes? To shapes on a layer? Or as independent entities, like they are now? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:11 PM, Stephan Boettcher wrote: > DJ Delorie writes: > >>> Why single out "via" and "footprint" when they are merely members of >>> an open-ended list of possible composite objects? >> >> Because a tool that doesn't deal with real-world concepts in a >> user-friendly way is unusable. > > Yes. The real world concepts must exist, in a higher level. In the > attributes. The HIDs must implement them in a user-friendly way. At > the lowest level, there shall be abstractions. > > The GUI must present footprints, vias, and hierachical sublayouts, both > in copy on write and in truly hierachical fashion. But at the core, > they work all just the same. Then there will be no more question if some > feature is supported in elements or not, or how convoluted a via may be. > I have had some convoluted vias for high speed signals. different diameters on different layers, with different clearances from the surrounding planes. And we really could have udes a DRC that checked if the blind via ended on top of another signal trace. High speed noise coupled on to that trace. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:40 PM, Martin Kupec wrote: > On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote: >> >> On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: >> >> >> Ok. So "via" should be a circle element on "hole" typed layer. >> > >> > No. A Via is a composit, consisting of a circle on the hole layer, and >> > various circles on copper layers, and circles on mask layes, and >> > thermals. >> >> The "layer" concept should be physical, not a metaphysical abstraction. >> Objects in a layer may contain holes, but a "hole layer" is nonsensical, a >> toxic conceptual shortcut. An "outline" layer is similarly bad: the >> insulating layers may all have the same shape sometimes, but not always. > > The outline layer will be part of 'physical' layer. So if you have 2 > 'physical' layers with different shape, it will play nicely. > > What I am prosposing is 2 level concept. There will be 'physical' > layers, so you can add properties to them. And than there will be > 'drawing' surfaces. And 'outline' is just drawing suface telling the > 'physical' layer it's edges. > > But I am not convinced that we need special 'hole' typed layer. Maybe we > can things like 'holes' which are not part of any specific layer just > float in space. I thing that it would work. >> >> Trying to model things that aren't layers as if they were layers is one >> common mistake in this kind of tool. Equally common is leaving out layers: >> the insulating layers in a PCB are just as important as the copper, and have >> their own properties (shape, thickness, material, etc.). They're a critical >> part of the layer stack. > > The problem I see with the insulating layers is that there is nothing on > them...So you don't need them as 'drawing' layers. But I agree that > there should be a way how to add some attributes to them. Embedded resistor and capacitors are in holes in the separating layers. Some separating layers are more like a solder mask and sprayed down rather than FR4 and prepreg. Just because standard FR4 Fabs don't usually use any drawings on that layer, should not preclude it. Now the exporter may barf if it finds something it can't cope with, like a line drawn on a separator layer. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 1:08 PM, DJ Delorie wrote: > >> I agree here, that a via and a footprint are essentially the same >> thing. > > Except the user doesn't interact with them the same way. > This is a UI representation, not a layer geometry issue. A via tool that makes the proper composite object and stamps it at a coordinate, is the via tool. Even if the UI is a script interface, a via macro in the layers file, or a GUI window and mouse pointer. A footprint tool takes the composite from a library and stamps it down. In the underpinnings the layers now has two composite objects, groups, or what ever you want to call it at two locations on the layout. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
DJ Delorie writes: >> Why single out "via" and "footprint" when they are merely members of >> an open-ended list of possible composite objects? > > Because a tool that doesn't deal with real-world concepts in a > user-friendly way is unusable. Yes. The real world concepts must exist, in a higher level. In the attributes. The HIDs must implement them in a user-friendly way. At the lowest level, there shall be abstractions. The GUI must present footprints, vias, and hierachical sublayouts, both in copy on write and in truly hierachical fashion. But at the core, they work all just the same. Then there will be no more question if some feature is supported in elements or not, or how convoluted a via may be. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> I agree here, that a via and a footprint are essentially the same > thing. Except the user doesn't interact with them the same way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:53 PM, DJ Delorie wrote: > >> Why single out "via" and "footprint" when they are merely members of >> an open-ended list of possible composite objects? > > Because a tool that doesn't deal with real-world concepts in a > user-friendly way is unusable. > User friendly is a subjective qualifier. IMHO: free rotate buffer is not user friendly. Where a group(collection) that has a specific rotation parameter is. > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 1:53 PM, DJ Delorie wrote: > >> Why single out "via" and "footprint" when they are merely members of >> an open-ended list of possible composite objects? > > Because a tool that doesn't deal with real-world concepts in a > user-friendly way is unusable. > I completely agree. So that's why clean composition machinery is needed, because *your* needs don't correspond to anybody else's, when it comes down to details. Inflexible wired-in behavior makes a mess (as in gschem's slotting "feature", for example). John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 12:52 PM, John Doty wrote: > > On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: > >> Generaly you are proposing that there should be a special type of >> footpring called 'via' and it should receive extra care. > > Why single out "via" and "footprint" when they are merely members of an > open-ended list of possible composite objects? > >> >> I am ok with that, I just need to figure out how to handle mapping from >> footprint layers to layout layers. I don't want concept of 'top', >> 'inner', 'bottom' layer at all...that is too naive for me. > > A general mechanism for describing composite objects is needed. > I agree here, that a via and a footprint are essentially the same thing. A via is a hole through some layers of the board and some copper bits on those layers, also known as a pad stack in some board packages. A footprint is traditionally a grouping of many pad stacks and additional layers. No real special treatment in the descriptions of the geometry. A group that origin is at x,y,rotation,layer Make a generic group (sub layout) concept and your good to go. A round via should have a rotation, it allows easy control of the thermals orientation. This is not to say that a special via macro could not be setup that makes the simplest traditional via or blind/buried vias. These groups should not be flattened into the layout until export, thus we loose the free rotate issue that we have today (lossy rotations). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 01:52:24PM -0600, John Doty wrote: > > On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: > > > Generaly you are proposing that there should be a special type of > > footpring called 'via' and it should receive extra care. > > Why single out "via" and "footprint" when they are merely members of an > open-ended list of possible composite objects? We need to single out 'via' so someone who want's simple board can find 'via' tool as everywhere. And under word 'footprint' I mean any other composite object. > > > > > I am ok with that, I just need to figure out how to handle mapping from > > footprint layers to layout layers. I don't want concept of 'top', > > 'inner', 'bottom' layer at all...that is too naive for me. > > A general mechanism for describing composite objects is needed. I agree. But we are trying to figure out how. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Martin Kupec writes: > On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: >> The file format need not know about these distictions. Both are >> graphical layers, with different attributes. The one has attributes to >> tell DRC to flag overlapping components, the other has attributes to >> tell some autorouter not to put copper there, and attributes to tell DRC >> to check for intruding copper. Future plugins need more layers to tell >> about different constraints. >> >> Ideally, any layer type is fully defined via attributes. The most >> common attribute may be "net:conductive" for normal copper layers, so >> that the HIDs know that the layer contributes to the implementation of >> the netlist. Copper layers need a second attribute "gbr:layer=inner5" >> to tell the (gerber) exporter where to put it. A third attribute >> defines the DRC rules that apply "drc:rules=default", plus per layer >> override "drc:minwidth=6mil". >> >> "drc:courtyard=front" >> "drc:keepout=front" >> "route:keepout=front" > > > That is a bit complicated. I need a clean definition of layer types, so > one can pick the right layer when needed. But some attributes in > addition to layer type are possible. I do not understand that argument. > Each element has a clearance attribute, so definition of extra space > around pads should be easy. But we can add 'keepout' layer in addition. > > Even when we would have more layer, it should be simplier to implement > them than some arbitrary flags. > > Defining DRC rules per layer is a bit different story and I hope it will > not be too closely related to changing of layer concept, as I don't want > to touch DRC. > > Martin Kupec > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 01:44:35PM -0600, John Doty wrote: > >> Trying to model things that aren't layers as if they were layers is > >> one common mistake in this kind of tool. Equally common is leaving out > >> layers: the insulating layers in a PCB are just as important as the > >> copper, and have their own properties (shape, thickness, material, > >> etc.). They're a critical part of the layer stack. > >> > >> The description language needs to be able to express "feature p in > >> layer x is aligned with feature q in layer y" in order to build up > >> composites. This is the geometrically sensible way to describe the > >> result of drilling through several layers. But the geometric > >> description language should not be tied to any particular fabrication > >> procedure. > > > > This is all too physikal for my taste. > > I assert that if you do it any other way, you wind up with the following > catastrophe: the code for every layer type needs to incorporate a specific > definition of its interaction with the code for every other layer type. A > total collapse of factoring, poisoning flexibility and maintainability. But > if layers correspond to actual geometric layers, this can be avoided, I > believe. Actually what I am trying to do, is to have concept so layers don't interract with layers of different type. The composits are a bit problem, because I would need to consider more layers when performing any action, but I think that it can still be interaction with object on the same layer. So, i.e., If we would have 'hole' layer. I would have check, that holes on hole layer are not intersecting. And also check the intersection of attached shapes on each layer. But all what can happen is that some layer will yell that something bad happend and I should cancel my action. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
> Why single out "via" and "footprint" when they are merely members of > an open-ended list of possible composite objects? Because a tool that doesn't deal with real-world concepts in a user-friendly way is unusable. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 18, 2011, at 1:44 PM, Martin Kupec wrote: > Generaly you are proposing that there should be a special type of > footpring called 'via' and it should receive extra care. Why single out "via" and "footprint" when they are merely members of an open-ended list of possible composite objects? > > I am ok with that, I just need to figure out how to handle mapping from > footprint layers to layout layers. I don't want concept of 'top', > 'inner', 'bottom' layer at all...that is too naive for me. A general mechanism for describing composite objects is needed. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
Generaly you are proposing that there should be a special type of footpring called 'via' and it should receive extra care. I am ok with that, I just need to figure out how to handle mapping from footprint layers to layout layers. I don't want concept of 'top', 'inner', 'bottom' layer at all...that is too naive for me. Martin Kupec On Wed, Mar 16, 2011 at 11:24:42AM +0100, Stephan Boettcher wrote: > Martin Kupec writes: > > > On Wed, Mar 16, 2011 at 02:42:26AM +0100, Stephan Boettcher wrote: > >> IMHO, .. holes are circles draw on just another layer. People were > >> asking for slots. If they find a vendor to do them, they may just draw > >> lines on that layer as well. Else, DRC shall flag non-circles. > >> > >> Each such hole layer shall have a spec (attribute) to which (copper) > >> layers they electrically connect. There will be at least one such layer > >> for each type of blind, burried, and through via. > >> > >> The GUI will happily stack vias according to the selected routing style > >> into a composites and paste them on the layout, so for simple cases > >> nothing changes from how we work now. > > > > Ok. So "via" should be a circle element on "hole" typed layer. > > No. A Via is a composit, consisting of a circle on the hole layer, and > various circles on copper layers, and circles on mask layes, and > thermals. > > A library (routing style) Via would have top, inner, (outer?), bottom > copper layers, which would be mapped to physical copper layers of the > layout according to some mapping, exactly as for footprints. > > In addition, some projects would have their own sets of Vias in a > library, where those circles are expressed explicitly for the physical > hole/coper layers of that board, for burried and blind vias, or special > annular ring config on certain inner layers. That library shall be > linked to some Via GUI to efficiently choose from. > > > That object will have some description to which "layers" of type cooper it > > belongs to. > > The hole _layer_ should have that description. The default connects to > all copper. Blind and burried vias require extra hole type layers, one > for each set of drill stacks. This information is needed for > connectivity checks mostly. Some DRC check may verify if the drilling > of the stacks is feasible. > > I think this is simpler and more flexible that DJs proposal: to > hierachically group (copper) layers into drill stacks. That would be a > John D violation, since it originates from a narrow view on how PCBs are > manufactured. It in no problem to reflect such a narrow view in a DRC > rule, but it is a mistake to cast it into the core data structure. A > HID may present the layers in such an arangement to the user. Said HID > may then proceed to add the required hole layers and Via types > automatically, after the user pushed the copper layers around as > required for the project. > > > And how would you describe the cooper around via on each layer? > > Someone wanted different cooper size/shape on different layers. > > > > Martin Kupec > > -- > Stephan > > > > ___ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Mar 16, 2011, at 11:09 AM, Stephan Boettcher wrote: > John Doty writes: >> >> The "layer" concept should be physical, not a metaphysical >> abstraction. Objects in a layer may contain holes, but a "hole layer" >> is nonsensical, a toxic conceptual shortcut. An "outline" layer is >> similarly bad: the insulating layers may all have the same shape >> sometimes, but not always. > > So, a via needs a separate hole in each copper and insulating layer? And > each layer needs its own discription of it's shape? Just as a program needs to know that every object in an array of integers is an integer. The composition machinery is responsible for keeping track: you don't need to declare each array element separately. > >> Trying to model things that aren't layers as if they were layers is >> one common mistake in this kind of tool. Equally common is leaving out >> layers: the insulating layers in a PCB are just as important as the >> copper, and have their own properties (shape, thickness, material, >> etc.). They're a critical part of the layer stack. >> >> The description language needs to be able to express "feature p in >> layer x is aligned with feature q in layer y" in order to build up >> composites. This is the geometrically sensible way to describe the >> result of drilling through several layers. But the geometric >> description language should not be tied to any particular fabrication >> procedure. > > This is all too physikal for my taste. I assert that if you do it any other way, you wind up with the following catastrophe: the code for every layer type needs to incorporate a specific definition of its interaction with the code for every other layer type. A total collapse of factoring, poisoning flexibility and maintainability. But if layers correspond to actual geometric layers, this can be avoided, I believe. > > Why are you so attached to the concept of drilling? I'm not. Indeed, I would urge our developers to purge the idea that a hole implies a drill from their minds when considering geometry. Export to instructions for a specific fabrication technology is a different problem from geometry capture, and in well factored software these will be kept separate. > For the design of a > layout, all that matters is that there are conductive connections > between layers. At the netlist level, that's all that matters. But at the layout level, it's geometry that matters. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Wed, Mar 16, 2011 at 06:09:25PM +0100, Stephan Boettcher wrote: > For me, a layer is something that the designer puts shapes on. Shapes > with atributes, if required. The semantics of these shapes on a given > layer shall all be the same. Some of these are required for netlisting, > some are steering the physical checkout. I agree with this one. We are just describing drawing surfaces and the meaning of elements on that sufrace are defined by type of that sufrace. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Wed, Mar 16, 2011 at 10:36:24AM -0600, John Doty wrote: > > On Mar 16, 2011, at 4:24 AM, Stephan Boettcher wrote: > > >> Ok. So "via" should be a circle element on "hole" typed layer. > > > > No. A Via is a composit, consisting of a circle on the hole layer, and > > various circles on copper layers, and circles on mask layes, and > > thermals. > > The "layer" concept should be physical, not a metaphysical abstraction. > Objects in a layer may contain holes, but a "hole layer" is nonsensical, a > toxic conceptual shortcut. An "outline" layer is similarly bad: the > insulating layers may all have the same shape sometimes, but not always. The outline layer will be part of 'physical' layer. So if you have 2 'physical' layers with different shape, it will play nicely. What I am prosposing is 2 level concept. There will be 'physical' layers, so you can add properties to them. And than there will be 'drawing' surfaces. And 'outline' is just drawing suface telling the 'physical' layer it's edges. But I am not convinced that we need special 'hole' typed layer. Maybe we can things like 'holes' which are not part of any specific layer just float in space. I thing that it would work. > > Trying to model things that aren't layers as if they were layers is one > common mistake in this kind of tool. Equally common is leaving out layers: > the insulating layers in a PCB are just as important as the copper, and have > their own properties (shape, thickness, material, etc.). They're a critical > part of the layer stack. The problem I see with the insulating layers is that there is nothing on them...So you don't need them as 'drawing' layers. But I agree that there should be a way how to add some attributes to them. > > The description language needs to be able to express "feature p in layer x is > aligned with feature q in layer y" in order to build up composites. This is > the geometrically sensible way to describe the result of drilling through > several layers. But the geometric description language should not be tied to > any particular fabrication procedure. I agree with this one. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: General Layers questions
On Fri, Mar 18, 2011 at 07:18:52PM +0100, Stephan Boettcher wrote: > The file format need not know about these distictions. Both are > graphical layers, with different attributes. The one has attributes to > tell DRC to flag overlapping components, the other has attributes to > tell some autorouter not to put copper there, and attributes to tell DRC > to check for intruding copper. Future plugins need more layers to tell > about different constraints. > > Ideally, any layer type is fully defined via attributes. The most > common attribute may be "net:conductive" for normal copper layers, so > that the HIDs know that the layer contributes to the implementation of > the netlist. Copper layers need a second attribute "gbr:layer=inner5" > to tell the (gerber) exporter where to put it. A third attribute > defines the DRC rules that apply "drc:rules=default", plus per layer > override "drc:minwidth=6mil". > > "drc:courtyard=front" > "drc:keepout=front" > "route:keepout=front" That is a bit complicated. I need a clean definition of layer types, so one can pick the right layer when needed. But some attributes in addition to layer type are possible. Each element has a clearance attribute, so definition of extra space around pads should be easy. But we can add 'keepout' layer in addition. Even when we would have more layer, it should be simplier to implement them than some arbitrary flags. Defining DRC rules per layer is a bit different story and I hope it will not be too closely related to changing of layer concept, as I don't want to touch DRC. Martin Kupec ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
