Re: gEDA-user: General Layers questions

[Steven Michalske <smichalske@xxxxxxxxx>]

On Mar 18, 2011, at 4:17 PM, Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx> wrote:

> DJ Delorie <dj@xxxxxxxxxxx> 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.
> 
What you call a hole layer is what I consider the insulating layer.

Or do your hole layers span physical layers? Mimicking the ability of the process.  (required to make the blind and burried vias your design dictates)

Side note,  the full stackup is a core part of the pcb design and should be chosen at an early stage.  Meaning that all the materials are chosen and dimensioned.

An example is: a four layer board is two double sided boards with prepreg between.  Such that the top copper, fr4, and second layer are a hole layer.  The bottom copper, fr4, and third copper layer are the next hole layer.  And the third hole layer is the top copper all the way to the bottom copper?


> 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@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user


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