A BFS-Based DEVS Simulation Kernel for HDL-Compatible Simulation

Abstract

The Discrete Event System Specification (DEVS) formalism provides a mathematical foundation for modeling hierarchical discrete-event systems. However, the Depth-First Search (DFS) scheduling used in the classical DEVS abstract simulator conflicts with the concurrency semantics of Hardware Description Language (HDL) simulators such as Verilog or VHDL. This mismatch induces timing distortions, including pipeline skew and zero-time feedback loops. To address these limitations, this study proposes a new DEVS simulation kernel that adopts Breadth-First Search (BFS) scheduling, integrating the delta-round concept. This approach employs an event-parking mechanism that separates event computation from application, structurally aligning with HDL’s Active–NBA–Reactive phases and enabling semantically simultaneous updates without introducing additional ε-time. Case studies demonstrate that the proposed BFS-based DEVS kernel eliminates timing discrepancies in pipeline and feedback-loop structures and establishes a formal foundation for semantic alignment between DEVS and HDL simulators.

1. Introduction

In recent decades, the Discrete Event System Specification (DEVS) formalism has served as a foundational framework for modeling discrete-event systems due to its modularity, hierarchical composition, and formally defined semantics [1,2,3]. Notably, its Closure under coupling property allows multiple interconnected submodels to behave equivalently to a single atomic model, enabling scalable hierarchical construction of complex systems [4,5,6,7,8,9,10]. From a hardware standpoint, atomic DEVS models resemble fundamental logic elements, and their hierarchical composition reflects the structural organization of digital circuits.

Building on this hierarchical capability, DEVS models can be recursively composed into higher-level structures while preserving consistent external behavior [11,12,13,14,15]. This hierarchical capability has enabled DEVS to model a wide range of real-world discrete-event systems [16,17,18,19]. Recent studies have also explored applying DEVS to hardware verification, particularly in timing-critical multi-clock environments, where explicit time representation is advantageous. Although RTL structures can be mapped onto DEVS models [20,21], structural correspondence alone is insufficient to guarantee behavioral equivalence.

1.1. Motivation

Despite the structural similarity between DEVS hierarchies and digital circuits, classical DEVS fails to reproduce the concurrency semantics required in hardware simulation. This limitation arises from the depth-first, sequential event-processing mechanism of the DEVS abstract simulator, which contrasts with the concurrency model enforced in HDL environments [20,22]. While HDL simulators utilize delta-cycles for deterministic concurrent evaluation [23,24], the sequential nature of the classical DEVS kernel creates a semantic gap that motivates the present study.

Verilog and SystemVerilog use a hierarchical event scheduling model called the stratified event queue, which provides simulation semantics equivalent to the delta-cycle mechanism in VHDL [25,26]. As illustrated in Figure 1, this scheduling model organizes events into multiple ordered regions within a single simulation time slot.

An HDL simulator divides each simulation time slot into several phases that are processed in order, typically the Active phase, the non-blocking assignment (NBA) phase, and the Reactive phase. In the Active phase, combinational logic and blocking assignments are executed, and the right-hand sides of non-blocking assignments are evaluated for later use. In the NBA phase, these deferred updates are applied simultaneously, and the Reactive phase then processes operations triggered by the updated signals.

By performing these fine-grained steps within a single simulation time unit, HDL simulators clearly separate the computation and application of zero-delay events. This structure ensures atomic and deterministic signal updates, preventing race conditions and accurately reflecting concurrent hardware behavior [27].

In contrast, the classical DEVS simulation kernel processes events sequentially, which conflicts with the delta-cycle semantics of HDL simulators. As illustrated in Figure 2, the kernel selects only one imminent model at a time based on a user-defined priority, and the selected model immediately propagates its output to connected components. This sequential propagation can cause timing distortions such as pipeline skew and zero-time feedback loops. When multiple events occur simultaneously, the SELECT function determines the execution order according to its priority rule, introducing additional ordering effects that do not exist in hardware [28].

The classical DEVS kernel follows a Depth-First Search (DFS)-like event propagation, where the output of a model is immediately delivered to connected models as soon as its event is processed. This sequential chain of reactions prevents simultaneous updates that should occur in hardware, breaking the concurrency semantics guaranteed by HDL simulators. As a result, signals that should be updated on the same clock edge may instead propagate one step earlier or later, causing pipeline distortions and timing mismatches. Furthermore, when models repeatedly execute zero-time transitions, DEVS may enter an infinite loop in which internal events circulate without advancing simulation time. Such behavior makes it difficult for the DFS-based kernel to satisfy HDL-like delta-cycle semantics, which require deterministic and simultaneous updates within a single simulation time unit.

1.2. Related Works

Various extensions of DEVS have been proposed to mitigate these limitations. As illustrated in Figure 3, Parallel DEVS (P-DEVS) introduces the confluent transition function, which enables simultaneous handling of internal and external events and reduces the dependence on user-defined priority ordering [29,30]. Although this improves determinism compared to the classical DEVS kernel, it still does not fully resolve the mismatch with HDL-style concurrency.

Although P-DEVS introduces confluent transitions, the model designer must still explicitly define these functions, and their computational cost increases rapidly with the size of the input set. To address these issues, Revised Parallel DEVS (RP-DEVS) was proposed to provide immediate reactions to input events and reduce sequential delays [31]. However, RP-DEVS continues to rely on a λ-iteration process in which outputs are produced only after repeated evaluations until all internal signals converge, leaving concurrency limitations unresolved [32].

Another extension, RTL-DEVS, demonstrated that sequential RTL behavior can be approximated by assigning three states, namely Wait, RHS Operation, and LHS Operation, to a single DEVS atomic model [21]. The modified model specification used in RTL-DEVS is illustrated in Figure 4, showing how internal registers, event queues, and zero-time transitions are organized to emulate HDL behavior.

However, because the entire system operates in lockstep with the testbench clock, RTL-DEVS cannot guarantee complete signal synchronization in combinational circuits containing multiple submodules unless additional helper modules are introduced. Consequently, existing DEVS derivatives such as P-DEVS, RP-DEVS, and RTL-DEVS remain fundamentally constrained by the sequential nature of DFS scheduling and cannot fully reproduce the concurrency semantics required in HDL simulations.

1.3. Research Contributions

