[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Christmas wishlist
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