delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/01/28/18:25:34

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=8tZB8c14PSetywgAByftCGRBy/7dGExKAXjaoXzeU6A=;
b=uPbX3jr9ZjoEnGhJ7k3LKfsFwRrGEO2IwV8tfnAc54w/tdX3pA/dkSYJfgsLkakJaL
9/PldT8ngxAg8eY6uHBK/Y3utdBhHTrVtVu5Wn6xJkgBf0S9CN/ylabr/OjSqGKd2rFh
O5RpJ2v04lnHTfO1aQCnRFGxrppjrp3hSHFM3g1ewRaUOJtpoRJWu7zfkZ9UjLEFg3rj
FyroB6Voe1GL6UTLLH9sRH1UTgLrLq01erzyrwGLyrPfdlTjIQNjHlZtAzl1O0vnhCEv
X1SUt9Eqpl/GE+Ji+DZYQwKDACFjd5L11737xMdp7QXm8lae/1LEFXb3uKi7UeilrlKI
EFsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:content-type;
bh=8tZB8c14PSetywgAByftCGRBy/7dGExKAXjaoXzeU6A=;
b=hUmqQy+4vrRdHmr9BOKQ/ULQGXVtJS1g//L9GUABE7ApFZ5fCTC0QMlBeF5pXEQ8dE
z15eZbIKPNBIJnZDh4DCXAE9EFwvXvJm4CxxtEGHuiXHeHV2nL2EniS00zIHWLNMeOCU
CyH5/jX94duA6dJcoeb1l6rP8qIKeVCrNfRDsDV1wDNWC8DgzRdCPMkGJuTTGevrzvUA
YSMEQqymAm8NyT/Pq9fLMPar31512uG95n5j6Jn1Te2HetfxAFiwlH7X0igPnPR30Dyf
txGK1mRVDkOMihuLUIbRMGOSN/imGCyXfebA/GC7A1Xy7RYeTbggSsBE6QJSYaKhDgeg
WWZw==
X-Gm-Message-State: AG10YOS69u08EP9WRy5/41LMAdfTFZrL1ilEfMjLBxe+c6uUIo869oTSSSemJGrvRyoW3E64sxkgT8Vl26KHcA==
MIME-Version: 1.0
X-Received: by 10.107.25.145 with SMTP id 139mr6738200ioz.89.1454023513602;
Thu, 28 Jan 2016 15:25:13 -0800 (PST)
In-Reply-To: <201601282134.u0SLYET7002642@envy.delorie.com>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1601180756390 DOT 9035 AT igor2priv>
<CAC4O8c-ZyNnCzCDHXkYYabSD4fG8vf+CKmhMycNJujGMPKzQDQ AT mail DOT gmail DOT com>
<s6nr3h49hrq DOT fsf AT blaulicht DOT dmz DOT brux>
<DDB07351-7C94-4B5C-99FA-83750CD4592A AT noqsi DOT com>
<20160126233332 DOT dec2f06f5c74354a3841989c AT gmail DOT com>
<s6n1t93h4ub DOT fsf AT blaulicht DOT dmz DOT brux>
<20160127091746 DOT 1c7a976c2752f913921688ac AT gmail DOT com>
<s6npowne74w DOT fsf AT blaulicht DOT dmz DOT brux>
<20160127141334 DOT c738feb9dbeb54a7dec3dff8 AT gmail DOT com>
<s6n37tjt1tv DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
<56A8F74B DOT 8080304 AT ecosensory DOT com>
<CAC4O8c9UKLsh5FAAwUMEtHThKH-w3gUmCU2i9dRW9igkyRt-TQ AT mail DOT gmail DOT com>
<CAJZxidDmjMtd_fKvR5qZVRa+hwDUbvfaz79oZjkBgDuE1m8RBg AT mail DOT gmail DOT com>
<56A961BC DOT 3040405 AT ecosensory DOT com>
<CAJZxidC=nbxAinOtpfGHHqwPXbEMrhfat7jKgA9KBp3EVVg4_Q AT mail DOT gmail DOT com>
<s6nbn863xlu DOT fsf AT blaulicht DOT dmz DOT brux>
<56A9E416 DOT 8080500 AT ecosensory DOT com>
<s6nfuxirm0b DOT fsf AT falbala DOT ieap DOT uni-kiel DOT de>
<CAC4O8c9D-F3p8sAm2UumoE+uoMZM1ufSP=mNEPeHHpn8YrcSyg AT mail DOT gmail DOT com>
<20160128200126 DOT 0fe1bb26d5c28e59d56dfd0e AT gmail DOT com>
<CAC4O8c8prUS=NSm_7BCwkCPntsCRRMCMu9--eXXVBtD0C4pYOg AT mail DOT gmail DOT com>
<201601282134 DOT u0SLYET7002642 AT envy DOT delorie DOT com>
Date: Thu, 28 Jan 2016 18:25:13 -0500
Message-ID: <CAJZxidBaFXQ=f3984gQehYy2X_g_BZ_XsjfOkFo=68PK-JBHdQ@mail.gmail.com>
Subject: Re: [geda-user] The nature of gEDA layers
From: "Chad Parker (parker DOT charles AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: geda-user AT delorie DOT com
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

