DEVS-Based CDC Synchronizer Design for Fast Debugging of Metastability

Abstract

This paper proposes a DEVS (Discrete Event System Specification) formalism-based approach to analyze Clock Domain Crossing (CDC) issues in digital circuit design. As modern System on Chip (SoC) designs increasingly integrate multiple clock domains, the verification of CDC-related metastability becomes more challenging and costly. While conventional EDA tools offer solutions for CDC analysis, they often involve substantial computational resources and licensing costs. We present a DEVS-based simulation framework that leverages its inherent advantages in time management and modular structuring to model and analyze CDC scenarios. The framework includes a CDC synchronizer model implemented within the HDL partially compatible DEVS environment, enabling precise analysis of metastability violations based on setup time and hold time requirements. Circuit designers or related engineers can potentially solve timing issues such as CDC by incorporating DEVS-based analysis tools into the design pipeline.

1. Introduction

With the rapid advancement of modern computer systems, the complexity of computer architecture has continuously increased [1]. Along with efforts to improve system processing speed by offloading certain software functions to hardware, the number and diversity of functions that can be handled within a single chip have grown exponentially. This trend has led to the emergence of multi-core processors, complex cache hierarchies, advanced branch prediction techniques, and the integration of various accelerators [2]. As a result, modern computer architects are facing the challenge of exploring much more complex and multidimensional design spaces than ever before [3,4,5,6].

The increase in system complexity has further highlighted the importance of system modeling and simulation. These tools are essential in the design, verification, and optimization processes of computer architecture. In all industries, including chip design, simulation serves as a critical tool for verifying design accuracy, predicting performance, and exploring potential design improvements before the hardware production stage [7,8].

In modern complex computer architectures, it is increasingly difficult to accurately predict the impact of design decisions, making the role of simulation even more critical. The scope of required simulations for a single system, including timing analysis, power analysis, and testability analysis, is also expanding [9].

The evolution of simulation techniques began with Finite State Machine (FSM)-based approaches, which form the foundation of Theoretical Computer Science. Initially, FSMs were used to model the basic operations of computer systems and played a key role in the design and verification of sequential logic circuits. However, as system complexity increased, FSMs alone became inadequate for designing and verifying increasingly complex computer architectures [10].

To overcome these limitations, Hardware Description Languages (HDLs) such as VHDL and Verilog were developed, enabling more detailed and accurate hardware modeling. These languages have become industry standards and serve as essential tools for the design and verification of complex digital systems [11,12,13,14].

1.1. Motivation

As shown in Figure 1, while traditional RTL (Register-Transfer Level) verification methodologies, including formal verification, functional verification, and DFT (Design for Testability), can validate design correctness in simulation environments, they may not capture real-world CDC (Clock Domain Crossing) issues that emerge during hardware implementation. Although the design may pass all RTL-level simulations under ideal conditions, FPGA-based testing reveals practical CDC challenges that only manifest in physical implementations. This testing environment, illustrated in the front-end process flow of Figure 1, provides a crucial platform for validating our proposed clock domain verification methodology before proceeding to back-end processes, allowing early detection and resolution of potential CDC issues that conventional verification methods might miss. However, when using standard design languages like Verilog, additional static analysis and external simulation tools are often required due to inherent limitations in their capabilities.

To address these limitations in conventional verification approaches, researchers are exploring the use of artificial intelligence to predict system behavior and optimize architecture configurations. The advancement of cloud computing and distributed systems has enabled large-scale parallel simulations, allowing for more comprehensive system testing while significantly reducing design-phase costs [15,16]. This technological evolution has led to considerable expansion in both the diversity of technologies and design languages in computer architecture.

However, this progress has introduced new challenges in hardware simulation, particularly from the perspective of mathematical and physical verification. The complexity of modern systems has exposed limitations in traditional formal verification methods, making it increasingly difficult to mathematically prove the correctness of entire systems as they grow larger and more intricate. This complexity not only affects the verification process but also impacts the prototyping phase, requiring substantial time and resources to validate even basic concepts in today’s sophisticated architectures. Moreover, from an educational standpoint, these developments have created additional challenges for students attempting to grasp and apply fundamental principles of modern computer architecture [17,18,19,20].

