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
>>
>> (2)<-(1)
>> (3)<-(2)
>> (4)<-(2)
>>
>> (A)<-(3)
>> (B)<-(3)
>> (C)<-(4)
>>
>> 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::GetClearan
ce().
>> 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.
Question:
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.
Dick
