| ID: | 3891 |
| From: | ge...@igor2.repo.hu |
| Date: | Thu, 2 Apr 2020 10:55:38 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] drc: implement dru files |
| in-reply-to: | 3890 from Alain Vigne <al...@gmail.com> |
| replies: | 3892 from Alain Vigne <al...@gmail.com> |
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-1796636772-1585817738=:10103 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 2 Apr 2020, Alain Vigne wrote: >I'm happy to contribute a little again ;) >See comments inserted below Cool, thanks! [about our existing dru parsing] >Then, once parsed, what happens ? At the moment a very few selected values that happen to implement features= =20 in DRU land that have a similar feature in the old drc are copied into the= =20 drc config nodes. The rest of the values are ignored. If we implement this with the new DRC, a set of DRC rules would be=20 generated by the io_eagle plugin instead. I don't expect 100% coverage,=20 but we could probably write a rule for majority of the values, covering=20 the most common and most important use cases. > > So questions are: > > 1. most relevant: where/why do you need this in practice, on > production > boards?=C2=A0 Are you fabbing boards at that fab or another fab that > provide > DRU files? > >Yes, I am fabbing my PCBs with this fab. >I could envision also this fab : https://www.eurocircuits.com >with this files :https://www.eurocircuits.com/drc-settings-and-guide-lines= -for-cad-packages/ >Same idea. Good, if there's production use, it's worth going for it! > > 2. are you willing to break down the DRU format into individual > rules? > (DRU itself has numeric fields, so "what exactly needs to be > checked for a > given field" is the translation to rule) > >Well, as a _user_, ideally, I don't give a damn about internal translation= s. >I expect pcb-rnd to read the rules, understand, and apply all the rules wh= en >I hit "DRC" button. Then, if I have no DRC error, I consider the design go= od As I wrote in the original call: I'd do the coding/scripting, all I need=20 is the rules (written in plain English). So please take your drc file and/or spec, and try to write a list of=20 what things need to be checked using which values in the DRC file. Focus=20 on the "what", not on the "how". Especially don't worry about layer=20 stacks and things like that. <snip> > 3. are you willing to test each rule implementation? > >TLDR: yes >long story: Depending on DRU file and user strategy, this might be not tru= e >with this very file. But a new DRU file can be created included really ALL >the required rules to pass. Then, other DRC jobs could be launched with >other requirements, on per request basis. I am only interested in the rules you are going to use/test. If your DRU=20 file implements rules you don't understand or don't want to use/test, we=20 should just skip those. Rationale: I want to stay focused and implement things that actually get=20 used, not fancy things that "look useful and may be used by someone some=20 day".=20 <snip> >The idea could also be a "translation" app: take the DRU file as an input >and output a tEDAX, or DRC? pcb-rnd file ? Don't really know. No need to complicate it with inserting a long chain of extra formats and= =20 external converters. We already parse DRU, what's needed is really only=20 what I wrote above, and that can't be saved with the longer path either. (We do have a very simple but rather generic tEDAx drc format, we already= =20 use some of it, the few things the old drc could handle, and I will=20 obviously implement the whole thing using drc_query. But that's an=20 independent effort from DRU or other formats.) Regards, Igor2 --0-1796636772-1585817738=:10103--
Reply subtree:
3891 Re: [pcb-rnd] drc: implement dru files from ge...@igor2.repo.hu
3892 Re: [pcb-rnd] drc: implement dru files from Alain Vigne <al...@gmail.com>
3893 Re: [pcb-rnd] drc: implement dru files from ge...@igor2.repo.hu