← Back to team overview

kicad-developers team mailing list archive

Re: Net Classes


Progress report:

Well how about we split this into two parts consisting of *my* part:

(1) data structures
(2) member functions to access the data structures
(3) persistence: loading and saving to disk
(4) specctra import/export enhancements
(5) switching the existing (soon to be insufficient) DRC code (track
routing) to use the new member functions

And *your* part:
(A) user interface to create, modify, delete net classes.
(B) user interface to add a net to a class, remove a net from a class.
(C) DRC or routing enhancements which will take into consideration the
net classes of both objects in a near collision, and chose the most
restrictive distance of the two when coordinating the allowed spacings.

I see these task dependencies, where "<-" means "depends on" the task(s)
to its right



It would be my preference to try and stay with a net class object which
is similar to the one given in the specctra dsn format, in terms of
conceptual attributes or fields.

Additional fields beyond what are used by an external router such as
freerouter, are likely to cause problems of compatibility during the
round trip.
There is much to be admired about the specctra format, and much to be
learned from it.

My design ideas:

The interface to (or access to) net classes should be through the net
itself. Calling code such as DRC should *ask the net* what class it is
in, i.e. how it wants to be treated.

For clearances only, I found it easier to have this support on the actual conductive object itself, ala BOARD_CONNECTED_ITEM::GetClearance().

Also, fields in a net class object should be either "specified" or
"unspecified" . When "unspecified" , they should be "inherited" from a
(board global) default net class. So if a user modifies the "default"
net class, he may be modifying all the like named fields in all the net
classes which are not "specified" or over-ridden.

The above is overkill for the time being, and complicates the UI editing of the netclass parameters.

All existing DRC rule globals values should be deleted from the source
code and moved into the default net class. The default net class should
be created automatically without user interaction for any board. All
net classes should always reside in the board file, not in any global
configuration file.

I now see a need to be able to establish some global DRC limits, like we have now. So my approach in re-doing DRC today has been to:

(1) preserve all parameters that are now in g_DesignSettings, for the indefinite future. (Future: possibly remove the 6 or so global DRC parameters from g_DesignSettings altogether, at least as true globals. They could be provided through the DRC dialog but not actually saved anywhere. The initial dialog values could come from scanning all NETCLASSes for minimums.)

(2) at the start of a full DRC check, qualify each NETCLASS's parameters against the global limits, and if any netclass is out of wack, complain and abort the DRC check. The user has to edit the problem netclasses before continuing, or relax the global limits. This is coded.

(3) qualify each BOARD_CONNECTED_ITEM as before, but use the limits established by the NETCLASS in which the item resides. This is coded.


If I commit without at least minimal work on the NETCLASS UI, then PCBNEW will not be useable. It will compile, but without the ability to edit the NETCLASS parameters, it will only create user frustration at DRC time. We can make this known, so user's do not install the compiled binary. Or I can do minimal enhancements to the UI before committing. Or you can do it just after I commit. What is your preference Jean-Pierre?

My work is basically done, but I would like to add consultation of NETCLASSes at the beginning of a new track or via addition, if it is not a continuation of an existing track. New segments should start with the width given by the pertinent netclass. This I can do in the morning.

So the question about the UI remains.


Follow ups