In this paper, we propose a BFS-based DEVS kernel combined with a delta-round scheduling algorithm to fundamentally overcome these limitations. The core idea of the proposed method is to replace the Depth-First event propagation in the traditional DEVS simulator with a breadth-first scheduling strategy and to introduce an event parking mechanism that emulates the evaluation–update separation principle of non-blocking assignments in HDL simulators. In each simulation time slot, all events that occur are collected and processed simultaneously within a single round. The resulting output events are then parked in a separate queue and applied collectively in the following delta-round, effectively replicating the behavior of the Active–NBA–Reactive phases in HDL simulation semantics.

Through this BFS + delta-round structure, the proposed method reproduces HDL-equivalent semantics at the DEVS simulation kernel under the assumptions of acyclic zero-delay combinational loops and pipeline configurations, without introducing additional micro-time delays. It also maintains structural equivalence between DEVS models and their Verilog counterparts, enabling cross-verification and co-simulation between DEVS-based and HDL-based systems.

The remainder of this paper is organized as follows: Section 2 presents the theoretical background and examines the limitations of classical DEVS semantics in reproducing HDL-style concurrency. Section 3 introduces the proposed BFS-based DEVS kernel and delta-round scheduling mechanism and describes how event parking is employed to model simultaneous signal updates. Section 4 provides comprehensive verification results using representative pipeline and combinational logic scenarios. Section 5 discusses the integration of the proposed kernel into existing DEVS modeling environments and highlights its broader applicability to hardware verification workflows. Finally, Section 6 concludes the paper and outlines potential directions for further enhancing DEVS–HDL semantic alignment.

2. Background

The structural mismatch between HDL concurrency semantics and the sequential scheduling of DEVS does not stem from shortcomings of DEVS-based model designers. It arises from the architecture of the classical DEVS abstract simulator itself. The aim of this section is to review the core operating principles of the classical DEVS formalism and its abstract simulator, with a focus on how the DFS-based scheduling framework determines event-processing order through the SELECT method. We then summarize the event-scheduling scheme of HDL to examine its concurrency execution mechanism comprising the Active, NBA, and Reactive phases. Finally, we provide a brief comparison between HDL simulation and event processing in P-DEVS.

2.1. Classical DEVS Formalism and Abstract Simulator

The DEVS formalism provides a mathematically rigorous framework for describing discrete-event systems in a modular and hierarchical manner. Each system component is modeled as an atomic model, which specifies its input behavior, internal state dynamics, and output generation within a well-defined temporal structure [2].

2.1.1. Classical DEVS Atomic Model

In the classical DEVS framework, an atomic model is represented as:

$$\mathrm{DEVS} \mathrm{Model} \mathrm{AM}: <X,S,Y,{\delta }_{int},{\delta }_{ext},\lambda ,ta>$$

where

• X: set of possible inputs
• Y: set of possible outputs
• S: set of sequential states
• Ta: S → $R_0^{+} \cup \{\infty \}$—time advance function
• Q ∈ {(s,e) | s ∈ S, 0 ≤ e ≤ ta(s)}: the total state set, e is the time elapsed since last transition
• δ ext: Q × X → S: external transition function,
• δ int: S → S: internal transition function.
• λ: S → Y: output function.

From this definition, the core structure of a DEVS model consists of the sets of inputs, states, outputs, the time-advance function, and the transition functions. DEVS composes these atomic models to form higher-level coupled models. A coupled model defines the overall system structure by wiring the outputs of multiple submodels to the inputs of others, and it may contain both atomic and coupled submodels.

2.1.2. Classical DEVS Coupled Model

A coupled DEVS model is formally defined as below:

$$\mathrm{DEVS} \mathrm{Coupled} \mathrm{Model} \mathrm{N}: <X,Y,D,\left\{M_d\right\},\left\{I_d\right\},\left\{Z_{i,d}\right\},Select >$$

where:

• X: set of possible inputs
• Y: set of possible outputs
• D: set of references to the DEVS submodules in $\left\{M_d\right\}$, each $d\in D$ refers to an atomic (or coupled) model (e.g., $D=\{M_1,M_2,M_3\}$).
• $\forall d\in D\cup \left\{N\right\}:I_d\subseteq D\cup \left\{N\right\},d \notin I_d$: influencing model set for each model and the coupled model
• $\forall d\in D, i\in I_d :Z_{i,d}:$ an i-to-d output translation with $Z_{i,d}$: $X\to X_d$ if i = N and $Z_{i,d}$: $Y_i\to Y$ if d = N and $Z_{i,d}$ and $Z_{i,d}$: $Y_i\to X_d$ otherwise
• Select: $2^D\to D$—tie-breaking function

In this formulation, $I_d$ denotes the set of models that can provide inputs to model $d$, and the condition $d\notin I_d$ prevents self-referential coupling. The mapping $Z_{i,d}$ defines the coupling relation that converts the output of one model into a valid input of another. Depending on the endpoints, couplings are categorized as external–internal, internal–external, or internal–internal.

A key property of the coupled DEVS defined above is closure under coupling: even when a model contains multiple submodels, its overall input–output behavior can still be represented in the same DEVS form. Although a coupled model may consist of multiple atomic or coupled submodels, the externally observable behavior reduces to one coherent set of input, state, and output variables together with time-advance and transition functions. From this perspective, a coupled model can be regarded as a higher-level atomic model that encapsulates its own state space and event scheduler. Because a coupled DEVS model determines the system-level input–output behavior through the interconnections among its components, the entire structure can be replaced by an equivalent atomic DEVS model.

In DEVS formalism, the states and event timings of lower-level submodels are composed at the higher level to define the global system state and time-advance function, so the externally observable input and output remain representable in the same form as a single atomic DEVS. Consequently, a coupled model becomes behaviorally equivalent to a flattened atomic DEVS within the simulator, which is the essence of closure under coupling [7,8].

This concept is established with mathematical rigor by formalism. As stated by Zeigler, any coupled DEVS model admits a mathematically constructed resultant atomic DEVS that exhibits the same externally observable behavior.

Because of these mathematical guarantees, DEVS supports hierarchical design while preserving formally predictable and consistent system behavior. Even for systems with deeply nested hierarchies, the entire model can be flattened into a single atomic model. This property is directly tied to how a DEVS simulator recursively schedules events across the hierarchy. The abstract simulator integrates events from all submodels so that the coupled DEVS behaves as a single atomic model.

Formally, as defined in Zeigler et al. [2], the global state $S$ of a coupled model is defined as the Cartesian product of the total states of all submodels:

$$S= {\times }_{i\in D}{Q}_i$$

(1)

The next event time $ta\left(s\right)$ of a coupled model is determined by the minimum of the next event times ${\sigma }_i$ reported by its internal components. The system therefore synchronizes to the earliest impending event, as expressed by the following equation:

