{"id":16755,"date":"2021-12-14T09:31:44","date_gmt":"2021-12-14T14:31:44","guid":{"rendered":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/?p=16755"},"modified":"2026-03-27T08:47:54","modified_gmt":"2026-03-27T12:47:54","slug":"logging-in-pyuvm","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/2021\/12\/14\/logging-in-pyuvm\/","title":{"rendered":"Logging in pyuvm"},"content":{"rendered":"\n

Logging in pyuvm<\/h1>\n\n
\n

This is part of the Python for Verification series<\/a> of blog posts.<\/p>\n<\/blockquote>\n\n

The IEEE UVM specification (1800.2-2020) devotes Section 6 to \u201cReporting classes\u201d because SystemVerilog does not provide a robust logging system. Python does. The logging<\/code> module provides standard logging functionality across the Python ecosystem, including cocotb<\/strong>. <\/p>\n\n

Therefore, pyuvm<\/strong> does not implement the UVM reporting classes. Instead, it incorporates the logging<\/code> module into the UVM hierarchy, links pyuvm<\/strong> logging to cocotb<\/strong> logging, and hides elements of the logging<\/code> module that frustrate new users.<\/p>\n\n

This blog post provides a brief overview of logging<\/code> and compares it to UVM reporting. Then it discusses logging in pyuvm<\/strong>.<\/p>\n\n

Logging levels<\/h2>\n\n

SystemVerilog UVM combines several concepts to control logging. Severity<\/em> is the most basic, ranging from UVM_INFO<\/code> to UVM_FATAL<\/code> and supported by macro calls that apply the severity to a log message.<\/p>\n\n

Verbosity<\/em> applies only to UVM_INFO<\/code> messages and controls whether a given info message gets logged. When users invoke the uvm_info()<\/code> macro, they supply a verbosity that ranges from UVM_NONE<\/code> through UVM_LOW<\/code> up to UVM_FULL<\/code>.<\/p>\n\n

Users can control information messages by setting a verbosity level in a component. The set_verbosity_level()<\/code> method creates a verbosity ceiling. The UVM reporting system prints a component\u2018s uvm_info()<\/code> messages only if their verbosity is below the ceiling.<\/p>\n\n

This ceiling system means information messages with verbosity UVM_LOW<\/code> get printed before those with UVM_FULL<\/code>. The uvm_warning<\/code>, uvm_error<\/code>, and uvm_fatal<\/code> messages ignore verbosity.<\/p>\n\n

The Python logging<\/code> module combines and simplifies these ideas into logging levels. There are five levels by default:<\/p>\n\n\n\n

Logging Level<\/td>Numeric Value<\/td><\/tr>
CRITICAL<\/td>50<\/td><\/tr>
ERROR<\/td>40<\/td><\/tr>
WARNING<\/td>30<\/td><\/tr>
INFO<\/td>20<\/td><\/tr>
DEBUG<\/td>10<\/td><\/tr>
NOTSET<\/td>0<\/td><\/tr><\/tbody><\/table>
Logging levels<\/figcaption><\/figure>\n\n\n\n

You log messages using functions such as self.logger.info()<\/code> or self.logger.critical()<\/code>. Then you set the logging level on a component. The messages created in that component get printed if their level is greater than or equal to the component logging level.<\/p>\n\n

pyuvm<\/strong> provides methods that set the logging level in components or component hierarchies.<\/p>\n\n

Logging in pyuvm<\/strong><\/h2>\n\n

pyuvm<\/strong> follows the IEEE 1800.2 specification in that it defines a class named uvm_report_object<\/code> and extends that class to create uvm_component<\/code>. This means that all uvm_components<\/code> are report objects, which is why you must <\/em> call super().__init__()<\/code> if you override the __init__()<\/code> method in a uvm_component<\/code>.<\/p>\n\n

UVM components support logging with the following steps.<\/p>\n\n

    \n\t
  • Every component creates a logger stored in self.logger<\/code>. These loggers are part of the cocotb<\/strong> logging system.<\/li>\n\t
  • The component sets the logger\u2019s level to the default logging level. By default the default is INFO<\/code>. You can change the default by using the class method uvm_report_object.set_default_logging_level()<\/code> before awaiting uvm_root().run_test()<\/code>.<\/li>\n\t
  • pyuvm<\/strong> defines PyuvmFormatter()<\/code> which makes pyuvm<\/strong> log messages look like UVM log messages.<\/li>\n\t
  • The component creates a StreamHandler<\/code> that prints messages to sys.stdout<\/code> rather than sys.stderr<\/code>.<\/li>\n<\/ul>\n\n

    Now any component can log messages.<\/p>\n\n

    Logging messages in pyuvm<\/strong><\/h2>\n\n

    We log messages using the critical<\/code>, warning<\/code>, error<\/code>, info<\/code>, and debug<\/code> functions in self.logger<\/code>. For example, these components print warning, info, and debug messages:<\/p>\n\n

    class WarningComp(uvm_component):\n    def start_of_simulation_phase(self):\n        self.logger.debug(\"This is WARNING\")\n\nclass InfoComp(uvm_component):\n    def start_of_simulation_phase(self):\n        self.logger.info(\"This is INFO\")\n\nclass DebugComp(uvm_component):\n    def start_of_simulation_phase(self):\n        self.logger.debug(\"This is DEBUG\")<\/code><\/pre>\n\n
    We instantiate these components in a test and call the test from a @cocotb.test()<\/code>:<\/p>\n\n
    class LogTest(uvm_test):\n    def build_phase(self):\n        self.info = InfoComp(\"info\", self)\n        self.warning = WarningComp(\"warning\", self)\n        self.debug = DebugComp(\"debug\", self)\n\n@cocotb.test()\nasync def default_logging_levels(_):\n    \"\"\"Demonstrate default logging levels\"\"\"\n    await uvm_root().run_test(\"LogTest\")<\/code><\/pre>\n\n
    And voila<\/em>!<\/p>\n\n
    #      0.00ns INFO     running default_logging_levels (1\/5)\n#      0.00ns INFO     testbench.py(14)[uvm_test_top.info]: This is INFO\n#      0.00ns WARNING  testbench.py(10)[uvm_test_top.warning]: This is WARNING\n#   1000.00ns INFO     default_logging_levels passed<\/code><\/pre>\n\n
    Examining the log message<\/h3>\n\n
    The first question you might ask is, \u201cWhere is the DEBUG<\/code> message?\u201d It is not there because the default log level is INFO<\/code> (20), and DEBUG<\/code> (10) is less than 20.<\/p>\n\n
    On a terminal we\u2019d see that cocotb<\/strong> has colorized the WARNING<\/code> message. It\u2019s also added the time stamp to the INFO<\/code> and WARNING<\/code> messages.<\/p>\n\n
    The pyuvm<\/strong> log messages look much like the UVM log messages with the following fields:<\/p>\n\n
      \n\t
    • The timestamp comes from the simulator. 0.00ns<\/code> in this case because we haven\u2019t started the simulation.<\/li>\n\t
    • The level in all caps (INFO<\/code>, WARNING<\/code>) matches the function call.<\/li>\n\t
    • The file name and line number shows where the message was logged.<\/li>\n\t
    • pyuvm<\/strong> logging does not have the message ID from SystemVerilog UVM reporting. Instead, we find the UVM hierarchy between square brackets ([]<\/code>)<\/li>\n\t
    • Finally, we see the string passed to the logging function.<\/li>\n<\/ul>\n\n
      Changing the logging level<\/h2>\n\n
      There are two ways to change the logging level. The first way (as of pyuvm 2.5) is to change the default logging level before awaiting the run_test()<\/code> coroutine. This way, all components get their logging level set to the new default:<\/p>\n\n
      @cocotb.test()\nasync def debug_default_logging_level(_):\n    \"\"\"Demonstrate debug logging level\"\"\"\n    uvm_report_object.set_default_logging_level(DEBUG)\n    await uvm_root().run_test(\"LogTest\")<\/code><\/pre>\n\n
      The second way to change the logging level is to use the set_logging_level_hier()<\/code> method in the end_of_elaboration_phase()<\/code>. This is analogous to the set_verbosity_level_hier()<\/code> method in the SystemVerilog UVM. It changes the logging level from this point in the hierarchy down. There is also a set_logging_level()<\/code> method that only changes the calling component’s logging level.<\/p>\n\n
      We extend LogTest<\/code> and change the logging level:<\/p>\n\n
      class DebugTest(LogTest):\n    def end_of_elaboration_phase(self):\n        self.set_logging_level_hier(DEBUG)<\/code><\/pre>\n\n
      Both approaches deliver the same result:<\/p>\n\n
      1000.00ns INFO     running debug_default_logging_level (2\/5)\n#   1000.00ns INFO     testbench.py(14)[uvm_test_top.info]: This is INFO\n#   1000.00ns WARNING  testbench.py(10)[uvm_test_top.warning]: This is WARNING\n#   1000.00ns DEBUG    testbench.py(18)[uvm_test_top.debug]: This is DEBUG\n#   2000.00ns INFO     debug_default_logging_level passed\n#   2000.00ns INFO     running debug_logging_level (3\/5)\n#   2000.00ns INFO     testbench.py(14)[uvm_test_top.info]: This is INFO\n#   2000.00ns WARNING  testbench.py(10)[uvm_test_top.warning]: This is WARNING\n#   2000.00ns DEBUG    testbench.py(18)[uvm_test_top.debug]: This is DEBUG\n#   3000.00ns INFO     debug_logging_level passed<\/code><\/pre>\n\n
      Controlling output<\/h2>\n\n
      The logging<\/code> module controls output using handlers that extend logging.Handler<\/code>. There are several predefined handlers in the logging.handlers<\/code> module. We will discuss three of them.<\/p>\n\n
      Every uvm_components<\/code> has a data member named self.logger<\/code>, which contains a StreamingHandler<\/code> that writes to stdout. You can remove this default handler using self.remove_streaming_handler()<\/code>, at which point your logger will have no handler, so you\u2019ll replace it with another handler.<\/p>\n\n
      Writing to a file<\/h3>\n\n
      If you want to log your information to a file instead of writing to the screen, you add a FileHandler<\/code> and remove the streaming handlers:<\/p>\n\n
      class FileTest(LogTest):\n    def end_of_elaboration_phase(self):\n        file_handler = logging.FileHandler(\"log.txt\", mode=\"w\")\n        self.add_logging_handler_hier(file_handler)\n        self.remove_streaming_handler_hier()<\/code><\/pre>\n\n
      The result is that the pyuvm<\/strong> log messages go into log.txt<\/code>:<\/p>\n\n
      #  cat log.txt\n  3000.00ns INFO     testbench.py(14)[uvm_test_top]: This is INFO\n  3000.00ns WARNING  testbench.py(10)[uvm_test_top]: This is WARNING\n  3000.00ns DEBUG    testbench.py(18)[uvm_test_top]: This is DEBUG<\/code><\/pre>\n\n
      The add_logging_handler()<\/code> and add_logging_handler_hier()<\/code> methods work for any of the handlers that extend logging.Handler<\/code>.<\/p>\n\n
      Disabling Logging<\/h3>\n\n
      To completely disable logging use self.disable_logging()<\/code> or self.disable_logging_hier()<\/code>which removes the stream handler and replaces it with a NullHandler<\/code>.<\/p>\n\n
      class NoLog(LogTest):\n    def end_of_elaboration_phase(self):\n        self.disable_logging_hier()<\/code><\/pre>\n\n
      Which gives the result:<\/p>\n\n
      #   4000.00ns INFO     running disable_logging (5\/5)\n#   5000.00ns INFO     disable_logging passed<\/code><\/pre>\n\n
      Summary<\/h2>\n\n
      This blog post showed how pyuvm<\/strong> incorporated the logging<\/code> module into a UVM testbench. We learned the difference between SystemVerilog UVM\u2019s severity<\/em> and verbosity<\/em> levels and how they relate to the levels<\/em> in the logging<\/code> module.<\/p>\n\n
      We saw how pyuvm<\/strong> mimics the message structure of SystemVerilog UVM and how it replaced the message-id<\/em> with the UVM component path between the square brackets.<\/p>\n\n
      Finally, we saw how to direct pyuvm<\/strong> logging output to different locations using logging.Handler<\/code> objects and how to disable logging.<\/p>\n\n\n\n
      <\/p>\n","protected":false},"excerpt":{"rendered":"
      Logging in pyuvm This is part of the Python for Verification series of blog posts. The IEEE UVM specification (1800.2-2020)…<\/p>\n","protected":false},"author":74314,"featured_media":16760,"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":[984,1,981,10],"tags":[902,971,787,819],"industry":[],"product":[],"coauthors":[947],"class_list":["post-16755","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cocotb","category-news","category-pyuvm","category-tips-tricks","tag-python","tag-pyuvm","tag-uvm","tag-verification"],"featured_image_url":"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/54\/2021\/12\/cover.png","_links":{"self":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16755","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=16755"}],"version-history":[{"count":4,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16755\/revisions"}],"predecessor-version":[{"id":16767,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/posts\/16755\/revisions\/16767"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media\/16760"}],"wp:attachment":[{"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/media?parent=16755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/categories?post=16755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/tags?post=16755"},{"taxonomy":"industry","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/industry?post=16755"},{"taxonomy":"product","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/product?post=16755"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blogs.sw.siemens.com\/verificationhorizons\/wp-json\/wp\/v2\/coauthors?post=16755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}