Mixed-signal designs are where standard DRC libraries start showing their limits. When you have an ADC frontend sharing a ground reference with a switching regulator and a microcontroller GPIO rail, the risks are specific to your topology, your supply voltages, and your signal paths. No generic rule set handles that combination correctly out of the box.
We added custom rule authoring to CADY because we kept seeing the same pattern: teams would run the default library, get a clean report, and still send boards with analog-digital crosstalk problems that a senior engineer reviewing the schematic would have flagged. The built-in rules cover broad categories, but topology-specific checks require you to express what your design actually requires.
This article walks through how custom rule authoring works in CADY and which kinds of rules matter most in mixed-signal designs.
What built-in rules miss in mixed-signal schematics
Built-in DRC libraries focus on patterns that appear across many different designs: missing decoupling caps, undriven nets, pin-type mismatches, net naming conflicts. These rules are correct and worth running on every review. But mixed-signal designs carry additional risks that only appear in context:
- Your analog supply domain (AVDD, AGND) may require physical separation from the digital supply domain (DVDD, DGND), with a single-point star connection at a specified reference net
- Return current paths for high-frequency digital signals should not cross analog-sensitive net segments
- ADC input nets may require specific coupling capacitor proximity constraints, with decoupling within a specified distance of the device's reference pin
- Op-amp feedback networks may carry net constraints that generic connectivity rules cannot express
None of these appear in a standard rule set. They are specific to your architecture, and the only way to check them automatically is to author rules that reflect your design intent.
The CADY custom rule format
Custom rules in CADY are written as predicate expressions over the component graph and net table. You define a selector (which nets or components to examine), a condition (what property to check), and a severity level (CRIT, WARN, or INFO).
A simplified example for analog-digital ground isolation looks like this:
rule "analog-supply-isolation" {
select nets where name_matches("AGND", "AVDD")
check not connected_to nets where name_matches("DVDD", "DGND")
except via ref("U_GND_BRIDGE")
severity WARN
message "Analog supply net connected to digital supply domain outside bridge reference"
}This rule selects all nets matching your analog supply naming convention and verifies they do not connect to digital supply nets except through a designated bridge component. If your schematic connects AGND and DGND at two separate points, this rule fires. If the bridge component is missing entirely, it also fires.
Return path continuity rules
Return path problems are among the most expensive missed errors in mixed-signal design. A high-speed digital clock line that references a return path through a split ground plane causes electromagnetic interference problems that are difficult to debug on a physical board. By the time you have a prototype in hand, the problem is expensive to fix.
At the schematic level, you cannot directly express the physical routing of return currents. What you can express is the ground topology constraint: digital clock nets should reference a specific ground net symbol, and that ground net should not have connections that bridge across your analog-digital split.
rule "digital-clock-return-domain" {
select nets where category == "clk" and frequency_hint > 10MHz
check all_connected_grounds in domain("DGND")
severity CRIT
message "Clock net references ground outside digital domain"
}The frequency_hint attribute is derived from component parameters if your EDA tool exports them, or from a custom attribute you define in your component library. CADY reads component properties from the netlist when they are present in the export.
Analog coupling and reference pin proximity
For ADC designs, a common requirement is that the reference pin of the converter (VREF or REFIN) must have a dedicated decoupling network with specific capacitor values, and analog input nets must not share net segments with high-impedance digital I/O lines.
Custom rules handle both:
rule "adc-vref-decoupling" {
select component where designator_matches("U_ADC*")
check pin("VREF").connected_nets has_cap
with value_range(100nF, 10uF)
severity CRIT
message "ADC VREF pin missing required decoupling capacitor"
}
rule "adc-input-isolation" {
select nets where connected_to pin("U_ADC*.AIN*")
check not shared_segment_with
nets connected_to pin_type("GPIO")
severity WARN
message "ADC analog input net shares segment with digital GPIO net"
}The first rule checks that a bypass capacitor is present on the VREF net within the value range your design requires. The second checks that analog input nets are not sharing net segments with GPIO lines, which would introduce digital switching noise onto a high-impedance analog path.
Power domain separation rules
Power domain separation in mixed-signal designs frequently requires expressing constraints about which nets can be connected to which supply symbols. This is where CADY's custom rules integrate with your team's naming conventions.
If your team uses a standard naming scheme where analog supply nets begin with "A_" and digital supply nets begin with "D_", you can write domain isolation rules that enforce this boundary across the full schematic automatically. Violations introduced during schematic revisions, when an engineer copies a reference circuit block without updating the net names, become visible immediately in the next review.
In our early-access program data, teams running custom domain separation rules typically surface two to three violations per revision cycle that were invisible in the standard DRC output. Most of them trace back to copy-paste operations that brought in a supply net name from a different design family.
Where custom rules have limits
CADY flags violations according to the rules you define. It does not rewrite your schematic, auto-correct net assignments, or determine whether a flagged condition will actually cause a functional problem in your specific design. A rule fire is a signal for review, not a verdict on whether the board will work.
This distinction matters in mixed-signal work because some intentional connections between analog and digital domains are correct. A ferrite bead between AGND and DGND is a valid single-point connection in many designs. A custom rule that fires on that ferrite bead's reference component needs an explicit exclusion in the rule definition, or you will accumulate false positives and start ignoring the rule altogether.
Good custom rules spend as much effort on exclusion conditions as on the primary check. High false-positive rates are the main reason teams disable rules they wrote themselves. Build the exclusion list before you commit the rule to your project's rule file.
Building a team rule library over time
CADY's rule files are plain text, so they belong in version control alongside your schematic files. When a new board revision introduces a new topology, the rule set should be updated in the same commit. That way, the schematic and the review criteria that apply to it stay in sync across branches and revisions.
The rule libraries that grow most usefully are the ones that accumulate rules from real errors caught in prior designs, not rules written speculatively before a design has been tested. Start with the two or three patterns that burned you most on your last mixed-signal board. Write rules that would have caught those. Run them on the current design. Add from there.
Mixed-signal rule authoring is not a one-time setup task. The rules that matter for one design family often do not apply to another. Keeping rule files project-specific, tracked in version control, and reviewed alongside the schematic is the pattern that produces consistently useful checks rather than a growing library of rules that no one is sure still apply.