kicad-developers team mailing list archive

[Maciej Sumiński <maciej.suminski@xxxxxxx>]

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.

> 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).

> 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.

> 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.

> 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.
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.

Regards,
Orson