To address these complex issues and facilitate the application of latest methodologies in hardware design, our research focuses on using the DEVS (Discrete Event System Specification) formalism. The DEVS formalism provides a powerful framework that enables effective system simulation through event-based strict time management, modularity, and hierarchical structure, offering new possibilities in the design and verification of advanced computer architectures [21].

DEVS formalism, as illustrated in Figure 2, provides comprehensive features to address causality dependencies and synchronization requirements in parallelized structures. Its modular and hierarchical approach, shown through both structural and hierarchical views in Figure 2a,b, enables systematic system partitioning through the composition of atomic models into coupled models. While the structural representation (Figure 2a) demonstrates how models interact through well-defined interfaces, the hierarchical view (Figure 2b) showcases the multi-level organization of system components. This architectural foundation, combined with precise time management, ensures strict control over causal relationships and model synchronization. Figure 2c shows the structure of a DEVS atomic model. Atomic model state can be represented by the state set $S$, and δext and δint describe state transitions caused by external input events and internal state transitions triggered by time advance. Key functions λ, δ, ta are fundamental components of a DEVS atomic model:

• λ (Lambda Output): The output function that maps the current state to an output value before an internal transition;
• δext (External Delta): The external transition function that updates state based on input events;
• δint (Internal Delta): The internal transition function that manages autonomous state changes;
• ta (Time Advance): The function that determines the time until the next internal transition.

These functions work together to define the dynamic behavior of the atomic model. λ determines outputs, δext handles responses to external inputs, δint manages autonomous state changes, and ta controls the timing of internal transitions. Figure 2d illustrates how atomic models which are described in Figure 2c can be coupled to create a larger system model that forms a higher-level system. And as shown in Figure 2a, these coupled models can be used as modules of an even larger system model.

Furthermore, DEVS enhances simulation capabilities through standardized interfaces for tool interoperability, support for distributed execution, and multi-resolution modeling, making it particularly effective for complex system simulation [22,23].

Building upon these DEVS formalism capabilities, we propose a simulation methodology that leverages its precise timing control and hierarchical modeling features to analyze complex timing scenarios. This approach provides a systematic framework for investigating timing anomalies that are typically time-consuming to trace through conventional RTL validation processes.

1.2. Advantage of DEVS Framework

The construction of a DEVS-based framework offers the following advantages:

• Modularization and Hierarchical Structuring of Complex Systems: DEVS enables systematic decomposition of large systems into manageable units and organizes them hierarchically, significantly reducing the complexity of design and verification processes;
• Improved Accuracy in Time Management and Synchronization: DEVS’s strict time management mechanisms allow for accurate modeling and simulation of timing mismatches and metastability issues between clock domains;
• Ease of Integration with Heterogeneous Models and Tools: The framework provides standardized interfaces and formats for seamless integration with various simulation tools, supporting comprehensive co-simulation between hardware and software, as well as between analog and digital systems;
• Dynamic Analysis: DEVS-based simulation is performed in a runtime environment. It includes test vectors with iterations or randomness and analysis termination conditions, allowing for code analysis without the need for repetitive constraint modifications and recompilation.

1.3. Clock Domain Crossing Problem with DEVS

We aim to explore the applicability of DEVS formalism as a complementary approach to addressing metastability issues that may arise in CDC within digital circuit design. Modern System on Chip (SoC) designs have become increasingly prevalent, integrating diverse functionalities into a single chip. This integration process combines multiple subsystems and modules, each operating at different clock frequencies. The presence of multiple clock domains on a single chip necessitates comprehensive verification, including CDC structural analysis, protocol verification, and metastability validation [22,23].

