Re: [Kicad-developers] Net names and net codes

[jp charras]

Le 28/01/2014 10:51, Maciej Sumiński a écrit :
> Hi Jean-Pierre,
> 
> I am done with the changes that would let me rely on the net codes in
> other parts of code. I did my best to perform tests and put comments to
> each commit, so they could be easier to understand and verify.
> Could you please have a look at the lp:~cern-kicad/kicad/netnames
> branch? If you think the proposed changes do not break anything, I would
> be grateful for merging the branch. Thank you in advance.
> 
> Regards,
> Orson

Sorry for the delay.

I hope many guys who are on the kicad-developers list have tested you code.

I made some tests and did not found any issue.
I need more time to test corner cases.

Just, currently, when a net does not exist no more in schematic, the DRC
does not display a warning, when this net is used by a zone.
But, still, I need some time to find the better idea to fix this kind of
issue (the right answer to this issue is not easy: there are some corner
cases (at least one: an one pad net) ).

Thanks, Orson, you are doing a great work.


-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

I'm glad you like it. You did most of the work by eliminating the statics
in the triangulator.

I have not tested it under any other platform than Linux, but it's supposed
to work under MSVC++ as well.


On Fri, Jan 31, 2014 at 12:01 PM, Maciej Sumiński
wrote:

> Hi Carl,
>
> Great job! I have just tested your patch and I confirm 2x boost on my
> machine as well. To tell the truth, I consider this a big speedup -
> particularly that you made it with just a few lines of code.
> RN_DATA::Recalculate() is run every time when there are changes on the
> board (e.g. items are moved/rotated/etc.) - it checks which nets where
> modified and updates the ratsnest for them.
> Speeding up the computation while parts are moved is obviously desired,
> but a bit harder to obtain, as GAL drawing functions are not thread-safe
> and it's not that easy to make them so. The main reason is that all items
> to be drawn are saved in a common buffer, so that has to be synchronized ->
> I expect a very little boost, if any. On the other hand, this type of
> ratsnest is not as demanding as the one you have accelerated in terms of
> CPU cycles.
> Thank you for the efforts. I will propose your changes for merging next
> week, together with some new features related to the ratsnest and tools.
>
> Regards,
> Orson
>
>
> On 01/31/2014 04:17 PM, Carl Poirier wrote:
>
>> Hi Maciej,
>>
>> Your last changes allow a complete independence of the loop iterations
>> in RN_DATA::Recalculate( int aNet ).
>>
>> I have almost a 2x speedup on a Core i7-4770 with the very simple
>> parallelization in the attached patch. I was expecting more, though.
>> There seems to be a bottleneck somewhere. I have a question, however.
>> Did you want to speedup the computation when you move the part? From
>> what I see, RN_DATA::Recalculate( int aNet ) is run only when the user
>> loads the board. Am I missing out on something?
>>
>> BTW, I've included in the patch some output to measure computation time,
>> which obviously is not meant to be committed. I have also added the
>> required build flag at the top of the CMakeLists.txt, because I don't
>> know exactly where it should go in it.
>>
>> Carl
>>
>>
>> On Tue, Jan 28, 2014 at 4:51 AM, Maciej Sumiński
>> mailto:maciej.sumin...@cern.ch>> wrote:
>>
>> Hi Jean-Pierre,
>>
>> I am done with the changes that would let me rely on the net codes
>> in other parts of code. I did my best to perform tests and put
>> comments to each commit, so they could be easier to understand and
>> verify.
>> Could you please have a look at the lp:~cern-kicad/kicad/netnames
>> branch? If you think the proposed changes do not break anything, I
>> would be grateful for merging the branch. Thank you in advance.
>>
>> Regards,
>> Orson
>>
>> On 01/11/2014 05:31 PM, jp charras wrote:
>>
>> 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

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

Hi Carl,

Great job! I have just tested your patch and I confirm 2x boost on my 
machine as well. To tell the truth, I consider this a big speedup - 
particularly that you made it with just a few lines of code.
RN_DATA::Recalculate() is run every time when there are changes on the 
board (e.g. items are moved/rotated/etc.) - it checks which nets where 
modified and updates the ratsnest for them.
Speeding up the computation while parts are moved is obviously desired, 
but a bit harder to obtain, as GAL drawing functions are not thread-safe 
and it's not that easy to make them so. The main reason is that all 
items to be drawn are saved in a common buffer, so that has to be 
synchronized -> I expect a very little boost, if any. On the other hand, 
this type of ratsnest is not as demanding as the one you have 
accelerated in terms of CPU cycles.
Thank you for the efforts. I will propose your changes for merging next 
week, together with some new features related to the ratsnest and tools.


Regards,
Orson

On 01/31/2014 04:17 PM, Carl Poirier wrote:

Hi Maciej,

Your last changes allow a complete independence of the loop iterations
in RN_DATA::Recalculate( int aNet ).

I have almost a 2x speedup on a Core i7-4770 with the very simple
parallelization in the attached patch. I was expecting more, though.
There seems to be a bottleneck somewhere. I have a question, however.
Did you want to speedup the computation when you move the part? From
what I see, RN_DATA::Recalculate( int aNet ) is run only when the user
loads the board. Am I missing out on something?

BTW, I've included in the patch some output to measure computation time,
which obviously is not meant to be committed. I have also added the
required build flag at the top of the CMakeLists.txt, because I don't
know exactly where it should go in it.

Carl


On Tue, Jan 28, 2014 at 4:51 AM, Maciej Sumiński
mailto:maciej.sumin...@cern.ch>> wrote:

Hi Jean-Pierre,

I am done with the changes that would let me rely on the net codes
in other parts of code. I did my best to perform tests and put
comments to each commit, so they could be easier to understand and
verify.
Could you please have a look at the lp:~cern-kicad/kicad/netnames
branch? If you think the proposed changes do not break anything, I
would be grateful for merging the branch. Thank you in advance.

Regards,
Orson

On 01/11/2014 05:31 PM, jp charras wrote:

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.

   

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

Hi Maciej,

Your last changes allow a complete independence of the loop iterations
in RN_DATA::Recalculate( int aNet ).

I have almost a 2x speedup on a Core i7-4770 with the very simple
parallelization in the attached patch. I was expecting more, though. There
seems to be a bottleneck somewhere. I have a question, however. Did you
want to speedup the computation when you move the part? From what I
see, RN_DATA::Recalculate( int aNet ) is run only when the user loads the
board. Am I missing out on something?

BTW, I've included in the patch some output to measure computation time,
which obviously is not meant to be committed. I have also added the
required build flag at the top of the CMakeLists.txt, because I don't know
exactly where it should go in it.

Carl


On Tue, Jan 28, 2014 at 4:51 AM, Maciej Sumiński wrote:

> Hi Jean-Pierre,
>
> I am done with the changes that would let me rely on the net codes in
> other parts of code. I did my best to perform tests and put comments to
> each commit, so they could be easier to understand and verify.
> Could you please have a look at the lp:~cern-kicad/kicad/netnames branch?
> If you think the proposed changes do not break anything, I would be
> grateful for merging the branch. Thank you in advance.
>
> Regards,
> Orson
>
> On 01/11/2014 05:31 PM, jp charras wrote:
>
>> 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 + 3 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 

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

