Connectivity Sign-Off: 5 Ways to Prevent Costly Errors

1a. Need user-defined comprehensive ruleset

To achieve sign-off, it’s critical to have a comprehensive set of rules. For example, an industry standard bus with multiple drivers and receivers may need to have different connectivity depending on the design mode. Additional connectivity checks might be that all sources are connected to all destinations, only one source is connected to the specified set of destinations, etc.

Example 1. Check that the connectivity between two flip-flops exists or does not exist.

Connectivity should exist between FF_SRC & FF_DEST

Connectivity should not exist between FF_SRC & FF_DEST

Example 2: Check that source bus [0:3] is connected to destination bus [0:3] without any bit swapping.

Expected connectivity

Bit swizzle error

If the design has a connection from A to C, then a connection from B to C is not allowed.

The engineer should check for both the connections – one existing and the other not existing.

Mutually exclusive driver connection

1b. Create groups, define clear rules & granular sub-checks

The most efficient way to build a connectivity checking ruleset is to first create groups to aggregate objects for checking, based on sources, destinations, and path tracing control.

1c. Define rules to avoid redundancy

Connectivity rules should be defined such that there is no redundancy in checking the same source and destination for different violation types.

Paths from source to destination can be checked for not having combo logic in one rule and then checked for extra fanouts in another rule. Precisely combining this functionality in one rule avoids redundancy to improve analysis and user review efficiency.

RTL design stage: Validate connectivity for memory, power, and debug logic, and avoid glitches. Identify & remedy improper connections that could create complications when blocks are placed side by side in physical design.

Post-synthesis stage: Re-run connectivity checks on the synthesized netlist to uncover new issues introduced — especially around power rail crossings, DFT, and debug logic that could affect implementation or test.

Abutment connectivity checking

An example of how significant benefit can be achieved with early verification is abutment connectivity checking.

Some blocks are abutted in the physical layout and need to follow strict rules to avoid design failures. Ensuring compliance of the expected connectivity at RTL level can proactively avoid finding issues later.

For the blocks to be abutted, various checks, e.g., open, tie, split, combo, loopback, and extra connection should be performed. As shown here, the allowed arcs show top-level instances that are to be checked for abutment compliance.

Allowed Arcs = { A B } { A C } { * TOP }

3a. Formal verification vs. Static sign-off

Exhaustive verification. Both connectivity static sign-off and formal methods perform exhaustive verification, but the combination of static sign-off’s speed and capacity enables it to fully analyze both short, simple paths and complex paths with multiple sources and destinations.

Performance. Static sign-off has analyzed tens of millions of gates in about 30 minutes — including reading the design to create the database — with only a few minutes of analysis time.

This is orders of magnitude faster than formal verification, which can take hours. Static sign-off also performs well on a single CPU, while formal requires multiple cores. Memory usage for static sign-off is estimated to be less than 1 GB per million gates.

Capacity. Static sign-off can analyze billions of gates in a few hours — without requiring black boxing. This can include checking millions of paths from multiple sources to destinations very efficiently.

Formal verification, however, typically supports only a few million gates, even after using multiple processing cores for analysis.

Connectivity static sign-off’s performance is orders of magnitude faster than formal methods

3b. Simulation vs. Static sign-off

Coverage. With simulation, coverage depends on test vectors, testbenches, and VIP availability. The checks only cover conditions explicitly specified in the test vectors, so designers cannot guarantee all conditions are covered. Additionally, to try to do glitch checking during simulation, an engineer would write assertions to do limited glitch checking for specific points.

Static sign-off user-defined rules automatically cover all conditions. If the engineer specifies a source/destination pattern, it will cover all combinations.

Similar to simulation, connectivity static sign-off checks that the destination has the expected value for specified source and constraint values providing the basic expected checks.

Checking expected value at a destination

Feasibility. Certain checks are only feasible in static sign-off — and not simulation. Some examples are:

1. Confirming bus bits aren’t swapped (see 1a, ex 2)

2. Verifying only one source drives multiple destinations (see 1a, ex 3)

3. Checking physical connectivity early by verifying proper abutment (see 1b)

4. Confirming that a connection does not exist

• Static sign-off will flag that the specific connection does not exist– in any situation.
• Simulation will not flag that connection does not exist — if other signals drive destination to the expected value.

Does connection from A to B exist?

5. Confirm there is no extra fanout

• Static sign-off will check whether A is connected to B, and  check for an extra fanout
• Simulation will only check that A is connected to B. It cannot check for an extra fanout

Is there an extra fanout?

Further, because static sign-off rule creation is not dependent on test vectors or test bench availability, the sign-off step can start very early in RTL design.

3c. Tcl scripting vs. Static sign-off

Rule Creation. Tcl scripts require complex coding and ongoing maintenance for connectivity checking. In contrast, static sign-off uses efficient, flexible commands with minimal rule specification or maintenance effort.

Performance. Tcl scripts take hours to run just one block, which static sign-off can complete in minutes.

Early vs. late sign-off. Tcl scripts run only on netlists, so checks do not occur until after synthesis. Static sign-off can be run during RTL, enabling early detection of connectivity errors and reducing unnecessary iterations.

3d. RTL linting vs. Static sign-off

RTL linting sign-off is focused on ensuring RTL quality for the selected rules. Connectivity static sign-off goes further, understanding more of the design’s functionality, including power, and performing more explicit checks across the entire design. It also supports constraint-based connectivity and glitch checking.

Connectivity checking should include glitch checking to be complete. A glitch is a signal transition with a duration shorter than the system clock period. Glitches can lead to functional failures— especially when they occur on untimed paths.

A transition on the select line of a multiplexer can induce a glitch at the MUX output due to unequal combinational delays along the data input paths. This glitch can propagate through downstream combinational logic and arrive at the input of a receiving flip-flop.

If the transition occurs near a clock edge, it may violate timing constraints or place the flip-flop in an indeterminate state, potentially resulting in functional errors. On untimed paths, a glitch can cause unexpected system behavior leading to functional failures.