On Sat, 25 Dec 2010 10:10:16 +0100 Stephan Boettcher <[email protected]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
