CDC and RDC Verification CDC and RDC Verification Solution ALINT-PRO™ features an ALDEC_CDC rule plug-in that focuses on clock and reset domain crossings analysis as well as the handling of metastability issues in complex, modern multi-clock and multi-reset designs. Included rules uncover critical problems during the RTL Design and Functional Verification stages, significantly cutting down time to market. Clock Domain Crossing (CDC) issues constitute a complex and widely spread verification problem for the majority of modern designs, regardless of the application type or implementation technology. The number of independent interacting clocks, and their associated mistakes, in designs is continuously growing in most industries. Reset Domain Crossing (RDC) issues represent a relatively new class of errors, which are typical for designs with complex reset strategies having dynamically switchable parts, and thus, they require more frequent reset sequences within certain regions of the design. The root-cause are the unsynchronized data transfers between sequential elements that have different unrelated asynchronous reset signals, even if they are controlled with an identical clock. As a rule of thumb, CDC bugs have a higher probability than RDC bugs, as RDC-related metastability can only happen during a reset event, while CDC-related metastability may occur at any point in time. Still, it is very important to clean both classes of domain crossing issues, and the verification methods for both types of issues have a lot in common. The CDC/RDC verification strategy is comprised of three key elements: static structural verification, design constraints setup, and dynamic functional verification. Static checks are implemented in the form of linting and are performed in ALINT-PRO, while dynamic verification is based on integration with Riviera-PRO™, Active-HDL™, or ModelSim® through an automatically generated SystemVerilog or VHDL testbench. The testbench can seamlessly integrate with an existing design, and enables the revealing of metastability triggered issues during RTL simulation. ALINT-PRO is equipped with CDC and RDC Viewers designed to facilitate analysis of metastability issues. It can visualize asynchronous clock or reset domains with a distinct color in the RTL Schematic Viewer, as well as display a detailed view of detected clock and reset domain elements, related clock and reset signals, group-identified domain crossings, and synchronizers to help users understand whether the discovered asynchronous transfers are being properly handled. This enables high level design analysis in respect to the clock and reset domains partitioning. Design Constraints Support Design constraints support is an essential element for proper metastability verification. ALINT-PRO™ can read SDC files for design configuration and retrieve information relevant for linting. This includes: clock declarations and relations between them, input and output ports’ correlation to the clocks, asynchronous and physically/logically exclusive clock groups, false and multi-cycle paths, setup of case analysis, etc. Without the constraints, ALINT-PRO attempts to detect the structure of the clock, reset networks, I/O delays, clock groups, and synchronization circuits, all automatically on its own based only on the netlist topology and predefined circuit patterns. The tool can generate the initial draft of the SDC file for use in subsequent design stages, such as timing-driven logic synthesis and static timing analysis. The generated SDC draft contains clock declarations, including master and generated clocks, asynchronous clock groups, and descriptions of I/O delays for the top-level ports relative to the corresponding reading/writing clocks. The exact clock frequencies and delay values cannot be extracted from the RTL, so default values are used, which should be adjusted later before use in the subsequent design tools. Based on structural verification results, ALINT-PRO can also generate templates for some of the most challenging SDC constraints, which declare timing exceptions and provide extra hints for consumption by the vendor-specific place & route and static timing analysis tools. Mixing partially specified SDC input and automatic detection is allowed. Both methods complement each other, and SDC can often be used to direct the automatic detection into a right direction, which is hard to avoid in some advanced cases, especially in ASIC designs having complex custom clock gating, multiplexing, and scan-enable circuitry. ALINT-PRO offers a custom extension to design constraints: Aldec Design Constraints (ADC). These extensions help capture high level intent on elements of the design that cannot be expressed by commonly supported SDC syntax, such as reset semantics. Thus, ADC can be considered as a superset of wide-spread SDC. Generating ADC extensions, such as master and generated resets based on pure topology, is provided similarly to the SDC processing flow. These extended ADC constraints are divided into two groups: Block-level design constraints – used for describing modules, which cannot be directly synthesized: FPGA vendor primitives, behavioral models, or encrypted IPs. It is also possible to describe custom synchronizers, clock and reset generation cells, as well as specific RAMs and FIFOs to validate their correct usage in the design. Chip-level design constraints – used for describing reset networks, quasi-static registers, CDC and RDC waivers, and the retrieving of additional information from the netlist, clocks/resets, as well as CDC and RDC models. ALINT-PRO provides pre-packaged, up-to-date accurate timing annotations (block-level constraints) for the most relevant Xilinx, Intel (Altera), Microsemi and Lattice FPGA libraries, including input and output delays relative to clock pins, and multi-mode primitives having timing behavior dependent on the values of particular generics. This dramatically reduces the amount of CDC/RDC false positives and uncovers previously invisible clock and reset domain crossing paths. Writing custom block-level constraints is a must for the designs instantiating complex multi-clock IP-blocks (for example, encrypted cores) and other types of black boxes. The user needs to explicitly declare clock and asynchronous control pins, as well as express the relation between non-control I/O pins and the assumed clocks. Without clear timing abstraction associated with the black-box, ALINT-PRO makes pessimistic assumptions regarding the possible clock domain crossings within the block, and may generate many false positive messages. Block-level design constraints can also be used to improve the performance of CDC analysis using a hierarchical approach. If a large design block was already verified against internal CDC issues, it makes sense to replace it with a black-box and block-level design constraints model, as new CDC violations related to the verified block may only appear at its I/O border. Static Verification ALINT-PRO features a set of rules (ALDEC_CDC rule plug-in), which can be statically verified. These rules consist of two sections: constraint rules (clocks, resets, and I/O delay analysis) and CDC/RDC rules (synchronizer’s structure analysis). A phased-based CDC flow can be utilized to facilitate running the rules in a recommended predefined order that minimizes the potential number of verification reruns until the design reaches a CDC-clean state. Clock and reset networks verification is performed prior to CDC checks to ensure proper clock domains extraction. The CDC rules verify crossings between asynchronous clock domains. Crossings are verified against having combinational logic, convergence, or divergence. It is also checked, that a valid synchronizer is present on the crossing. For the asynchronous resets, de-assertion is verified to be synchronous with the proper clock. Finally, the uncovered synchronizers are checked against combinational or sequential re-convergence, possibly very deep in the target domain. The RDC rules verify crossings between independent reset domains, looking for RDC-specific synchronization patterns. Resets from different domains are analyzed by pairs. For the same crossing, there could be multiple different combinations of reset signals that can cause the path to be asynchronous, leading to a metastable state. Special care must be taken to analyze the designs with multiple clock operation modes that may be selected either statically, or dynamically, which dramatically complicates CDC verification. ALINT-PRO is capable to support the modal CDC analysis in consolidated multi-mode manner, or, individually, on a case basis. A key differentiator of the consolidated multi-mode CDC analysis is that it takes only a single tool run to produce the combined verification result that lists all unexpected CDC topologies in all valid modes at once. The invalid activation conditions are smartly eliminated, so that only the relevant mode combinations are being checked. The larger number of valid modes undoubtedly complicates interpreting the results of CDC checks. However, the performance savings are significant. Alternatively, each of the individual operational modes may be analyzed in isolation using the matching ‘set_case_analysis’ constraints, which basically eliminate the inactive paths during the analysis. Although this type of verification result is much easier to understand, it requires multiple runs per each mode, and in case any corrections happen to design itself or to the associated timing constraints, the verification must be re-run for every mode from scratch. Dynamic Verification Structural checks can verify that a proper synchronizer is present in the crossing, however to ensure there are no metastability bugs, the communication protocol should be verified. ALINT-PRO can generate SystemVerilog, pure VHDL, and VHDL with PSL testbench to enhance RTL simulation with additional checks. It contains the following elements: Metastability Emulation – behavioral SystemVerilog or VHDL code, which inserts random delays on crossings between asynchronous clock domains. This allows revealing such issues as missed pulse or data incoherence during RTL simulation. Assertions – assertions are generated for synchronized crossings to ensure proper usage of the synchronizers. This includes checks for data stability and proper capturing of data sent over clock domain boundaries. Coverage – allows validating a user’s testbench to trigger data transfers on the synchronized crossings and checks if that random delay, inserted due to metastability emulation, has actually occurred during the simulation. The generated testbench doesn’t contain stimulus and cannot be used for simulation without a design’s original testbench.
