← Back to team overview

kicad-developers team mailing list archive

Re: Experiments and considerations for more layer

 

Lorenzo,

On Tue, 03 Sep 2013, Lorenzo Marcantonio wrote:

> On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote:
> > Mid-term in the wrong direction.  Kicad is like that...
> 
> Look. I have this board due to fabrication for the end of month.
> I simply can't implement the whole object model in time *and* do the
> board layout to produce it.
> 
> It's a human resource allocation problem :D it's a temporary solution
> but *it works*; the optimal solution is not useful if it's not available
> for use.
> 
> The kicad object model is not perfect (and anyway everyone has its own
> idea of perfect model), but kicad itself is not exactly small. Probably
> only you and me know exactly how many time a layer type is
> used/iterated/converted in pcbnew:P
> 
> Also if you remember even my type cleanup was partially rejected
> becaused they wanted to keep layers as 'simple integer'. And if was
> actually a little more than a typedef. A mergeable layerset
> implementation would require a full layer class and other objects (as
> you said, correctly), but I simply don't think that would be accepted by
> the 'steering commitee' of kicad:P I don't like, too, the asymmetry
> between the board layer structure (renameable) and the module one (the
> 'standard english'). Going generic requires a pervasive layer container
> (call it stackup or whatever) and layers would then coordinate with
> their own container, or something like that.
> 
> In short, I perfectly agree with you but I don't think is feasible to
> propose such a big change (which is mostly a management issue). I almost
> got lynched when I proposed switching to enums from #defines.. (reason:
> you have to type the containing namespace, too)

I hear you.

But for conjecture sake (nothing will ever really change in kicad),
consider this: someone though that because bit masks are fast that
it would be a simplification to take each mask and ALWAYS COMPARE IT
TO EVERY FEATURE ON THE BOARD, EACH TIME!

Better way: remember what items are on what layers.  That's what I
did.  What's on copper layer 4?  Kicad makes a bitmask for copper
layer 4 and then compares its (mask and match) to every feature on
the board just to get the list of whats currently on copper layer
4.  What I do: when the feature is defined to exist on copper layer
4, I add it to the copper layer 4 LAYER_SET.  Want to know whats on
copper layer 4 now?  Just iterate over the copper layer 4 layer set.
Kicad must first assemble the set on each request, and then throws
it away after each request.  It must still iterate over the set.
I just iterate over the set because it is always assembled.  I save
all the masking operations.

Want to generate a Gerber for copper layer 4?  Just iterate.  No
masking required.


> > funner stuff was the simulated annealing for location of items in the
> > vicinity of another.
> 
> ? What would be that for ? hit testing or drc? and why annealing instead
> of a circular sweep or similar?

Because you can't precalculate a circular sweep.

The same as layers is true for locality.  Want to know what is close
to board item 14951?  Kicad compares its geometrical distance to
EVERY OTHER ITEM ON THE BOARD, EACH TIME!  Using crude integer math
none the less.  What I do: break the board into cells.  When an item
is placed on the board it is added to the set of items of the cells
which it occupies.  Want to know what's close to board item 14951?
Use the union of the members of the set of cells a clearance distance
from its shape (precalculated when it is placed) and simply iterate
over the union.  Then do full blown floating point math on this
(often empty) set to calculate exact clearances.

Performing a union of sets of layers and cells you can find what
is close on adjacent layers without masking a without integer
math calculations.  Performace: way faster.  Improvements over
100 fold.  Memory footprint: somewhat larger.   But lots of
memory is much cheaper than more faster processors.

--brian

-- 
Brian F. G. Bidulock    � The reasonable man adapts himself to the �
bidulock@xxxxxxxxxxx    � world; the unreasonable one persists in  �
http://www.openss7.org/ � trying  to adapt the  world  to himself. �
                        � Therefore  all  progress  depends on the �
                        � unreasonable man. -- George Bernard Shaw �


Follow ups

References