Hi Jean-Pierre,

I am done with the changes that would let me rely on the net codes in 
other parts of code. I did my best to perform tests and put comments to 
each commit, so they could be easier to understand and verify.
Could you please have a look at the lp:~cern-kicad/kicad/netnames 
branch? If you think the proposed changes do not break anything, I would 
be grateful for merging the branch. Thank you in advance.


Regards,
Orson

On 01/11/2014 05:31 PM, jp charras wrote:

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 + 3 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 v

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

Hi Maciej,

I will do very soon as well as send you a patch for my changes.

Carl


On Mon, Jan 27, 2014 at 5:47 AM, Maciej Sumiński wrote:

> That is a good start, I hope we can get even more performance boost now.
> Could you please try the lp:~cern-kicad/kicad/ratsnest_threadsafe branch
> to check if it solves the problem with createDelaunay() function?
> It would be great if you shared your changes (especially if they crash the
> application), so I could test them as well and look for fixes.
>
> Regards,
> Orson
>
>
> On 01/24/2014 04:35 PM, Carl Poirier wrote:
>
>>
>> I think that we will have a very great speedup if each thread can have
>> its own Triangulation. Just by parallelizing the loop in
>> RN_DATA::recalculate() but going sequentially with one Triangulation, I
>> still have ~25% gain in calculation time.
>>
>> On Wed, Jan 22, 2014 at 2:59 PM, Maciej Sumiński
>> mailto:maciej.sumin...@cern.ch>> wrote:
>>
>> Hi Carl,
>>
>> Thank you for putting efforts to boost the performance of the
>> ratsnest.
>> The function is brought by an external library
>> (http://www.sintef.no/__Projectweb/Geometry-Toolkits/__TTL/
>> <http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/>), I am not
>>
>> sure what is exactly inside. The expected output should be a
>> Delaunay triangulation of all nodes that are taken into account
>> while computing ratsnest.
>> The only issue I am aware of, is the function does not handle well
>> empty containers, but it should not be the case right now.
>>
>> Now, when I looked again to the source code, RN_DATA is derived
>> after hed::Node class (include/ttl/halfedge/__hetriang.h), which
>>
>> contains a static field. Another thing is (I believe this is the
>> main source of troubles) static hed::Triangulation
>> (include/ttl/halfedge/__hetraits.h:73).
>>
>> Sorry that I did not say about that before, but I have just
>> discovered that it is done that way. I will try to change it, but
>> unfortunately there are little chances that I manage to do that
>> before Sunday.
>>
>> Regards,
>> Orson
>>
>>
>>
>> On 01/22/2014 06:08 PM, Carl Poirier wrote:
>>
>> Maciej,
>>
>> Can you summarize to me how the function
>> "Triangulation::__createDelaunay(
>>
>> nodes.begin(), nodes.end() )" works, and what are the data
>> structures
>> involved?
>>
>> I believe there are some dependencies in there.
>>
>>
>> On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
>> mailto:cirilo_berna...@yahoo.com>
>> <mailto:cirilo_bernardo@yahoo.__com
>> <mailto:cirilo_berna...@yahoo.com>>> wrote:
>>
>>   >__
>>
>>   > From: Carl Poirier > <mailto:carl.poirie...@gmail.com>
>>  <mailto:carl.poirier.2@gmail.__com
>>
>> <mailto:carl.poirie...@gmail.com>>>
>>   >To: Marco Serantoni >     <mailto:marco.serant...@gmail.com>
>>  <mailto:marco.serantoni@gmail.__com
>>
>> <mailto:marco.serant...@gmail.com>>>
>>   >Cc: Kicad Developers
>> > <mailto:kicad-developers@lists.launchpad.net>
>>  <mailto:kicad-developers@__lists.launchpad.net
>>
>> <mailto:kicad-developers@lists.launchpad.net>>>
>>
>>   >Sent: Wednesday, January 22, 2014 3:51 AM
>>   >Subject: Re: [Kicad-developers] Net names and net codes
>>   >
>>   >
>>   >
>>   >There are some things in the code that don't like being
>>  multithreaded. If I parallelize the for loop in
>>  RN_DATA::Recalculate( int aNet ), I get a segfault. It does
>> not
>>  happen if I put a lock to the call updateNet( i ), but
>> obviously
>>  there is no increase in performance. I'm trying to find out
>> what's
>>  the problem now.
>>   >
>>   >
>>   >
>>  This sounds to me like data is being altered by different
>> threads
>>  and possibly there is some memory reallocation happenin

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

That is a good start, I hope we can get even more performance boost now. 
Could you please try the lp:~cern-kicad/kicad/ratsnest_threadsafe branch 
to check if it solves the problem with createDelaunay() function?
It would be great if you shared your changes (especially if they crash 
the application), so I could test them as well and look for fixes.


Regards,
Orson

On 01/24/2014 04:35 PM, Carl Poirier wrote:


I think that we will have a very great speedup if each thread can have
its own Triangulation. Just by parallelizing the loop in
RN_DATA::recalculate() but going sequentially with one Triangulation, I
still have ~25% gain in calculation time.

On Wed, Jan 22, 2014 at 2:59 PM, Maciej Sumiński
mailto:maciej.sumin...@cern.ch>> wrote:

Hi Carl,

Thank you for putting efforts to boost the performance of the ratsnest.
The function is brought by an external library
(http://www.sintef.no/__Projectweb/Geometry-Toolkits/__TTL/
<http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/>), I am not
sure what is exactly inside. The expected output should be a
Delaunay triangulation of all nodes that are taken into account
while computing ratsnest.
The only issue I am aware of, is the function does not handle well
empty containers, but it should not be the case right now.

Now, when I looked again to the source code, RN_DATA is derived
after hed::Node class (include/ttl/halfedge/__hetriang.h), which
contains a static field. Another thing is (I believe this is the
main source of troubles) static hed::Triangulation
(include/ttl/halfedge/__hetraits.h:73).
Sorry that I did not say about that before, but I have just
discovered that it is done that way. I will try to change it, but
unfortunately there are little chances that I manage to do that
before Sunday.

Regards,
Orson



On 01/22/2014 06:08 PM, Carl Poirier wrote:

Maciej,

Can you summarize to me how the function
"Triangulation::__createDelaunay(
nodes.begin(), nodes.end() )" works, and what are the data
structures
involved?

I believe there are some dependencies in there.


On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
mailto:cirilo_berna...@yahoo.com>
<mailto:cirilo_bernardo@yahoo.__com
<mailto:cirilo_berna...@yahoo.com>>> wrote:

  >__
  > From: Carl Poirier mailto:carl.poirie...@gmail.com>
 <mailto:carl.poirier.2@gmail.__com
<mailto:carl.poirie...@gmail.com>>>
  >To: Marco Serantoni mailto:marco.serant...@gmail.com>
 <mailto:marco.serantoni@gmail.__com
<mailto:marco.serant...@gmail.com>>>
  >Cc: Kicad Developers
