| Thread Previous • Date Previous • Date Next • Thread Next |
Progress report:
For clearances only, I found it easier to have this support on the actual conductive object itself, ala BOARD_CONNECTED_ITEM::GetClearance().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.
The above is overkill for the time being, and complicates the UI editing of the netclass parameters.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.
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: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.
(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
| Thread Previous • Date Previous • Date Next • Thread Next |
