kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/26/2013 09:43 AM, Tomasz Wlostowski wrote:
> On 04/26/2013 04:08 PM, Simon Huwyler wrote:
>> One more thing: I agree that the additional numbers may confuse a bit.
>> So, why not just insert a check box named: "Use layer based constraints"?
> 
> Hi Simon,
> 
> I agree that such constraints are very useful, I use them frequently in 
> Altium, but this is only a small piece of the whole DRC machinery that 
> needs to be rewritten. A makeshift patch to the current DRC code will 
> only make it more difficult to fix properly in the future, for instance 
> by keeping these extra rules hardcoded in PCB files (that any newer 
> release will have to parse to keep compatibility).
> 
> For example, what about area-bound clearance/width constraints (i.e. 
> different clearance values for different parts of the PCB?). Why not 
> just insert another checkbox named "Use area based constraints" next to 
> yours and store a few more parameters in the .kicad_pcb file? Then 
> someone else comes up with yet another specialized constraint, and we'll 
> end up with bloated GUI and mess in code.
> 
> What about simply letting users specify a set of boolean expressions 
> that return the clearance for a pair of objects to be checked. For example:
> 
> 1. both.GetLayer() in ['Top', 'Bottom']: 10 mil
> 2. not both.GetLayer() in ['Top', 'Bottom']: 14 mil
> 3. first.InArea ('My area'): 20 mil else: 10 mil
> 4. any.InComponent ('Some BGA that needs smaller clearance'): 5 mil
> 5. default: 10 mil
> 
> .... and so on, and so forth, for any DRC check.
> 
> These can be python expressions, evaluated through the scripting engine 
> for each item before starting the DRC.
> 
> The advantages are:
> - no need to change DRC's C++ code and/or GUI whenever somebody requests 
> a fancy constraint configuration
> - rule expressions can be stored in .kicad_pcb files without risk of 
> being deprecated (unless somebody changes the API of the scripting engine).
> - P&S must follow design rules as well. I would prefer get the clearance 
> value for any pair of objects directly via scripting engine  instead of 
> parsing and analyzing all specialized constraints again in P&S code.
> - automatic trace impedance calculation via python expressions:
> 
> both.IsDiffPair() && both.GetLayer() == 'Top'  : 
> DifferentialMicrostrip(first, second).Gap
> 
> Regards,
> Tom


both is a python object that is visible to C++ that is stuffed at each distance test point
in the DRC?  At least one of the two members would need to be updated on each compare.

It will definitely be a bottleneck.  Maybe we should measure how bad soon, otherwise this
is a suggestion which serves as a roadblock to progress, and the roadblock itself it not
currently a solution.

The idea is innovative, and if it is not like watching snails race, it may have some merit.

Dick