Skip to content
Connectivity & Glitch Sign-off
Real Intent SafeConnect connectivity & glitch sign-off tool enables early RTL and gate-level netlist sign-off for IP blocks or across SoCs.
Design and verification engineers can quickly define connectivity rules and glitch checks for various source-destination types. SafeConnect’s high-capacity static analysis is about ten times faster than other approaches — with low noise reporting, and integrated debug.
It is the only solution in the industry that enables both connectivity rules and glitch checking.
Shift Left with Early RTL Sign-Off
SafeConnect is deployed during key stages of the IP and SoC design process.
- During RTL design — to ensure memory, power, and debug logic connectivity, and to avoid glitches for user-specified paths. Designers can also detect & eliminate improper connectivity that can lead to block abutment issues during physical design.
- Post-synthesis — to repeat the connectivity checks and glitch checks on the netlist. Engineers can also find and address new issues such as improper connectivity for power supply rail crossing, DFT, and debug logic.
What is Connectivity & Glitch Sign-Off?
What is connectivity?
Connectivity refers to expected paths between specified sources and destinations. Errors can occur when the path is broken, goes through disallowed logic, or connects unspecified sources or destinations. Connectivity sign-off tools & methodologies ensure the connection is valid.
What is a glitch in digital design?
A glitch is a transition that is shorter than the clock period for a signal. A glitch, such as one occurring on an asynchronous path, can cause errors if it occurs close to the clock edge of the receiving flop. Glitch sign-off tools & methodologies ensure the designs still function reliably.
Connectivity & Glitch Bugs Can Cause Chip Failures
Errors in connectivity of any valid path and glitches associated with user-specified asynchronous, multicycle, and false paths can affect design functionality, causing chip failures. Some examples of asynchronous paths are CDC data paths, asynchronous reset paths, global control signals, and power control signals.
Connectivity errors and glitch errors require dedicated analysis. Further, static timing analysis does not analyze for glitch impact for asynchronous paths, false paths, or multicycle paths. Without proper connectivity and glitch sign-off, chips can fail in the field, requiring costly effort to fix.
Connectivity Errors
If a control signal is expected to drive only the enable pins of specific instances without any combo logic on the path, then a broken connection or extra fanout can affect its functionality.
This needs to be identified as a violation of design connectivity rules as it can lead to design errors.
Glitch Errors
As shown in the figure, a transition on the select line of a MUX can lead to a glitch at the output of that MUX. Different combinational delays on the paths to the MUX output can cause this glitch to occur.
The glitch can then propagate through combinational logic, causing a transition at the input of the receiving FF. This untimed transition can put the receiving FF in an unexpected state and lead to functional failure.
Early RTL checks avoid connectivity violations
Abutment rules. To get the best timing and area result, chip place and route may need to ensure that certain blocks are abutted (placed next to each other tightly).
Doing so requires that specific connectivity rules are followed for connections between the two blocks. Violation of any of these rules can make it impossible to properly complete chip placement and routing.
The connections between the blocks are defined in the RTL design. Ensuring the block abutment connectivity rules are adhered to at the RTL level can help avoid problems in the downstream flow.
Debug bus observability rules. To maintain the observability of certain signals, they must be connected to observing ports through only specific logic allowed on the path.
If the connection between the signal to be observed and the port observing it is broken or goes through disallowed logic, it can cause failure in the observability of the signal.
SafeConnect Resources
Datasheet
Case Studies
White Papers
Short VideosEfficiently Define Variety of Sign-Off Rules
Design and verification engineers can flexibly create a diverse set of connectivity and glitch sign-off rules, as well as utilize Real Intent’s existing documented library of checks.
SafeConnect’s efficient, flexible commands require only a minimum rule specification effort, as compared with tedious and error-prone spreadsheets or complex Tcl coding. SafeConnect also accepts UPF as direct input to further ease the specification effort.
The following, are representative rules that customers have created to check for issues at block or SoC level:
- EMA (Extra margin adjustment) memory connectivity
- Retention resets/clocks
- Glitch occurrence and propagation
- DFT logic MUX and debug busses observability
- Abutment & partial abutment
Control Granular Sub-Checks for Further Noise Reduction
Further, SafeConnect allows sub-checks for additional reduction of noise in the violation reports. A few sub-check examples are:
- Cross connect (switched sources & destinations)
- Source / destination miss
- Extra connection
- Bit flips
Individual designers precisely control which rules and sub-checks to run and report.
SafeConnect Has Integrated Debug
SafeConnect integrates Real Intent’s familiar iDebug environment, along with additional functionality for focused connectivity & glitch violation debugging.
Real Intent’s iDebug design intent debugger and analysis manager provides user configurability with a command line interface (CLI), along with organized, low noise reports to help users quickly pinpoint the root cause of the errors.
SafeConnect is Superior to Scripts & Formal Approaches
Real Intent SafeConnect’s highest capacity in the industry makes it suitable for both block-level and SoC-level sign-off. Black boxing is available — but in contrast to other approaches, it is not required for large designs.
SafeConnect can be run early, on RTL design. Further, it takes only minutes to run block-level analysis — compared to hours for formal and Tcl-based scripting for comparable blocks.
Additionally, SafeConnect can be run on any design type, including designs with complex control logic and clock gating.
It provides low noise reports via efficient pattern matching and user-specified configurations, including destination exclusions. SafeConnect enables seamless, targeted connectivity and glitch violation debugging.
Finally, ongoing maintenance and support are minimal for SafeConnect, compared with the extensive maintenance effort required for Tcl-based scripting.