Mail Archives: geda-user/2014/07/09/18:23:18
> > * board-level fill
> > * board-level cut
> > * footprint-level fill
> > * footprint-level cut
> > * traces
> I agree with all that. The need for a footprint-level version of the
> layers distinct from the lay-out level isn't extremely clear for me, but
> I assume that makes internal operations easier to sort out.
It doesn't need to be footprint-vs-layout, it's just that there needs
to be rules about how to apply layered patterns when recursively
defining layouts in terms of sub-layouts and/or footprints. I.e.
the above list is, internally, simply:
* positive, polygons, lines, etc
* negative, polygons, lines, etc
* sub-part (from footprint, sub-layout, whatever)
* positive, etc
* negative, etc
* positive, etc
* positive, etc
> And what are the chances of this happening in pcb? Is that a doable
> change?
Someone would have to have the drive and time to do it. I think it's
a fundamental change to the pcb internals, which means it touches most
of the code.
> So here is another one. I saw my KiCad-using friend (at the "Wednesday
In some EDA packages, the footprint includes some "skyscraper"
information that gives a rough idea of space needed in 3-D terms.
Sometimes that info can be used to do a 3-D model of the layout,
sometimes that info is used as a 3-D "keep out". We could define a
type of that data that means "remove board here" but I'm not sure how
well that would relate to the rest of PCB.
I mean, lots of places in pcb need to know the "shape of the board".
Now we're adding "shape of the board from layer X to layer Y" etc.
How much of this shape will be dynamically computed by scanning the
layout? How much will be pre-computed and cached? How will this
affect performance or code readability? I don't know the answers to
those questions.
- Raw text -