PCB layout has always used schematics to describe the component instantiations and connections along with a set of engineering notes to provide the extra requirements that are needed for the design to actually work. These notes were included on the schematic sheets for the PCB layout engineer to read and implement by hand.
This is no longer acceptable for even an opensource PCB system like Kicad. We need to include these notes as part of the data base that is passed from eeschema to pcbnew so that DRC checks will catch them if they are not met. Its time we put the automation into EDA.
One proposal:
Add the ability to support “Legs” either in the .sch or as a new filetype. Each line would contain a unique name and two instance.port names.
Add a list of “Rules” either in the .sch or in a new filetype.
Use Case #1
Design has an H-Bridge that connects to a motor connector. Designer creates two legs called Mot_Plus and Mot_Minus with the H-Bridge and connector pins. Designer creates two rules that Mot_Plus and Mot_Minus are 1000 mA currents.
Pcbnew reads the Legs and Rules files and calculates the needed trace width and number of vias needed to pass the current based on the selected Board technology. DRC checks for violations along with checking that both legs actually exist in the netlist. Other connections to filters or sensors do not need the fat traces.
Use Case #2
Design has a differential pair of signals. Designer lists both signals as legs and creates a rule that they are a differential pair. Pcbnew checks that the legs are actual connections and that their lengths match with minimal loop area.
Use Case #3
Design has signals with requirements for high voltage or impedance. Designer creates a leg for each signal and a rule to tell pcbnew what to design/check for.
Use Case #4
Power and ground need a grid distribution. Each power pin is listed in a leg. Rules specify current draws and the need for (2,3 or 4) parallel connections.
I think something like this is planned for v6. (Or the implementation of the supporting data structure that is required for something like this.)
It will all depend on how much manpower kicad will have over the next few years.
Also: This is a user forum. You can gauge the user requirements and finalize your feature request with the feedback but you still need to contact the developers via the bugtracker. (create a bug marked wishlist. But also make sure first that there is not yet a similar request. If there is then add your voice to that bug report. If you feel it has not been well enough described then add a comment. Otherwise use the “this affects me as well” flag to increase the heat of the bug.)
You are right about that. (I was sure i read somewhere that there are plans to make the netlist more powerful for just such a usecase. Can’t find it any more. Maybe this has been dropped or it was a discussion on the mailing list. Or i see ghosts.)
Please confirm that I understand your suggestion correctly. You are asking for two features:
Create and assign “Net Classes” in EESchema, rather than in PCBNew.
Calculate the parameters for a Net Class (width, spacing, via size, etc) based on factors external to KiCAD
The first feature seems to be a straightforward concept, though I won’t guess how much development effort may be required. It could be done by moving the “Design Rules” > “Net Classes” menu from PCBNew, into EESchema; then passing the Net Class information to PCBNew.
Some practical details of implementation include:
Can Net Classes be created ONLY in EESchema, or is there still the ability to create a Net Class in PCBNew? If the latter, there should probably be a way to communicate the newly specified Net Class back into EESchema. (This is similar to “back annotation” of Ref Des and Value information from PCBNew back into EESchema.) Perhaps it would be easier to create Net Classes (but not assign nets to the classes) only at the Project level, and send the catalog of available Net Classes from the Project to both EESchema and PCBNew.
Please don’t burden the user with an absolute requirement to create Net Classes and assign nets to them. There should be a default Net Class - or perhaps two or three default Classes - with reasonable parameters, so that a user can draft a schematic and design a board without the additional task of creating and assigning Net Classes.
As I understand KiCAD’s top-level architecture, the Netlist file (and only the Netlist file) is the medium for passing information between EESchema and PCBNew. I’d argue for keeping it that way. Information about Net Class membership can probably be passed in the netlist file, either as a new section, or by adding a parameter to the existing entries in the “(nets () )” section.
Of course, the new system should be able to read netlists from old projects, and it would be nice if existing versions of KiCAD could read the new netlist format and act on it. (A bunch of “Warnings” is probably acceptable, but not an “Error” that brings everything to a stop.)
The second feature (calculating parameters for a Net Class) is more difficult to implement, due to the wide range of factors that must be considered. The great majority of us use a few values for trace widths and spacing out of habit, but we know the underlying calculations are not simple. It’s not just a matter of current in the trace. Even adding copper “weight” (thickness) and substrate material into the equation isn’t really enough information. There may be differing requirements for traces on surface layers versus interior layers. There must be a definition for trace failure - melting, delamination, or a specified temperature rise (and how much rise). The end-equipment environment also enters into play. There will be different trace criteria for equipment used in habitable environments versus hostile aerospace environments. And, artificial restrictions such as regulatory requirements or “house rules” may usurp any engineering calculation.
In summary, I don’t think it is practical for KiCAD to capture all of the information necessary for trace calculations, and properly apply the information to all situations. At this point in history it is still wisest to let the engineers do the engineering, and let the tools do the engineers’ bidding.
Dale
P.S. - I get annoyed by poorly-defined terms created for their cuteness. The Arduino world is rife with imprecise jargon that obfuscates rather than specifies. I’ve experienced too many meetings where an entire staff quibbles for hours over, e.g., whether something is a “feather” or a “jacket” or a “shield” or a “cape” or some other alternative term for a plug-in module. I am not opposed to “Legs” - I happen to own two of them myself - but I fail to see the relation between my appendages and a data structure with three elements, as you described.
Its not a Net Class since some of the connections are to filters or sensors that do not need a high current trace. I used the term “Legs” so that you can specify exactly which paths are high current. Perhaps “Path” would have been a better choice.
You want this information in the same place as the connectivity information because it is created by the circuit designer and that engineer might not be the same as the PCB designer. This mirrors the traditional practice of placing it in notes on the schematic so everything is in one place.
You would caculate the parameters the same way that you currently do. This likely will be implemented by a table. You give Kicad a technology file with the number of layers, min trace width and spacing along with a table of trace widths vs current requirements.
It’s difficult to follow these long posts, but I’ll try to offer my viewpoint.
A net is a connection between several pins. Often there are more than 2 pins in one net. A net class in the board editor has one track width for one net. The problem is that often this one width isn’t suitable or necessary for all parts of track/tracks which connect these pins together. For example there’s a power source which feeds several parts. These all parts don’t need or take the same amount of current. The source must be able to send, say, send 2A, one part takes 1A, another one 1A, yet another one is just a feedback input and takes only a negligible amount of current. So, for the source pin we need track width, say (to simplify), 0.6mm, but for the two parts 0.3mm, and the feedback pin needs only 0.2 or whatever is the non-current signal track width. It’s not nice to use 0.6mm for the whole net and change the narrower parts of the tracks manually, especially if they are rerouted or modified several times.
I think the track width information doesn’t belong naturally to the schematics, but the amount of current for each pin certainly belongs there.
This is all just daydreaming, but I like designing general re-usable concepts. So here’s a proposal:
The schematics (and the netlist) would have extra information for pins of symbols. This information could partly even be in the symbol library, for example the maximum current a part can handle (for atomic or other unique parts). The designer can, wherever he/she wants, to define current values. That would be just another data field in the symbol pin. The data, if it exist, would be added to the netlist. The board editor could handle it to calculate track widths if the user wants to do so. There’s already a track width calculator in KiCad - you need to give the max current, temperature rise and trace thickness. The trace thickness is the copper layer thickness which is decided once for one board, the acceptable temperature rise should be one general approximate for the whole board, and the track width could be calculated for each part of each track. This is simplistic but enough for many situations. In the UI level in the board editor it could be an option for a selected net: “Use calculated track widths” or something like that.