| ID: | 4382 |
| From: | Erich Heinzle <a1...@gmail.com> |
| Date: | Sun, 20 Sep 2020 19:25:55 +0930 |
| Subject: | Re: [pcb-rnd] Back annotation |
| in-reply-to: | 4381 from ge...@igor2.repo.hu |
| replies: | 4401 from Hannu Vuolasaho <vu...@msn.com> |
--0000000000002e917e05afbbbec9 Content-Type: text/plain; charset="UTF-8" If the only constraint is avoiding colinearity of terminals for differing net rat lines, then a simple orthogonalising routine to tidy up "as the crow flies" rat lines that observes this constraint is what would be needed, I guess. Step one, auto place the symbols on a grid such that there is a minimum gap d between a symbol and any other symbol in any x or y direction Step two, subdividing the schematic white space gap d finely enough for the n nets to run in parallel in the x and y directions, would allow n distinct nets spaced d/n apart to occupy the gaps as notional grids, from which connections would be made. Step three, make net n's connection y1...ym adhering to the assigned grid for all of net n's interconnects Step four, maybe get rid of loops? Maybe avoid loops by ordering based on a steiner tree prior to step three, using manhattan distance. Not completely trivial. Regards, Erich On Sun, 20 Sep 2020 19:09 , <gedau@igor2.repo.hu> wrote: > > > On Sun, 20 Sep 2020, Erich Heinzle wrote: > > >I find myself thinking about reverse engineering/implementing an existing > >legacy design again. > >It occurs to me the slightly dumb autorouter coded by Igor2 to test the > new > >auto route plugin API would work really well for auto routing a schematic > >with unconnected symbols and a netlist from back annotation. > > > >Thoughts? > > Autorouting a schematics is a different task from autorouting a board, > imho, so I would be surprised if the same method would work for both. > > These are the main differences: > > 1. On pcb, the hard constraint is that you can't have nets crossing; > that's the thing that throws the whole problem in the NP domain. On > schematics, crossing is totally okay > > 2. On pcb you have a lot of constraints on part placement, and then how > you do the wiring is almost arbitrary^1. The actual wiring you end up > with does not mean anything to the human eye, the only thing you are > interested in is getting the connections right. On schematics it's the > opposite: the whole thing is about making the reader understand what's > going on. > > 3. Layers and vias. On schematics you don't have layers of wiring, and no > vias. What my simplistic horver router is doing is a good example: it goes > and arranges things assuming 2 (or even number of) layers and how vias > would be then placed. > > 4. Logical/implied connections. A good schematics, because it tries to be > readable, will use a lot of those. Starting from the simplest vcc/gnd > symbols through named nets hooking up, through pin attributes in > components making implicit connections to buses. Figuring when the router > wants to draw a single net as a line across the whole drawing and when it > should use an implicit connection looks like a very different problem from > what we have on pcb routing. > > > It's an interesting topic, and I've been pondering this since the early > back annotation days^2. Unfortunately I don't have answers. I wonder > if anyone ever did a prototype on this in any EDA... > > > Footnotes: > > ^1: apart from some rather local things like differential pairs, "keep > this short", etc; what I meant is that your autorouter will rarely go and > rearrange your parts to get better wiring, e.g. moving connectors or LEDs > you carefaully matched up with your enclosure. > > ^2: which was back in 2016 IIRC. The most usable idea I had was something > like a "rat line" on schematics after a back annotation, in case both ends > of a new connection can be found on the same page. Unfortunately one of > gEDA's main design flaw kept me from doing it: gschem doesn't know > anything about nets really! As in, it can't really tell in which net an > object is or search objects that make up a net, etc. It just lacks the > concept of net, which I still find funny, especially that another very > similar concept, slotting, is hardwired down to the GUI level. > > Best regards, > > Igor2 > > > --0000000000002e917e05afbbbec9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">If the only constraint is avoiding colinearity of termina= ls for differing net rat lines, then a simple orthogonalising routine to ti= dy up "as the crow flies" rat lines that observes this constraint= is what would be needed, I guess.<div dir=3D"auto"><br></div><div dir=3D"a= uto">Step one, auto place the symbols on a grid such that there is a minimu= m gap d between a symbol and any other symbol in any x or y direction</div>= <div dir=3D"auto"><br></div><div dir=3D"auto">Step two, subdividing the sch= ematic white space gap d finely enough for the n nets to run in parallel in= the x and y directions, would allow n distinct nets spaced d/n apart to oc= cupy the gaps as notional grids, from which connections would be made.</div= ><div dir=3D"auto"><br></div><div dir=3D"auto">Step three, make net n's= connection y1...ym adhering to the assigned grid for all of net n's in= terconnects<br><div dir=3D"auto"><br></div><div dir=3D"auto">Step four, may= be get rid of loops? Maybe avoid loops by ordering based on a steiner tree = prior to step three, using manhattan distance.</div><div dir=3D"auto"><br><= /div><div dir=3D"auto">Not completely trivial.</div><div dir=3D"auto"><br><= /div><div dir=3D"auto">Regards,</div><div dir=3D"auto"><br></div><div dir= =3D"auto">Erich</div></div></div><br><div class=3D"gmail_quote"><div dir=3D= "ltr" class=3D"gmail_attr">On Sun, 20 Sep 2020 19:09 , <<a href=3D"mailt= o:gedau@igor2.repo.hu">gedau@igor2.repo.hu</a>> wrote:<br></div><blockqu= ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= olid;padding-left:1ex"><br> <br> On Sun, 20 Sep 2020, Erich Heinzle wrote:<br> <br> >I find myself thinking about reverse engineering/implementing an existi= ng<br> >legacy design again.<br> >It occurs to me the slightly dumb autorouter coded by Igor2 to test the= new<br> >auto route plugin API would work really well for auto routing a schemat= ic<br> >with unconnected symbols and a netlist from back annotation.<br> ><br> >Thoughts?<br> <br> Autorouting a schematics is a different task from autorouting a board, <br> imho, so I would be surprised if the same method would work for both. <br> <br> These are the main differences:<br> <br> 1. On pcb, the hard constraint is that you can't have nets crossing; <b= r> that's the thing that throws the whole problem in the NP domain. On <br= > schematics, crossing is totally okay<br> <br> 2. On pcb you have a lot of constraints on part placement, and then how <br= > you do the wiring is almost arbitrary^1. The actual wiring you end up <br> with does not mean anything to the human eye, the only thing you are <br> interested in is getting the connections right. On schematics it's the = <br> opposite: the whole thing is about making the reader understand what's = <br> going on.<br> <br> 3. Layers and vias. On schematics you don't have layers of wiring, and = no <br> vias. What my simplistic horver router is doing is a good example: it goes = <br> and arranges things assuming 2 (or even number of) layers and how vias <br> would be then placed.<br> <br> 4. Logical/implied connections. A good schematics, because it tries to be <= br> readable, will use a lot of those. Starting from the simplest vcc/gnd <br> symbols through named nets hooking up, through pin attributes in <br> components making implicit connections to buses. Figuring when the router <= br> wants to draw a single net as a line across the whole drawing and when it <= br> should use an implicit connection looks like a very different problem from = <br> what we have on pcb routing.<br> <br> <br> It's an interesting topic, and I've been pondering this since the e= arly <br> back annotation days^2. Unfortunately I don't have answers. I wonder <b= r> if anyone ever did a prototype on this in any EDA...<br> <br> <br> Footnotes:<br> <br> ^1: apart from some rather local things like differential pairs, "keep= <br> this short", etc; what I meant is that your autorouter will rarely go = and <br> rearrange your parts to get better wiring, e.g. moving connectors or LEDs <= br> you carefaully matched up with your enclosure.<br> <br> ^2: which was back in 2016 IIRC. The most usable idea I had was something <= br> like a "rat line" on schematics after a back annotation, in case = both ends <br> of a new connection can be found on the same page. Unfortunately one of <br= > gEDA's main design flaw kept me from doing it: gschem doesn't know = <br> anything about nets really! As in, it can't really tell in which net an= <br> object is or search objects that make up a net, etc. It just lacks the <br> concept of net, which I still find funny, especially that another very <br> similar concept, slotting, is hardwired down to the GUI level.<br> <br> Best regards,<br> <br> Igor2<br> <br> <br> </blockquote></div> --0000000000002e917e05afbbbec9--
Reply subtree:
4382 Re: [pcb-rnd] Back annotation from Erich Heinzle <a1...@gmail.com>
4401 Re: [pcb-rnd] Back annotation from Hannu Vuolasaho <vu...@msn.com>