Re: gEDA-user: Christmas wishlist

[Levente Kovacs <leventelist@xxxxxxxxx>]

On Sat, 25 Dec 2010 10:10:16 +0100
Stephan Boettcher <boettcher@xxxxxxxxxxxxxxxxxx> wrote:

> 
> Merry Christmas!

Same to you and to the community!

> == PCB wishlist ==
> 
> The recent (and some not so recent) discussions made me think about
> how development of PCB could proceed to solve some of the feature
> request, in a future-proof way.  This is what came up in my mind.
> 
> === Make all layers explicit ===
> 
> Everything shall be layers. Silk, paste, mask layers shall be exlicit.
> 
> Via-layers typically only contain filled circles, the holes.  A
> via-layer defines to which subset of other (copper) layers it connects
> to.  A Via is a hole on a via layer plus copper circles on all copper
> layers.  Vias-layers will probably not be implememted before macros
> (below) are available.  Until then, they may be special case macros,
> like they are now.
> 
> The old layergroup mechanism will be replaced by defining for a copper
> layer to which other layers it electrically connects, in the same way
> as a via-layer does.
> 
> File format/connectivity does not require different layer types.
> There is no difference between via-, copper-, graphical layers.  Layer
> types steer footprint import, routers, drc, ...  Those can be
> arbitrary attributes, understood by the respective HID engines.

Yes. That would be nice

> === Make elements small layouts ===
> 
> An element shall be defined as a small layout, same syntax, same
> semantics. A pin/pad shall be an attribute on any piece of copper
> (which may then be drawn dark gray by the HID).
> 
> On footprint import, some layer mapping needs to happen, so that
> generic pads and pins appear on and connect to the right layers.

I like this idea. Then, there would be only one file format. In the same way,
we could import other PCBs to e.g. a panel pcb. Only grouping needs to be
implemented. The same way, we could define padstacks as well.

> === Introduce the concept of classes/macros ===
> 
> A macro is a sub-layout that can be instantiated at a higher level,
> positioned and rotated.
> 
> Footprints and via-stacks are defined as macros. A via is defined as a
> via-stack macro instance, an element initially typically contains a
> single footprint macro instance. The HIDs will implement Copy-On-Write
> by default, so we can still change individual vias, pads, ... Or
> descend into the hierarchy, and edit the macro.
> 
> COW can either create a new macro (default for Vias?) or copy the
> macro contents into the Element.  

Yes!

> === Hierarchical layout ===
> 
> Elements may contain Elements. Either with hierarchical netlist, or
> with flattened refdes, like gnetlist generates. When the higher level
> elements are defined as macros, a fully hierarchical layout is
> possible.
>  
> === Convert the internal units from decimil to nanometer ===
> 
> Start by defining a variable (=254e-9), and make all output HIDs use
> that to convert to PS-point or gerber units or whatever. Then
> introduce attributes of the layout file which sets the internal units
> and the default unit of the file.

Use 64bits integers.
 
> === ASIC HID ===
> 
> When all that is implemented, an HID(-mode) optimized for chip design
> is only a small step.

Well, I'd focus on PCB layout for the first time.

Levente




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