DRAMPyML: A Formal Description of DRAM Protocols with Timed Petri Nets

The JEDEC committee defines various domain-specific DRAM standards. These standards feature increasingly complex and evolving protocol specifications, which are detailed in timing diagrams and command tables. Understanding these protocols is becoming progressively challenging as new features and complex device hierarchies are difficult to comprehend without an expressive model. While each JEDEC standard features a simplified state machine, this state machine fails to reflect the parallel operation of memory banks. In this paper, we present an evolved modeling approach based on timed Petri nets and Python. This model provides a more accurate representation of DRAM protocols, making them easier to understand and directly executable, which enables the evaluation of interesting metrics and the verification of controller RTL models, DRAM logic and memory simulators.

💡 Research Summary

The paper addresses the growing complexity of modern DRAM standards such as DDR5, LPDDR5 and HBM, whose specifications are spread across numerous timing diagrams and command tables. Traditional JEDEC state‑machine descriptions are insufficient because they ignore bank‑level parallelism and cannot capture the intricate timing constraints required for correct controller operation. Earlier work introduced a domain‑specific language called DRAMml together with a timed‑inhibitor‑reset Petri net model. While DRAMml enabled automatic generation of a cycle‑accurate simulator (DRAMSys) and SystemVerilog assertions, its rigid hierarchical syntax could not express newer features like SameBank and Per2Bank commands, making it hard to maintain as standards evolve.

To overcome these limitations, the authors propose DRAMPyML, a new formal description method that leverages the general‑purpose Python language combined with timed Petri nets. The approach retains the expressive power of the previous Petri‑net model—places represent conditions, transitions represent commands, and tokens encode bank activation states—while adding the flexibility of Python for hierarchical construction and rapid prototyping. In the model, each bank has an ACTIVE place; an ACT transition creates a token in this place, and PRE or PREA transitions reset it via reset arcs. Inhibitor arcs prevent illegal command sequences (e.g., issuing ACT on an already active bank) and block power‑down or self‑refresh transitions when any bank is active. Timed arcs, equipped with age guards, enforce JEDEC‑specified minimum delays such as tRCD, tRAS, tRC, and more complex constraints like the N‑Activate Window or command‑bus occupancy. Custom timed‑inhibitor‑reset arcs model “command‑to‑command” blocking periods (tx) without needing separate DSL constructs.

Implementation details show a concise Python API: a graph object g is populated with places and transitions using g.add_node and g.add_edge, while specialized arc objects (ResetArc, InhibitorArc, TimedArc) encode the required semantics. The authors provide example code snippets that automatically generate the full hierarchy of ranks, banks, and channels based on parameterized loops, dramatically reducing description size compared with DRAMml. Because the model is executable in the Python interpreter, designers can feed a sequence of commands and obtain immediate feedback on timing violations, enabling rapid functional validation of controller logic.

For verification, the authors demonstrate two complementary uses. First, the executable model drives a simple protocol‑compliant memory controller that can be co‑simulated with RTL designs, exposing mismatches early in the design flow. Second, the model is traversed to automatically emit SystemVerilog Assertions (SVAs) that encode the same timing constraints; these assertions can be integrated into standard verification environments to check existing RTL controllers for JEDEC compliance. Formal analysis algorithms are also described: reachability analysis verifies that all banks can be simultaneously active, dead‑lock detection ensures that power‑down and self‑refresh transitions are always reachable, and timing‑window analysis quantifies the maximum number of outstanding activates allowed under a given tFAW constraint.

Experimental results on a DDR5‑like configuration show that DRAMPyML can model the full set of commands, including SameBank and Per2Bank, with a description size roughly 30 % of the equivalent DRAMml model. The generated SVAs correctly flagged injected protocol violations in a reference RTL controller, and the Python‑based simulator reproduced the timing behavior of the DRAMSys cycle‑accurate model with negligible performance overhead.

In summary, DRAMPyML provides a flexible, Python‑driven formalism for DRAM protocol specification that captures both functional and temporal aspects using timed‑inhibitor‑reset Petri nets. It enables executable modeling, automatic generation of verification artifacts, and formal analyses that were previously cumbersome or impossible with rigid DSLs. The approach promises easier adaptation to future JEDEC standards and a unified verification flow from high‑level protocol description down to RTL and silicon validation.