kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

I verified using Novak's test case on the Launchpad bug report.  DRC error
is generated if the distance between the tracks is exactly equal to the
clearance.
If you increase the spacing by the minimum distance recognized by the
software's precision, the DRC passes.
So, I think it's an issue of DRC specification -- The code currently
requires that the clearance be *larger* than the minimum in the design
rules.
The diff pair router is setting the spacing to the minimum (exactly) which
causes this bug.

IMHO, the DRC code should be changed to "larger or equal to", but I am not
sure if there is some subtle reason why it is implemented this way.
If you tell KiCad that you can go down to 2mm clearance, you should be able
to design something with *exactly* 2mm clearance :-)

-Jon

On Mon, Feb 13, 2017 at 11:15 AM, Andy Peters <devel@xxxxxxxxx> wrote:

>
> > On Feb 13, 2017, at 2:06 AM, Clemens Koller <cko@xxxxxxxxx> wrote:
> >
> > Hello!
> >
> > If the global minimum mandatory clearance/spacing (pitch) of a design
> (due to manufacturing limitations) is set (& activated) it should complain
> when some other settings are violating that.
>
> I purposely set the differential gap and trace width to something higher
> than the global minimum to see if that would have an effect, and it didn’t.
>
> > It could be assisting if the user gets a clear warning when the
> differential pair dimensions violate the design limitations and then give
> options to
> > a) reset the differential pair dimenstion to the global minumum, which
> is x.
> > b) create an exception for the differential pairs (the DRC need to
> handle that).
> > c) adjust the global design limitations accordingly.
> >
> > If b) or c) is selected, the Ok button should be labelled with "Ok, I
> really know what I do..." ;-).
>
> Differential routing in the GAL canvas with “shove” as the default routing
> mode should result in never having a DRC clearance failure. Let’s expand on
> that — all routing in that mode should never result in a DRC clearance (or
> width) fail. I remember the first time I tried differential routing and it
> wouldn’t let me draw any traces because the default diff width/gap violated
> my global minimums.
>
> So the question is: what is the real source of the error? Is it in the
> routing algorithm that allows the user to place differential traces that
> violate the design rules, or is it, as Jon Evans wrote, an error in the
> post-routing DRC code?
>
> -a
>
> > On 2017-02-13 03:15, Jon Evans wrote:
> >> I took a quick look at the DRC code, and it looks like it is doing an
> exclusive check on the minimum distances for clearance -- i.e. it is
> requiring the clearance be greater than the minimum, not greater or equal.
> >> I'm not familiar enough with this part of the code to want to submit a
> patch for this now, but maybe someone who is familiar can comment on
> whether there is a reason that it is done this way.
> >>
> >> -Jon
> >>
> >> On Sun, Feb 12, 2017 at 8:08 PM, Andy Peters <devel@xxxxxxxxx <mailto:
> devel@xxxxxxxxx>> wrote:
> >>
> >>
> >>> On Feb 12, 2017, at 5:59 PM, Andy Peters <devel@xxxxxxxxx <mailto:
> devel@xxxxxxxxx>> wrote:
> >>>
> >>> I am using a nightly build from 26 January 2017 on a Mac.
> >>>
> >>> The design has a handful of differential pairs. I have set up design
> rules for most nets in the design as 1.6 mm trace width and 1.6 mm
> clearance. I created a net class for the pairs with those clearances and
> widths and made that the “diff pair width” and “diff pair gap” too.
> >>>
> >>> Then I set the “Differential Pair Dimensions” in the Dimensions menu
> to that same width and gap. Aside: why is this step necessary? Why doesn’t
> the differential routing use the net classes set up by default?
> >>>
> >>> I route the signals and run the DRC, and for every corner in the trace
> pairs, I get an ErrType(x): “Two Track Ends Too Close” complaint. Sometimes
> it’s ErrType(16), sometimes it’s ErrType(17), the rest ErrType(18), but
> they are for all corners. See the picture. This doesn’t make any sense.
> >>
> >>    This was reported as a bug over a year ago:
> https://bugs.launchpad.net/kicad/+bug/1533551 <https://bugs.launchpad.net/
> kicad/+bug/1533551>
> >>    _______________________________________________
> >>    Mailing list: https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> >>    Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx <mailto:
> kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >>    Unsubscribe : https://launchpad.net/~kicad-developers <
> https://launchpad.net/~kicad-developers>
> >>    More help   : https://help.launchpad.net/ListHelp <
> 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
> >>
> >
> > _______________________________________________
> > 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
>
> Andy Peters
> 5511 E Rosewood St
> Tucson, AZ 85711
> 520-907-2262
> devel@xxxxxxxxx
>
>
>
>
> _______________________________________________
> 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
>