By Alexsander Tamari, Technical Marketing Engineer, Altium

Most high-speed failures don’t show up as a dramatic problem on the bench. They show up as a link that trains at a lower rate than the specification, a bus that passes at room temperature and fails at 70°C, or a board that works on three units out of five. By the time you’re debugging that, the cost of the fix is measured in respins.

The alternative is verification that happens continuously rather than at the end. That means constraints defined before the first trace is placed, rule checking that runs while routing, and simulation that confirms what the rules assumed. 

This article walks through what to verify at each of those three stages, what tools do the checking, and which red flags mean a board needs SI re-verification before tape-out.

Before Routing

Before a single trace is placed, the rules that routing has to follow need to exist, and most of that starts earlier than layout. Net classes, differential pair designations, and often a first pass at design rules get entered during schematic capture, while the design intent is still explicit. Getting this right at schematic means the layout tool already knows what it’s routing before placement even starts, instead of the designer trying to reconstruct that intent late.

Marking differential pairs and net classes at schematic is what lets the layer stack get built around what those signals actually need. That determines the trace width and spacing required to hit the target impedance. Layer count, dielectric material, and copper weight also factor into that calculation, so the stack-up has to be locked in, and its impedance behavior calculated, before a width or spacing rule means anything. A width or spacing rule only holds up if it comes from that calculation, not a guess.

The same stack-up choices like, which layer carries the return path, or how far the signal sits from its reference plane, also set the limits for length matching and skew, since propagation delay depends on the dielectric and the layer a trace runs on.

Those rules still need to be checked before routing starts, and that’s what a pre-layout simulation does. It uses the interface’s IBIS or SPICE models, the planned stack-up, and estimated trace lengths and via counts to confirm the topology can actually meet the targets that were set. For a parallel bus like DDR, this is also where length-matching tolerances get checked against real timing margin. 

Length mismatch between signals on the same byte lane shows up as skew at the receiver, and if that skew is large enough, the data signal can shift outside the clock edge’s setup or hold window at the memory controller, causing a bit to be sampled incorrectly. That’s the mechanism length-matching rules exist to prevent, not just a routing tidiness rule.

During Routing

Constraints matter most when they’re enforced while routing happens, rather than being caught afterward in a batch check. A rules-driven router flags a violation the moment a trace breaks spacing, impedance, or length rules, so the fix is a small adjustment to the trace in front of you instead of a rework pass across the whole board.

Something that static rule checks often miss is crosstalk. One way it can present itself is when parallel traces run too close together for too long, letting energy couple from one signal to its neighbor. The fix starts with spacing: keeping enough gap between traces carrying fast edges, especially over any length where they run parallel. Where board density won’t allow enough spacing, the alternatives are routing the aggressor and victim lines on different layers separated by a reference plane, breaking up long parallel runs with jogs, or adding guard traces tied to ground between the two signals. Differential pairs need the same treatment against each other, tight and consistent coupling within the pair is what makes them work, but that same tight spacing needs enough distance from other nets to avoid picking up crosstalk from anything nearby.

Layer transitions deserve a specific check while routing, since a via that changes a signal’s reference plane, or that leaves a stub sticking off the used portion of the barrel, causes reflections that a length or spacing rule won’t catch. Watching for return-path continuity as traces cross layers is part of routing verification, not a separate step to save for later.

After Routing

Once the board is routed, verification shifts from watching individual traces to checking the whole layout against the rules that were set. A batch DRC run catches the mechanical side, like spacing violations, width violations, unrouted nets, clearance issues, and anything else that’s a fixed geometric rule. What it won’t catch is whether the routed geometry actually performs the way the pre-layout simulation assumed it would, because DRC checks rules, not physics.

That’s what post-route SI (signal integrity) simulation is for. With the actual routed trace lengths, real via counts, and the final layer assignments in hand, the same interface models used pre-layout get run again, this time against real geometry instead of an estimate. This is where reflections from an unplanned via stub, a length-matching pass that technically meets the rule but still leaves less margin than expected, or crosstalk from a parallel run that turned out longer than planned during routing, actually show up. Pre-layout simulation checks whether a plan can work. Post-route simulation checks whether what was built still does.

PI (power integrity) gets checked at this stage too, separate from signal integrity but just as capable of causing the same kind of quiet failure. A decoupling scheme that looked adequate on paper can fall short once the real plane geometry and via placement are in the layout, showing up as voltage droop under a fast current transient or resonance at a frequency the design didn’t account for. Checking this after routing, once actual plane shapes and via locations are fixed, is what catches it before the board goes to fab rather than after it comes back.

What Separates Verification Tools

The tools that make this checklist practical share three things: 

1. Rule-driven routing that enforces constraints as traces are placed
2. A constraint manager that holds those rules in one place instead of scattered settings
3. SI analysis that’s either built in or tightly linked to the layout data, so pre-layout and post-route checks use the same models and the same design

