kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

Le 10/01/2014 18:35, Maciej Sumiński a écrit :
> 
> On 01/09/2014 04:51 PM, jp charras wrote:
>> Le 09/01/2014 11:22, Tomasz Wlostowski a écrit :
>>> On 01/08/2014 04:39 PM, jp charras wrote:
>>>
>>>> Tracks do not store the net name but just the net code, because they
> are
>>>> expected to be connected to pads which store this info.
>>>> (this is the reason tracks and vias not connected to a pad lose their
>>>> net after loading a board, or reading a netlist)
>>>> Therefore, after loading a board, or reading a netlist, the track net
>>>> code should be initialized, but you have to store this net name in
> pads.
>>>> (Of course, one can use an other way to store net names, and an other
>>>> way to calculate net codes)
>>>
>>> Hi Jean-Pierre,
>>>
>>> I see another point in modifying the net assignment mechanism. If we
>>> allow tracks/vias to retain net names and propagate them from the pads
>>> only when the schematic netlist has changed (not every time the board is
>>> loaded), it would also fix the infamous zone stitching issue...
>>>
>>> Regards,
>>> Tom
>>>
>>>
>>
>> Stitching vias and generally speaking not connected (to a pad) items
>> (stitching vias, usual vias and tracks) create an other problem than
>> retaining the net name.
>>
>> Retaining the net name of items not connected to a pad (or a zone) items
>> is easy to fix (I already received a patch to do that).
>>
>> But the major issue is:
>> if the net names are retained in not connected (to a pad) items, all
>> track ends and vias should be included in the ratsnest generation.
>> Otherwise, we will have not connected vias and/or not connected copper
>> zone areas (floating copper islands).
>> This is the only one reason stitching vias do not exist in Pcbnew.
>>
>> Therefore fixing stitching vias issue is:
>> 1 - finish and validate (this is the more important step toward
>> stitching vias) the new ratsnest algorithm which takes in account
>> pad+vias+track ends: mainly for very complex boards, see if it is fast
>> enough.
> 
> This is done by the ratsnest algorithm we added for the GAL (it is
> currently available in the testing branch). I have to admit that it
> probably is slower, but it is hard to keep the performance when amount
> of data for computation increases. The toughest test case I have by hand
> is the board that I recommended for testing the GAL
> (http://www.ohwr.org/attachments/download/2187/wrs.kicad_pcb), when you
> drag the biggest IC in the middle, as it contains the greatest number of
> nets connected. After being dropped you may observe a freeze for a short
> time, it is the ratsnest algorithm going - we have to decide if it is
> acceptable.

wrs.kicad_pcb is a decent board for tests.

The GAL ratsnest shown when moving a large footprint is very fast, no
problem.
(I tested also an other large board, and the ratsnest is also fast)

> 
>> The current ratsnest algorithm is very fast for 6000 pads (50 ms on my
>> computer).
>> What happen for 10x to 20x more (roughly 6000 pads + 30000 tracks (2
>> point) and 3000 vias for instance)
>> 2 - after this, Retaining the net name of items not connected.
>> And be sure the calculation time to know if 2 items are connected by a
>> zone area is fast. Currently, this is 90% of calculation time.
>> Because stitching vias will create a *lot* of items connected by zones,
>> the calculation time in a very important criteria.
> 
> We take it into account during the ratsnest calculation. I agree, it
> takes the biggest amount of time, but still on a decent hardware is
> acceptable (at least in my opinion, I would like to know other views).

The current GAL ratsnest calculation is fast.
Just keep in mind this is to find connections by copper areas which are
time consuming.

I do not know if you are using my code for this, or a new code you wrote.

If it is my code, I am using an usual algorithm to determine if a via,
pad or track end is inside a copper polygon.
I am thinking it could be optimized to be faster (for instance
considering the fact most of large copper polygon areas are built mainly
from very small segments, and have very few long lines.)

> 
>> 3 - add tools to change items net names, when a net name has changed in
>> schematic (for instance AGND changed to GND) (easy, obviously, but
> needed)
> 
> I think this could be handled easily if net names were kept in
> NETINFO_ITEM and D_PAD stored only net code or a pointer to the
> appropriate data.

This is certainly easy, but must be done...

> 
>> I know the ratsnest need to be rebuild only for the modified net (this
>> is also currently the case).
>> But the full ratsnet need to be fully rebuild, for instance when
>> existing copper zones are modified (when creating/moving a via, for
>> instance).
>> This is frequently the case, for complex boards.
> 
> Until now, when I was not aware of the fact that net codes are a subject
> to change - I indexed all items by their net codes and if anything was
> modified, I checked its netcode and recalculated this. This also applies
> to zones, vias and tracks. This is one of reasons why I wanted to keep
> net codes constant during a single run time.

Net codes are subject to change only after reading a netlist.
Adding new net name is not allowed in pad edit dialog, and there is no
reason to add a new net name in a board, outside the schematic.

> 
>> In Altium, you need to deactivate (shelve) copper polygons to be able to
>> work on you boards when the calculation time is too long...
> 
> I did not think of this, but actually it is a good hint to reduce
> computation time if user wants to do so.

It is a good hint only for calculation time.
When you deactivate a copper pour, (this is *exactly* like when you
remove the zone filling in Pcbnew) the corresponding ratnest is no more
usable (you do not know anymore what is actually connected, and what do
you connect), and this is very bad for the user.
Power planes and split planes are other (poor) tricks to try to reduce
the calculation time.
But from my point of view, planes are poor features, because they are
not (by far) as good as true polygons.
The idea behind these planes is just to forbid tracks on these planes to
avoid connection calculations (hard to call it "a good idea": in the
better case this is just an idea).

> I already have the first changes proposal. As they are related to the
> KiCad's core, it is very important to me if you could assess if they are
> suitable to commit before I move on. If you have some spare time, please
> have a look at the lp:~cern-kicad/kicad/netnames branch.
> If in your opinion they do not break anything, the next step I wanted to
> do is to remove m_Netname/m_ShortNetname fields, move
> GetNetname()/GetShortNetname() to BOARD_CONNECTED_ITEM and make them use
> net names stored in NETINFO_ITEMs.

I am thinking it should break nothing.
But do not forget to keep a trace of the origin of net names: those
which are in netlist (in schematic) and those from existing items not
connected to a pad (currently, only the zones, but could be also not
connected vias and track segments) which have net names not found in
netlist.
We need to display a DRC error, and to be able to change the non
existent net names, or to delete corresponding items.

> 
> Regards,
> Orson
> 

Thanks for you work.

-- 
Jean-Pierre CHARRAS