$$ta\left(s\right)= min\left\{{\sigma }_i\right|i\in D\}$$

(2)

Once the most imminent submodel is selected, that component performs its internal state transition and produces an output, and the output triggers external state transitions in the connected components. The entire cascade constitutes a single internal state transition of the coupled model.

In this way, a coupled model defines its state, time advance, and state transitions by aggregating information from its internal models, and the simulator guarantees consistent execution. This theoretical closure and simulation architecture have provided the foundation for subsequent DEVS extensions, including Parallel DEVS and Cell-DEVS [33].

2.2. Event Scheduling Method in HDL

Hardware description languages such as Verilog and SystemVerilog define event scheduling semantics to systematically handle concurrent events that occur at the same simulation instant. An HDL simulator divides simulation time into discrete time slots and processes a sequence of event queues within each slot in a defined order.

According to the IEEE 1800-2017 standard [26], execution proceeds through three principal regions:

• Active phase: All blocking assignments (=) and combinational evaluations execute immediately. For non-blocking assignments (<=), only the right-hand side (RHS) is evaluated, and the left-hand side (LHS) update is deferred.
• NBA phase: The non-blocking assignments scheduled in the Active phase are applied in a single batch, causing all related signals to update simultaneously. This mechanism realizes the concurrent-update semantics of hardware.
• Reactive phase: Processes that observe or verify the newly updated signals are executed in this phase, including monitors, assertions, and output display tasks such as the Verilog/SystemVerilog system task $display.

All three phases are executed within a single simulation time slot, and additional delta cycles may repeat when necessary. A delta cycle is an internal iteration in which the simulator propagates logical effects while physical time remains fixed, and all iterations share the same timestamp. The Active–NBA–Reactive loop repeats until it stabilizes. This procedure performs evaluation followed by commit within the same physical time and enables the HDL simulator to model zero-delay signal propagation while producing deterministic results.

Figure 5 illustrates two flip-flops exchanging values on the same clock edge. In the Active phase, the current values of $b$ and $a$ are evaluated and placed in the NBA queue. In the NBA phase, the queued updates are applied to the left-hand sides simultaneously, so both signals update at the same time. Without this separation of evaluation and commitment, the first statement executed could overwrite the input of the other, resulting in a non-deterministic outcome.

An attempt to implement a similar evaluation-commit separation within DEVS was presented in the RTL-DEVS framework. To emulate the Active and NBA phases of Verilog, RTL-DEVS introduced two event queues inside the simulator, an Active queue and a non-blocking queue. Under a synchronized clock condition, the Active queue performs the computations, and the non-blocking queue applies the results collectively afterward. This approach demonstrated the feasibility of reproducing the deterministic concurrency semantics of HDL within a DEVS environment [21].

2.3. Parallel-DEVS (P-DEVS)

In classical DEVS, the Select function assigns a priority when multiple internal events occur at the same simulation time and determines which submodel is executed first. As noted earlier, when several submodels within a coupled DEVS become imminent at the same simulation instant, the simulator resolves priority using the following selection procedure [2]:

$$2^D\to D$$

(3)

The select function chooses one model from the set of imminent submodels:

$$I=\{\hspace{0.17em}i\in D\mid t_i=t^{*}\hspace{0.17em}\}$$

(4)

Even when multiple models belong to $I$, the select function chooses exactly one according to a fixed priority rule, typically specified by the model designer, and that model executes its internal transition first. This mechanism preserves determinism at the level of the coupled model, yet the tie-breaking converts inherently parallel behavior into a sequential order and forces logical concurrency to follow an artificial sequence. As a result, classical DEVS retains closure under coupling in theory, but events that should be processed in parallel still propagate in a depth-first manner, introducing a structural limitation.

This sequential handling yields deterministic simulation results but fails to fully reflect the semantics of truly concurrent systems. P-DEVS was introduced to address this limitation. Although P-DEVS remains structurally similar to classical DEVS, it enables parallel scheduling and simultaneous event handling by defining the internal, external, and confluent transitions as follows:

$$M= <X,Y,S,{\delta }_{int},{\delta }_{ext},{\delta }_{conf},\lambda ,ta>$$

(5)

In this formulation, ${\delta }_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{f}}$ is invoked when an internal event and an external input occur at the same simulation time [29]. The presence of ${\delta }_{\mathrm{c}\mathrm{o}\mathrm{n}\mathrm{f}}$ is the principal distinction from classical DEVS. It enables the model designer to explicitly encode priority for the scenarios under consideration.

In the parallel scheduling of P-DEVS, at simulation time t∗, the next internal event time reported by each component i is given by the following equation [29]:

$$t_i=t+ta\left(s_i\right)$$

(6)

These components, the subset that attains the minimum is defined as follows:

$$I=\{i\mid t_i=\underset{j\in D}{\min }{t}_j\}$$

(7)

In P-DEVS, unlike classical DEVS where Select chooses only a single imminent model, the entire set I is processed simultaneously. Every $i\in I$ evaluates its output function $\lambda \left(s_i\right)$ at the same simulation instant, and the resulting outputs are routed to their recipients according to the coupling relations. Because multiple senders may deliver inputs concurrently, each input port stores arrivals in a bag structure, and the external transition consumes this bag as its argument to merge and process the inputs. Accordingly, the external transition function is redefined as follows:

$${\delta }_{ext}: S\times R_{\ge 0}\times B\left(X\right)\to S$$

(8)

In this equation, $S$ denotes the state space of the model, and $B\left(X\right)$ represents a bag data structure that holds input events arriving at the same instant without ordering. This design allows the simulator to merge and process many inputs in a single step, even when multiple senders deliver messages at the same time. A core element of P-DEVS is the use of the confluent transition function when external inputs arrive exactly at an internal transition time. In that situation, the function provides a mechanism to evaluate multiple simultaneous events in parallel and to resolve conflicts in a consistent and deterministic manner.

2.4. HDL and P-DEVS

In P-DEVS, even when multiple models become imminent at the same simulation instant, all of them execute their output functions simultaneously. Each model then receives its input in a bag structure and processes the corresponding external transitions concurrently. This behavior is conceptually analogous to the Active phase in HDL simulation, where multiple logical events within a single time slot are evaluated concurrently.

