Refactor of handle objects

Handles (in handle.py) support dot syntax for traversal of the HDL object hierarchy, but they also contain a number of attributes for using the value. These namespaces are known to collide and there currently is no mechanism to work around this issue. And to some degree it is unavoidable, Python objects have a number of builtin attributes (usually starting and ending with 2 underscores).

To solve this I recommend we split the traversal and analysis of HDL objects into two. Object traversal objects will only be able to be used to traverse the hierarchy. We can then obtain a HDLValue object which will contain all the other expected and useful behavior. One would obtain this value with an attribute that will not collide with valid identifiers in Verilog, VHDL or Python: use is a keyword in both languages and not a keyword in Python.

type(dut.input)  # -> child of SimHandleBase
int(dut.input)  # -> Error
type(dut.input.use)  # -> HDLValue
int(dut.input.use)  # -> 0

Alternatively, since we should already mention Python builtin attributes names (__{name}__) will not work we could put such a function in a similar name (e.g. __value__), and provide a free function (or constructor) for access.

type(HDLValue(dut.input))  # -> HDLValue
int(HDLValue(dut.input))  # -> 0

[eric-wieser]

operator: still valid Verilog identifiers, but unfortunately unavoidable

Not true, because python operators only cares about type(dut).__operator__, we’re free to replace dut.__operator__ via type(dut).__getattribute__.

[ktbarrett]

I have run into .value before, it’s the biggest offender. In that case the solution was to rename the object 😕 This may not be easy depending upon the user. Formal verification processes are extremely bureaucratic, turn around time on a rename might be over a week. But every attribute on those classes is a valid Verilog identifier (VHDL identifiers can’t start with _) and has the potential to collide.

• setimmediatevalue, drivers, loads, and value: valid Verilog and VHDL identifiers
• _thing: while they are “private”, they are still valid Verilog identitifers
• __operator__: still valid Verilog identifiers, but unfortunately unavoidable

I just made this issue to highlight an implementation flaw that might one day be worked and poll for potential solution.