--001a113fd3e2060403052a6d3b6e
Content-Type: text/plain; charset=UTF-8

> > > - Allow more/all things inside Elements, on explicit layers.
> >
> > This one in particular is not a small incremental step but a fairly
> > drastic change.  A lot of work is likely to be required to fix all the
> > points that make assumptions about Elements.  I'm not saying it's a
> > bad idea, but it's hard.
>
> Yeah, hard :-)  Internals-wise, the problems are many-fold:
>
>
If it were easy, anyone could do it! :)


> * 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 have
> BBVias
>

These are solvable problems that are for the UI to work, and shouldn't
affect the design of the underlying data structures (opinion).


> * The exporters need to know how to export a BBVia (esp drill files)
>

Exporting a BBVia is as simple as exporting any other through hole pad. The
drill file is the trick. That's why I suggested being able to create a
drill layer that is could associated with a particular layer. Then the fab
could use it to know which layers to drill for the buried components prior
to lamination.


> * DRC needs BBVia-specific rules
>

This depends on how DRC looks at the BBVia. If DRC just sees them as pieces
of copper, then it can those pieces and look for overlaps, or however the
regular DRC works.

* DRC needs to know where BBVias connect to
>

I wouldn't think (perhaps naively) that this problem is unique to BBVias.

* 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
>

If the auto DRC is just checking connectivity and spacing, then if you
route a trace on a layer that the via doesn't intersect (have a pad on), it
shouldn't actually notice it. A layer ordering is necessary certainly, but
it doesn't have to be a real physical stackup. And the layer ordering is
really only important when the BBVia is placed because that's when it
creates the primitives on particular layers. I don't think that the DRC
should really care much what kind of component placed the primitive where
it is, it should just care whether the primitive is too close or
overlapping with another primitive (clearly this is opinion, and there are
probably lots of cases I haven't thought about).


> * ...which implies more GUI changes
> * will autoroute use BBVias?
>

It could if you teach it to, but there's no reason it has to. The
autorouter doesn't need to use every tool in the tool box. The interface
should allow it to if it's smart enough, but I would suggest worrying about
the autorouter down the road. What we've been discussing here is at a much
lower level.


> * what about the optimizers?
> * We need a way of storing BBVias in a file
> * ...and storing them internally
>

I think that if the component model becomes a collection of primitives,
then they would be stored just like components, or other vias. Primitives
on particular layers. I know someone has disagreed with me about vias or
BBVias being essentially simple components, but I don't understand that
argument. Perhaps someone could explain it to me?


> * ...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 layers
> in question
> * ...and define "layers in question" accordingly
> * etc
>
>


> So let's call this a "drastic incremental change" - it's doable in the
> context of the current code set but it's a lot of work.
>
> But enough talk.  Who's going to do all that work?
>

I'd love to help (and I've had the sentiment for a year or so now, btw, in
spite of all the drama on the mailing list), but my familiarity with the
code base is 0, and I haven't really had the time to dive deep into it and
figure it out. I've been dissatisfied with most layout tools that I've
used, and so I've spent a lot of time thinking about "how it should be
done". To that end, I think I have some good ideas. But I think that a lot
of people on this list have also spent a lot of time thinking about these
things, and are probably have an infinitely more practical perspective on
it than I do.

If you (by which I mean the greater pcb community) are actually interested
in implementing some of these fundamental changes to the core codebase,
then I might be able to help with that.

Cheers,
--Chad

