{"id":16786,"date":"2022-01-14T10:04:49","date_gmt":"2022-01-14T15:04:49","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/?p=16786"},"modified":"2026-03-27T08:48:19","modified_gmt":"2026-03-27T12:48:19","slug":"odds-and-ends","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2022\/01\/14\/odds-and-ends\/","title":{"rendered":"Odds and Ends"},"content":{"rendered":"\n

I hope that the Python for Verification Series<\/a> has demonstrated that Python is a new tool in the verification team\u2019s toolbox. We can now write complete UVM testbenches in Python using pyuvm<\/strong> and connect them to the simulator using cocotb<\/strong>. Python as a verification language explodes the ecosystem at a verification engineer\u2019s fingertips while making it easier to hire engineers who know the team\u2019s language (Python) immediately.<\/p>\n\n

This final blog post in the series discusses odds and ends that may have gotten little attention in the blog posts or may not have been invented when the blog post was written. <\/p>\n\n

Python and SystemVerilog<\/h2>\n\n

Verification falls into a deeply committed relationship with every language it meets. You can look across the verification landscape and find old friends such as VHDL, Verilog, SystemC, e<\/em>, and C++. Our industry will likely add Python to that list, using it on projects where it does the most good.<\/p>\n\n

SystemVerilog is still the best way to define complicated randomization constraints and functional coverage bins. Python needs to take advantage of what SystemVerilog has to offer.<\/p>\n\n

Siemens EDA has a skunkworks project named SVConduit that allows engineers to define objects using YAML and then pass those objects between SystemVerilog and Python using put()<\/code> and get()<\/code> operations. Python uses get()<\/code> to retrieve a randomized transaction and put()<\/code> to store functional coverage.<\/p>\n\n

SVConduit is an example of how SystemVerilog will remain relevant in the future. Contact your Siemens EDA AE if you\u2019d like the SVConduit source code.<\/p>\n\n

pyuvm changes to run_test()<\/h2>\n\n

pyuvm<\/strong> changes the run_test()<\/code> task in several ways, starting with the fact that you use the await<\/code> keyword to start your test.<\/p>\n\n

await uvm_root().run_test("MyTest")<\/code><\/pre>\n\n
Passing classes to run_test()<\/h3>\n\n
The string in the above call raises another change. pyuvm<\/strong> slavishly copied the SystemVerilog UVM\u2019s use of a string to hold the test name. There is no need to do that in Python as we can pass the class directly. This also enables error checking for misspellings. So now we can do this without the string:<\/p>\n\n
await uvm_root().run_test(MyTest)<\/code><\/pre>\n\n
pyuvm does not need uvm_test<\/h3>\n\n
Python has no typing, so pyuvm<\/strong> does not need uvm_test<\/code>, though it implements it to follow the standard. Here is the uvm_test<\/code> implementation. It is an empty extension:<\/p>\n\n
# 13.2 \nclass uvm_test(uvm_component):\n    """\n        The base class for all tests\n    """<\/code><\/pre>\n\n
This means we could pass a uvm_component<\/code> class to run_test()<\/code>, and it would work with no problem.<\/p>\n\n
Keeping singletons<\/h3>\n\n
The SystemVerilog UVM built and ran a single UVM testbench per simulation run. cocotb<\/strong> allows you to store many tests in one Python file and run a different pyuvm<\/strong> test in each of them.<\/p>\n\n
This feature was broken before version 2.6 because the singletons in one test carried over to the next test. For example, the ConfigDB()<\/code> would keep data from the previous test.<\/p>\n\n
Starting in 2.6, run_test()<\/code> clears all singletons except the uvm_factory()<\/code>. It clears the overrides in uvm_factory()<\/code>. You can keep the singletons by using the keep_singletons<\/code>argument:<\/p>\n\n
uvm_root().run_test(keep_singletons=True)<\/code><\/pre>\n\n
This argument will also keep the existing factory overrides. You can clear them explicitly using uvm_factory().clear_overrides()<\/code>.<\/p>\n\n
If you want to keep data between calls to run_test()<\/code> you store it in one or more singletons, and tell run_test()<\/code> to keep them using keep_set<\/code>. For example, you may keep persistent data in a singleton class named GlobalData<\/code><\/p>\n\n
uvm_root().run_test(MyTest, keep_set=set([GlobalData])<\/code><\/pre>\n\n
This will clear all the singletons but GlobalData<\/code><\/p>\n\n
Enabling deep UVM log messages<\/h2>\n\n
The Python logging<\/strong> module defines logging levels. A message is more likely to be logged if its logging level is high. The default logging levels range from CRITICAL<\/code> (50) to DEBUG<\/code> (10). <\/p>\n\n
pyuvm<\/strong> adds two logging levels below DEBUG<\/code>: FIFO_DEBUG<\/code> (5) and PYUVM_DEBUG<\/code> (4). Setting a FIFO\u2019s logging level to PYUVM<\/code> will log all the activity in the FIFO. It is useful if your testbench is hanging.<\/p>\n\n
The PYUVM_DEBUG<\/code> level will become more verbose over time as there is more need to print UVM debug messages.<\/p>\n\n
Changing the default logging level<\/h3>\n\n
pyuvm<\/strong> sets logger objects to the INFO<\/code> logging level by default. You can change that default before awaiting run_test()<\/code>:<\/p>\n\n
uvm_report_object.set_default_logging_level(DEBUG)\nuvm_root().run_test(MyTest)<\/code><\/pre>\n\n
pyuvm does not need uvm_subscriber\n<\/em><\/h2>\n\n
The SystemVerilog UVM provides the uvm_subscriber<\/code> class as a convenience class. uvm_subscriber<\/code> creates an analysis_export<\/code> with the correct parameterized type and links it to the write()<\/code> function. One could code this manually, and one does to have multiple analysis_export<\/code> objects in a single subscriber, such as a scoreboard.<\/p>\n\n
Python doesn\u2019t have typing issues, so a programmer can create a subscriber by directly extending uvm_analysis_export<\/code> and providing the write()<\/code> function.<\/p>\n\n
This is the same procedure as using uvm_subscriber<\/code>, except you can pass an object that extends analysis_export<\/code> directly to the connect()<\/code> function.<\/p>\n\n
Here is an example. We define Adder<\/code> by extending uvm_analysis_export<\/code> and instantiate it in the test. Then we pass the instantiated adder (self.sum<\/code>) directly to the ap.connect()<\/code> function:<\/p>\n\n
class Adder(uvm_analysis_export):\n    def start_of_simulation_phase(self):\n        self.sum = 0\n\n    def write(self, nn):\n        self.sum += nn\n\n    def report_phase(self):\n        self.logger.info(f"Sum: {self.sum}")\n\n\nclass AdderTest(uvm_test):\n    def build_phase(self):\n        self.num_gen = NumberGenerator("num_gen", self)\n        self.sum = Adder("sum", self)\n\n    def connect_phase(self):\n        self.num_gen.ap.connect(self.sum)<\/code><\/pre>\n\n
Summary<\/h2>\n\n
This blog post examined how pyuvm<\/strong> is different from the SystemVerilog UVM. I hope it becomes a valuable tool in the verification engineer\u2019s toolbox.<\/p>\n\n\n\n","protected":false},"excerpt":{"rendered":"
I hope that the Python for Verification Series has demonstrated that Python is a new tool in the verification team\u2019s…<\/p>\n","protected":false},"author":74314,"featured_media":16788,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spanish_translation":"","french_translation":"","german_translation":"","italian_translation":"","polish_translation":"","japanese_translation":"","chinese_translation":"","footnotes":""},"categories":[1],"tags":[989,902,971,787,788,819],"industry":[],"product":[],"coauthors":[947],"class_list":["post-16786","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news","tag-cocotb","tag-python","tag-pyuvm","tag-uvm","tag-uvm-1-2","tag-verification"],"featured_image_url":"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2022\/01\/lego-blocks.jpeg","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16786","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/users\/74314"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/comments?post=16786"}],"version-history":[{"count":3,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16786\/revisions"}],"predecessor-version":[{"id":16961,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16786\/revisions\/16961"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media\/16788"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=16786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=16786"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=16786"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=16786"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=16786"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=16786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}