According to a white paper by Cliff Cummings, CDC issues can be minimized through designer’s static code analysis, the application of EDA tools (such as SpyGlass, Questa CDC, and 0-In CDC) for simulation functions, and the establishment of team-wide rules. However, increasing chip sizes leads to greater circuit complexity and more clock domains, substantially raising the cost of CDC analysis tools, particularly for commercial solutions. Conventional CDC verification involves two time-consuming processes. The first process involves simulation-based verification using standard mechanisms. These mechanisms, like VITAL (VHDL Initiative Towards ASIC Libraries) with VitalTimingCheck procedures in VHDL [24], specify blocks with setup-hold directives in Verilog. The second process involves iterative static timing analysis using TCL-based scripting for various timing constraints. Repeated compilation requirements for different timing scenarios can significantly impact project timelines.

The event-driven structure of DEVS provides clear representation of discrete event occurrence and propagation, enabling accurate simulation of inter-module interactions across different clock frequencies. DEVS’s strict time-based approach ensures precise synchronization between simulation models, effectively minimizing errors from data mismatches and temporal distortions. These capabilities suggest that DEVS-based co-simulation could serve as one of the methodological approaches for modeling and analyzing CDC issues.

1.4. Research Contribution

Previous research confirmed that simulations using DEVS within the same clock domain were available, as demonstrated through conventional HDL-DEVS modeling structures shown in Figure 3 [25,26]. Each atomic model contains state buffers (0, 1) and input registers that allow it to monitor signal transitions based on clock timing and track propagation delays through the system. However, additional research was needed to model interactions between heterogeneous clock domains. Our research focused on developing a CDC synchronizer model within the DEVS environment, utilizing property-based verification methods. Through systematic testing, we successfully identified metastability violations occurring under specified timing constraints and Clock Domain Crossing conditions. Figure 3 shows signal “zzzzz”, and it indicates the metastable state detected in our test environment. This approach enables designers to identify potential CDC problems early in the design phase and expedite debugging processes, resulting in reduced simulation costs.

In this paper, we extend our DEVS-based simulation environment to perform HDL simulation, incorporating a specialized synchronizer for CDC issue analysis. We propose a framework that enables the analysis of metastability occurrence points under given CDC conditions, focusing on setup time and hold time requirements. By leveraging the simulation capabilities of the DEVS environment, we anticipate improvements in reliability verification efficiency and potential time savings in the CDC analysis process.

The structure of this paper is as follows: Section 2 introduces the background of Clock Domain Crossing and metastability; Section 3 details the implementation of a CDC synchronizer using Verilog and DEVS formalism and describes the DEVS model for flip-flop state transitions; Section 4 comprehensive verification results based on simulation scenarios; Section 5 discusses the integration of DEVS-based metastability analysis into practical design flows and explores its broader applications; finally, Section 6 concludes with simulation results and discusses potential enhancements to the HDL-DEVS framework for timing analysis.

2. Background of Clock Domain Crossing

In digital circuit design, when signals are exchanged between two different clock domains, these domains often operate at different frequencies. The process of integrating multiple designs with such heterogeneous frequency environments into a single module is essential for improving system performance and reducing costs.

However, controlling signals between different clock domains introduces timing mismatch issues in digital circuits. Each clock domain must maintain the setup time and hold time corresponding to its own domain specifications to switch states properly. If a synchronizer is not used when exchanging signals between different clock domains, metastability issues may arise. This issue occurs when signals are not properly synchronized between different clock domains [27,28].

The primary potential issues include the following:

• Metastable State: This refers to a logically undefined state where the receiving clock fails to capture the correct value during signal transition;
• Timing Errors: Due to different timing rules in different clock domains, if a signal does not arrive within a specific clock cycle, the receiving domain may fail to correctly recognize the value. This can result in data loss or transmission of incorrect data;
• Unstable Operation: Without a synchronizer, the signal may randomly fluctuate between logic levels (0 and 1), causing unpredictable circuit behavior or introducing severe functional errors;
• Difficulty in Design Verification: Metastable states or irregular timing issues occur sporadically, even during testing, making it difficult to trace or reproduce the problem. This complicates design verification and reduces the reliability of the circuit.

2.1. Example Scenario

As shown in Figure 4a, two blocks operate in different clock domains: clock domain A (100 MHz) and clock domain B (75 MHz). Between these domains, a signal called data_signal transfers data from the circuit in clock domain A to clock domain B.