--001a113fd3e2060403052a6d3b6e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
&gt; &gt; - Allow more/all things inside Elements, on explicit layers.<br>
&gt;<br>
&gt; This one in particular is not a small incremental step but a fairly<br=
>
&gt; drastic change.=C2=A0 A lot of work is likely to be required to fix al=
l the<br>
&gt; points that make assumptions about Elements.=C2=A0 I&#39;m not saying =
it&#39;s a<br>
&gt; bad idea, but it&#39;s hard.<br>
<br>
</span>Yeah, hard :-)=C2=A0 Internals-wise, the problems are many-fold:<br>
<br></blockquote><div><br></div><div>If it were easy, anyone could do it! :=
)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
* The GUI needs a way of letting the user specify a BBvia<br>
* The GUI needs to be able to *draw* a BBvia (+1 in 3D mode)<br>
* The GUI needs a way to let the user specify which layer pairs may have BB=
Vias<br></blockquote><div><br></div><div>These are solvable problems that a=
re for the UI to work, and shouldn&#39;t affect the design of the underlyin=
g data structures (opinion).<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
* The exporters need to know how to export a BBVia (esp drill files)<br></b=
lockquote><div><br></div><div>Exporting a BBVia is as simple as exporting a=
ny other through hole pad. The drill file is the trick. That&#39;s why I su=
ggested being able to create a drill layer that is could associated with a =
particular layer. Then the fab could use it to know which layers to drill f=
or the buried components prior to lamination. <br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
* DRC needs BBVia-specific rules<br></blockquote><div><br></div><div>This d=
epends on how DRC looks at the BBVia. If DRC just sees them as pieces of co=
pper, then it can those pieces and look for overlaps, or however the regula=
r DRC works.<br></div><div><br><blockquote style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_q=
uote">
* DRC needs to know where BBVias connect to <br></blockquote><br></div><div=
>I wouldn&#39;t think (perhaps naively) that this problem is unique to BBVi=
as.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
* Find, likewise<br>
* Report, likewise<br>
* auto-drc needs to know when to let you go &quot;past&quot; a BBVia<br>
* ...which implies a real physical stackup is needed, and enforced<br></blo=
ckquote><div><br></div><div>If the auto DRC is just checking connectivity a=
nd spacing, then if you route a trace on a layer that the via doesn&#39;t i=
ntersect (have a pad on), it shouldn&#39;t actually notice it. A layer orde=
ring is necessary certainly, but it doesn&#39;t have to be a real physical =
stackup. And the layer ordering is really only important when the BBVia is =
placed because that&#39;s when it creates the primitives on particular laye=
rs. I don&#39;t think that the DRC should really care much what kind of com=
ponent placed the primitive where it is, it should just care whether the pr=
imitive is too close or overlapping with another primitive (clearly this is=
 opinion, and there are probably lots of cases I haven&#39;t thought about)=
.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x">
* ...which implies more GUI changes<br>
* will autoroute use BBVias?<br></blockquote><div><br></div><div>It could i=
f you teach it to, but there&#39;s no reason it has to. The autorouter does=
n&#39;t need to use every tool in the tool box. The interface should allow =
it to if it&#39;s smart enough, but I would suggest worrying about the auto=
router down the road. What we&#39;ve been discussing here is at a much lowe=
r level.<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
* what about the optimizers?<br>
* We need a way of storing BBVias in a file<br>
* ...and storing them internally<br></blockquote><div><br></div><div>I thin=
k that if the component model becomes a collection of primitives, then they=
 would be stored just like components, or other vias. Primitives on particu=
lar layers. I know someone has disagreed with me about vias or BBVias being=
 essentially simple components, but I don&#39;t understand that argument. P=
erhaps someone could explain it to me?<br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
* ...and hooking them up to all the object-oriented code throughout<br>
* ...and hooking them up to the rtrees<br>
* ...and teaching rtrees how to find only BBVias that intersect the layers =
in question<br>
* ...and define &quot;layers in question&quot; accordingly<br>
* etc<br>
<br></blockquote><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex">
So let&#39;s call this a &quot;drastic incremental change&quot; - it&#39;s =
doable in the<br>
context of the current code set but it&#39;s a lot of work.<br>
<br>
But enough talk.=C2=A0 Who&#39;s going to do all that work?<br>
</blockquote></div><br></div><div class=3D"gmail_extra">I&#39;d love to hel=
p (and I&#39;ve had the sentiment for a year or so now, btw, in spite of al=
l the drama on the mailing list), but my familiarity with the code base is =
0, and I haven&#39;t really had the time to dive deep into it and figure it=
 out. I&#39;ve been dissatisfied with most layout tools that I&#39;ve used,=
 and so I&#39;ve spent a lot of time thinking about &quot;how it should be =
done&quot;. To that end, I think I have some good ideas. But I think that a=
 lot of people on this list have also spent a lot of time thinking about th=
ese things, and are probably have an infinitely more practical perspective =
on it than I do.<br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">If you (by which I mean the greater pcb community) are act=
ually interested in implementing some of these fundamental changes to the c=
ore codebase, then I might be able to help with that.<br><br></div><div cla=
ss=3D"gmail_extra">Cheers,<br></div><div class=3D"gmail_extra">--Chad<br></=
div><div class=3D"gmail_extra"><br></div></div>

--001a113fd3e2060403052a6d3b6e--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019