While traditional UVM uses SystemVerilog's concurrent constructs (fork-join, always, etc.), Python's async/await syntax provides a cleaner and more explicit approach to concurrency. This is particularly valuable in hardware verification, where we constantly need to model parallel processes, handle timing, and manage complex interactions between components.
In Part 1, we explored the fundamental components of pyUVM and how they compare to traditional SystemVerilog UVM. We covered transactions, drivers, monitors, coverage, and scoreboards – the building blocks of any verification environment. In Part 2, we’ll dive deeper…
Part 1 of my 2-part guide on transitioning from SystemVerilog UVM to pyUVM. Compare verification components like transactions, drivers, and scoreboards with real TinyALU examples. Learn how Python features simplify verification workflows for modern engineers. Continue to Part 2 for advanced features.
This is the first in a series of tutorials exploring Python-based hardware verification. As someone with experience in SystemVerilog UVM, I’m investigating whether Python-based verification frameworks like Cocotb and PyUVM offer advantages over traditional approaches. Join me on this journey as I learn, experiment, and share my findings. In this post, we’ll set up Cocotb and run our first testbench. In the next post, we’ll explore PyUVM.
Introduction Throughout my verification career, I’ve consistently used uvm_config_db as my go-to mechanism for sharing data between components in UVM testbenches. It’s ubiquitous in training materials, example code, and verification environments. However, after reading Cliff Cummings’ illuminating paper “The Untapped…
The recently released 2024 Wilson Research Group Functional Verification Study offers a fascinating window into the world of IC/ASIC design and verification. As chips become increasingly complex and integrated into every aspect of our digital lives, understanding the verification landscape is crucial for industry professionals, investors, and technology enthusiasts alike.
In modern SoC designs, transaction routing through multiple paths is a common scenario. When the same transaction can take different routes with variable delays, ensuring data consistency becomes challenging. This blog post explores a UVM testbench architecture designed to verify out-of-order transaction handling while maintaining correct ordering for transactions with matching IDs.