When transmitting the data_signal directly between these asynchronous clock domains, signal transitions originating from clock domain A may not be accurately captured in clock domain B. This issue becomes critical when data_signal transitions occur between the rising edges of clocks A and B. In such cases, the flip-flop in domain B, shown as Figure 4b, may fail to capture the signal correctly, causing it to enter a metastable state—an intermediate state that is neither 0 nor 1.

In clock domain B, this metastable state can propagate, causing flip-flops in domain B to sample incorrect values. As a result, the circuit in domain B may make incorrect decisions, or the metastable state may persist for several clock cycles, disrupting normal operation. For example, if data_signal is intended to trigger a specific operation, the circuit in domain B may fail to detect the signal and not operate, or it may operate at the wrong time. Consequently, processes running in clock domain B could behave abnormally, or data processing errors could occur. When logic is implemented on FPGA or hardware, the physical properties of the materials can cause a violation of setup time or hold time requirements, and an unstable state due to the material properties can lead to a metastable state where accurate values cannot be identified until the unstable state stabilizes. During the HDL simulation phase, only logical verification is performed, so metastable states caused by material properties cannot be detected. However, when synthesized to actual hardware, this phenomenon occurs. So, designers may find it challenging to detect such issues, and the system could enter an indeterminate state.

2.2. Synchronizer

A two-stage flip-flop synchronizer synchronizes the data_signal transitioning from clock domain A to clock domain B. This approach ensures that even if a metastable state occurs in the first flip-flop, the second flip-flop can process the signal as a stable value. This method prevents the metastable state from propagating and resolves the timing issues that can arise in CDC.

However, at high clock frequencies, the clock period may be too short to allow sufficient time for metastability resolution. Therefore, it is necessary to predict the likelihood of errors caused by metastability using MTBF (Mean Time Between Failures) calculations based on design parameters and adjust the depth and design of the synchronizer accordingly to meet system reliability requirements. In some cases, designing specialized synchronizer circuits may be required.

Despite these precautions, unexpected CDC violations may still occur due to design defects or specific characteristics of modules. It is practically impossible for a designer to manually review all potential scenarios, and in complex systems, hidden bugs or timing issues may exist. Depending on factors such as the frequency of a given clock domain and physical parameters like setup time and hold time, issues may arise that necessitate the addition of flip-flop stages to the synchronizer.

All these problems typically require engineers to reverse-engineer the issue by statically inspecting waveforms and code when the final output signal is incorrect. Since CDC issues are inherently timing-related, tracing the root cause of the problem can be extremely challenging.

2.3. Timing Issue

If a signal transitioning from domain A does not meet the setup time and hold time conditions in domain B, metastability may occur. Based on these conditions, each of the constraint conditions can be modeled.

2.3.1. Setup Time Violation

If the sampling point of clock B occurs just before the signal transition in domain A, the signal may not stabilize, causing the flip-flop to capture the data incorrectly.

This condition can be modeled using the following Equation (1):

$$T_{arrival}+T_{setup}>T_{period}$$

(1)

where $T_{arrival}$ represents the time at which the signal transitions from domain A and arrives in domain B, $T_{setup}$ is the setup time of the flip-flop in domain B. And $T_{period}$ is the clock period of domain B. If these conditions are not met, clock domain B will fail to sample the signal correctly, resulting in metastability.

2.3.2. Hold Time Violation

When crossing clock domains from A to B, if the signal is not maintained long enough in domain B after transitioning from domain A, a hold time violation may occur.

This condition can be modeled using the following Equation (2):

$$T_{hold}>T_{co}+T_p$$

(2)

$T_{hold}$ is the hold time of the flip-flop in domain B and $T_{co}$ is the clock-to-output delay of the source flip-flop. $T_p$ is the propagation delay through the combinational logic. If these conditions are not satisfied, the receiving flip-flop in domain B may capture incorrect data, potentially leading to metastability. Additionally, all variables are subject to jitter, and metastability occurs in corner cases where the jitter conditions are violated.

2.4. Metastability Probability Model

The probability of remaining in a metastable state decreases exponentially over time due to the inherent instability of the state. As time progresses, small voltage differences in the circuit are naturally amplified, driving the system toward one of its stable states. Based on this behavior, the probability of escaping from the metastable state can be modeled by an exponential decay function.

This probability model can be expressed as following Equation (3):

$$P\left(t\right)=P_0\ast e^{(-{\displaystyle \frac{t}{\tau }})}$$

(3)

where $P\left(t\right)$ represents the probability of remaining in a metastable state after time t and $P_0$is the initial probability of entering the metastable state. $\tau$ represents the time constant characterizing the recovery from the metastable state, and $t$ is the time elapsed since entering the metastable state. This equation demonstrates that the probability of remaining in the metastable state decreases exponentially over time [28]. Therefore, to address metastability issues, designers can implement two primary strategies: ensuring sufficient time for the signal to recover from the metastable state or increasing the depth of the synchronizer stage.

While this exponential model provides an abstract representation of metastability probability, it has limitations in practical modeling and debugging. The model demonstrates that the probability of remaining in a metastable state decreases exponentially over time, but it cannot identify specific timing issues or the exact conditions that trigger metastability. It simply illustrates a general trend where the probability decreases as the value of t increases.

Therefore, in practical applications, some designers use multi-stage synchronizers to reduce metastability-induced errors. In multi-stage synchronizers, metastability propagation is expressed as a product of probabilities at each stage, which is influenced by various implementation factors such as flip-flop design, clock characteristics, and environmental conditions. While increasing the number of synchronizer stages generally improves MTBF (Mean Time Between Failures), this represents an empirical and loose approach.

The optimal number of stages must be determined through careful analysis of these parameters in conjunction with system-specific requirements for latency and power consumption, as increasing stages also incur additional overhead in terms of both latency and power [29,30].

3. Design of CDC Synchronizer

3.1. Design of CDC Synchronizer Using Verilog

When adding a synchronizer through Verilog, it can be modeled in the following form:

The synchronizer module addresses metastability issues in CDC between different clock domains (clk_A and clk_B) through a three-stage synchronization architecture. The design accepts an asynchronous input signal (async_in) and produces a synchronized output (sync_out) in the target clock domain.

The synchronization mechanism employs three registers in a cascaded configuration, as implemented in Figure 5a: stable_async_in samples the asynchronous input at clk_A domain, providing initial signal stabilization, while meta_ff1 and meta_ff2 form a dual flip-flop chain operating in the clk_B domain. At each rising edge of clk_B, meta_ff1 captures the stabilized input from stable_async_in, and meta_ff2 provides additional settling time, ensuring reliable metastability resolution before final output.

Functional verification was performed using a testbench simulating realistic multi-clock domain conditions (50 MHz for clk_A, 75 MHz for clk_B), as illustrated in Figure 5b. The test scenarios included multiple asynchronous input transitions with varying timing conditions, demonstrating sufficient synchronization performance across clock domains.

However, since Verilog simulations operate in an idealized environment, they cannot accurately reproduce the physical metastable states that occur in real hardware. As a result, it is not possible to confirm whether the value coming from sync_out is in a metastable state. Therefore, designers must rely on their experience to perform static analysis and use simulation and debugging techniques when modeling with Verilog.

3.2. Design of CDC Synchronizer Through DEVS

In CDC design, it is important not only to account for latency delays but also to track the propagation of metastable states. To achieve this, a separate metastable state must be propagated when setup time or hold time violations occur. While Verilog simulates discrete events in digital circuits, similar simulation capabilities can be achieved through DEVS. Furthermore, by modeling metastability propagation in a DEVS model, the simulation can immediately verify the occurrence of metastability violations during synchronizer operation.

3.2.1. Designing a DEVS Environment Without a Synchronizer

Figure 6 shows a configuration consisting of two clock atomic models generating signals at fixed clock cycles, a Generator producing a data_signal with precise timing, and two flip-flop atomic models handling the transmission and reception of the data_signal.

3.2.2. DEVS Environment Design with Added Synchronizer