mailto:kicad-developers@lists.launchpad.net>
 <mailto:kicad-developers@__lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>>>

          >Sent: Wednesday, January 22, 2014 3:51 AM
  >Subject: Re: [Kicad-developers] Net names and net codes
  >
  >
  >
  >There are some things in the code that don't like being
 multithreaded. If I parallelize the for loop in
 RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
 happen if I put a lock to the call updateNet( i ), but
obviously
 there is no increase in performance. I'm trying to find out
what's
 the problem now.
  >
  >
  >
 This sounds to me like data is being altered by different
threads
 and possibly there is some memory reallocation happening
(growing
 arrays, etc). Locks are only needed when there is contention
 somewhere and of course locks should only be held for as
short as
 needed. Another pitfall with threading is that some
variables may
 need to be declared 'volatile' if they can be altered in
another
 thread while one function is executing. For example, let's
say the
 variable 'bool someX' can be altered in 2 threads;
something like
 this can happen:

 1. FunctionA starts, and runs a loop while(!someX) { ... }
 2. FunctionB sets 'someX' to 'true'
 3. FunctionA continues to run the loop, which is not the
intended
 behavior

 Of course similar things can happen when using shared
memory and
 forked processes.

 Threading has other problems to watch out for - for
example, are
 there any static variables in fun

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

I think that we will have a very great speedup if each thread can have its
own Triangulation. Just by parallelizing the loop in RN_DATA::recalculate()
but going sequentially with one Triangulation, I still have ~25% gain in
calculation time.

On Wed, Jan 22, 2014 at 2:59 PM, Maciej Sumiński wrote:

> Hi Carl,
>
> Thank you for putting efforts to boost the performance of the ratsnest.
> The function is brought by an external library (http://www.sintef.no/
> Projectweb/Geometry-Toolkits/TTL/), I am not sure what is exactly inside.
> The expected output should be a Delaunay triangulation of all nodes that
> are taken into account while computing ratsnest.
> The only issue I am aware of, is the function does not handle well empty
> containers, but it should not be the case right now.
>
> Now, when I looked again to the source code, RN_DATA is derived after
> hed::Node class (include/ttl/halfedge/hetriang.h), which contains a
> static field. Another thing is (I believe this is the main source of
> troubles) static hed::Triangulation (include/ttl/halfedge/hetraits.h:73).
> Sorry that I did not say about that before, but I have just discovered
> that it is done that way. I will try to change it, but unfortunately there
> are little chances that I manage to do that before Sunday.
>
> Regards,
> Orson
>
>
>
> On 01/22/2014 06:08 PM, Carl Poirier wrote:
>
>> Maciej,
>>
>> Can you summarize to me how the function "Triangulation::createDelaunay(
>> nodes.begin(), nodes.end() )" works, and what are the data structures
>> involved?
>>
>> I believe there are some dependencies in there.
>>
>>
>> On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
>> mailto:cirilo_berna...@yahoo.com>> wrote:
>>
>>  >
>>  > From: Carl Poirier > <mailto:carl.poirie...@gmail.com>>
>>  >To: Marco Serantoni >     <mailto:marco.serant...@gmail.com>>
>>  >Cc: Kicad Developers > <mailto:kicad-developers@lists.launchpad.net>>
>>
>>  >Sent: Wednesday, January 22, 2014 3:51 AM
>>  >Subject: Re: [Kicad-developers] Net names and net codes
>>  >
>>  >
>>  >
>>  >There are some things in the code that don't like being
>> multithreaded. If I parallelize the for loop in
>> RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
>> happen if I put a lock to the call updateNet( i ), but obviously
>> there is no increase in performance. I'm trying to find out what's
>> the problem now.
>>  >
>>  >
>>  >
>> This sounds to me like data is being altered by different threads
>> and possibly there is some memory reallocation happening (growing
>> arrays, etc). Locks are only needed when there is contention
>> somewhere and of course locks should only be held for as short as
>> needed. Another pitfall with threading is that some variables may
>> need to be declared 'volatile' if they can be altered in another
>> thread while one function is executing. For example, let's say the
>> variable 'bool someX' can be altered in 2 threads; something like
>> this can happen:
>>
>> 1. FunctionA starts, and runs a loop while(!someX) { ... }
>> 2. FunctionB sets 'someX' to 'true'
>> 3. FunctionA continues to run the loop, which is not the intended
>> behavior
>>
>> Of course similar things can happen when using shared memory and
>> forked processes.
>>
>> Threading has other problems to watch out for - for example, are
>> there any static variables in functions? If so then you simply
>> cannot thread those functions without locks.
>>
>> - Cirilo
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Cirilo Bernardo]

>
> From: Carl Poirier 
>To: Vesa Solonen  
>Cc: KiCad Developers  
>Sent: Thursday, January 23, 2014 4:41 AM
>Subject: Re: [Kicad-developers] Net names and net codes
> 
>
>
>Maybe. Having no experience whatsoever in vectorization, I'm looking into 
>multithreading. Anyway, I believe one doesn't exclude the other.
>
>
>
>

For over a year now, compiling with gcc (I can't remember the exact version of 
this change) with -O3 performs auto-vectorization. Unless you can see 
significant gain in structuring some loops so that the compiler algorithms can 
make a more efficient vectorization, just compile with -O3 and don't worry 
about it.

A little off topic: If -O3 shows up problems in some places (this is not 
uncommon with something as complex as an optimizing compiler) you can still 
attempt at a different optimization level and by using the explicit flags to 
enable vectorization. In cases where a compiler's vectorization code isn't 
working well and introducing bugs, then the only solution is to explicitly 
invoke the SIMD instructions ... and really, I see no reason for that and would 
simply disable auto-vectorization until the compiler is fixed.

- Cirilo

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

Hi Carl,

Thank you for putting efforts to boost the performance of the ratsnest.
The function is brought by an external library 
(http://www.sintef.no/Projectweb/Geometry-Toolkits/TTL/), I am not sure 
what is exactly inside. The expected output should be a Delaunay 
triangulation of all nodes that are taken into account while computing 
ratsnest.
The only issue I am aware of, is the function does not handle well empty 
containers, but it should not be the case right now.


Now, when I looked again to the source code, RN_DATA is derived after 
hed::Node class (include/ttl/halfedge/hetriang.h), which contains a 
static field. Another thing is (I believe this is the main source of 
troubles) static hed::Triangulation (include/ttl/halfedge/hetraits.h:73).
Sorry that I did not say about that before, but I have just discovered 
that it is done that way. I will try to change it, but unfortunately 
there are little chances that I manage to do that before Sunday.


Regards,
Orson


On 01/22/2014 06:08 PM, Carl Poirier wrote:

Maciej,

Can you summarize to me how the function "Triangulation::createDelaunay(
nodes.begin(), nodes.end() )" works, and what are the data structures
involved?

I believe there are some dependencies in there.


On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
mailto:cirilo_berna...@yahoo.com>> wrote:

 >
 > From: Carl Poirier mailto:carl.poirie...@gmail.com>>
 >To: Marco Serantoni mailto:marco.serant...@gmail.com>>
 >Cc: Kicad Developers mailto:kicad-developers@lists.launchpad.net>>
 >Sent: Wednesday, January 22, 2014 3:51 AM
     >Subject: Re: [Kicad-developers] Net names and net codes
 >
 >
 >
 >There are some things in the code that don't like being
