Why Your pll_locked Assertion is Failing: SVALint Liveness Rules

As we gear up for the 63rd Design Automation Conference (DAC) next week, the engineering team at AsFigo (in collaboration with VerifWorks) is rolling out a major extension to SVALint—our blazing-fast, Verible-backed SystemVerilog Assertion linter.

Among our new suite of functional correctness checks, one major hazard we are targeting is the misapplication of liveness operators in dynamic simulation environments: specifically, bounded weak-strong patterns like eventually s_always.

The Trap: A Common Scenario with pll_locked

Consider a standard verification check for a clock generation block. An engineer writes an assertion expecting that within a reasonable window after reset, the PLL locks and remains permanently stable:

// Risky Assertion Style
property p_pll_stable;
  @(posedge clk) disable iff (!rst_n) 
    eventually [1:10] s_always pll_locked;
endproperty : p_pll_stable

a_p_pll_stable : 
assert property (p_pll_stable) else begin
  `uvm_error("a_p_pll_stable", "PLL went out of lock");

On paper, this looks correct. But in a full-chip simulation lifecycle, this assertion is a ticking time bomb.

Why This Style Fails in Simulation SVA

1. Testbench Phase Shifts & Mode Changes

Modern hardware blocks transition through multiple dynamic phases: boot-up, active processing, low-power entry/exit, and multi-mode clock switching. If your testbench later triggers a power-gating sequence or re-initializes the PLL, the s_always pll_locked condition is broken, resulting in a false simulation failure.

2. The Illusion of Finality

Assertions meant to verify stabilization often accidentally morph into permanent lock detectors. In dynamic simulation runs, expecting a signal to never change again until simulation finish ignores the reality of multi-scenario verification flows.

The SVALint Solution

To eliminate these noise-heavy failures from your assertion logs, the new release of SVALint flags these hazardous patterns automatically out-of-the-box:

  • [FUNC_AVOID_EV_S_ALW]: Detects bounded weak-strong patterns (eventually s_always).
  • Companion Rules: Automatically audits equivalent pitfalls like s_eventually always, s_eventually s_always, and eventually always.

Recommendation: Instead of enforcing unyielding, permanent stability via weak-strong temporal chains, bound your stabilization windows strictly on both sides or verify transient behavior using bounded cadence checks.

Catch us at DAC next week to see SVALint live and learn how automated structural linting can protect your assertion coverage metrics.

Comments

Post a Comment

Popular posts from this blog

Cracking the UVM-Verilator Code: 50+ IPs, AI Guardrails, and the Open-Source North Star

UVM on Verilator Isn’t Impossible. It’s Just Hard. We Did It Anyway. The “standard” line in the industry: UVM and Verilator don’t mix. Enterprise-grade open-source verification is a fantasy. So we put that claim under load. ✔ 50+ production UVCs ported ✔ 35 + non-obvious failure modes uncovered ✔ Converted into UVMLint and SVALint rules ✔ AI guardrails to prevent regressions This post is the why and what; the how and numbers are for the room at Hacker Dojo.  This is production-grade code—the kind that tapes out chips—running on open-source infrastructure. The implication is bigger than a port: Reduced dependency on closed ecosystems. Negotiating leverage with EDA vendors. Strategic control over your verification stack. If you’re a semiconductor company exploring Verilator for serious IP, don’t start from scratch. Start from the team that already mapped the minefield. 📅 Join us at the Hacker Dojo Next Thursday, the AsFigo team...
Read more

Call for Collaboration: Seeking Public UVM Environments for Verilator 5.0+ Porting

The transition of SystemVerilog UVM environments to open-source simulators presents specific technical challenges. While Verilator 5.0+ has expanded support for various SystemVerilog constructs, the industry still lacks a documented and repeatable path for certain UVM-specific behaviors. In parallel, we aim to curate a public vault of UVM repositories that have been successfully ported to Verilator. AsFigo is initiating a collaborative effort to document these gaps, and we are looking for engineers, researchers, and students to contribute original UVM codebases to this effort.  Link to Google Form: Submit Your code base The Technical Focus This effort intentionally moves beyond minimal or illustrative examples. We are seeking unique, original UVM implementations that reflect realistic UVM environments and non-trivial SystemVerilog usage found in real-world verification flows. Infrastructure Components: Memo...
Read more

Breaking the License Barrier: The World’s First UVM + Verilator Hands-On Bootcamp - Mar-1, Sunday 3-5 PM PST

Remote link:  AsFigo UVM Verilator Bootcamp | Meeting-Join | Microsoft Teams For decades, the power of UVM (Universal Verification Methodology) has been locked behind the high-cost gates of commercial simulators. At AsFigo , we believe the future of silicon verification belongs to the community. We are breaking those gates down to empower a new generation of verification engineers. A Community Milestone The dream of open-source UVM is the result of a massive, multi-year industry effort. Foundations laid by the CHIPS Alliance, DARPA, Google, and Antmicro have reached a critical tipping point. This movement was fueled by the relentless technical contributions of pioneers such as Wilson Snyder, Geza Lore, Krzysztof Bieganski, et al. , whose work over the last several years made the "impossible" possible. The public breakthrough for UVM support in Verilator was announced in late 2023. On that very day, we at AsFigo successfully ported a complete APB UVC and...
Read more