delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2018/07/14/23:40:17

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Sun, 15 Jul 2018 05:44:55 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Luis de Arquer (ldearquer AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] DRC clearance bugs
In-Reply-To: <CAGqyy=b0L49LYm_gfpJ_m9agJjtjSVPq50Ofvff-unSXkxmkyA@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1807150455120.8169@igor2priv>
References: <CAGqyy=b0L49LYm_gfpJ_m9agJjtjSVPq50Ofvff-unSXkxmkyA AT mail DOT gmail DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Hello Luis,

On Sat, 14 Jul 2018, Luis de Arquer (ldearquer AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

> Chad -and everyone,
>
> I have been diving a bit more into the DRC clearance issues on
> launchpad, and I found that the problem is bigger than I thought. The
> same problem is present in pcb-rnd.

Thanks!

> The DRC clearance-check works in three steps (this is line to polygon,
> but arc and pad to polygon is probably the same)
>
> 1. Check whether bounding box of the line overlaps the polygon
> 2. If so, check if they are joined or separated.
> 3. If they are separated, check the clearance between them.
>
> This scheme looks fine to me, except on how it is executed:
>
> 1. The bounding box used for checking the overlap is the line's
> regular bounding box. This bounding box is built with [line thickness
> + line clearance]. This is wrong. It should be made with [line
> thickness + *DRC clearance*]. The consequence is missed errors in DRC.

You are right. The basic wrong assumption probably was that the 
per object clearance value will always match the drc clearance value.

(Somewhat related: many other EDA systems have a much more limited model: 
they don't have per object clearance, but only one global clearance which 
is then used both for polygon clearances and DRC checks. In those systems 
they can have this assumption)

This problem is more generic and affects a lot of other parts of the code.

A typical example is the dashed outline of the subcircuit. It is drawn at 
the boudning box of the subcircuit, which is the bounding box union of all 
objects within the subcircuit. This, of course, also includes the 
clearance - which makes the subcircuit bounding box extend slightly beyond 
the expected.

This is somewhat tolerable with copper because one can reason for 
including all side effects of a subcircuit in bbox. But it gets especially 
bad if you have lines objects on silk or outline or mask or paste where 
clearance won't matter (because you won't draw polygons there), but you 
left the clearance value non-zero. There you really have the extra bloat 
in the subc bbox for seemingly no reason.

Another example where this hurts: draw a line with a large clearance 
value, then cut to buffer and move. The buffer content will bump into 
board edge at the buffer's bounding box. Which, of course, is again the 
union of all contained objects' bounding boxes - including the clearance. 
So you can't get the _copper_ of the line close to the edges because it 
insists on keeping even the clearance within the drawing area, which is 
stupid.

Solutoin:

This generic problem is well known in pcb-rnd and I have a plan for it: we 
simply need to track two bounding boxes for every object. One is the naked 
("copper") bounding box that is the base object without any side effect, 
and the other is the final bounding box, the object with all side effects 
including clearance. We need to keep the second only for historical 
reasons because the code depends on it everywhere. As long as the only 
such side effect we have is clearance it is cheap to calculate: most of 
the cases you just bloat up the naked box by clearance on all sides to get 
the final box. Then each part of the code can decide which bbox to use.

So in case of drc, we'd use the naked bbox and would add the drc 
clearance on top of it.

> 2. In order to check whether the line and polygon are joined or
> separated, the "clearline" [J] flag on the line is checked. This is
> wrong too, because false positives and negatives exist:
> - A line may belong to the same net than the polygon, even though it
> has the "clearline" set (e.g. a third line connects each other)

That's not necessarily a bug imho. It depends on how we define things and 
what we want of DRC.

Approach #1 is that DRC is coupled with nets. In this setup, you are 
mostly interested whether your nets risk a break (minimal overlap not met) 
or risk a short (minimal copper distance not met).

Approach #2 is that you have a board with different objects and you want 
to fab the board. At the end, the dabbing process will go wrong (or at 
least will get very expensive) if you have thin hair of objects (copper, 
or even silk!) or you don't meet the minimal overlap.

We inherited approach #1 from pcb. But I believe we should go toward 
approach #2.

A trivial example is if you start drawing copper objects that are not part 
of any network. In most cases they are totally invisible to the drc code 
as they are not reachable from any netlisted terminal. But at the end, 
physics work on them too, and your fab's CAM checking too, and they will 
charge you the extra cost if you did something strange on non-net copper 
(or even silk).

