incorrect variable capture in uhdm

[Thomasb81]

1. on following testcase

module dut ( output var logic a);

assign a = 0;
assign a = 1;

endmodule

The uhdm elaborated tree is

...
  \_port: (a), line:1:31, endln:1:32
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test2.sv, line:1:1, endln:6:10
    |vpiName:a
    |vpiDirection:2
    |vpiLowConn:
    \_ref_obj: (work@dut.a), line:1:31, endln:1:32
      |vpiParent:
      \_port: (a), line:1:31, endln:1:32
      |vpiName:a
      |vpiFullName:work@dut.a
      |vpiActual:
      \_logic_var: (work@dut.a), line:1:31, endln:1:32
    |vpiTypedef:
    \_logic_typespec: , line:1:25, endln:1:30
  |vpiContAssign:
  \_cont_assign: , line:3:8, endln:3:13
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test2.sv, line:1:1, endln:6:10
    |vpiRhs:
    \_constant: , line:3:12, endln:3:13
      |vpiParent:
      \_cont_assign: , line:3:8, endln:3:13
      |vpiDecompile:0
      |vpiSize:1
      |UINT:0
      |vpiConstType:9
    |vpiLhs:
    \_ref_obj: (work@dut.a), line:3:8, endln:3:9
      |vpiParent:
      \_cont_assign: , line:3:8, endln:3:13
      |vpiName:a
      |vpiFullName:work@dut.a
      |vpiActual:
      \_logic_net: (work@dut.a), line:1:31, endln:1:32                                       <---- should be logic_var ?
  |vpiContAssign:
  \_cont_assign: , line:4:8, endln:4:13
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test2.sv, line:1:1, endln:6:10
    |vpiRhs:
    \_constant: , line:4:12, endln:4:13
      |vpiParent:
      \_cont_assign: , line:4:8, endln:4:13
      |vpiDecompile:1
      |vpiSize:1
      |UINT:1
      |vpiConstType:9
    |vpiLhs:
    \_ref_obj: (work@dut.a), line:4:8, endln:4:9
      |vpiParent:
      \_cont_assign: , line:4:8, endln:4:13
      |vpiName:a
      |vpiFullName:work@dut.a
      |vpiActual:
      \_logic_net: (work@dut.a), line:1:31, endln:1:32                                       <---- should be logic_var ?

On both ConsAssign, Lhs vpiActual return a logic_net, while it should probably be logic_var.

As a is declare as a variable, the linter should throw an error. See chapter 6.5 : Alternatively, variables can be written by one continuous assignment or one port.

2. Another thing odd to me, on a different testcase, but still related to variable:

module dut ();

logic a;
var logic b;
var c;

endmodule

In non-elaborated model, a, b and 'c' are capture has net. While by source code definition the tool should capture them as variable without elaboration step needed. Later in elaborated tree, element take their correct object type.

  |vpiNet:                                                             <---- vpiVariables ?
  \_logic_net: (work@dut.a), line:3:7, endln:3:8  <---- logic_var
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test5.sv, line:1:1, endln:7:10
    |vpiTypespec:
    \_logic_typespec: , line:3:1, endln:3:6
    |vpiName:a
    |vpiFullName:work@dut.a
    |vpiNetType:36                                               <--- inconsistent concequence 
  |vpiNet:                                                                 <---- vpiVariables ?
  \_logic_net: (work@dut.b), line:4:11, endln:4:12  <---- logic_var
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test5.sv, line:1:1, endln:7:10
    |vpiTypespec:
    \_logic_typespec: , line:4:5, endln:4:10
    |vpiName:b
    |vpiFullName:work@dut.b
  |vpiNet:                                                             <---- vpiVariables ?
  \_logic_net: (work@dut.c), line:5:5, endln:5:6  <---- vpiVariables ?
    |vpiParent:
    \_module_inst: work@dut (work@dut), file:/home/tom/prog/git/Surelog/test5.sv, line:1:1, endln:7:10
    |vpiName:c
    |vpiFullName:work@dut.c

See chapter 6.8 :

[alaindargelas]

@Thomasb81, there is no effort (and bandwidth on my end) in the non-elaborated tree to compute the correct data type.
Only in the elaborated tree.
You or @hs-apotell are welcome to contribute the required changes in the non-elaborated tree.

Both cases presented here are identical in nature, only a placeholder type in the non-elaborated tree, and correct type in the elaborated tree