Elyas Bayati

Making Sense of UVM Philosophy: Modular, Reusable & Layered Testbenches UVM adopts three strategies to keep its environment modular, reusable, and layered. 1) Modular means that each component of the testbench performs only its own specific function without interfering with the work of other components. This is possible when each component can achieve its intended functionality independently. For example, if we are building a generator class, we must ensure that it executes independently without requiring help from any other class. Each class has a unique role, which makes the environment modular. This also means that if you wish to modify any component, you don’t need to worry about how it will affect other components—you can merge changes without concern for unintended impacts elsewhere. 2) The second strategy is reusability, which means that components can be reused if the design uses the same protocols. For example, if we designed a verification environment for UART in a previous project, and the current product also includes UART interfaces, then the verification environment used earlier can be reused for the current project with minimal modifications. 3) The third strategy is a layered architecture, where the environment is divided into layers based on levels of abstraction. The sequence layer is responsible for generating high-level transaction data for test cases. The driver layer converts high-level transactions into signal-level activity for the DUT. The monitor layer captures signal-level activity from the DUT and converts it back into high-level transactions. The scoreboard layer compares these high-level transactions with the expected (golden) data. The environment layer handles the interconnection of components, and the test layer is the highest level of abstraction—it selects which sequence to execute on which environment. In summary, there are two layers (driver and monitor) that operate at the signal level, two layers (sequence and scoreboard) that operate at the transaction level, one layer (environment) that works at the component level, and finally the test layer, which operates at the highest level of abstraction. The environment and test layers can sometimes be confusing to distinguish. The environment layer handles the interconnection of components using TLM ports, which means you must understand each component’s functionality to connect them correctly. In contrast, the test layer only needs to know the names of the environment and the sequence—it doesn’t need to understand TLM connections or internal architectures. Therefore, the test layer represents the highest level of abstraction, working with component instances at a high level, while the environment layer operates just below it, requiring detailed knowledge of internal component architecture to make proper connections. Learn how we build UVM verification env from scratch here : https://lnkd.in/d4-3TK4d

52

I am pleased to share my newest paper about the pros and cons of drain vs. gate modulation when used on a GaN RF PA. Which one to use has been an ongoing debate for a while, and this work should add some clarity to the problem. Here is the link to the paper, it is in open access: https://lnkd.in/ek6_tcCd Villanova University College of Engineering IEEE Microwave Theory & Technology Society

139

7 Comments

As chip complexity skyrockets, verification engineers are under pressure to correlate behavior across abstraction levels—from SystemVerilog RTL to UVM sequences and even C testbenches. But how do you debug across these domains when traditional waveform views fall short? When you are logging signals, but missing the story behind the transactions, whether you're working in SystemVerilog, VHDL, or C, correlating transactions across simulation layers is essential to understand system behavior and accelerating debug. Rich Edelman of Siemens EDA has presented a powerful methodology at recent Design & Verification Conferences (DVCon) that bridges this gap. His paper, “SystemVerilog Transactions, UVM and C: Correlation in a Functional Verification Environment,” explores how to record and correlate transactions across RTL, UVM, gate-level, and C environments—using open-source examples you can run today. 📘 Read the full paper, download the presentation and access examples on Verification Academy https://sie.ag/36Hyh2. Whether you're building monitors, instrumenting sequences, or integrating DPI-C, this is a must-read for anyone serious about improving verification productivity. #FunctionalVerification #UVM #EDAInnovation

16

Can LLMs Really Design and Debug Hardware? This week, we’re spotlighting our collaboration with NVIDIA on CVDP (Comprehensive Verilog Design Problems), a benchmark-grade dataset for evaluating LLMs in real-world RTL design workflows. Built around 783 Verilog tasks, CVDP spans everything from single-file prompts to Git-style agentic challenges involving tool invocation, bug fixing, and architectural comprehension. Standard code generation benchmarks can’t capture the complexity of RTL design. With agentic simulations and real-world failure triggers, CVDP redefines what it means to benchmark hardware AI. → Read the full case study https://bit.ly/4q36ZHK

63

1 Comment

🚀 Excited to share that our latest paper has been published in Optics Express! "High-repetition-rate electro-optic frequency combs using cascaded silicon phase modulators" 📄 Read it here: https://lnkd.in/eu6w2vUu In this work, we explore novel techniques to enhance comb line spacing and spectral flatness using cascaded silicon phase modulators. We demonstrate a record-high comb repetition rate of 37.5 GHz using integrated modulators — a promising step toward high-speed optical communications and signal processing. Huge thanks to my amazing co-authors: 👉 Erwan Weckenmann, Alireza Geravand, Simon Levasseur, Prof. Leslie Ann Rusch, and Prof. Wei Shi. Grateful to be part of the vibrant research community at COPL and Université Laval. #research #photonics #optics #siliconphotonics #frequencycombs #OpticsExpress #UniversitéLaval #COPL

126

9 Comments

Large Language Models (LLMs) have demonstrated impressive capabilities in generating various types of software code. However, their effectiveness in producing high-quality hardware description language (HDL), such as RTL code, remains largely unproven. This gap is primarily due to the significantly larger availability of software code datasets compared to hardware design datasets. To address this limitation, the development of high-quality datasets—comprising functionally verified and synthesizable designs—is a critical first step toward enabling LLMs to generate reliable RTL code. The paper below outlines, in detail, the methodology used to create such a dataset. Thanks to Paul Calzada Zahin Ibnat Tanvir Rahman Sujan Saha and Farimah Farahmandi https://lnkd.in/ejtYHW9J

143

6 Comments

Exploring Python-Based Hardware Verification: From UVM to Cocotb After years of working with SystemVerilog UVM for hardware verification, I've started exploring Python-based verification with Cocotb and PyUVM. I'm curious: is this truly the future of hardware verification? I've started documenting my journey on my blog (first comment) where I'll be sharing my findings as I dive deeper into Cocotb and PyUVM. Join me in my journey to discover: - Can Python-based verification match UVM's capabilities for complex testbenches? - Does the promise of faster development time and reduced boilerplate hold up? - How well does this approach scale to real-world verification challenges? - Can we leverage Python's rich ecosystem (data analysis, ML) in hardware verification? If you've made the transition from traditional UVM to Python-based verification or are considering it, I'd love to hear about your experience! #HardwareVerification #Cocotb #PyUVM #Python #ASIC

216

33 Comments

UVM has become essential for hardware verification but is notorious for its steep learning curve.�� As highlighted by Clifford Cummings in his article Why UVM (and OVM) is Hard to Learn, many engineers struggle due to its complex macros, the reliance on object-oriented programming, and a lack of simple, complete examples. The key to mastering UVM lies in understanding SystemVerilog fundamentals, such as classes, randomization, and polymorphism, before diving into advanced UVM concepts. Simplifying your approach and focusing on core components can make a huge difference. In my recent webinar, we explored practical strategies to navigate these challenges and improve efficiency with UVM. Want to dive deeper? Check out the full details in the first comment. #UVM #HardwareVerification #SystemVerilog #TechChallenges #Verification

18

1 Comment

Delighted to share our latest paper on mitigating nonlinear effects in semiconductor optical amplifiers (SOAs) for O-band optical communication. We demonstrate how probabilistic amplitude shaping (PAS) significantly improves BER, EVM, and mutual information compared to uniform QAM. Additional gains are achieved using forward error correction (FEC). This work highlights PAS as a promising approach for high-capacity, energy-efficient photonic networks. Many thanks to the co-authors and collaborators. #OpticalCommunications #Photonics #Research #Collaborations #Frontiers Salman Ghafoor

18

*** New To Chiplets World: What I’d Focus On *** As a new engineer entering the world of chiplets, the learning curve is steep, but there are three areas I’d focus on first: 1.Understanding the interconnects. The core of chiplet-based SoCs is the inter-chiplet communication.Whether it’s UCIe, BoW, EMIB, or any other protocol, understanding how data moves between chips is crucial. If you don’t get how chiplets communicate, you won’t understand how your design will work in a multi-die system. 2.System-level thinking. Chiplet designs aren’t about optimizing individual chips—they’re about creating a coherent system. As a new engineer, it’s essential to look beyond the chiplet’s boundary and think about how your piece fits into the larger architecture. Understanding power, thermal, & communication interactions is key. 3.Verification from the start. The hardest issues with chiplets often surface at integration. Focus on building verification strategies early—both at the individual chipletlevel and in the full-chip system. A deep understanding of how chiplets interact will be your biggest asset. If you were starting fresh in the chiplet world, what would you prioritize?

21

Y. Liu, M. Ahmadi, J. Fuchs, M. Alaee-Kerahroodi, and M. R. Bhavani Shankar develop a versatile channel simulator that can generate frequency modulation continuous wave (FMCW) waveform multiple inputs and multiple outputs (MIMO) signals of indoor scenarios. Read it at: https://lnkd.in/d-QN4VJg #ieee #ieeetap #ieeeaps #radar #fmcw #mimo #indoor #mmwave

52

✤ Electromigration in VLSI Design ✤ • Electromigration (EM) is a major reliability issue in chips. When high current flows through tiny metal wires, atoms start moving—causing voids or hillocks that can break circuits. • Why it matters: It reduces chip lifetime and reliability. • Fix: Wider wires, redundant vias, better routing, and EM-aware tools. • In modern VLSI, reliability is as critical as performance. ✦ Join our whatsaap Community:- https://lnkd.in/gJexy6rB #Electromigration #VLSIDesign #ChipReliability #SemiconductorDesign #VLSICommunity #SoCDesign #EDA

144

2 Comments