However, HDL and P-DEVS differ in their semantics for propagating and committing outputs. HDL employs a delta-cycle structure divided into the Active, NBA, and Reactive phases, which strictly separates evaluation from update. Even though all computations are performed during the Active phase, actual signal updates occur collectively in the NBA phase, preventing mutual interference among signals within the same slot. This structure ensures hardware-level concurrency at the simulator level and maintains determinism at the slot level.

In contrast, in P-DEVS the output produced by an internal transition ${\delta }_{\mathrm{i}\mathrm{n}\mathrm{t}}$ can be immediately delivered as an input to another model at the same simulation time. These outputs may then propagate in a cascade within the same time step. As a result, events occurring at the same instant can directly reference each other’s outcomes, and full state synchronization within a single delta-cycle, as achieved in HDL, cannot be guaranteed.

This difference can lead to semantic mismatches in synchronization for feedback loops or pipelined structures. For example, in HDL, all flip-flops are updated simultaneously during the NBA phase of the delta-cycle, maintaining the behavior of a one-cycle delay for a given clock. In contrast, in P-DEVS, the output of one model may be immediately delivered to another model as input within the same simulation time, which can distort the temporal ordering of events inside the simulator. As a result, incorrect signal propagation that would never occur in real hardware may appear, causing pipeline skew or timing mismatches.

Although the confluent transition in P-DEVS is designed to merge simultaneous internal and external events within the same function, it resolves event-ordering conflicts only locally, not globally. It does not ensure slot-level concurrency across the entire system. While P-DEVS can determine which event to process first when multiple events occur at the same time, it cannot reproduce the NBA-phase semantics of HDL, in which all evaluated updates are applied collectively after computation. Consequently, the parallelism in P-DEVS remains limited to local merging, and global slot-level synchronization is not guaranteed. This may cause simultaneous events to unintentionally affect one another’s results or lead to order-dependent nondeterministic behavior. These differences are summarized in

Table 1. Structural Comparison of P-DEVS and HDL Simulation Frameworks.

Aspect	HDL	P-DEVS
Event-processing scheme	Active–NBA–Reactive (delta-cycle)	Internal/External/Confluent transition
Separation of evaluation and commit	Clearly separated (Evaluate→Commit)	Not separated (Evaluate→Propagate)
Feedback handling	Stable	May exhibit cyclic propagation (0-time feedback possible)
Order dependency	None (slot-level deterministic)	Partially present (confluent transition)
Simulation granularity	Time-slot based	Event based

.

3. Problem Statement

There is a fundamental structural difference between HDL and DEVS simulators. In particular, the slot-based execution mechanism of HDLs such as Verilog, which support delta-cycles, is incompatible with the traditional event-driven sequential processing of the DEVS abstract simulator. HDL simulators guarantee phase-based parallel execution, where multiple signal changes occurring at the same simulation time are evaluated concurrently and committed collectively. In contrast, DEVS simulators do not process all scheduled events at a given simulation time simultaneously; instead, they select a single model and propagate events sequentially in a depth-first manner. Consequently, DEVS cannot reproduce the concurrency semantics inherent in HDL simulation. The following two representative cases illustrate how the DFS-based DEVS simulation kernel fails to maintain compatibility with HDL simulation and the resulting issues.

3.1. Pipeline Skew

The first problem is the timing distortion that occurs in pipeline stages, as illustrated in Figure 6a. This issue arises when a pipeline register chain composed of multiple flip-flops fails to reproduce HDL-equivalent behavior under a DEVS simulator. Each flip-flop latches its previous input, and new outputs are committed only after the NBA phase, preventing interference within the same cycle.

In contrast, the classical DEVS kernel processes these concurrent triggers sequentially. If FF1 and FF2 are both scheduled at the same time, the simulator selects one model first, updates its output, and immediately propagates the new value to the next stage. This causes FF2 to read an updated signal within the same cycle, advancing the pipeline by one step and creating pipeline skew.

Such distortion arises not from model defects but from the kernel’s depth-first event handling. Since the selection priority is arbitrary, the simulation may also produce non-deterministic results. This timing skew, which never appears in HDL simulators, undermines the reliability of DEVS-based hardware simulation.

3.2. Infinity Loop

The fundamental limitation of classical DEVS simulation becomes most apparent in self-feedback structures such as the SR latch, which is illustrated in Figure 6b. Consider the typical SR latch composed of two cross-coupled NOR gates, NOR1 and NOR2, each referencing the output of the other as its input. If the propagation delay of these gates is modeled as zero ($ta=0$), an infinite exchange of output events may occur in simulation time.

For instance, starting from an initial state where both NOR1 and NOR2 outputs are LOW, NOR1 receives inputs $S=0$ and $\bar{Q}=0$, changes its output $Q$ to HIGH, and transmits this to NOR2. NOR2 then reacts to inputs $R=0$ and $Q=1$, switches its output $\bar{Q}$, and sends it back to NOR1. When this process repeats without any time advancement, the two gates continuously trigger each other, forming a feedback loop that generates new output events with zero-time intervals. From the DEVS simulator’s perspective, as soon as NOR1 produces an output, it is immediately delivered to NOR2 as an external event, which then produces its own output that is fed back to NOR1. This results in an unbounded chain of events occurring without any progression in simulation time.

In such a situation, the simulation becomes deadlocked, endlessly processing events within the same simulation time without progressing to the next step. In real hardware, the outputs under these conditions may enter a metastable state or eventually resolve to a stable value through analog physical effects. However, in an ideal discrete-event model, no such physical resolution mechanism exists, causing the simulator to loop indefinitely. The inability to handle zero-time infinite loops therefore originates from a structural limitation of the DEVS kernel itself.

The traditional DEVS simulator does not fundamentally resolve the two problems and has typically relied on the ε-time technique as a mitigation approach. This method introduces infinitesimal time offsets between logically simultaneous events, forcing them to be processed sequentially. Although this approach can alleviate infinite loops and race conditions in feedback paths, it distorts the simulation semantics by imposing an artificial temporal order.

Other practical methods, such as those employed in HDEVS, approximate a zero-valued time advance as a single hardware clock cycle. These methods sequentialize events that should occur simultaneously and assign additional clock steps to prevent infinite loops while preserving causal order [28]. However, they ultimately impose real execution order dependencies on transitions that should occur concurrently.

In conclusion, ε-time–based separation may temporarily mitigate pipeline skew and feedback-loop issues, but it cannot reproduce the strict separation between evaluation and commit that HDL simulators guarantee. As a result, slot-level determinism and structural equivalence are not preserved. The following section proposes a BFS-based simulation kernel that eliminates dependence on ε-time by evaluating all outputs occurring at the same simulation instant, parking them, and then performing a collective commitment.

