kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 05/07/2013 04:06 PM, Simon Huwyler wrote:
> 
>> If this feature would work neither with freerouter, nor Cern's push and 
>> shove router, then
>> it would be useless to me.
> 
> fair enough. Of course it has to be consistent with the whole package!
> 
>> I currently use freerouter in p&s mode exclusively, never route in kicad.
> 
> what? Actually, I've always seen freerouter just as an autorouter (and I 
> don't like autorouters). I never had the idea to manually route with it. 
> Will try this eventually.

Recommended.

Here is a memory aid for others:  Freerouter can be split into two words.

Free router.

I don't see auto in there, and I don't see push and shove in there.  But it does both.

It routes.





> I think I have seen that freerouter doesn't know layer constraints, but you 
> can tell net classes to be valid on certain layers. I personally still 
> think, my way is the better one. :-) But that's not the point. Because also 
> in this way, as I said, Kicad's constraint handler should be aware of the 
> different layers implement what freerouter does.
> 
>> Tom, if he had time might comment on the likelihood of support for 
>> something like this in
>> his p&s work for internal pcbnew.
> 
> Looking forward to that. But acually I don't think there will be a problem. 
> I think, Tom will "just" ask about clearances and do some (very complex) 
> stuff to avoid violations. How these clearances are calculated, I's suppose, 
> is not of interest to Tom's P&S router. Or am I wrong?
> 
> 
> 
> On 05/07/2013 11:30 AM, Simon Huwyler wrote:
>> I have worked a bit more on the idea of the “layer based constraints”. We
>> have already argued quite a bit about how one should tell KiCad about
>> different constraints on different layers. But I think, we all more or 
>> less
>> agree that there are realistic use cases where a constraint is not only
>> dependent on the net, but also on the layer (and maybe other things).
>>
>> So, the routine getConstraint() (with or without an ‘other’ item passed as
>> argument) should get another argument: LAYER_NUM aLayer, because, as soon 
>> as
>> the layer, in one way or the other, influences the minimal acceptable
>> clearance between different nets, I have to distinguish between these 
>> nets.
>> For all these connectedItems that are only on one layer (like tracks), the
>> item can just check on which layer it is, and return the appropriate 
>> value.
>> But there are also pads and vias. And here, it is not sufficient anymore 
>> to
>> just ask “what is the miminal clearance around you”? Instead, I have to 
>> ask:
>> What is the minimal clearance around you on layer two?” That’s why I
>> inserted the additional argument aLayer. Of course, I included it on all
>> connectedItems because of subtyping. A track, for example, just ignores it
>> and takes its own layer as a reference.
>>
>> Ok, then, I did another thing: ConnectedItems can show their clearance as 
>> a
>> line around the item, which is one of the best features of KiCad, if you 
>> ask
>> me. I LOVE this feature! But now, I had a problem with it. Again, if an 
>> item
>> is on only one layer, it’s fine. Just show the clearance according to the
>> layer of the track. But what about a pad? A pad can “sit” on all layers. 
>> So,
>> which clearance to show? Possible anwers:
>>
>> - none
>> - the net-based clearance (only feasable if we ARE separating net-based 
>> and
>> layer-based clearances, and not mixing them in any way)
>> - all clearances, in the respective color
>> - the clearance according to the layer that is currently active, if it is 
>> a
>> copper layer, and none if it is a non-copper layer.
>>
>> I, for my personal branch, decided to pick the last solution. But this
>> confronted me with another question: If I am on layer two, and there is a
>> multi-layer pad, a track on layer two and a track on layer one. What do I
>> expect to see?
>> I decided that I would like to see the clearances on layer two. Nothing
>> else. So, the pad shows me the clearance it has on layer two. And the pad,
>> that is on layer two, shows me its clearance, and the track on layer shows
>> no clearance line.
>> I hacked this behavior and must say that I like it. I never checkt 
>>  “always”
>> at “show tracks clearances”, because it was just too much information. But
>> with my patch, I now think I’m going to stay at this option. It shows my 
>> all
>> clearances I have to respect on the layer that is currentla active (a.e. 
>> the
>> layer on which I am placing tracks at the moment). After all, I don’t care
>> about a layer two’s clearance if I’m on layer one.
>>
>> I will upload a branch eventually so you guys can have a look at it. Not 
>> so
>> much to press my implementation of it into a release (there's no chance 
>> for
>> it, either ;-), but more to let you get a feeling of it, because I really
>> think this is an issue. I think, a good CAE tool should take the layer 
>> into
>> account when it comes to constraints. And as KiCad IS a very good tool, it
>> is proven by induction, that KiCad should be able to handle this! :-) Just
>> kidding....
>>
>> Now, there are still other things, like, for example, constraints between
>> two defined nets, area based constraints... all the fancy stuff. Of 
>> course,
>> we could add also these things as additional parameters... or we could 
>> pass
>> an object containing all important parameters an item has to know to
>> calculate the clearance. Or... hmmm... just a reference to the caller 
>> item:
>> - Item xy, tell me, please, how much clearance I have to keep to you. I am
>> item yz.
>> - Item yz, on what layer are you? And what’s your net?
>> - Ok, Item xy, please stay 2mm away from me.
>>
>> Oh, I almost forgot: There is another thing that, as I suppose, is quite
>> connected to this issue: Pads with defined pad-stacks. Say, I want to 
>> insert
>> a pad on the outer layers, but on the inner layers, there should be no
>> copper (or less copper). This surely influences the clearance. Again, the
>> clearance strongly depends on the layer on which I am approaching the pad.
>>
>>
>> What do you think? Is this worth a blue-print?
>> I really really like the idea of implementing such a thing. I am, 
>> actually,
>> now starting to work productively with my patch (but only as a hobbyist) 
>> and
>> up to now, I really like also the slightly changed look-and-feel as
>> described above.
>>
>> - I can define clearance and width constraints for every layer (which is, 
>> as
>> I said, very useful to me because of manufactuer’s constraints)
>> - I am shown all clearances (max of net-based and layer based) on the 
>> active
>> layer
>> - when I place a track with the “standard” thickness setting, it gets me 
>> the
>> actual thickness of the net on the layer I am.
>> - When I switch layers (a.e. place a via) the width changes according to 
>> the
>> new rules (same net, but different layer, again, the max i taken).
>> - It, of course, also gives me the the updated clearance.
>> - Pads: It shows me the clearance for the actual layer (or none, of it is
>> not a copper layer).
>> - copper fills are taking taking care of the different layer constraints
>> around pads.
>> - DRC I didn’t check intensively yet, but should work.
>>
>> I am very well aware that it’s a bad idea to just take this first
>> realization into the main branch instead of really thinking about future
>> features, and how to do it right. As I said, I don't intend this branch to
>> be merged as-is, but more as a basepoint for some discussion.
>>
>>
>> Greets
>> Simon
>>
>>
>> -----Ursprüngliche Nachricht----- 
>> From: Dick Hollenbeck
>> Sent: Sunday, April 28, 2013 3:12 PM
>> To: kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Subject: Re: [Kicad-developers] layer based constraints
>>
>> On 04/27/2013 12:10 PM, Lorenzo Marcantonio wrote:
>>> On Sat, Apr 27, 2013 at 11:11:54AM -0500, Dick Hollenbeck wrote:
>>>> But how important is that really?  Will it result in a reduction in pay?
>>>>
>>>> The "common" user has been a hobbyist, and is becoming a corporate
>>>> employee as the
>>>> software gets better.
>>>
>>> OK, even most of the corporate employees have probably 0% of
>>> understanding a boolean expression. Unless he's a digital designer :D
>>> woes on him in that case
>>>
>>>> So while I agree, I think the importance of this concern is minimal.
>>>> Actually zero.
>>>> If we like it, that should be good enough.  We are corporate employees,
>>>> and are paying to
>>>> make this software useable for our needs.  You said yourself the same
>>>> thing.
>>>
>>> Agree on that. But if it's possible to make it usable for the
>>> non-programmer people (without too much work) then it's better.
>>> Otherwise I'd looking for components using grep instead of the component
>>> browser for example (the sad thing is that often grepping is more
>>> effective...)
>>>
>>>> Great idea, do it.  It seems we are all still open to the best ideas.
>>>
>>> In a previous message I wrote about how CAM350/gerbtool do DRC. The CAM
>>> products are for 60% DRC beasts so they know how to do their job:D
>>>
>>> Eagle has a simple netclass-to-netclass clearance. I haven't used any
>>> other of the 'big ones' (Altium, Allegro, PADS or Expedition) so I don't
>>> really know how they handle it. Many entry level products don't have even
>>> a netclass notion, so we already are way above them:D
>>>
>>>> Is there a way we can provide a python expression, but do most of the
>>>> work in C++?, by
>>>> implementing the functions being called in C++ behind the expression, by
>>>> following the
>>>> python C API.
>>>>
>>>> This is a slight variation on the original idea, which can be a way to
>>>> turbo charge it,
>>>> maybe to cut out a few lookups at runtime.
>>>>
>>>> Obviously the python expressions can all be "pre-compiled", but I don't
>>>> think they can be
>>>> "pre-evalutated" when "both" is in play, since that is a dynamic match
>>>> maker.
>>>
>>> Caching (memoizing, actually) strategies for the python calls would
>>> depend on the data available to the call. Assuming the function is pure
>>> (i.e. depending only on the passed parameters) you could cull *a lot* of
>>> calls.
>>>
>>> Example (in C, I don't know python enough): function returning
>>> the clearance (one of the contended values) between two netclasses and
>>> the current layer; with only the minimum data we'd have:
>>>
>>> int dynamic_clearance(const char *netclass1, const char *netclass2,
>>>                       const char *layer);
>>>
>>> *iif* the implementation is pure, as from the hypothesis, there are no
>>> external dependancies and no collateral effects so *every* call with
>>> a tuple (triplet) would always return the same value. Put it in a map
>>> (memoize it) and you have just resolved the clearance issues between
>>> these two classes on that layer with just one python call. AFAIK
>>> memoizing is a standard idiom in python, too.
>>>
>>> More flexibility reduces optimization possibilities. Let's say we pass
>>> the netnames too (don't ask why, maybe the user wants more granularity
>>> than netnames, no idea)
>>>
>>> int dynamic_clearance(const char *netclass1, const char *netclass2,
>>>                       const char *netname1, const char *netname2,
>>>                       const char *layer);
>>>
>>> Here memoizing is a lot less effective... you only cache clearance
>>> between two nets (the netclasses are actually redundant and passed as
>>> convenience). However you would optimize the common case of buses
>>> wandering around the board. Still a good improvement, probably.
>>>
>>> At the other end, if the decision function has the whole segment
>>> information at hand:
>>>
>>> int dynamic_clearance(const char *netclass1, const char *netclass2,
>>>                       const char *netname1, const char *netname2,
>>>                       const char *layer, int stuff, int other_stuff...)
>>>
>>> Then we gain *no* performance since (ideally) every segment is tested
>>> against any other segment just once. In fact caching overhead would
>>> probably make it slower than without.
>>>
>>> That said, maybe a python call is just so fast that the big time is
>>> spent computing distances maybe. Or the bottleneck is in the string
>>> comparison. If it was LUA instead of Python I'd say to directly call the
>>> function without any doubt (LUA strings are interned so the string
>>> equality is pointer equality for example, and the byte code interpreter
>>> is... well, fast).
>>>
>>> As you said instrumented profiling is needed, at least to compare the 
>>> cost
>>> of a python call to the rest of the stuff in the DRC routines.
>>
>>
>> Caching is an interesting idea to keep in our toolbox.  I think C++ has 
>> some
>> great
>> potential in developing some wrapper classes for making use of python
>> expessions fairly
>> painless.  It is an area I hope to contribute to when I have some more 
>> time.
>>
>> Each year we host a large memorial day party here at the ranch, and often
>> have a pig roast
>> on a spit.  The preparations for that can get overwhelming and start weeks
>> in advance.  So
>> this has reached full scale as of this weekend.  Time is more scarce than
>> ever.
>>
>> Dick
>>
>>
>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
> 
>