| ID: | 3922 |
| From: | ge...@igor2.repo.hu |
| Date: | Sat, 4 Apr 2020 13:46:31 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] drc: Different part of board, different rules |
| in-reply-to: | 3921 from Hannu Vuolasaho <vu...@msn.com> |
| replies: | 3926 from ge...@igor2.repo.hu |
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-777994997-1586000791=:10103 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 4 Apr 2020, Hannu Vuolasaho wrote: >> What do you think? > > Solution 2. is extension what I had in my mind. I thought having rectangl= es :) > > First thing which comes to my mind is that who wins if there are two diff= erent > rule polygons intersecting. There's no winner: polygons and the checks are not exclusive. It's rather= =20 like: "run this rule only under matching polygons" - without caring about= =20 any other polygon or any other rule. If you have multiple rules with=20 multiple polygons and there are overlapping sections, all matching rules=20 would run in the overlap. > Second is bonus: zone=3Dnodrc so that DRC can be run on partially done bo= ard when > the undone part is just a mess or already done part where DRC would take = ages > like a power supply are made with polygons. Actually I don't know if this= is > even possible. That's not a special case; as long as you are willing to add the zone=20 check in every single rule. But carefully choosing what you take the=20 default case, you can even avoid that, see below. > > I this possible optimization strategy? > > Could the rule selection be done first and not when making the check? cop= y > rules, split=C2=A0 targets temporarily if needed, link the rules and do t= he real > check? Not directly. Our architecutre is based on query(). You can build lists of= =20 objects for a rule, and you can iterate on them. You can build the lists=20 using expressions. Idea #2 is based on the fact you will be able to list=20 objects that overlap specific(ally attributed) polygons. Please also note: the query() languge is not procedural, it is=20 declarative, with immutable lists. So a rule can't iterate over your zone= =20 polygons and create new lists for each zone or zone type. Lists are=20 created only once, when the rule is initialized. This needs sort of an=20 upside-down thinking. (The reason for this is future optimizations which are relevant for big=20 boards and a lot of rules. These optimizations are possible only with=20 such restrictions on language level.) So this means you have basically 2 ways to write such scripts: 1. the generic way: iterate over all board objects once; check each object= =20 against each zone polygon; run your rule not against a hardwired value but= =20 an attribute of the polygon. So the structure of the script (it's just a=20 schematic, not an actually working query script, just making it up now): rule zone based thin trace; let Z (@.type =3D=3D POLYGON) && (@.a.zone =3D=3D "thickness") assert (overlap(Z, @) && (@.thickness < Z.a.min_thickness)) This lists all polygons with the zone attribute set to "thickness" in a=20 list called Z. Then it iterates over all objects overlapping with any such= =20 polygon. When the overlap happens, the object's thickness is checked=20 against the value in the "min_thickness" attribute of the overlapping zone= =20 poly. If there are multiple zone polys overlapping the object, they are=20 all checked. If none overlapping the object, the object is not checked. (Finding shorts is not possible this way, as that doesn't work on a per=20 object level but on a per net level, so that will need some more=20 pondering!) I wrote this schematic script to show how easy some complicated-looking=20 things can get with query(). 2. the hardwired way: write one rule per zone type. So you say you have a= =20 fanout zone and a psu zone. That means 2 specific rules. Each rule would=20 list objects overlapping with the corresponding zone polygons then run=20 your original rule on this list instead of "@".=20 Note: in both setup, any zone poly would affect only the rules that=20 explicitly care about them. Stock rules won't care. So you either turn off stock rules, rewriting the relevant ones for zones,= =20 or you set up things in a clever way. For example let's talk about shorts,= =20 minimum net-net distance. Let's say for the PSU you want 1mm (high=20 voltage), for your board 0.3mm and for your fanout 0.2mm. Then you could=20 say the generic rule that checks everything, independently of zone=20 polygons, will warn under 0.2mm because that's your absolute minimum. Then= =20 you write an extra rule for the non-fanout areas that warn below 0.3mm and= =20 a second rule for the PSU zone that warns under 1mm. Drawback is that you= =20 will iterate over almost everything 3 times. (But that's why I went for=20 declarative with restrictions: a lot of things will be faster than=20 expected). > > Both solutions have strengths and weaknesses and I like both. What to imp= lement > is then choice of efficiency, speed and time. I could (and probably will) implement the building blocks of both. For this use case I don't plan to include the actual rule implementations= =20 (scripts) in the default drc config we ship, rather have examples on=20 edakrill and pool nodes. It's because I find this case too specific. I=20 don't like the idea of having complex, special use cases hardwired and=20 shipped with pcb-rnd, that'd make the illusion "this is what the new drc=20 does" instead of the truth, which is "the new drc does whatever you=20 script it to do".=20 So the rule of thumb is that for more advanced things we won't have=20 hardwired rules with trillions of settings. Instead we assume who needs=20 advanced stuff will learn a bit of the query() language, download an=20 existing doc/script that does already almost exactly what he needs and=20 makes the final tweaking. I expect such advanced users maintaining their=20 own little drc lib, just like they maintain their own footprint lib. I=20 expect their projects or even board files would have special, local drc=20 rules. This is true for the zone based rules. Especially that these zones=20 probably wouldn't be some special hardwired thing in the drc code, but=20 just how you write your drc scripts, just an extra check in your=20 expressions. Regards, Igor2 --0-777994997-1586000791=:10103--
Reply subtree:
3922 Re: [pcb-rnd] drc: Different part of board, different rules from ge...@igor2.repo.hu
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