2016-01-30 11:49 GMT+01:00 Chris Smith (<= a href=3D"mailto:space DOT dandy AT icloud DOT com">space DOT dandy AT icloud DOT com) [via <= a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com] <ge= da-user AT delorie DOT com>:

> On 28 Jan 2016, at 21:34, DJ Delorie <dj AT delorie DOT com> wrote:
>
>>> - Allow more/all things inside Elements, on explicit layers. >>
>> This one in particular is not a small incremental step but a fairl= y
>> drastic change.=C2=A0 A lot of work is likely to be required to fi= x all the
>> points that make assumptions about Elements.=C2=A0 I'm not say= ing it's a
>> bad idea, but it's hard.
>
> Yeah, hard :-)=C2=A0 Internals-wise, the problems are many-fold:
>
> * The GUI needs a way of letting the user specify a BBvia
> * The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)
> * The GUI needs a way to let the user specify which layer pairs may ha= ve BBVias
> * The exporters need to know how to export a BBVia (esp drill files) > * DRC needs BBVia-specific rules
> * DRC needs to know where BBVias connect to
> * Find, likewise
> * Report, likewise
> * auto-drc needs to know when to let you go "past" a BBVia > * ...which implies a real physical stackup is needed, and enforced
> * ...which implies more GUI changes
> * will autoroute use BBVias?
> * what about the optimizers?
> * We need a way of storing BBVias in a file
> * ...and storing them internally
> * ...and hooking them up to all the object-oriented code throughout > * ...and hooking them up to the rtrees
> * ...and teaching rtrees how to find only BBVias that intersect the la= yers in question
> * ...and define "layers in question" accordingly
> * etc
>
> So let's call this a "drastic incremental change" - it&#= 39;s doable in the
> context of the current code set but it's a lot of work.

Isn=E2=80=99t this a bit too specific?=C2=A0 Why does PCB need = to know specifically about BBVias, or any other type of via?=C2=A0 Wouldn= =E2=80=99t it be better to allow the concept of a =E2=80=98foreign=E2=80=99= connection, i.e. a connection that is made outside of PCB=E2=80=99s routin= g.=C2=A0 You would do this by allowing the user to attach one or more conne= ction attributes (call them net names, if you will) to a primitive; PCB wou= ld then run its existing geometrical/graphical algorithms to determine conn= ectivity, collecting all explicit connection attributes at the same time.= =C2=A0 The final connection would then be a logical OR=E2=80=99ing of all g= raphically connected primitives with common explicit connection attributes.=

In this way any type of via is simply a group of primitives on a number of = layers, with those on copper layers sharing a common connection attribute.= =C2=A0 DRC and auto-DRC would work as normal, with little to no change.=C2= =A0 It would also provide a mechanism to do other, similar things, like wir= e connections, internally connected pins, wrap-around board edge connectors= , etc =E2=80=94 it would all work in exactly the same way.

In terms of GUI you would then =E2=80=98only' need:

- sub layouts or groups/blocks of primitives
- unique connection attribute for each =E2=80=98paste=E2=80=99 of a block/g= roup.

It would be up to the user to ensure that their via groups are physically m= anufacturable, but you could also provide a GUI mechanism to cover the comm= on options.

Surely this is much cleaner and more flexible than providing Via and BBVia = specific functionality?

Chris
=E2=80=94
Chris Smith <space DOT dandy AT iclou= d.com>