multithreaded. If I parallelize the for loop in
RN_DATA::Recalculate( int aNet ), I get a segfault. It does not
happen if I put a lock to the call updateNet( i ), but obviously
there is no increase in performance. I'm trying to find out what's
the problem now.
 >
 >
 >
This sounds to me like data is being altered by different threads
and possibly there is some memory reallocation happening (growing
arrays, etc). Locks are only needed when there is contention
somewhere and of course locks should only be held for as short as
needed. Another pitfall with threading is that some variables may
need to be declared 'volatile' if they can be altered in another
thread while one function is executing. For example, let's say the
variable 'bool someX' can be altered in 2 threads; something like
this can happen:

1. FunctionA starts, and runs a loop while(!someX) { ... }
2. FunctionB sets 'someX' to 'true'
3. FunctionA continues to run the loop, which is not the intended
behavior

Of course similar things can happen when using shared memory and
forked processes.

Threading has other problems to watch out for - for example, are
there any static variables in functions? If so then you simply
cannot thread those functions without locks.

- Cirilo




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

Maybe. Having no experience whatsoever in vectorization, I'm looking into
multithreading. Anyway, I believe one doesn't exclude the other.


On Wed, Jan 22, 2014 at 12:23 PM, Vesa Solonen wrote:

> 21/01/14 18:51, Carl Poirier kirjoitti:
> > There are some things in the code that don't like being multithreaded.
> If I
> > parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
> > segfault.
>
> It probably makes more sense to vectorize the loop than making it
> multi-threaded. Then you don't need tricky thread handling, but just
> have to make the loop handle data in, say four int32 chunks. Naturally
> that needs some more trickery to handle the remainder if division by
> four doesn't go even.
>
> -Vesa
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Vesa Solonen]

21/01/14 18:51, Carl Poirier kirjoitti:
> There are some things in the code that don't like being multithreaded. If I
> parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
> segfault.

It probably makes more sense to vectorize the loop than making it
multi-threaded. Then you don't need tricky thread handling, but just
have to make the loop handle data in, say four int32 chunks. Naturally
that needs some more trickery to handle the remainder if division by
four doesn't go even.

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

Maciej,

Can you summarize to me how the function "Triangulation::createDelaunay(
nodes.begin(), nodes.end() )" works, and what are the data structures
involved?

I believe there are some dependencies in there.


On Tue, Jan 21, 2014 at 4:05 PM, Cirilo Bernardo
wrote:

> >
> > From: Carl Poirier 
> >To: Marco Serantoni 
> >Cc: Kicad Developers 
> >Sent: Wednesday, January 22, 2014 3:51 AM
> >Subject: Re: [Kicad-developers] Net names and net codes
> >
> >
> >
> >There are some things in the code that don't like being multithreaded. If
> I parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
> segfault. It does not happen if I put a lock to the call updateNet( i ),
> but obviously there is no increase in performance. I'm trying to find out
> what's the problem now.
> >
> >
> >
> This sounds to me like data is being altered by different threads and
> possibly there is some memory reallocation happening (growing arrays, etc).
> Locks are only needed when there is contention somewhere and of course
> locks should only be held for as short as needed. Another pitfall with
> threading is that some variables may need to be declared 'volatile' if they
> can be altered in another thread while one function is executing. For
> example, let's say the variable 'bool someX' can be altered in 2 threads;
> something like this can happen:
>
> 1. FunctionA starts, and runs a loop while(!someX) { ... }
> 2. FunctionB sets 'someX' to 'true'
> 3. FunctionA continues to run the loop, which is not the intended behavior
>
> Of course similar things can happen when using shared memory and forked
> processes.
>
> Threading has other problems to watch out for - for example, are there any
> static variables in functions? If so then you simply cannot thread those
> functions without locks.
>
> - Cirilo
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Cirilo Bernardo]

>
> From: Carl Poirier 
>To: Marco Serantoni  
>Cc: Kicad Developers  
>Sent: Wednesday, January 22, 2014 3:51 AM
>Subject: Re: [Kicad-developers] Net names and net codes
> 
>
>
>There are some things in the code that don't like being multithreaded. If I 
>parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a 
>segfault. It does not happen if I put a lock to the call updateNet( i ), but 
>obviously there is no increase in performance. I'm trying to find out what's 
>the problem now.
>
>
>
This sounds to me like data is being altered by different threads and possibly 
there is some memory reallocation happening (growing arrays, etc). Locks are 
only needed when there is contention somewhere and of course locks should only 
be held for as short as needed. Another pitfall with threading is that some 
variables may need to be declared 'volatile' if they can be altered in another 
thread while one function is executing. For example, let's say the variable 
'bool someX' can be altered in 2 threads; something like this can happen:

1. FunctionA starts, and runs a loop while(!someX) { ... }
2. FunctionB sets 'someX' to 'true'
3. FunctionA continues to run the loop, which is not the intended behavior

Of course similar things can happen when using shared memory and forked 
processes.

Threading has other problems to watch out for - for example, are there any 
static variables in functions? If so then you simply cannot thread those 
functions without locks.

- Cirilo


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

There are some things in the code that don't like being multithreaded. If I
parallelize the for loop in RN_DATA::Recalculate( int aNet ), I get a
segfault. It does not happen if I put a lock to the call updateNet( i ),
but obviously there is no increase in performance. I'm trying to find out
what's the problem now.


On Tue, Jan 14, 2014 at 9:18 PM, Carl Poirier wrote:

> Well, if OpenMP is alright with you, I'll give it a shot this weekend.
>
>
> On Tue, Jan 14, 2014 at 5:12 AM, Marco Serantoni <
> marco.serant...@gmail.com> wrote:
>
>> Nice,
>> But please, think before add dependencies and look deeply if those are
>> supported for all platforms, I wish being able to don't trash years of work.
>>
>>
>>
>> --
>> Marco
>>
>>
>> On Tue, Jan 14, 2014 at 11:00 AM, Maciej Sumiński <
>> maciej.sumin...@cern.ch> wrote:
>>
>>> Great, now it seems that we have a group of people who are experienced
>>> with the subject. I believe this has to end up with some speed up in KiCad.
>>>
>>> Regards,
>>> Orson
>>>
>>>
>>> On 01/14/2014 10:59 AM, Marco Serantoni wrote:
>>>
 Only the warning: keep attention that boost::context doesn't support the
 context switch for the vector registers
 (mmx*/v*).
 If needed i can help you to implement.


 --
 Marco


 On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen >>> > wrote:

 13/01/14 10:04, Maciej Sumiński kirjoitti:

  > I fully support the idea, in fact I have dreamed about this too
  >
 (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#
 Possible-upgrades).
  > I had a short try with OpenMP, but I did not get any better
 results, so
  > it seems that I could have done it wrong.

 Some articles:
 http://locklessinc.com/articles/vectorize/
 http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://
 twiki.cern.ch
 https://twiki.cern.ch/twiki/bin/view/CMSPublic/
 WorkBookWritingAutovectorizableCode

 Some tools:
 http://code.entropywave.com/blog/
 http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk

 ORC may be the best tool to go with. GNU Radio's DSP stack and
 GStreamer
 depends on it.

  > If there are volunteers who have some experience with
 parallelization I
  > am very eager to cooperate to speed up some of computations. The
  > ratsnest algorithm is a perfect place to start with. It is
 performed on
  > per net basis, so they are all independent to each other.

 I could possibly do something, but I'm not familiar with much of the
 Kicad code. Single function "optimise this ->" might work, but
 delivery
 times can't be guaranteed...

 -Vesa


 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 

 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp




 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


>>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

Well, if OpenMP is alright with you, I'll give it a shot this weekend.


On Tue, Jan 14, 2014 at 5:12 AM, Marco Serantoni
wrote:

> Nice,
> But please, think before add dependencies and look deeply if those are
> supported for all platforms, I wish being able to don't trash years of work.
>
>
>
> --
> Marco
>
>
> On Tue, Jan 14, 2014 at 11:00 AM, Maciej Sumiński  > wrote:
>
>> Great, now it seems that we have a group of people who are experienced
>> with the subject. I believe this has to end up with some speed up in KiCad.
>>
>> Regards,
>> Orson
>>
>>
>> On 01/14/2014 10:59 AM, Marco Serantoni wrote:
>>
>>> Only the warning: keep attention that boost::context doesn't support the
>>> context switch for the vector registers
>>> (mmx*/v*).
>>> If needed i can help you to implement.
>>>
>>>
>>> --
>>> Marco
>>>
>>>
>>> On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen >> > wrote:
>>>
>>> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>>>
>>>  > I fully support the idea, in fact I have dreamed about this too
>>>  >
>>> (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#
>>> Possible-upgrades).
>>>  > I had a short try with OpenMP, but I did not get any better
>>> results, so
>>>  > it seems that I could have done it wrong.
>>>
>>> Some articles:
>>> http://locklessinc.com/articles/vectorize/
>>> http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
>>> https://twiki.cern.ch/twiki/bin/view/CMSPublic/
>>> WorkBookWritingAutovectorizableCode
>>>
>>> Some tools:
>>> http://code.entropywave.com/blog/
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>>>
>>> ORC may be the best tool to go with. GNU Radio's DSP stack and
>>> GStreamer
>>> depends on it.
>>>
>>>  > If there are volunteers who have some experience with
>>> parallelization I
>>>  > am very eager to cooperate to speed up some of computations. The
>>>  > ratsnest algorithm is a perfect place to start with. It is
>>> performed on
>>>  > per net basis, so they are all independent to each other.
>>>
>>> I could possibly do something, but I'm not familiar with much of the
>>> Kicad code. Single function "optimise this ->" might work, but
>>> delivery
>>> times can't be guaranteed...
>>>
>>> -Vesa
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> 
>>>
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>>
>>>
>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Marco Serantoni]

Nice,
But please, think before add dependencies and look deeply if those are
supported for all platforms, I wish being able to don't trash years of work.



--
Marco


On Tue, Jan 14, 2014 at 11:00 AM, Maciej Sumiński
wrote:

> Great, now it seems that we have a group of people who are experienced
> with the subject. I believe this has to end up with some speed up in KiCad.
>
> Regards,
> Orson
>
>
> On 01/14/2014 10:59 AM, Marco Serantoni wrote:
>
>> Only the warning: keep attention that boost::context doesn't support the
>> context switch for the vector registers
>> (mmx*/v*).
>> If needed i can help you to implement.
>>
>>
>> --
>> Marco
>>
>>
>> On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen > > wrote:
>>
>> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>>
>>  > I fully support the idea, in fact I have dreamed about this too
>>  >
>> (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#
>> Possible-upgrades).
>>  > I had a short try with OpenMP, but I did not get any better
>> results, so
>>  > it seems that I could have done it wrong.
>>
>> Some articles:
>> http://locklessinc.com/articles/vectorize/
>> http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
>> https://twiki.cern.ch/twiki/bin/view/CMSPublic/
>> WorkBookWritingAutovectorizableCode
>>
>> Some tools:
>> http://code.entropywave.com/blog/
>> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>>
>> ORC may be the best tool to go with. GNU Radio's DSP stack and
>> GStreamer
>> depends on it.
>>
>>  > If there are volunteers who have some experience with
>> parallelization I
>>  > am very eager to cooperate to speed up some of computations. The
>>  > ratsnest algorithm is a perfect place to start with. It is
>> performed on
>>  > per net basis, so they are all independent to each other.
>>
>> I could possibly do something, but I'm not familiar with much of the
>> Kicad code. Single function "optimise this ->" might work, but
>> delivery
>> times can't be guaranteed...
>>
>> -Vesa
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> 
>>
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

Great, now it seems that we have a group of people who are experienced 
with the subject. I believe this has to end up with some speed up in KiCad.


Regards,
Orson

On 01/14/2014 10:59 AM, Marco Serantoni wrote:

Only the warning: keep attention that boost::context doesn't support the
context switch for the vector registers
(mmx*/v*).
If needed i can help you to implement.


--
Marco


On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen mailto:vesa.solo...@aalto.fi>> wrote:

13/01/14 10:04, Maciej Sumiński kirjoitti:

 > I fully support the idea, in fact I have dreamed about this too
 >

(http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades).
 > I had a short try with OpenMP, but I did not get any better
results, so
 > it seems that I could have done it wrong.

Some articles:
http://locklessinc.com/articles/vectorize/
http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch

https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookWritingAutovectorizableCode

Some tools:
http://code.entropywave.com/blog/
http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk

ORC may be the best tool to go with. GNU Radio's DSP stack and GStreamer
depends on it.

 > If there are volunteers who have some experience with
parallelization I
 > am very eager to cooperate to speed up some of computations. The
 > ratsnest algorithm is a perfect place to start with. It is
performed on
 > per net basis, so they are all independent to each other.

I could possibly do something, but I'm not familiar with much of the
Kicad code. Single function "optimise this ->" might work, but delivery
times can't be guaranteed...

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Marco Serantoni]

Only the warning: keep attention that boost::context doesn't support the
context switch for the vector registers
(mmx*/v*).
If needed i can help you to implement.


--
Marco


On Mon, Jan 13, 2014 at 7:48 PM, Vesa Solonen  wrote:

> 13/01/14 10:04, Maciej Sumiński kirjoitti:
>
> > I fully support the idea, in fact I have dreamed about this too
> > (
> http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades
> ).
> > I had a short try with OpenMP, but I did not get any better results, so
> > it seems that I could have done it wrong.
>
> Some articles:
> http://locklessinc.com/articles/vectorize/
> http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
>
> https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookWritingAutovectorizableCode
>
> Some tools:
> http://code.entropywave.com/blog/
> http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk
>
> ORC may be the best tool to go with. GNU Radio's DSP stack and GStreamer
> depends on it.
>
> > If there are volunteers who have some experience with parallelization I
> > am very eager to cooperate to speed up some of computations. The
> > ratsnest algorithm is a perfect place to start with. It is performed on
> > per net basis, so they are all independent to each other.
>
> I could possibly do something, but I'm not familiar with much of the
> Kicad code. Single function "optimise this ->" might work, but delivery
> times can't be guaranteed...
>
> -Vesa
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Vesa Solonen]

