← Back to team overview

kicad-developers team mailing list archive

Re: Improving usability of KiCad


>> I have several 1000-ball BGAs on a metric pitch.  Every other ball is off
>> its position by part of 1/10000th of an inch.  No problem?  Well when
>> pulling dogbones for BGA breakout, I wind up with about 1000 0.1mil segments
>> connecting the imperial gridded vias to the imperial gridded balls.  So
>> I tried unlocking the 45-degree tracks pulling slightly off 45-degrees so
>> that there were no 0.1mil segments.  Instead I got 1000 DRC errors (yeah,
>> its tight in there), and a thousand 0.0mil segments.  Then there is the
>> performance problems associated with drawing thousands of 0.1mil or 0.0mil
>> traces.  Hard locking to a 10 nanometer minimum grid would remove all these
>> problems.  Any time pads, pins or lands are on a metric pitch, the same
>> problems arise.
> Ouch!!!
>> The maximum precision allowed by RS-274X is 6.6 for metric, so it makes
>> sense to use 1 nanometer as the internal unit.
> I agree. i don't understand why Dick is so hard set against metric.
> Maybe if you uploaded your branch/fork to launchpad, and enough people
> started throwing their firewood on that fire, he might turn softer.
> Alex

Alex, I said nothing about metric.


I'd like to see support for both metric and imperial (which we mostly
have), along with the 3rd notion of integer based internal units.  The
problem we have now is that the granularity of the internal unit is not
fine enough to avoid round trip conversion errors.  The finer we go, the
more memory the internal "cell" based autorouter (in PCBNEW) needs, and
the longer it will take.  The change in memory and speed will likely be
related to the square in the granularity change.  So if you increase the
granularity by 100, then you'll need 10,000 times as much memory and
time to run it.

(So maybe you decide at that point to simply toss it out and use

If you take the autorouter off the table, then the question becomes, "is
there a downside to having granularity that is finer than you need?" 
This is a question, not a suggestion.


Here is a posting which claims to have found the greatest common
denominator, GCD, for a new internal unit:


Here is another opinion:


Here is the root of the thread:


Until we revise the file format for PCBNEW, along with a comprehensive
migration plan, including a *.brd board converter, the best we can do is
plan and summarize, and schedule for later completion.  A summarizing
paragraph could be formulated on this mailing list and then copied to a
blueprint after it is agreed to by a majority, inclusive of someone
willing to do the work.

That's about all I can think to say about it for now.


Follow ups