kicad-developers team mailing list archive

[Greg Smith <ecomputerd@xxxxxxxxx>]

I have experience in python DRCs and have a background in ASIC layout software and Design Rule Checks as well as a healthy experience in GIS and layer manipulation..

I have started KiPadCheck exactly to fill in some missing (IMHO) DRC checks. It might be a good as a base for further development. I can help craft an API. A huge decision to make is whether it's worth implementing basic "full layer" checks. That is, generate all polygons on a layer, then use basic geometry calculations (union, then chop into non-overlapping convex polygons, then check separation, adjacency/touching, overlap, etc.

I've written a few of python routines for getting all drill holes (via and pad), extracting mask and paste, extracting all objects on a specified layer, checking items between two specific layers. And the beginnings of working with geometries in the functions within kipadcheck.wxPointUtil. There are quite a few speed ups to be made when checking large numbers of objects (pre-calculating normals, using squares for distance check (avoiding square roots).

One thing that might help using python for DRC is including numpy or one of a few other geometry-specific python libraries.

Another awesome addition would be to create objects on layers with annotation. That way, DRC errors can be indicated with shapes (the way Cadence Virtuoso does it) and the annotation is the error message.

Greg S.

> On Aug 23, 2017, at 6:32 AM, Oliver Walters <oliver.henry.walters@xxxxxxxxx> wrote:
> 
> Something I have been considering for a while - instead of hard coding complex DRC rules into base code, what if we developed a DRC API and write the rules in Python?
> 
> Each rule could be a separate python file (similar to how footprint wizards are done). Users could enable/disable each DRC and once the framework is in place, rather than *arguing* over DRC rules in the developer list, the community can create and perfect as many different checks as they wish. 
> 
> Each DRC should provide a pass/fail metric and also a way of providing formatted feedback. 
> 
> Currently there are minimal DRC checks so even if more are implemented in C++ I see no reason why such a framework could not be implemented concurrently anyway. 
> 
> Thoughts?
> 
> Oliver
> 
>> On 23 Aug 2017 10:02, "Andrey Kuznetsov" <kandrey89@xxxxxxxxx> wrote:
>> If you're looking for good DFM manuals, check out protoexpress, otherwise known as Sierra Circuits.
>> They're a professional board house in the USA with simple to complex board design support including high speed interfaces, uvias, etc.
>> 
>> 
>>> On Tue, Aug 22, 2017 at 2:33 PM, Thomas Langås <thomas.langaas@xxxxxxxxx> wrote:
>>> On Tue, Aug 22, 2017 at 9:36 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>> > I'm not opposed to this change.  However, there are two schools of
>>> > thought when it comes to board layout: strict layout constraints and no
>>> > layout constraints.  I tend to lean towards the latter but I've been
>>> > doing this for 30 years so I am painfully aware of the pitfalls of no
>>> > layout constraints and have a pretty good idea of what not to do.
>>> > Should we choose to loosen the layout constraints for blind/buried vias,
>>> > then we should be prepared for a serious tongue lashing the first time
>>> > someone violates their board vendor's manufacturing limitations and ends
>>> > up with a bunch of useless and likely expensive boards.  Maybe at some
>>> > point in the future we will have a complete constraint system that can
>>> > cover all possibilities but until then we have to walk that fine line
>>> > between power users and beginners.
>>> 
>>> 
>>> Is there a good reason why not to build this by rulesets, and allow
>>> people to define
>>> their own rulesets within KiCAD.  You can have a sensible default rule
>>> that covers
>>> the 80-90%, and allow the people who know more about this and what they need
>>> just remove the default rule and add their own advanced rules?
>>> 
>>> Of course, this would imply that without any rules at all, it's just
>>> willy nilly and
>>> everything allowed.  But isn't that the way design rules should be?  If you want
>>> to try ice skating down a mountain, it might not be smart, but it's your own
>>> choice  ;-)
>>> 
>>> 
>>> --
>>> Thomas
>>> 
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>> 
>> 
>> 
>> -- 
>> Remember The Past, Live The Present, Change The Future
>> Those who look only to the past or the present are certain to miss the future [JFK]
>> 
>> kandrey89@xxxxxxxxx
>> Live Long and Prosper,
>> Andrey
>> 
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp