kicad-developers team mailing list archive

[jp charras <jp.charras@xxxxxxxxxx>]

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-000004)
> 
> 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 is mainly in netlist reader.
If I remember well, the pad net name is used mainly here, and in the
function which generates the net codes.
(It is used in some other functions, but only to display/print the net
name, which is easy to change)

By definition it is not possible to have a pad with a net name that does
not exist, because if a net name is attached to a pad, after reading a
netlist, it exists, the purpose of the netlist is to attach a net name
to a pad.
And the pad editor does not allow a user to add non existent net name.

Net names attached to a zone are not modified by reading a netlist,
because there is no link between a zone and a netlist.

Currently, all net names found in a zones and not found in pads are
called "not existent net name".
the "not existent net name" is relative to the netlist, i.e. to the schema.
In this case the current code set the net code to -1.
-1 means only: net name error.

You can obviously change it, if it creates issues, as long as
a "non existent net name in schematic" can be detected by the DRC control.

In netlist, the netcode is not useful for Pcbnew.

In .kicad_pcb files the netcode in lines like
  (segment (start 107.061 61.468) (end 87.122 61.468) (width 0.2032)
(layer gnd) (net 1))
is just a convenient way to give a short reference to the net, because
net names can be long in hierarchies with many levels, and a file can
contain more than 30,000 lines like this.

> 
> 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 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
> 
> 


-- 
Jean-Pierre CHARRAS