Improve assignment mechanism to simulator handles

Currently Cocotb provides the following constructs to assign variables to signals:

Overloaded le

@cocotb.test()
def my_test(dut):
    # Assignment form 1: overloaded __le__ method
    dut.clk <= 1

This a slightly cheeky way to provide RTL-like syntax in Python. For people familiar with Python it’s counter-intuitive (and “un-pythonic”: https://twitter.com/jandecaluwe/status/370597832971259904). However it doesn’t alias any functionality since it’s not valid to compare a handle to anything other than direct equality to another handle (for example to check whether clk == dut.clk). If attempting to compare the actual value of a signal the signal value would have to be read:

if dut.clk.value <= 1:
    # do something

although we should probably support the following to avoid the value aliasing problem described below:

if int(dut.clk) <= 1:
    # do something

Value property

@cocotb.test()
def my_test(dut):
    # Assignment form 2: use the "value" property
    dut.clk.value = 0

This form will cause problems if an object in the RTL hierarchy is called “value”, for example if we had a port named value we wouldn’t be able to read or write to it.

Possible enhancement

There is a third possible mechanism - to use the __setattr__ method. This also has limitations in that it will only work if descending at least one level into the hierarchy.

@cocotb.test()
def my_test(dut):
    # Assignment form 3: Use __setattr__
    dut.clk = 1

    # limitation - doesn't work if we only have a handle to the signal
    clk = dut.clk
    clk = 0      # Reassigns clk, doesn't drive a value

What is the best way to tidy this up?

Discuss.

[ktbarrett]

I’ve mentioned this before. Because we start the user, we can easily enforce it’s loading.

dut.signal = 4

[ktbarrett]

We have recently deprecated the __setattr__ and <= syntax. Only .value remains. The problems with it can be side-stepped by traversing the hierarchy with a different syntax than the syntax used to access handle operators:

dut["a"]["b"'][0].value = 0
# or maybe as a convenience
dut["a.b[0]"].value = 0

We shouldn’t let pretty syntax get in the way of things working.