4. BFS-Scheduled DEVS Simulation Kernel

A BFS-Scheduled DEVS Simulation Kernel is proposed, which preserves the classical DEVS definitions of atomic and coupled models and their original time-management scheme, while replacing the Select function and DFS-based event propagation with Level-Synchronous BFS scheduling, Event Parking, and Delta-round.

We first introduce Level-Synchronous BFS, which performs fully parallel evaluation along the levels of the coupling graph at the same $t^{*}$. The Event Parking procedure is then defined in which computed outputs are temporarily stored in internal and external queues and applied collectively. Finally, the Delta-round method repeats evaluation and commitment within the same slot until a stable state is reached.

4.1. Level-Synchronous BFS

Level-Synchronous BFS evaluates all events occurring within the same simulation time slot according to the logical depth (level) of the coupling structure, without relying on the Select method of classical DEVS. All models at the same level are evaluated simultaneously, and the resulting outputs are stored temporarily in each model’s parking queue. Once one level has been fully evaluated, the next level is processed in the same manner. During this phase, only the computation functions $\lambda$ and ${\delta }_{\mathrm{i}\mathrm{n}\mathrm{t}}$ are executed, whereas external transitions ${\delta }_{\mathrm{e}\mathrm{x}\mathrm{t}}$ are deferred. Each atomic model retains the standard DEVS interface consisting of $X, Y, S, {\delta }_{\mathrm{i}\mathrm{n}\mathrm{t}}, {\delta }_{\mathrm{e}\mathrm{x}\mathrm{t}}, \lambda$, and $ta$, based on the formalism defined in [2].

The DEVS simulator synchronizes all activities based on the most imminent event. Execution begins by retrieving the imminent event time and identifying the components scheduled to transition within that slot.

As shown in the equation below, among all components in the set $D$, the earliest transition time reported by each atomic model $i$ which denoted as $t_N\left[i\right]$ is selected as the current simulation slot time $t^{*}$:

$$t^{*}= \underset{i\in D}{\min }{t}_N[i]$$

(9)

Next, the set of components scheduled for transition within the current slot is obtained, as defined by the following equation:

$$L_{t*}=\{i\in D\mid t_N[i]=t^{*}\}$$

(10)

The imminent set is partitioned according to the logical depth of the coupled input–output structure. A smaller level $l$ indicates a higher position in the hierarchy, while a larger $l$ corresponds to a lower-level model. This hierarchical division enables level-wise concurrent evaluation within the same simulation slot:

$$L_{t*,l}=\left\{i\in L_{t*}∣level\left(i\right)=l\right\}, L_{t*}= \bigcup _{l=0}^{l_{max}}{L}_{t^{*},l}$$

(11)

Then, for every imminent model $i$ at level $l$, the output function ${\lambda }_i$ is evaluated simultaneously based on the model’s pre-state at the beginning of the current slot, $s_i^{-}$:

$$y_i={\lambda }_i\left(s_i^{-}\right)$$

(12)

This step corresponds to the evaluate phase, which is analogous to the Active phase in HDL simulation. During this stage, each model computes its output independently without considering any new states or outputs from other models.

For each model $i$, the generated output $y_i$ is transformed according to the coupling relation and delivered to the corresponding destination models $j$. The transformed output is then appended to each model’s parking queue $Q_{\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{k}}[j]$ as defined by the following equation:

$$\forall j\in I_i:Q_{park}\left[j\right]\leftarrow Q_{park}\left[j\right]\oplus Z_{i\to j}\left(y_i\right)$$

(13)

$I_i$ denotes the set of receivers connected to the output of model $i$, and $Z_{(i\to j)}$ represents the coupling transformation that maps the output of model $i$ to the input format required by the receiving model $j$. The operator $\oplus$ indicates accumulated into the target model’s parking queue.

Accordingly, all effects destined for each target model are accumulated and stored in its parking queue. After this aggregation, all imminent models at the same level simultaneously perform their internal transitions ${\delta }_{\mathrm{i}\mathrm{n}\mathrm{t}}$. Once the internal transition is completed, each model updates its post-state $s_i^{+}$, the last transition time $t_L\left[i\right]$, and the next scheduled transition time $t_N\left[i\right]$ according to the standard DEVS rules, as expressed below:

$$s_i^{+}={\delta }_i^{int}\left(s_i^{-}\right), t_L\left[i\right]\leftarrow t^{*}, t_N\left[i\right]\leftarrow t_L\left[i\right]+t{a}_i\left(s_i^{+}\right)$$

(14)

When this procedure is completed, the next phase applies the external transitions ${\delta }_{\mathrm{e}\mathrm{x}\mathrm{t}}$ collectively to all models whose parking queues contain inputs accumulated during the previous evaluation step.

4.2. Event Parking

The purpose of the event parking queue is to define the rule by which all outputs parked for each target model during the Level-Synchronous BFS phase are applied collectively at the same simulation time $t^{*}$. In the previous step, each $Q_{\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{k}}\left[j\right]$ contains a merged collection of outputs from multiple sender models, aggregated by their target model. All inputs accumulated in each model’s parking queue are then applied simultaneously through the external transition function ${\delta }_{\mathrm{e}\mathrm{x}\mathrm{t}}$, as defined by the following equation:

$$\forall j:s_j\leftarrow {\delta }_j^{ext}\left(\left(s_j,e_j\right), Q_{park}\left[j\right]\right), Q_{park}\left[j\right]\leftarrow \varnothing$$

(15)

$e_j$ denotes the time elapsed since the last transition. At this point, all effects produced within the same slot are committed simultaneously, so the entire pipeline is updated at the same timing, and no further order dependence arises.

At this stage, all effects generated within the same slot are committed simultaneously, ensuring that the entire pipeline updates at the same timing and eliminating any order dependency. After this commit operation, each model $j$ updates its last transition time and recalculates its next scheduled transition time according to the standard DEVS rule, as follows:

$$t_L\left[j\right]\leftarrow t^{*}, t_N\left[j\right]\leftarrow t_L\left[j\right]+t{a}_i\left(s_j\right)$$

(16)

The set of models that have newly scheduled transitions at the same simulation time $t^{*}$ is identified as follows:

$$L_{t^{*}}^{\prime }=\{j\mid t_N[j]=t^{*}\}$$

(17)

If $L_{t^{*}}^{\prime }$ is an empty set, the current simulation time slot is terminated, and the simulator advances to the next scheduled event time. If not, the models within this set are processed again within the same slot through the delta-round procedure described in the following section.