13/01/14 10:04, Maciej Sumiński kirjoitti:

> I fully support the idea, in fact I have dreamed about this too
> (http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades).
> I had a short try with OpenMP, but I did not get any better results, so
> it seems that I could have done it wrong.

Some articles:
http://locklessinc.com/articles/vectorize/
http://gcc.gnu.org/projects/tree-ssa/vectorizathttps://twiki.cern.ch
https://twiki.cern.ch/twiki/bin/view/CMSPublic/WorkBookWritingAutovectorizableCode

Some tools:
http://code.entropywave.com/blog/
http://gnuradio.org/redmine/projects/gnuradio/wiki/Volk

ORC may be the best tool to go with. GNU Radio's DSP stack and GStreamer
depends on it.

> If there are volunteers who have some experience with parallelization I
> am very eager to cooperate to speed up some of computations. The
> ratsnest algorithm is a perfect place to start with. It is performed on
> per net basis, so they are all independent to each other.

I could possibly do something, but I'm not familiar with much of the
Kicad code. Single function "optimise this ->" might work, but delivery
times can't be guaranteed...

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

Hi Carl,

That's great news. Do not hesitate to ask about the code if you have any 
doubts. I keep fingers crossed.


Regards,
Orson

On 01/13/2014 03:46 PM, Carl Poirier wrote:

I read the small section about it in the wiki and have seen your
outcome. Having experience with not only OpenMP but
threading/multiprocessing in general (OpenCL, OpenMPI and GoRoutines), I
will give the code a look. I'll then let you know if I give it a go.

Regards,

Carl


On Mon, Jan 13, 2014 at 3:04 AM, Maciej Sumiński
mailto:maciej.sumin...@cern.ch>> wrote:

On 01/10/2014 08:45 PM, Vesa Solonen wrote:

10/01/14 19:35, Maciej Sumiński kirjoitti:

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.


While the big redesign/rewrite of Kicad core is going on, it
might be a
good moment to think some radical moves. Designing all
computationally
intensive parts with multi core processors, de facto available
SIMD/Vector instructions and OpenCL in mind.

As an example instruct the compiler to autovectorize just that
ratsnest
calculation. Or the previous plus function written to support
multiple
threads. Running the UI thread and processing threads separate,
say the
ratsnest being constantly iterated in the background when it
changes.

Just by GCC autovectorization its easy to get ten times more
comparing
or multiplying performane.

-Vesa


I fully support the idea, in fact I have dreamed about this too

(http://www.ohwr.org/projects/__cern-kicad/wiki/ratsnest-gal#__Possible-upgrades

).
I had a short try with OpenMP, but I did not get any better results,
so it seems that I could have done it wrong.
If there are volunteers who have some experience with
parallelization I am very eager to cooperate to speed up some of
computations. The ratsnest algorithm is a perfect place to start
with. It is performed on per net basis, so they are all independent
to each other.

Regards,
Orson

_
Mailing list: https://launchpad.net/~kicad-__developers

Post to : kicad-developers@lists.__launchpad.net

Unsubscribe : https://launchpad.net/~kicad-__developers

More help   : https://help.launchpad.net/__ListHelp






___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Carl Poirier]

I read the small section about it in the wiki and have seen your outcome.
Having experience with not only OpenMP but threading/multiprocessing in
general (OpenCL, OpenMPI and GoRoutines), I will give the code a look. I'll
then let you know if I give it a go.

Regards,

Carl


On Mon, Jan 13, 2014 at 3:04 AM, Maciej Sumiński wrote:

> On 01/10/2014 08:45 PM, Vesa Solonen wrote:
>
>> 10/01/14 19:35, Maciej Sumiński kirjoitti:
>>
>>  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.
>>>
>>
>> While the big redesign/rewrite of Kicad core is going on, it might be a
>> good moment to think some radical moves. Designing all computationally
>> intensive parts with multi core processors, de facto available
>> SIMD/Vector instructions and OpenCL in mind.
>>
>> As an example instruct the compiler to autovectorize just that ratsnest
>> calculation. Or the previous plus function written to support multiple
>> threads. Running the UI thread and processing threads separate, say the
>> ratsnest being constantly iterated in the background when it changes.
>>
>> Just by GCC autovectorization its easy to get ten times more comparing
>> or multiplying performane.
>>
>> -Vesa
>>
>
> I fully support the idea, in fact I have dreamed about this too (
> http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#
> Possible-upgrades). I had a short try with OpenMP, but I did not get any
> better results, so it seems that I could have done it wrong.
> If there are volunteers who have some experience with parallelization I am
> very eager to cooperate to speed up some of computations. The ratsnest
> algorithm is a perfect place to start with. It is performed on per net
> basis, so they are all independent to each other.
>
> Regards,
> Orson
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

On 01/10/2014 08:45 PM, Vesa Solonen wrote:

10/01/14 19:35, Maciej Sumiński kirjoitti:


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.


While the big redesign/rewrite of Kicad core is going on, it might be a
good moment to think some radical moves. Designing all computationally
intensive parts with multi core processors, de facto available
SIMD/Vector instructions and OpenCL in mind.

As an example instruct the compiler to autovectorize just that ratsnest
calculation. Or the previous plus function written to support multiple
threads. Running the UI thread and processing threads separate, say the
ratsnest being constantly iterated in the background when it changes.

Just by GCC autovectorization its easy to get ten times more comparing
or multiplying performane.

-Vesa


I fully support the idea, in fact I have dreamed about this too 
(http://www.ohwr.org/projects/cern-kicad/wiki/ratsnest-gal#Possible-upgrades). 
I had a short try with OpenMP, but I did not get any better results, so 
it seems that I could have done it wrong.
If there are volunteers who have some experience with parallelization I 
am very eager to cooperate to speed up some of computations. The 
ratsnest algorithm is a perfect place to start with. It is performed on 
per net basis, so they are all independent to each other.


Regards,
Orson

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[jp charras]

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 + 3 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 

Re: [Kicad-developers] Net names and net codes

[Vesa Solonen]

10/01/14 19:35, Maciej Sumiński kirjoitti:

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

While the big redesign/rewrite of Kicad core is going on, it might be a
good moment to think some radical moves. Designing all computationally
intensive parts with multi core processors, de facto available
SIMD/Vector instructions and OpenCL in mind.

As an example instruct the compiler to autovectorize just that ratsnest
calculation. Or the previous plus function written to support multiple
threads. Running the UI thread and processing threads separate, say the
ratsnest being constantly iterated in the background when it changes.

Just by GCC autovectorization its easy to get ten times more comparing
or multiplying performane.

-Vesa


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

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 + 3 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 i

Re: [Kicad-developers] Net names and net codes

[jp charras]

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

In Altium, you need to deactivate (shelve) copper polygons to be able to
work on you boards when the calculation time is too long...

-- 
Jean-Pierre CHARRAS

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[jp charras]

Le 09/01/2014 09:56, Maciej Sumiński a écrit :
> On 01/08/2014 04:39 PM, jp charras wrote:
>> Le 08/01/2014 15:35, Maciej Sumiński a écrit :
>>> I am wondering if there are any special reasons to keep net names and
>>> net codes separated. This gives programmer a chance to set a net code
>>> that is actually not related to the appropriate net name. One is even
>>> able to set a net name that does not exist using D_PAD::SetNetname() for
>>> a single pad or a group of pads.
>>> I have seen that in many places there are pairs of functions:
>>> item->SetNet( .. );
>>> item->SetNetname( .. );
>>> but if I recall correctly, that is not always the case.
>>>
>>> Also, net names are kept (and directly available) only for some specific
>>> classes (D_PAD, ZONE_CONTAINER, they are delivered via different
>>> functions - respectively GetNetname() and GetNetName()) but not all
>>> BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this
>>> information). For classes that miss net name, there can be used
>>> NETINFO_ITEM, which stores both net code and net name. Again, question
>>> arises - is it done on purpose?
>>
>> Net names come from the netlist created by the schematic.
>> Because a netlist knows only pads numbers, net names are stored in pads,
>> to handle netlist info.
>>
>> A net code is a number only for internal use, equivalent to the net
>> name, and used to compare, sort ... nets (just because compare 2 numbers
>> is faster ans easier than compare 2 strings.
>>
>> The net code is only for internal use, and has no meaning outside pcbnew.
>>
>> Zones store a net name because they are connected to a net name which
>> comes from the netlist.
>>
>> (An issue happen when this net name does not exist after a schematic
>> change, and the user should edit this zone when it net name is lost.
>>
>> By the way, Pcbnew currently crashes in RN_LINKS::AddNode(), when
>> reading a board which contains a zone which has a non existent net name,
>> i.e. which has a net code = -1)
>>
>> 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)
>>
>> Therefore net names cannot be easily removed from pads, unless rewriting
>> the way net codes are set from net names.
>> I do not know if rewriting that is worth (nad I do not see an advantage
>> to change this).
>>
>> However zones should store a net name anyway, because the user set a
>> zone net name, not a zone net code (which is not equivalent, after
>> schematic changes, because netlists do not store info for zones).
>>
>> Having both GetNetname() and GetNetName() is certainly a bug. One is
>> enough.
>>
>> The "short" net name is only used to display the net name. It could be
>> computed on the fly from the "full" net name (which includes the sheet
>> path).
>> It exists only for computing time reasons, to display the net name in
>> pads on screen.
>> (m_ShortNetname can be removed, if the cost to calculate it is small)
> 
> Thank you, now the principles are much clearer to me. But is not some
> kind of net code stored in .kicad_pcb files? You can find there lines
> where both net code and net name are stored, e.g.:
> 
>   (net 5 GND)
>   (net 6 N-04)
> 
> or
> 
> (pad 6 thru_hole oval (at 1.27 -3.81 270) (size 1.5748 2.794) (drill
> 0.812799) (layers *.Cu *.Mask F.SilkS)
>   (net 2 /pic_sockets.sch/CLOCK-RB6))
> 
> or
> 
>   (zone (net 5) (net_name GND) (layer Cuivre) (tstamp 48F6319A) (hatch
> edge 0.508)
> 
> For tracks, it looks like only net code is saved:
> 
> (segment (start 181.61 124.46) (end 182.88 123.19) (width 0.635) (layer
> Cuivre) (net 3))
> 
> Net codes change only in void NETINFO_LIST::buildListOfNets() function
> and only if all items from a given net were removed. I wonder if it
> would not be better if this kind of cleaning was done on file save.
> 
> The reason why I ask about this is the ratsnest implementation for the
> GAL. I index items by their net codes, so ratsnests are separate for
> every net. In this way, I wanted to update only nets that were changed,
> instead of recreating the whole ratsnest.
> Besides that, storing net names only in one place (e.g. NETINFO_ITEM)
> makes code less prone to errors, as then there is no possibility to have
> a pad with a net name that does not exist or have net code and net name
> that do not match each other.

For me, net names and net codes are equivalent.
Storing net names in a NETINFO_ITEM item and only a net code (therefore
an index) in connected items is just a decision which has a (minor)
effect in internal code.

I am thinking the change

Re: [Kicad-developers] Net names and net codes

[Tomasz Wlostowski]

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


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Net names and net codes

[Maciej Sumiński]

On 01/08/2014 04:39 PM, jp charras wrote:

Le 08/01/2014 15:35, Maciej Sumiński a écrit :

I am wondering if there are any special reasons to keep net names and
net codes separated. This gives programmer a chance to set a net code
that is actually not related to the appropriate net name. One is even
able to set a net name that does not exist using D_PAD::SetNetname() for
a single pad or a group of pads.
I have seen that in many places there are pairs of functions:
item->SetNet( .. );
item->SetNetname( .. );
but if I recall correctly, that is not always the case.

Also, net names are kept (and directly available) only for some specific
classes (D_PAD, ZONE_CONTAINER, they are delivered via different
functions - respectively GetNetname() and GetNetName()) but not all
BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this
information). For classes that miss net name, there can be used
NETINFO_ITEM, which stores both net code and net name. Again, question
arises - is it done on purpose?


Net names come from the netlist created by the schematic.
Because a netlist knows only pads numbers, net names are stored in pads,
to handle netlist info.

A net code is a number only for internal use, equivalent to the net
name, and used to compare, sort ... nets (just because compare 2 numbers
is faster ans easier than compare 2 strings.

The net code is only for internal use, and has no meaning outside pcbnew.

Zones store a net name because they are connected to a net name which
comes from the netlist.

(An issue happen when this net name does not exist after a schematic
change, and the user should edit this zone when it net name is lost.

By the way, Pcbnew currently crashes in RN_LINKS::AddNode(), when
reading a board which contains a zone which has a non existent net name,
i.e. which has a net code = -1)

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)

Therefore net names cannot be easily removed from pads, unless rewriting
the way net codes are set from net names.
I do not know if rewriting that is worth (nad I do not see an advantage
to change this).

However zones should store a net name anyway, because the user set a
zone net name, not a zone net code (which is not equivalent, after
schematic changes, because netlists do not store info for zones).

Having both GetNetname() and GetNetName() is certainly a bug. One is enough.

The "short" net name is only used to display the net name. It could be
computed on the fly from the "full" net name (which includes the sheet
path).
It exists only for computing time reasons, to display the net name in
pads on screen.
(m_ShortNetname can be removed, if the cost to calculate it is small)


Thank you, now the principles are much clearer to me. But is not some 
kind of net code stored in .kicad_pcb files? You can find there lines 
where both net code and net name are stored, e.g.:


  (net 5 GND)
  (net 6 N-04)

or

(pad 6 thru_hole oval (at 1.27 -3.81 270) (size 1.5748 2.794) (drill 
0.812799) (layers *.Cu *.Mask F.SilkS)

  (net 2 /pic_sockets.sch/CLOCK-RB6))