> - A line may not join the polygon, even with the clearline unset. For
> example, when other elements (vias, etc) clear the polygon around.

I agree. The generic rule should be real connection checking over 
heuristics and assumptions.

>
> 3. Once the line is considered to plow the polygon, the DRC checks the
> clearance setting on the line (line->Clearance). This may create false
> positives, because there may be other elements clearing the polygon,
> or the line may be at a corner of the polygon. This is the bug i fixed
> in https://bugs.launchpad.net/pcb/+bug/746178
>
> I have attached three PCB examples, showing the three bugs separately.
> Most, if not all, the polygon to line/arc/pad bugs in launchpad are
> variants of these three.
>
> I think the solution is:
>
> 1. Use the DRC setting to build the line bounding box, not its own
> clearance setting.

I generally agree, but I'd prefer to do what I described above: just keep 
track on both a naked and a with-side-effects bbox, because it's not only 
the DRC that needs this.

Adding it only in the drc would lead to code duplication and more 
expensive drc because it wouldn't be able toe asily cache this so it would 
ahve to recalculate it every time.

> 2. Forget about the "clearline" flag. Instead, check whether there is
> electrical connection between the line and the polygon. Only if they
> are (directly or indirectly) connected, skip it. If there is an
> accidental, small connection betwen them though, it won't show up in
> DRC, but updating the rat nest will do (this is consistent with the
> overall behaviour of how DRC/rats work).

I agree.

Caveat/risk/challenge: the line end cap is a true half cirlce, while the 
clearance arc cutout is emulated with straight line approximation (the 
polygon code can't yet handle arc-in-contour). IIRC there's some 
provisions for this in the polygon code, making the rounding in favor of 
"rather staying farther than closer than the clearance", but we will need 
to double check that. Worst case we can end up in a situation where the 
clearance causes a 1..2 nanometer drc error because of the approximation.

> 3. Once the line is considered to plow the polygon, bloat the line
> with DRC clearance, and use IsLineInPolygon() for an exhaustive test.
> This uses the real shape of the line and the polygon, and should not
> throw any false positives.

Sounds good!

> I have corrected 1 and 3 in my local tree, as I need it for our PCB
> production (and verified 2 does not affect me). I will try to fix 2
> asap.
>
> Couple of requests/questions:
> - Any help confirming these issues is welcome (even just confirming
> the bug on the three attached files)

Your examples don't contain nets. I am not sure what mainline does these 
days, but original PCB and pcb-rnd won't do much checks with these 
objects. So as expected, I got no drc warnings for any of the examples.

I've tried connection find (a.k.a find.c, {c f}) on them, and that seemed 
to do the right thing for all cases.

Extending your test set:

http://igor2.repo.hu/tmp/drc4.pcb
http://igor2.repo.hu/tmp/drc5.pcb
http://igor2.repo.hu/tmp/drc6.pcb

These demonstrate that actual minimal overlap or minimal distance rules 
can be violated without DRC detection if objects are not part of the net. 
This is the case where your fab will start charging a lot without DRC 
warning you.

drc6 is a flag trickery: we do have clearline flag on the line but we do 
not have clearpoly flag on the polygon. This results in the same 
situation, no clearance, but with a different set of flags. We need to 
make sure this doesn't break either.

> - Any thoughts/discussion about the proposed solutions would be very
> healthy too.
> - What is the normal workflow to publish the patches, so they are
> included asap in mainline?

pcb-rnd: we use svn instead of sending or collecting or tracking patches. 
You still have your commit access. We are in feature development phase 
yet, very far from the pre-release code freeze. If you fix drc bugs, 
please feel free to commit them. I will review and comment (if needed) 
after the commit (I do get automatic notification of commits).

Your commits are accessible for pcb-rnd users immediately - and we have a 
strong, productive community and there are quiet a lot of hardcore folks 
using SVN HEAD even for production! So your changes are tested through 
fast. And of course, anything commited is included in the next release as 
well.

If you say yes to commiting your drc fixes in pcb-rnd, I can add the 
2-bbox system in the code today/tomorrow, so you don't need to worry 
about that part.

(Offtopic: you got your write access for the rubber band upgrade back 
then. You did a great job there; Ade went on building on top of your work 
and combined it with his rubber band extensions. You should check it out 
with either pcb-2.0.0 or SVN HEAD - the rubber band is so nice by now that 
even I started to use it, while I was a rubber-band-hater for a decade, 
lol)

Best regards,

Igor2

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019