4.3. Delta-Round

A Delta-round is a process that repeats evaluation and commits operations within the same simulation time slot $t^{*}$ if there remain events requiring immediate re-evaluation. Conceptually, it is equivalent to the delta cycle in HDL simulation, ensuring convergence of zero-time feedback and pipeline propagation without using ε-time.

Each Delta-round follows four sequential stages: evaluate→parking→commit→time update which operate in the same manner as the Level-Synchronous BFS and Event parking procedures.

The repetition is triggered based on the set $L_{t^{*}}^{\prime }$, which contains models that still have pending transition events within the same time slot $t^{*}$. If this set is empty, it indicates that no additional events remain to be processed at the current time slot. If the set is not empty, that is $L_{t^{*}}^{\prime }\ne \mathrm{\varnothing }$, the Delta-round process begins.

We obtain the working set for this round from $L_{t^{*}}^{\prime }$ and decompose it by the logical depth of the coupling structure:

$$L_{t^{*}}^{(∆)} \leftarrow L_{t^{*}}^{\prime }, L_{t^{*},l}^{(∆)}=\{i\in L_{t^{*}}^{\left(∆\right)}\mid level\left(i\right)=l\}, L_{t^{*}}^{(∆)} =\bigcup _{l=0}^{l_{max}}{L}_{t^{*},l}^{(∆)}$$

(18)

$L_{t^{*}}^{(∆)}$ is the set of models to be handled in the current Delta-round, and $L_{t^{*},l}^{(∆)}$ is its partition at level $l$. We obtain the working set for the current round, $L_{t^{*}}^{(∆)}$ from $L_{t^{*}}^{\prime }$ and decompose it by the logical depth of the coupling structure to form $L_{t^{*},l}^{(∆)}$. This decomposition establishes a precedence within the same slot, which enables level-wise concurrent evaluation.

The subsequent operation repeats the proposed BFS procedure and event parking queue process. For each target model at every level, the output is computed and internal transitions are performed as follows:

$$y_i^{(∆)}={\lambda }_i\left(s_i^{-}\right), s_i^{+}={\delta }_i^{int}\left(s_i^{-}\right)$$

(19)

The computed outputs are not propagated immediately; instead, they are accumulated in each target model’s parking queue $Q_{\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{k}}\left[j\right]$ using the same mechanism as the event parking step. The equation below describes how $Q_{\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{k}}[j]$ is updated during the delta-round:

$$\forall j\in I_i: Q_{park}\left[j\right] \leftarrow Q_{park}\left[j\right]\oplus Z_{i\to j}\left(y_i^{\left(∆\right)}\right)$$

(20)

In the commit phase, all accumulated events in the parking queues are applied collectively to their corresponding receiver models. For every model $j$, the external transition function ${\delta }_{\mathrm{e}\mathrm{x}\mathrm{t}}$ is invoked once, after which the parking queue $Q_{\mathrm{p}\mathrm{a}\mathrm{r}\mathrm{k}}\left[j\right]$ is cleared. The process is expressed as follows:

$$\forall j:s_j\leftarrow {\delta }_j^{ext}\left(\left(s_j,0\right), Q_{park}\left[j\right]\right), Q_{park}\left[j\right]\leftarrow \varnothing$$

(21)

The elapsed time is set to 0 because all commits occur within the same simulation slot $t^{*}$. And each model then updates its timing variables according to the standard DEVS rule, $t_L\left[j\right]\leftarrow t^{*}$ and $t_N\left[j\right]\leftarrow t_L\left[j\right]+t{a}_j\left(s_j\right)$, for ensuring proper synchronization before the next slot begins.

Finally, we recompute the set of newly scheduled transitions at the same slot:

$$L_{(t^{*},\Delta +1)}^{\prime }=\left\{k\in D∣t_N\left[k\right]=t^{*}\right\}$$

(22)

If $L_{(t^{*},\hspace{0.17em}\mathrm{\Delta }+1)}^{\prime }=\mathrm{\varnothing }$, the current time slot terminates and the simulator advances to the next event time. Otherwise, the algorithm increments the delta-round index $\mathrm{\Delta }\leftarrow \mathrm{\Delta }+1$ and repeats the Delta-round at the same time slot $t^{*}$. This procedure repeats until all zero-time interactions within the same slot are stabilized, ensuring that the simulator achieves complete state convergence without any progression of physical time.

In exceptional cases, an infinite loop may occur due to improperly designed models. To prevent this, the simulator should define a maximum number of delta-rounds ($\max \hspace{0.17em}\mathrm{\Delta }$), and when this limit is reached, a non-convergence error must be reported.

This mechanism ensures that the generation of outputs and the application of external transitions remain clearly separated within each simulation slot, thereby preserving causality and determinism. Even in the presence of 0-time feedback or combinational chains, the simulator produces deterministic results within the same slot without relying on ε-time. A detailed comparison with Verilog event regions is provided below

Table 2. Formal mapping between Verilog event regions and the proposed BFS-based Kernel.

Target Event Region (HDL)	Proposed DEVS Kernel	Key Features
Active	Level-Synchronous BFS (evaluate phase)	Prevents interference among models within the same slot by evaluating all outputs simultaneously without immediate propagation. Each result is stored only in the target-specific parking queue.
NBA	Event parking and commit	Preserves concurrent inputs from multiple senders by holding RHS values in queues, then performs simultaneous LHS commits, mimicking the non-blocking assignment semantics of HDL.
Reactive	Delta-round detection	After commit, recalculates the new state and next event time for each model. Depending on slot conditions, either proceeds with another delta-cycle or terminates the slot and updates simulator outputs.

.

4.4. Comparison of Classic DEVS Kernel and Proposed Kernel

This section analyzes the structural and operational differences between the classical DEVS kernel and the proposed BFS-based kernel. We focus on two key aspects: the event propagation mechanism and the consistency of state transitions under concurrent events.

In the classical DEVS transition flow, which is illustrated in Figure 7, an output event generated by an internal transition is immediately propagated to the connected models. This triggers an immediate external transition in the receiving model before other simultaneous atomic models have completed their execution. Consequently, the simulation proceeds in a depth-first manner, where a single event chain is fully resolved before the next simultaneous event is processed.

In contrast, the proposed BFS-DEVS transition flow adopts a synchronization approach using an event parking mechanism. When multiple atomic models are scheduled for the same simulation time $ta=0$, their generated output events are not propagated immediately but are accumulated in the parking queue. The kernel checks if any imminent models remain $ta=0$. Figure 8 shows how propagation is managed in the proposed BFS-DEVS kernel.

