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.