In Figure 7, this configuration is enhanced with the addition of a synchronizer coupled model. The synchronizer, designed to address CDC issues, comprises n chained D flip-flops that introduce intentional timing delays to prevent metastable states. Figure 8 presents a coupled model featuring 2-stage flip-flop atomic models connected in series, implementing the traditional synchronizer approach for CDC timing issue. This figure represents a synchronizer configuration with the minimum number of stages used in Figure 5a and Figure 7. Based on simulation results from various scenarios, the number of flip-flop stages can be increased if metastable states are detected.

3.2.3. Flip-Flop Model Specification

The flip-flop model is designed to specify setup time and hold time using DEVS, and it contains three major internal states: setup state, hold state, and clock state. The setup state manages the metastable conditions related to the setup time, while the hold state handles the metastable conditions related to the hold time. The clock state manages the synchronization state and triggers output events when a CLK event occurs.

As shown in Figure 9, the initial setup state is represented as $(D\_in,\infty ).$When a toggled D_in event occurs, an external transition updates D_in to the new value and sets $Ta=T\_setup$. After Ta time elapses, an internal transition returns the state to $(D\_in,\infty )$. A metastable condition arises if a CLK event occurs while Ta is still active. In this case, the setup state transitions to a metastable state. After the remaining Ta time has elapsed, the state transitions back to the normal state of $(D\_in,\infty )$. In a normal situation, if a toggled Din external transition occurs, or in a metastable situation where a D_in event occurs, the state transitions again to one where $Ta=T\_setup$.

As shown in Figure 10, the hold state initially begins in the normal state $(D\_in,\infty )$. When an external transition occurs due to a CLK event, Ta is set to T_hold, and the state transitions to a metastable state. After Ta time has elapsed, an internal transition returns the state to the normal state $(D\_in,\infty )$. If a Din event occurs while the state is already in metastable condition due to a CLK event, changing the internal state value, the hold state transitions to a metastable state with $Ta=\infty$. In this metastable state, if another external Din event occurs, the metastable state persists while the internal state value is updated. If an external CLK event occurs, Ta is reset to T_hold, and the state transitions back to a metastable state awaiting the completion of the hold time. If Ta is set and the system is waiting for hold time to complete but another CLK event occurs, this is considered a violation of the hold time invariant condition, and the state transitions to a fallback state.

As shown in Figure 11, the clock state initially begins at $(D\_in,\mathrm{\infty })$. When a clock event occurs, Ta is set to 0, and the current value is assigned to the Output. After Ta time elapses, an internal transition returns the state to $(D\_in,\mathrm{\infty })$.

Based on the DEVS atomic model structures shown in Figure 2c and Figure 3, the flip-flop model can be explained in terms of its functions from the perspective of a single atomic model as follows:

• External Transition: In the flip-flop model, two types of external transitions, D_in and CLK are possible. The D_in transition occurs due to changes in the signal connected to the flip-flop model, which can take one of three states: T, F, or X. This signal updates the internal state value of the flip-flop to D_in. Additionally, it triggers a state transition in the setup state. The details of this transition follow the state siagram. The CLK transition occurs due to changes in the clock signal connected to the flip-flop model. This signal triggers transitions in all states: setup, hold, and clock. The specific details of these transitions are described in the state diagram.
• Internal Transition: An internal transition occurs when a Ta event elapses in setup, hold, or clock state. Before this transition takes place, an output event is generated. In this model, output events are triggered either by clock events or events in the hold state. When an external CLK transition occurs, both the clock state and hold state set $Ta=0$. At this point, if the hold state transitions to a metastable state, an output event indicating the metastable condition is generated. Subsequently, when the hold time has elapsed and the hold state transitions back to its normal state, an output event indicating the normal condition is generated.
• Time Advance: The time advance is determined by selecting the smallest Ta among the setup state, hold state, and clock state, and assigning it as the next Ta.

  $$Ta=Min(T{a}_{setup},T{a}_{hold},T{a}_{clock})$$

  (4)
• Time Shift: When a time shift request occurs, the time shift is applied to all states: setup state, hold state, and clock state.

  $$\begin{gathered} T{a}_{setup}=Max\left(T{a}_{setup}-Ta,0\right) \\ T{a}_{hold}=Max\left(T{a}_{hold}-Ta,0\right) \\ T{a}_{clock}=Max(T{a}_{clock}-Ta,0) \end{gathered}$$

  (5)

If you wish to understand the overall model flow in relation to the detailed model transition specifications described in the Section 3.2.3, please refer to the Appendix A.

4. Simulation Design and Verification

The model configuration follows the DEVS environment design with synchronizer implementation described in Section 3.2.2. The DEVS-based simulation methodology is illustrated in Figure 12. Throughout the simulation timeline, the simulator tracks the next event time (time advance, Ta) for each model, managing internal state transitions and event propagation. Models with $Ta=0$ undergo immediate internal transitions, while $Ta=\mathrm{\infty }$ indicates no further transitions are scheduled for that model. The simulation continues until all models reach $Ta=\mathrm{\infty }$, signifying completion of all designed model transitions. In this experimental setup, CLK_A and CLK_B are configured at 100 MHz and 75 MHz, respectively. The SetupTime and HoldTime parameters are process-dependent values provided by the manufacturing specifications. The simulation generates random async_in events (data events) to measure the occurrence of metastable states between clock domains under the given SetupTime and HoldTime constraints.

Test scenario:

#35 async_in = True #5 async_in = false

4.1. Verification Scenario for SetupTime Violation

In this scenario, the experimental setup comprises a synchronizer implemented with two chained flip-flops, operating between two clock domains: CLK_A at 100 MHz and CLK_B at 75 MHz. The flip-flops are configured with timing constraints of 4 ns setup time and 0 ns hold time.

When analyzing metastable states in this test scenario, a setup time violation was detected on async_out at 79.98 ns. This violation occurred due to data transitions at 35 ns and 40 ns, which induced a metastable state in the flip-flop. The metastable state propagated to the flip-flop operating at 75 MHz in clock domain B, manifesting in the clock_B domain at 79.98 ns.

Analysis confirmed a violation of the SetupTime condition (Tarrival + TsetupB < TperiodB). Subsequent testing verified that the test case passes successfully when SetupTime is configured below 3.33 ns.

4.2. Verification Scenario for HoldTime Violation

In this scenario, the experimental setup comprises a synchronizer implemented with two chained flip-flops, operating between two clock domains: CLK_A at 100 MHz and CLK_B at 75 MHz. The flip-flops are configured with timing constraints of 0 ns setup time and 14 ns hold time.

When analyzing the metastable state in this test scenario, metastable states were detected starting from 39.99 ns, recurring at regular intervals of 13.33 ns. These occurrences result from hold time violations, manifesting as metastable states in the output at each interval. The 13.33 ns periodic transition of metastable states corresponds to the 75 MHz operating frequency of clock domain B.

Analysis confirmed a violation of the hold time condition (Thold < TperiodB). Subsequent testing verified that the test case passes successfully when HoldTime is configured below 13.33 ns.

5. Discussion

This section discusses how a DEVS-based metastability analysis tool can be integrated into the practical design flow.

While synthesis tools like Vivado and Quartus provide comprehensive reports on setup/hold time violations and can identify potential CDC violation points in the design, they are primarily focused on static timing analysis and structural CDC checks. These tools may require considerable time investment in simulating and verifying the actual behavior of CDC circuits under specific conditions where metastability might occur. This fundamental limitation stems from the fact that metastability is an analog physical phenomenon occurring in real hardware, making it impossible to accurately model and capture the indeterminate state of a digital signal through conventional logic simulation or static timing analysis alone.

In CDC designs, metastability susceptibility is primarily determined by setup and hold timing margins, which are influenced by various factors including jitter and noise—characteristics that vary significantly based on semiconductor process variations and manufacturing quality. These effects become particularly critical during back-end implementation compared to front-end design. During the pre-silicon verification phase, accurate metastability prediction remains challenging, with actual failure modes often manifesting only after chip fabrication, necessitating iterative cycles of violation detection, analysis, and redesign.

The most straightforward approach to addressing CDC issues in practical designs involves inserting multiple synchronizer flip-flops along the target CDC paths (over-synchronization), rather than optimizing synchronizer placement based on rigorous MTBF calculations. While this approach ensures robust signal stability, it introduces significant trade-offs in terms of Power-Performance-Area (PPA) metrics.

The flip-flop atomic model as detailed in Figure 8 provides a systematic framework for engineers to simulate and analyze potential metastability occurrences in practical designs using DEVS methodology. While our experimental framework leverages a RUST-based DEVS Simulation Engine, offering enhanced simulation performance compared to previous RTL-DEVS implementations, it is important to note that DEVS itself is a robust specification methodology for discrete event systems, independent of specific implementation tools. Engineers can implement their DEVS simulation environment using their preferred programming language or utilize various established open-source DEVS simulation frameworks available online.

Design engineers inherently possess knowledge of CDC crossing points within their designs, enabling them to conduct targeted verification of suspicious modules using metastability probability models, even when front-end verification reveals no apparent issues. In teams with dedicated verification engineers, they can receive comprehensive CDC crossing documentation from designers, implement corresponding DEVS models, and develop specific test scenarios focusing on setup/hold time violation conditions. This systematic approach facilitates the development of a methodical verification framework to effectively validate metastability immunity across identified CDC paths. Figure 13 illustrates an example scenario demonstrating how DEVS-based external simulation can be integrated into the failure analysis process when hardware validation issues emerge during the post-placement phase.

While this methodology requires additional design and verification resources, it proves more efficient than conventional approaches such as static analysis of Verilog code or comprehensive commercial tool-based simulations. The targeted nature of this verification strategy significantly reduces overall simulation time. Figure 14 shows the general timing analysis flow and the DEVS-based time analysis flow. By applying the FF model proposed in Section 3.2.3, we can obtain benefits like performing dynamic analysis for the designed objectives during runtime.

Beyond focusing solely on metastability analysis, the proposed DEVS-based methodology aims to assist in verifying various design-phase issues, such as timing mismatches, through external simulation capabilities. This systematic approach could help identify potential design vulnerabilities in the early stages, potentially supporting their resolution during the implementation phase and contributing to design robustness.

6. Conclusions

While traditional Verilog simulations and EDA tools provide robust mechanisms for CDC analysis through static timing verification and structural checks, analyzing multiple timing scenarios across different clock domains can require significant computational and time resources.

This paper proposes a DEVS-based CDC simulation methodology that enables detection and analysis of metastability violations under specified setup time, hold time, and clock domain conditions. By leveraging DEVS formalism alongside existing HDL methods, this approach could support efficient exploration of multiple CDC timing scenarios.

Furthermore, the DEVS formalism’s language and environment-agnostic nature enables hardware designers and software engineers to develop custom automated analysis pipelines. This flexibility supports integration across various design languages, including Verilog and VHDL, and simulation platforms, enhancing simulation versatility through co-simulation environments.

Unlike conventional static analysis, this research employs dynamic simulation incorporating jitter as a simulation parameter to evaluate system behavior under random conditions, enabling comprehensive validation in temporally uncertain environments.

The proposed model demonstrates effective observation and debugging of metastable state transitions, validating DEVS’s capability in modeling and applying these states. Integrating DEVS-based tools into design and verification processes, as demonstrated in Clock Domain Crossing applications, can help reduce risks associated with iterative redesigns. However, the current approach has several limitations. Developing project-specific tools and converting HDL code to DEVS formalism introduces significant overhead costs and implementation complexity. Furthermore, compared to commercial tools that provide comprehensive automated static analysis and test vector generation capabilities, the cost-effectiveness of this approach requires careful consideration. Future research directions include enhancing the model through development of observation and verification methods for loss value due to clock domain speed differences and validation of Reset Domain Crossing (RDC) environments, pipeline synchronization challenges, and developing more comprehensive timing analysis capabilities to strengthen the practical applicability of this approach.