Only when all simultaneous internal transitions are completed does the kernel pop the aggregated events from the queue and deliver them collectively to the target models. This ensures that all events generated within the same time slot are treated as a single logical batch, mirroring the concurrency semantics of hardware systems.

As illustrated in Figure 9, the classical DFS-based DEVS framework processes simultaneous events sequentially via the Select function. Consequently, the target model experiences a structural limitation where it fails to converge immediately to the final state $X″$ instead of updating through a transient intermediate state $X^{\prime }$. This mechanism imposes strict constraints on model designers to guarantee simulation determinism. Specifically, to ensure consistent results regardless of the input order, the model logic must satisfy the commutative property, and framework places excessive reliance on the design of the SELECT function to control the execution order among numerous models.

In contrast, when the target model simultaneously observes all concurrent events arriving at a given simulation time, it can execute a definitive state transition that maps the initial state directly to the final state based on the entire input set. Figure 10 illustrates the distinction between these two approaches from the perspective of state transition trajectories, demonstrating that the collective transition of the atomic model in the proposed method is structurally consistent with an ideal concurrent processing model. In this context, the proposed BFS-based kernel effectively eliminates the ambiguity caused by serialization, enabling rigorous state updates without requiring commutative model design or complex priority management.

4.5. Quantitative Analysis of Event Scheduling Complexity

In this section, to assess the relative scheduling overhead of different approaches for simulating synchronous registers, we approximate the number of DEVS transition events required to process $N$ registers over $C$ clock cycles. Although the exact runtime depends on additional factors such as queue management and coupling structure, we count only calls to the DEVS transition functions ${\delta }_{ext}$ and ${\delta }_{int}$, which dominate scheduling overhead in practical simulators. For clarity of exposition, we consider a representative case in which three synchronous register models, denoted as a, b, and c, perform a non-blocking assignment during every clock cycle.

4.5.1. Conventional Snapshot Method with a Clock Atomic Model

In a classical DEVS environment, non-blocking behavior is often emulated by adding a snapshot phase after the clock phase. A dedicated clock atomic model first broadcasts a clk event and, after an ε-delay, sends a snapshot message to all connected register models.

• Clock phase (clk.int):
  $a.ext\left(clk\right)\Rightarrow b.int\left(a.curr\right)$→$\left(b.prev,b.curr\right)$
  $b.ext\left(clk\right)\Rightarrow c.int\left(b.curr\right)$→$\left(c.prev,c.curr\right)$
  $c.ext\left(clk\right)\Rightarrow a.int\left(c.curr\right)$→$\left(a.prev,a.curr\right)$

• Snapshot phase (clk.int after ε-delay):
  $a.ext\left(snapshot\right) : a.curr$←$a.prev, ta= \infty$
  $b.ext\left(snapshot\right) : b.curr$←$b.prev, ta= \infty$
  $c.ext\left(snapshot\right) : c.curr$←$c.prev, ta= \infty$

Effectively, each register performs two external transitions per cycle: one for clk, one for snapshot. This doubles the logical work per cycle, and, in practice, the simulation time tends to grow to almost twice the clock period and increases linearly with the number of registers. Then, per-cycle scheduling cost is $N \times C \times 2_{\delta ext} \approx 2NC$.

4.5.2. Model-Level Emulation in RTL-DEVS

RTL-DEVS implements Verilog-like behavior by embedding a micro-state machine which has (wait, operation, out) inside each atomic model [21]. At each clock edge, the model works:

• Receives the clock via an external transition and moves from wait to operation.
• Performs RHS evaluation via an immediate internal transition, computing the next state and RHS values.
• Commits the LHS update and produces output in another internal transition, moving to the out state and then back to wait.

Thus, each register incurs one ${\delta }_{ext}$ and two ${\delta }_{int}$ per clock. Then, per-cycle scheduling cost is $N \times C \times {(1}_{\delta ext}+2_{\delta int}) \approx 3NC$.

4.5.3. Proposed BFS-Based Kernel with Event Parking

In the proposed kernel, non-blocking behavior is offloaded from the models to the scheduler. Each register model responds to the clock only once per cycle, and the commit is handled collectively by the kernel through the parking queue:

• Evaluation:
  $a.ext\left(clk\right)\Rightarrow enqueue a.curr$ in $park.queue\left[a\right]$
  $b.ext\left(clk\right)\Rightarrow enqueue b.curr$ in $park.queue\left[b\right]$
  $c.ext\left(clk\right)\Rightarrow enqueue c.curr$ in $park.queue\left[c\right]$

• Commit:
  When the slot terminates (sim.ta > 0), the kernel pops all parking queues once and invokes a single ${\delta }_{ext}$ per target model to apply the accumulated inputs. No additional snapshot messages or model-level micro-states are needed. Under the assumption of a stable synchronous pipeline, each register executes one external transition per cycle. Then, per-cycle scheduling cost is $N \times C \times 1_{\delta ext} \approx NC$.

Accordingly, the proposed BFS-based kernel reduces the number of scheduled transitions by approximately 50% relative to the snapshot method and by 66% relative to RTL-DEVS, while still preserving HDL-equivalent non-blocking behavior.

5. Case Studies and Discussions

5.1. Case of Pipeline Skew

In a DFS-based propagation, even within the same time slot, a cascade effect occurs because the state and output changes of a preceding stage are immediately reflected in the subsequent stage. In contrast, a BFS-based simulation initiates a collective event evaluation using the initial state of each model at that slot.

The following discussion explains, for an identical time slot $t^{*}$, how the initial and final states of each model $i$(denoted as $s_i^{-}$ and $s_i^{+}$) differ in behavior between the DFS-based DEVS simulation and the BFS-based simulation combined with a parking queue, as illustrated in Figure 6 for a two-stage pipeline:

DFS-Based Propagation:

• Flip-flop FF1 evaluates the input $D_{\mathrm{in}}$ and immediately applies $Q_1\leftarrow f_1\left(D_{\mathrm{in}}\right)$within the same time slot $t^{*}$
• The updated value of $Q_1$is then propagated in the same slot as the input to FF2.
• Consequently, FF2 performs its computation using the updated $Q_1^{+}$instead of the original $Q_1^{-}$that should have been observed at $t^{*}$. As a result, the output of FF2 appears one slot earlier than expected, producing a pipeline skew effect.

Proposed BFS + Event Queue–Based Propagation:

• In the time slot $t^{*}$, both FF1 and FF2 compute their outputs by referring only to their initial states $s_i^{-}$. Computations are defined as FF1: $y_1={\lambda }_1\left(s_1^{-}\right)$and FF2: $y_2={\lambda }_2\left(s_2^{-}\right)$
• The resulting outputs $y_1$and $y_2$are temporarily collected in target-specific parking queues.
• When the current time slot $t^{*}$ concludes, these results are collectively applied to update the final states $s_i^{+}$. Because FF1 and FF2 do not reference each other’s updated values within the same slot $t^{*}$, no skew occurs.

During simulation, in a model with a synchronized pipeline, the BFS-based approach first computes the outputs and then applies them simultaneously at the end of the time slot. As a result, each DEVS model produces its output independently of the preceding model’s updated output within the same slot, ensuring consistent results regardless of evaluation order.

5.2. Case of Infinity Loop

In the classical DEVS environment, the absence of infinitesimal time delays, known as ε-time, in zero-delay feedback loops often leads to infinite oscillations where events ping-pong endlessly between sub-models. To resolve this, explicit ε-time is traditionally introduced into the internal transition logic. For instance, in self-feedback circuits like an SR Latch, such artificial delays are required to ensure the model converges within a finite number of delta-cycles upon input changes.

However, the proposed BFS-based and delta-round technique incorporates an internal event parking queue, enabling the stable simulation of these structures without requiring explicit ε-time in the model. Functionally, ε-time serves as a heuristic mechanism to prevent the simultaneous overlap of input processing and consequent output generation within the same time slot. The proposed kernel structurally separates the evaluation of inputs from the commitment of the outputs through the introduction of the parking queue. This mechanism provides an equivalent effect to ε-time by enforcing a strict logical phase separation. Consequently, the kernel emulates the behavior of ε-time at the architectural level, guaranteeing convergence without imposing the burden of artificial delay management on the model designer.

5.3. Discussion

This study originates from the observation that the DFS-based event propagation in the classical DEVS abstract simulator structurally conflicts with the stratified event queue and delta-cycle mechanisms of HDL simulators. Such conflict leads to phenomena such as pipeline skew and zero-time feedback loops. To address these issues, we propose a DEVS simulation kernel that integrates level-synchronous BFS, event parking, and delta-round scheduling. Within a single simulation time slot, the proposed kernel performs evaluation, parking, and commit procedures, which formally correspond to the Active, NBA, and Reactive phases of industry-standard HDL simulators.

DEVS, with its rigorous time management, modularity, and hierarchical structure, provides precise control over complex and realistic systems, making it advantageous for co-simulation and dynamic scenario–based runtime analysis. Therefore, applying HDL design within the DEVS modeling space offers a complementary approach to systematically reproducing and analyzing design-level verification issues such as clock domain crossing (CDC) and metastability.

This can be facilitated through model-exchange and integration interfaces, reducing verification costs and the burden of repetitive compilation. However, existing approaches have primarily attempted to emulate HDL behavior or translate between HDLs by adding specialized functions to DEVS atomic or coupled models. As a result, a newly extended DEVS model had to be developed whenever a different HDL-related problem was addressed.

The BFS-scheduled DEVS simulation kernel proposed in this study aims to formally align the simulation kernel with the standard scheduling semantics of HDL simulators. This alignment reduces complexity during model conversion and provides a stronger foundation for achieving reliable and reproducible simulation outcomes. However, the proposed kernel is specifically designed to replicate HDL concurrency semantics with high fidelity within the DEVS environment.

Therefore, applying this approach uniformly to all general DEVS simulation domains may impose unnecessary constraints. For system models that do not require HDL-level concurrency guarantees, the classical DFS-based simulator can still serve as a more efficient and appropriate choice. Consequently, system designers intending to integrate the proposed method into general-purpose DEVS simulators should adopt a selective strategy that allows both the conventional DFS approach and the newly introduced BFS scheduling method to be applied as needed.

In conventional DEVS simulation, the DFS-based implementation offers the advantage that all models can be flattened into a directed acyclic graph (DAG) structure. In contrast, the proposed method requires tracking and managing the logical depth of the entire model. Before simulation begins, a static analysis must be performed to identify coupled models that contain self-feedback structures, which are then maintained in a dedicated reference table. This analysis stage is essential for detecting and managing coupled models that include zero-time feedback loops, such as SR latches. Because such coupled models are highly prone to oscillation during the delta-round process, additional safeguards may be required to mitigate computational complexity.

6. Conclusions and Future Work

The DFS-based event handling of classical DEVS fundamentally differs from the concurrency semantics of HDL simulators, which limits its scalability in hardware verification domains. This semantic inconsistency has been a major cause of timing distortion and output skew in DEVS-based modeling environments.

Early parallelization attempts, such as P-DEVS, primarily aimed to evaluate events occurring at the same simulation instant in parallel. However, DEVS simulations inherently allow computed outputs to be immediately propagated to other models within the same time slot, preventing them from faithfully reproducing the HDL principle of separating evaluation and commit in non-blocking assignments. The concurrency problem in HDL does not concern probabilistic convergence but rather deterministic state transitions that occur within a zero-time delta-cycle. Therefore, the classical DEVS formalism, in which outputs are propagated instantaneously, is inherently limited in addressing this limitation.

This work presents a conceptual design for a BFS-based simulation kernel inspired by the hierarchical event-queue mechanisms of HDL simulators. The proposed kernel ensures semantic equivalence with the Active, NBA, and Reactive phases of HDL through its event parking and delta-round mechanisms. As a methodological framework, the proposed approach has not yet been realized as a complete simulator. Future work will therefore focus on implementing the kernel and applying it to representative hardware design models to experimentally evaluate its correctness and performance. Ultimately, this study aims to narrow the semantic gap between DEVS and HDL, suggesting the potential of DEVS as a complementary framework for dynamic behavior analysis in complex digital systems.

The results of this study suggest that the semantic mismatch between DEVS and HDL simulators arises primarily from differences in their event-scheduling mechanisms rather than from limitations of the DEVS formalism itself. By adopting a BFS-based scheduling strategy with event parking and delta-round execution, the proposed kernel provides a practical means to align DEVS simulation behavior more closely with the concurrency semantics of standard HDL simulators.

Consequently, this approach mitigates timing inconsistencies, such as pipeline skew and zero-time feedback loops. It also suggests the utility of DEVS as a complementary framework for analyzing complex hardware behaviors that are challenging to capture through conventional HDL simulation alone.