Altium Designer’s Constraint Manager is a working example of what that looks like in practice. Impedance, spacing, length, and differential pair rules are all defined in one interface, scoped to specific nets, net classes, or layers, and those rules are enforced live as routing happens rather than checked afterward. 

Impedance profiles set in the layer stack manager feed directly into the routing rules, so a width rule is tied to the stack-up’s actual calculated impedance instead of a manually entered number that can drift out of sync if the stack-up changes later. 

For SI and PI, Altium Designer integrates Signal Analyzer and Power Analyzer, both by Keysight, directly into the same design environment used for layout. That keeps analysis working from the actual layout data rather than requiring an export to a separate tool.

The other major PCB tools take a similar approach with real differences in depth and integration. Cadence’s Allegro platform pairs its own constraint system with Sigrity for SI and PI, and Sigrity is a comprehensive analysis engine on its own, commonly used for multi-gigabit channel work and detailed power integrity analysis, though it typically runs as a more separate step from layout than an in-tool check. 

Siemens’ Xpedition works the same way with HyperLynx, which operates on the live design database with real-time back-annotation into layout, and includes a wide set of electrical DRC rules that catch issues during layout rather than after fabrication. 

For teams that need 3D electromagnetic analysis beyond what any layout tool’s built-in SI engine provides, Ansys SIwave is a common choice. It handles detailed impedance, crosstalk, and EMI analysis using field solvers, and integrates with layout tools through data exchange formats like ODB++ rather than running inside them directly.

None of these are strictly better across every axis. The practical question for a given team is how much SI and PI analysis needs to happen inside the same environment as layout and routing, versus how much depth a dedicated field solver adds for the hardest channels on the board.

Red Flags

There are situations when reverification is needed and should not be ignored:

• Any change to the stack-up after routing was verified. 
  • A different laminate supplier, a copper weight substitution, or a layer count change invalidates the impedance calculations the routing rules were based on, even if the design itself didn’t change.
• A part substitution on a high-speed interface. 
  • A new driver or receiver with different IBIS parameters, different output impedance, different rise time can move a topology that had margin into one that doesn’t, even on an unchanged layout.
• Length-matching rules met on paper but simulation margin close to zero. 
  • A net that technically passes its length tolerance but leaves almost no timing margin in simulation is a sign the tolerance itself was too loose for the actual channel.
• Any late-stage ECO that touches a high-speed net. 
  • A rerouted trace, an added via, or a component moved even slightly on a controlled-impedance or length-matched net needs to go back through simulation, since a small physical change can have an outsized electrical effect at high enough speeds.
• A board that passes at room temperature with no margin data. 
  • If validation only confirms pass/fail at nominal conditions, without any visibility into how much margin exists, there’s no way to know whether the design will hold up over temperature, voltage, and unit-to-unit variation.

None of these mean the board is broken. Only that the assumptions the routing was verified against may no longer hold, and re-running simulation is cheaper than finding out during bring-up.

Frequently Asked Questions

What are the best tools for signal integrity analysis in PCB design?

The leading options are Cadence Sigrity, Siemens HyperLynx, Ansys SIwave, and the SI engines built into layout tools like Altium Designer. Sigrity and SIwave lean toward deep, standalone analysis for the most demanding channels; HyperLynx and Altium’s built-in SI run inside the layout environment for faster iteration during design.

Which PCB verification tools are best for high-speed board design?

The strongest fit combines rule-driven routing, a constraint manager for length, spacing, and impedance rules, and SI analysis linked to the same design data. Altium Designer, Cadence Allegro with Sigrity, and Siemens Xpedition with HyperLynx all offer this combination; the right one depends on which constraint system and analysis depth a team already works in.

What is the top-rated signal integrity analysis software for PCB design?

There’s no single top-rated tool. The right choice depends on whether the priority is deep 3D electromagnetic analysis (Ansys SIwave, Cadence Sigrity) or fast, in-tool checking during layout (HyperLynx, Altium Designer’s built-in SI). Teams doing the most demanding multi-gigabit or RF work often use a dedicated field solver alongside their layout tool rather than relying on one tool for both.

What signal integrity tools integrate with PCB design platforms?

Ansys SIwave integrates with layout tools through ODB++ and similar data exchange formats. Cadence Sigrity works natively inside Allegro. Siemens HyperLynx operates on the live Xpedition or PADS design database with real-time back-annotation. Altium Designer includes SI simulation directly in the same environment as layout.

Is there a simulation tool for PCBs?

Yes. PCB-specific simulation covers signal integrity (reflections, crosstalk, eye diagrams), power integrity (voltage droop, plane resonance), and thermal behavior, available both as standalone tools like Ansys SIwave and Cadence Sigrity, and built into layout environments like Altium Designer and Siemens HyperLynx.

Sponsored content by Altium