Static Design Rules and Constraints Verification

Comprehensive logic and circuit verification of complex VLSI designs has become more critical than ever with the exploding design complexities enabled by current semiconductor technologies. As designs become larger and more complex, it also becomes increasingly difficult to achieve the same level of verification that was possible in earlier generation designs, unless the verification methodology keeps pace with the designs.

Existing verification solutions do not completely cover the verification space for complex ASIC and custom designs. There are numerous design constraints and requirements that are not verified exhaustively in many complex designs at present. These design constraints arise due to various design rules, requirements, restrictions, guidelines, specifications and assumptions that are common in most designs. These constraints must be met in order for the design to function correctly and reliably.

The constraints may be related to various verification domains such as functionality, timing, testability, reliability, circuit restrictions, or combinations and overlaps of these areas. In general, such design constraints often straddle multiple verification domains and usually require exhaustive verification over the entire design. Therefore, the verification tool must use static analysis techniques to provide exhaustive coverage. The tool should also be able to analyze multiple problem domains and interactions between them in a single framework.

There is clearly a need for a new design constraint verification tool that can meet these requirements, complement existing tools and fit easily into most design methodologies. Since the design constraints may vary significantly between different designs, it is also necessary to allow users to "program" the tool, so that the verification space can be customized to suit each design.

SDA’s static design constraint verifier is capable of exhaustively analyzing large designs in acceptable run times. It allows users to program various design rules, specifications, constraints, assumptions, etc., using a very simple language. It then exhaustively verifies the entire design for conformance to those requirements.

The constraints can be written to verify existence of certain properties, as well as nonexistence of certain other properties. These properties are typically not completely verified in the course of normal functional and timing verification methodologies. The intent of constraint checking is to help enforce the fundamental rules of a particular design or design environment on a day-to-day basis as the design is created and modified. This prevents potentially serious design problems that may require costly analysis, debug and redesign late in the design cycle or after the chip is already in production.

SDA’s static design constraint verifier is intended to be used together with existing verification tools, and is not meant as a replacement for any other tool. For example, it can work closely with timing verifiers and delay calculators, by means of importing Standard Delay Format (SDF) delays or signal arrival times from these tools. The uniqueness of this tool is that it can analyze and process topology, functionality, timing and electrical information in a single framework, so that potential interactions between these analysis areas can be considered in the verification.

The following are examples of typical rules and constraints that can be verified exhaustively using SDA:

• Cell usage rules, which can verify rules related to input and output pins of cells: functional relationships, timing phase relationships, timing skew, load limits and connectivity rules at inputs or outputs of a cell.
• Path validity rules, which can be coded in detail to verify the existence of paths which run between and through specific points in the design (and meet specific logic properties), the nonexistence of invalid paths, exclusive paths between specific points, etc. The paths can be combinational, or they can be sequential paths that pass through multiple flip-flops or latches.
• Testability rules, such as: scan chain connectivity, controllability/observability logic, test clock schemes, and mutual exclusion conditions to avoid logic conflicts. (This is an example of how path validity rules can be used in particular applications.)
• Clock gating/buffering and clock distribution rules. (This is yet another example of how path validity rules can be applied.)
• Clock phase rules between source and destination of a path, between inputs of a dynamic logic gate, etc.
• Detailed clock skew constraints within and between various regions in a global clock distribution network.
• General timing constraints, such as: skews at cell inputs, pulse-widths, delay of a path segment, skew between delays of two path segments, etc.
• Functional rules such as mutual exclusion of drivers at tristate buses, requirement that there should be a default driver on every tristate bus, mutual exclusion of multiplexer select signals, etc.
• False timing path checks based on logic functionality.
• Signal coupling checks based on both timing and functional analyses.