or

  (zone (net 5) (net_name GND) (layer Cuivre) (tstamp 48F6319A) (hatch 
edge 0.508)


For tracks, it looks like only net code is saved:

(segment (start 181.61 124.46) (end 182.88 123.19) (width 0.635) (layer 
Cuivre) (net 3))


Net codes change only in void NETINFO_LIST::buildListOfNets() function 
and only if all items from a given net were removed. I wonder if it 
would not be better if this kind of cleaning was done on file save.


The reason why I ask about this is the ratsnest implementation for the 
GAL. I index items by their net codes, so ratsnests are separate for 
every net. In this way, I wanted to update only nets that were changed, 
instead of recreating the whole ratsnest.
Besides that, storing net names only in one place (e.g. NETINFO_ITEM) 
makes code less prone to errors, as then there is no possibility to have 
a pad with a net name that does not exist or have net code and net name 
that do not match each other.


Regarding the RN_LINKS::AddNode() bug - right now I am coupling the 
ratsnest algorithm with improved tools, so I will fix it soon.


Regards,
Orson



Another thing that I observed is that net codes may be subject to change
during edition of a board (I guess it happens when you remove all pads
that belong to a single net). As I understand, it is to keep net codes
consecutive, but it also disallows to reliably index items using their
net codes. Is the only right way to index items by nets is to use their
net names?

As I am not as f

Re: [Kicad-developers] Net names and net codes

[jp charras]

Le 08/01/2014 15:35, Maciej Sumiński a écrit :
> I am wondering if there are any special reasons to keep net names and
> net codes separated. This gives programmer a chance to set a net code
> that is actually not related to the appropriate net name. One is even
> able to set a net name that does not exist using D_PAD::SetNetname() for
> a single pad or a group of pads.
> I have seen that in many places there are pairs of functions:
> item->SetNet( .. );
> item->SetNetname( .. );
> but if I recall correctly, that is not always the case.
> 
> Also, net names are kept (and directly available) only for some specific
> classes (D_PAD, ZONE_CONTAINER, they are delivered via different
> functions - respectively GetNetname() and GetNetName()) but not all
> BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this
> information). For classes that miss net name, there can be used
> NETINFO_ITEM, which stores both net code and net name. Again, question
> arises - is it done on purpose?

Net names come from the netlist created by the schematic.
Because a netlist knows only pads numbers, net names are stored in pads,
to handle netlist info.

A net code is a number only for internal use, equivalent to the net
name, and used to compare, sort ... nets (just because compare 2 numbers
is faster ans easier than compare 2 strings.

The net code is only for internal use, and has no meaning outside pcbnew.

Zones store a net name because they are connected to a net name which
comes from the netlist.

(An issue happen when this net name does not exist after a schematic
change, and the user should edit this zone when it net name is lost.

By the way, Pcbnew currently crashes in RN_LINKS::AddNode(), when
reading a board which contains a zone which has a non existent net name,
i.e. which has a net code = -1)

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)

Therefore net names cannot be easily removed from pads, unless rewriting
the way net codes are set from net names.
I do not know if rewriting that is worth (nad I do not see an advantage
to change this).

However zones should store a net name anyway, because the user set a
zone net name, not a zone net code (which is not equivalent, after
schematic changes, because netlists do not store info for zones).

Having both GetNetname() and GetNetName() is certainly a bug. One is enough.

The "short" net name is only used to display the net name. It could be
computed on the fly from the "full" net name (which includes the sheet
path).
It exists only for computing time reasons, to display the net name in
pads on screen.
(m_ShortNetname can be removed, if the cost to calculate it is small)

> 
> Another thing that I observed is that net codes may be subject to change
> during edition of a board (I guess it happens when you remove all pads
> that belong to a single net). As I understand, it is to keep net codes
> consecutive, but it also disallows to reliably index items using their
> net codes. Is the only right way to index items by nets is to use their
> net names?
> 
> As I am not as familiar with the KiCad's core as you are, then I would
> like to ask what do you think of:
> - removing m_Netname & m_ShortNetname fields from D_PAD and m_Netname
> from ZONE_CONTAINER
> 
> - use net codes to refer to a specific NETINFO_ITEMs, that actually
> store useful informations for nets
> 
> - adding something similar to (it actually exists in the code as
> ZONE_CONTAINER::SetNetNameFromNetCode()):
> wxString BOARD_CONNECTED_ITEM::GetNetname() const
> {
> BOARD* board = GetBoard();
> if( board == NULL )
> return wxString( "" );
> 
> NETINFO_ITEM* netinfo = board->FindNet( m_NetCode );
> if( netinfo == NULL )
> return wxString( "" );
> 
> return netinfo->GetNetname();
> }
> 
> 
> wxString BOARD_CONNECTED_ITEM::GetShortNetname() const
> {
> BOARD* board = GetBoard();
> if( board == NULL )
> return wxString( "" );
> 
> NETINFO_ITEM* netinfo = board->FindNet( m_NetCode );
> if( netinfo == NULL )
> return wxString( "" );
> 
> return netinfo->GetShortNetname();
> }
> 
> or improve it to make it faster, if it is necessary.
> 
> Regards,
> Orson
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 


-- 
Jean-Pierre CHARRAS

___
Ma

[Kicad-developers] Net names and net codes

[Maciej Sumiński]

I am wondering if there are any special reasons to keep net names and 
net codes separated. This gives programmer a chance to set a net code 
that is actually not related to the appropriate net name. One is even 
able to set a net name that does not exist using D_PAD::SetNetname() for 
a single pad or a group of pads.

I have seen that in many places there are pairs of functions:
item->SetNet( .. );
item->SetNetname( .. );
but if I recall correctly, that is not always the case.

Also, net names are kept (and directly available) only for some specific 
classes (D_PAD, ZONE_CONTAINER, they are delivered via different 
functions - respectively GetNetname() and GetNetName()) but not all 
BOARD_CONNECTED_ITEMs (TRACK and its derivatives does not contain this 
information). For classes that miss net name, there can be used 
NETINFO_ITEM, which stores both net code and net name. Again, question 
arises - is it done on purpose?


Another thing that I observed is that net codes may be subject to change 
during edition of a board (I guess it happens when you remove all pads 
that belong to a single net). As I understand, it is to keep net codes 
consecutive, but it also disallows to reliably index items using their 
net codes. Is the only right way to index items by nets is to use their 
net names?


As I am not as familiar with the KiCad's core as you are, then I would 
like to ask what do you think of:
- removing m_Netname & m_ShortNetname fields from D_PAD and m_Netname 
from ZONE_CONTAINER


- use net codes to refer to a specific NETINFO_ITEMs, that actually 
store useful informations for nets


- adding something similar to (it actually exists in the code as 
ZONE_CONTAINER::SetNetNameFromNetCode()):

wxString BOARD_CONNECTED_ITEM::GetNetname() const
{
BOARD* board = GetBoard();
if( board == NULL )
return wxString( "" );

NETINFO_ITEM* netinfo = board->FindNet( m_NetCode );
if( netinfo == NULL )
return wxString( "" );

return netinfo->GetNetname();
}


wxString BOARD_CONNECTED_ITEM::GetShortNetname() const
{
BOARD* board = GetBoard();
if( board == NULL )
return wxString( "" );

NETINFO_ITEM* netinfo = board->FindNet( m_NetCode );
if( netinfo == NULL )
return wxString( "" );

return netinfo->GetShortNetname();
}

or improve it to make it faster, if it is necessary.

Regards,
Orson

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp