| ID: | 3926 |
| From: | ge...@igor2.repo.hu |
| Date: | Sun, 5 Apr 2020 17:08:41 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] drc: Different part of board, different rules |
| in-reply-to: | 3922 from ge...@igor2.repo.hu |
| replies: | 3928 from Britton Kerin <br...@gmail.com> , 4050 from ge...@igor2.repo.hu |
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! So in practice this means we will be able to have the following implementation: Query script iterates on all objects that fall under the zone polygon. Then determine the net of that one object. Then run a single level (non-recursive) find.c search from that object with the bloatup. This will result in all _directly_ connected object and check if they are all in the same network (this part has to be in C because of immutable lists, but this won't limit flexibility anymore). Bonus: if you do this for multiple overlapping zone polygons areas, the net mapping won't be done multiple times because of the cache; the one-level bloatup-connection-check will be done multiple times, but with different bloat values (as you want to have different clearance requirement per zone) which could not be saved anyway. Best regards, Igor2
Reply subtree:
3926 Re: [pcb-rnd] drc: Different part of board, different rules from ge...@igor2.repo.hu
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
4050 Re: [pcb-rnd] drc: Different part of board, different rules - from ge...@igor2.repo.hu