A net-no-driver violation is one of the most common ERC findings in hierarchical schematics, and also one of the most frequently misunderstood. The rule is simple to state: a net that has input or passive pins connected to it but no output, bidirectional, or tristate pin to drive it. The difficulty is in correctly interpreting when that condition represents a real design error versus an artifact of how the schematic was organized or how pin types are declared in the component library.
CADY's connectivity rule set includes net-no-driver checks as a CRIT-level violation by default, because an undriven input pin left floating will behave unpredictably on a real board. But when users first run these checks on an existing schematic, a significant fraction of the violations are false positives caused by library annotation issues, hierarchical sheet port conventions, or intentional open-drain wiring that is not reflected in the pin type metadata.
This post covers how CADY detects net-no-driver conditions, what the common false positive patterns look like, and how to configure the rule to minimize noise while preserving genuine catches.
How the rule works
CADY's net-no-driver check operates on the canonical conductor table after net resolution. For each conductor in the table, the rule queries the set of pin types connected to it. The pin type set comes from the component library metadata attached to each pin in the netlist export.
A conductor fails the rule if:
- It has at least one pin with type
input,passive, orno_connect_expectedconnected to it - It has no pin with type
output,bidirectional,tristate, orpower_outputconnected to it
The severity is CRIT by default, because a net matching this condition has at least one pin that will receive no valid logic level. Floating inputs are susceptible to noise injection and can draw excessive current when biased into the linear region of a CMOS input buffer.
The exception list for this rule includes power rails: a net connected only to power_input pins is checked by separate power supply rules and excluded here to avoid duplicate violations on supply nets.
The library annotation problem
The most common source of false positives in net-no-driver checks is incorrect pin type annotation in the component library. This affects both commercial component libraries and community-maintained ones.
Two patterns appear most frequently. First, bidirectional pins annotated as input-only: a GPIO pin that can be configured as either input or output in firmware is correctly typed bidirectional, but many library entries mark GPIO pins as input because that is the pin's function in the specific configuration the library author intended. If your design uses that GPIO as an output, the net it drives will appear undriven.
Second, open-drain output pins annotated as passive: open-drain outputs on I2C SDA and SCL lines are frequently annotated as passive in component libraries because they can sink but cannot source current. A net with only passive-annotated open-drain drivers and input-annotated receivers will trigger a net-no-driver violation even when the I2C bus is correctly designed with pull-up resistors to supply.
CADY flags both of these as CRIT violations because the rule cannot infer design intent from pin type metadata alone. The fix in both cases is to either correct the library annotation or add an explicit exception in your project's rule configuration file.
Hierarchical sheet boundary cases
In hierarchical schematics, net-no-driver violations at sheet boundaries are another common category. A hierarchical port defined as an output on the parent sheet connects to a net that appears on the child sheet as an input. If the hierarchical port's type is annotated inconsistently between the two sheets, one of the two sheets will appear to have an undriven net.
KiCad's netlist export resolves hierarchical port connections into direct net links in the flattened netlist, so CADY sees the resolved conductor after all sheet boundaries have been crossed. If the port type annotations on both ends of the hierarchy are consistent, the resolution is correct and no false positive appears. If they differ, the rule fires on whichever sheet has the input-side annotation without a matching driver.
The diagnostic step when you see a net-no-driver violation on a hierarchically named net (identifiable by the slash-delimited path prefix like /TOP/SENSOR_SHEET/DATA_OUT) is to check the port type declarations on both the parent and child sheets. In most cases, a port annotated as bidirectional on both ends resolves the violation without requiring a rule exception.
Intentional floating nets: no-connect markers
Some designs intentionally leave specific pins unconnected. A multi-channel ADC where only two of eight channels are used, or a processor where certain peripheral pins are unused in a given product variant, will have input pins that should be left floating or tied to a specific logic level.
EDA tools handle this with no-connect markers (the X symbol placed on a pin in the schematic editor). Most netlist export formats preserve no-connect information either as a special pin type annotation or as an explicit no-connect entry in the component's pin list.
CADY recognizes no-connect markers in KiCad exports (pin type no_connect) and Altium exports (explicit NoConnect property). A net where all connected pins are either no-connect markers or passive pull-up/pull-down resistors is excluded from the net-no-driver check. This prevents the rule from firing on legitimately unused pins that the engineer has explicitly marked as intentionally disconnected.
If your export format does not include no-connect information, or if your component library uses a different convention, you can configure CADY to exclude specific net name patterns or specific component/pin combinations from the net-no-driver rule.
When the rule fires and it is a real error
The most important genuine catches this rule makes are in three scenarios:
First, missing connections due to net naming errors in hierarchical schematics: a net named SPI_CS_1 on one sheet and SPI_CS1 on another (underscore position differs) will not resolve to the same conductor. The SPI_CS_1 net will appear connected only to the chip select input on one device, with no driver, because the signal driving it came from the other sheet under the slightly different name. The board will fail to communicate with that device.
Second, copy-paste errors that bring in component blocks without updating the signal connections: an engineer copies a sensor interface block and forgets to connect the enable line from the microcontroller to the new block's enable input. The enable net on the new block has an input pin but no driver. CADY catches this as a CRIT violation; the schematic editor may not visually highlight it because the symbol renders cleanly with the pin simply unconnected.
Third, deleted driver components where the receiver was not cleaned up: a design revision removes a level-shifter in the signal path but the downstream input net remains in the schematic connected only to the receiving device. The net is electrically orphaned.
Configuring the rule for your project
CADY allows per-rule configuration in your project's rule configuration file. For net-no-driver, the most useful configuration options are the exception list (nets or net name patterns to exclude from the check) and the pin type override map (component/pin combinations where you want to override the library-declared pin type for the purpose of this rule).
A working pattern for I2C busses is to configure the open-drain pin combinations on your specific SDA/SCL driver components as bidirectional in the override map. This suppresses the false positive on the I2C nets while preserving the rule's sensitivity to genuine undriven nets elsewhere in the design.
CADY flags connectivity violations based on the rule definitions and pin metadata in the netlist. It does not determine which violations will result in functional failures on the physical board. Some undriven nets in a design produce obvious failures; others float to a stable state because of parasitic coupling to adjacent nets and may be invisible until environmental conditions change. The rule catches the structural condition. Determining the consequence is the engineer's responsibility.