| ID: | 3928 |
| From: | Britton Kerin <br...@gmail.com> |
| Date: | Sun, 5 Apr 2020 18:02:41 -0800 |
| Subject: | Re: [pcb-rnd] drc: Different part of board, different rules |
| in-reply-to: | 3926 from ge...@igor2.repo.hu |
| replies: | 3929 from ge...@igor2.repo.hu |
On Sun, Apr 5, 2020 at 7:37 AM <gedau@igor2.repo.hu> wrote: > > > > On Sat, 4 Apr 2020, gedau@igor2.repo.hu wrote: > > >(Finding shorts is not possible this way, as that doesn't work on a per > >object level but on a per net level, so that will need some more > >pondering!) > > Good news: I figured how to do this, so this will be possible too. Adding > it to the accepted feature request list. > > Details (for advanced users interested in query scripting and DRC rule > internals): > > The old drc, and what the new drc does for shorts at the moment goes from > top-down: it maps networks starting from the netlist. Imagine it as the > outmost for() loop being one on all nets, then the inner for() loop does > the "normal size" connection mapping, then the "bloated up" mapping and if > the two results (objects-being-in-the-net) don't match, something was too > close. In this setup any geometrical "where the object is" don't fit > because the inmost loop is already in C, beyond the reach of query(). > > But I figured how we can do it in the other way around _and_ speed things > up a bit! > > The idea is: > > - we could build a temporary cache of which object belongs to which net > (at the moment) > > - this cache is built on-demand, the first time a query script needs > it > > - even better, it is built from an object and not from networks - which > means it's really mapping which network segment the object is in, and it > does any mapping only for objects the query script ever cared about - this > can save a lot of computing time in some cases! > > - and even better, this on-demand cache can be shared within a drc > session, so the network mapping doesn't have the be repeated over and over > again > > - in practice this means: in query script, you will be able to get the > parent network (or even network segment!) of a copper object; any object, > any time; and it will be coming from a cache so if you request it multiple > times (e.g. in different rules) it won't cost more, and it won't need to > do a whole network mapping ever, only as much mapping as your script > really needs! > > - if we have all the above, then our check doesn't need to bloat up whole > networks - it can bloat up objects and check local object connections, > all scripting in the drc query script, no loop hardwired in C! I have a vague sense that asymmetrical bloating (making only one of two objects which might be too close bigger, which I think is what is being proposed here) might not be equivalent to bloating everything simultaneously, but I haven't thought about it carefully. While on this subject one thing I labored to fix in pcb in the old days was the bad location reporting for DRC violations, where a violation involving one long object like a line would get reported at the center of the object, rather than in the bloat intersection itself. I don't know if pcb-rnd still has this behavior or not but if so this might be a good time to fix it :) Britton
Reply subtree:
3928 Re: [pcb-rnd] drc: Different part of board, different rules from Britton Kerin <br...@gmail.com>
3929 Re: [pcb-rnd] drc: Different part of board, different rules from ge...@igor2.repo.hu