3.0.0.dev0 with RAL UVM Register Access Layer

The UVM Register Access Layer (RAL) comes to pyuvm

pyuvm as I originally wrote it did not support the UVM Register Access Layer. Fortunately our wonderful contributors especially @EngRaff92 and @crteja took a leadership role in bringing RAL to pyuvm. This dev release is the first release of that work.

pyuvm* 3.0.0 will be the first RAL release. Before we make the release official, I am releasing this dev release so that people can try out the new technology.

Thank you to everyone who contributed to pyuvm 3.0.0.dev0!

Details and names are below.

What's Changed

• Automatic string conversion for log messages by @timothyscherer in #148
• Update example TinyALY to work with Verilator 5 by @teja-91 in #145
• Add support for uvm_transaction simulation time recording by @teja-91 in #153
• Replace fork with start_soon in example by @crteja in #155
• Add implementation for chapter 17 by @crteja in #154
• Update uvm_reg_map implementation by @crteja in #157
• Rationalized testing using tox by @raysalemi in #159
• Use 1800.2 naming convention for all base classes by @crteja in #162
• Enable CI for ral_dev by @crteja in #164
• TinyALU reg block implementation by @crteja in #166
• PR branch to main shared ral_dev branch push by @EngRaff92 in #168
• Ral dev by @EngRaff92 in #169
• Add the changes from PR 170 by @raysalemi in #171
• Generate passthrough interface by @crteja in #172
• Regenerate reg block using peakrdl-verilog by @crteja in #173
• Fix #160, replace all cocotb.fork() with cocotb.start_soon() in all tests by @MehanathanS in #175
• Fix Typo mentioned in #121 by @MehanathanS in #176
• Add default argument to ConfigDB().get() by @timothyscherer in #178
• Latest ral_dev update by @EngRaff92 in #186
• Add RAL to pyuvm. This is the primary 3.0 feature by @raysalemi in #194

New Contributors

• @timothyscherer made their first contribution in #148
• @teja-91 made their first contribution in #145
• @crteja made their first contribution in #155
• @EngRaff92 made their first contribution in #168
• @MehanathanS made their first contribution in #175

Full Changelog: 2.9.1...3.0.0.dev0

2.9.1 Fixed issue with cocotb 1.8.0.dev0 version string

Some users want to run with the cocotb 1.8.0.dev0 version. This string caused a ValueError in pyuvm. Now pyuvm ignores the string. 1.8.0.dev0 becomes 1.8.0 when testing the version number in the pyuvm.test() decorator.

What's Changed

• Minor edit to tox.ini to support Python 3.6/3.9 by @svenka3 in #123
• Fix environment variable definition in TinyALU Makefile by @miserva in #127
• Replace logger name with pathname+lineno in logging messages by @miserva in #131
• Fix colored output when COCOTB_ANSI_OUTPUT is set 0 by @viewtifulRafa in #132
• Change "UVMNotImplemented" error to "UsePythonMethod" error when applicable by @hzisman in #133
• Fix markdown lint errors in main README.md by @hzisman in #135
• Fix bug regarding cocotb versions that contain a string by @raysalemi in #142

New Contributors

• @viewtifulRafa made their first contribution in #132
• @hzisman made their first contribution in #133

Full Changelog: 2.9.0...2.9.1

Compatible with cocotb 1.7.1

This release supports the new cocotb 1.7.1 release manager. However, the decorator @pyuvm.test() no longer supports the TESTCASE command line argument in cocotb.

TESTCASE problem with pyuvm.test()

** Thanks to @ktbarrett for fixing this**

