I think that adding a kind of resistance specifications between the paths would be beneficial for quick evaluation of resistances in power traces, as well to satisfy the ERC, as simple as unidirectional graph:
R[pin1, pin2] = X [Ohms]
and in contrary:
R[pin2, pin1] = Y [Ohms]
which is same for resistors, ferrite beads, … but gives a simple solution to describe diodes in power supplies,
Components with more than 2 pins just add relation-ships to other pins
R[pin1, pinX] = …
to satisfy ERC for more “complicated” scenarios. Therefore for each such path the resistance is known, the path can be evaluated and ERC checked, for those unknown (equals to present state), ERC would return same.
Regarding the 2nd link above: Net-classes could have specified a minimum required resistance (or max [A]) which could be also checked and also reported.
I would not consider this as a part of spice simulation but rather as a solution for a proper ERC evaluation and as a tool to help designing optimal traces in power applications.
I think you want to set up too complicated tasks for simple schematic check what ERC is.
How you then imagine the specified track resistance will be controlled. During routing track - the longer it is automatically the wider it becomes (taking in account copper thickness).
Specifying the minimum resistance (or max current) for net has little (or no) sense. Just consider VCC net with specified current of 1A. Do the track to 10k pull up resistor also have to be wide enough as for 1A?
Having resistance track calculator is a common thing for EDA, even Altium has it
Main issue is that having ferrite beads it is “the most” common thing in all digital circuits, per simple MCUs there could be 3…5, for FPGAs many more. This is a wide use case. 2nd common use case are diodes in switching power supplies, besides the inductors.
To your Q: assume vcc has netclass “vcc” and 10k is wired to another signal, of different netclass. As it is crossing the net classes where the 2nd one has no, or different specification, the ERC simply ignores that.
The specification would be per [mm], so like 123 mOhm/mm; the trace width is known from routing, the Copper thickness is known from Board setup.
Maybe simpler solution without additional resistance specifiers would be to add an option, that:
Passive Components are considered as “pass-through” or
a component could have an option, consider as pass-through
I cannot recall a case in which case (1) would bring issues at the moment, if there is then still (2) is an option, but (1) does not imply any library changes. Maybe (1) is a potential and very simple option to go (?)
When 2…3 years ago there were the discussion like this my proposition if remember well was to let
ERC assume power is propagating through L and through R if its value is lower than a specified value (like 1 Ohm).
Your 1 generates problems.
Capacitor is passive component so power passes from VCC to GND and they both probably have power output pins.
Pull-up resistor is passive and power at one end and some kind of output at the other.
Assuming that power propagates through L is good for filtering L but can be a problem for L used in DCDC.
I take place in discussions on like this subject but it is not important for me - I don’t run ERC.
(1) True,
(2) is the only option but then maybe better idea is to define:
instead of just passive, we could split into:
Passive or Passive Voltage : for voltage based elements
Passive Current : for current based elements
Changing to Passive Current would then do the job.
Use of ERC is from my eyes mandatory to keep sch clean, but ERC must handle such cases to be useful instead of generating warnings/errors where there are not, then you might have used it as well.
To me it is not clear what you mean.
I understand that you divide all passives into passive voltage and passive current. And the capacitor is…?
Only passive voltage would pass power to the other side?
There are elements like L with taps.
If remember well those time (few years ago) I suggested to may be add a flag to each of symbol pin and all pins with that flag set could be considered as passing power between them.
I don’t think so.
Now using ERC would generate a need for a lot of PWR_FLAGs as I have each IC powered through ferryte bead.
Even when transferring power through elements would be solved the need for at least two PWR_FLAGs left and I simply don’t like to have any symbol at schematic that really is nothing. For me it disturbs reading schematic.
Capacitor is of course voltage passive, it stores voltage; inductor (beads) are current. For two taps this is simple; with multi taps we would already need to specify relationship, so in this case a matrix of cross resistances is still the best.
I also dislike the extensive use PWR_FLAG to overcome kicad weakness, that was the reason to start this post.
Track resistance is often about track temperature rise for UL etc. This gets complicated when a couple of high current tracks are close to each other - a situation that often arises in power supplies where you are trying to minimize current loops for EMC compliance.
It looks like IBIS will be the way to go. If IBIS model for a part is given it could at the same time be used for improved ERC, unless a new button Signal Integrity Checks will appear.