The pyuvm.test() decorator wraps the cocotb.test() decorator, but changes to the cocotb regression manager make this approach incompatible with the TESTCASE command line argument. There is an easy workaround (which was actually the original conception of using pyuvm with cocotb.

Typically, one might make a pyuvm test like this:

@pyuvm.test()
class MyTest(uvm_test):
     # all the test things

This would create a test object that cocotb would recognize and launch as a test. However, you can no longer put TESTCASE=MyTest on the command line in cocotb 1.7. Instead, you do the following:

class MyTest(uvm_test):
  # all the test things

@cocotb.test()
async test_run_MyTest(_):
        uvm_root().run_test(MyTest)

This will run MyTest as you would expect and will work with TESTCASE=test_run_MyTest

Fixed bug in objections.

@mkorbel1 noticed that pyuvm did not handle the case where multiple components had raised and lowered objections to ending the test. pyuvm was ending when one run_phase() dropped all its objections but not all. He fixed the problem.

Thanks, @mkorbel1!

Fixed bug in get_response()

uvm_sequence.get_response() was searching the response queue using the response ID instead of the transaction ID. Also, the signature was incorrect. This corrects that problem. Also fixed issues in the README.md file with regards to @pyuvm.testI()

Now with @pyuvm.test() decorator

The pyuvm.test() decorator

Now you can define a uvm_test to be a cocotb test using the @pyuvm.test() decorator. You no longer need to create a cocotb test that calls uvm_root().run_test(<test class>)

Now the ALUTest code looks like this:

import pyuvm  # To use the decorator

@pyuvm.test()
class AluTest(uvm_test):
    """Test ALU with random and max values"""

    def build_phase(self):
        self.env = AluEnv("env", self)

    def end_of_elaboration_phase(self):
        self.test_all = TestAllSeq.create("test_all")

    async def run_phase(self):
        self.raise_objection()
        await self.test_all.start()
        self.drop_objection()

VHDL Example

You can now run the VHDL version of the TinyALU example. Set TOPLEVEL_LANG=VHDL

Bug Fixes

Fixed a bug in drop_objection() that would exit prematurely if the same object called raise_objection() twice.

v2.6.1 Now with clone() and do_copy()

This release fixes minor bugs and adds expected UVM functionality:

• Now do_copy() works as expected in a uvm_object and you can use it to enable copy() and clone(). However I recommend using the Python copy module instead
• run_test() did not clear out the singletons properly and was losing the uvm_root() singleton
• run_test() now sets the default logging level to INFO unless you pass keep_singletons=True
• The example had a bug where it did not catch errors. Now it does and demonstrates errors.

Fix sequences. Clear Singletons.

New in pyuvm 2.6

2.6 is potentially a breaking release

This version of pyuvm clears the singletons when you await uvm_root().run_test().

You can disable this behavior with the keep_singletons=True argument in run_test().

For example:

	await uvm_root().run_test("MYTEST", keep_singletons=True)

You can keep singleton's you've created by passing them as a set to keep_set={}. For example if you have a singleton named MySingleton you would keep it like this:

    await uvm_root().run_test("MYTEST", keep_set={MySingleton})

Clearing Singletons

Clearing the singletons upon run_test() has the following implications.

ConfigDB() empties upon run_test()

This means that you cannot store data in the ConfigDB() in a cocotb.test() and then await run_test(). This raises the question of getting the dut argument into the pyuvm testbench.

The solution is to use the cocotb.top in pyuvm to get access to the dut handle. cocotb.top has the same handle as dut so there is no need to pass the dut using ConfigDB()

The uvm_factory() clears the overrides

You cannot call set_override... before awaiting run_test() Instead this must
happen in the uvm_test or in other components.

Multiple tests run without side effects

This release solves the problem of side effects from run_test(). pyuvm
was original written to have one test per simulation, but cocotb can run
multiple tests in one Python file. The side effects between tests caused
unexpected results.

Passing a uvm_test class to run_test()

The SystemVerilog UVM passes the name of the uvm_test class to run_test(). This is not necesary in pyuvm as you can pass the class as an object.

The examples in 2.6 now demonstrate this behavior instead of the string-passing behavior.

The uvm_sequence has a default name.

Now UVM sequences have a default name of "uvm_sequence" as per the 1800.2 specification.

start_item() and finish_item() work correctly

There was a bug that caused the driver to get your sequence item as soon as you awaited start_item(). This defeated late stimulus-generation, which is the point of these coroutines. This is now fixed.