chipsalliance
incorrect variable capture in uhdm
- 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: ([email protected]), line:1:31, endln:1:32
|vpiParent:
\_port: (a), line:1:31, endln:1:32
|vpiName:a
|vpiFullName:[email protected]
|vpiActual:
\_logic_var: ([email protected]), 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: ([email protected]), line:3:8, endln:3:9
|vpiParent:
\_cont_assign: , line:3:8, endln:3:13
|vpiName:a
|vpiFullName:[email protected]
|vpiActual:
\_logic_net: ([email protected]), 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: ([email protected]), line:4:8, endln:4:9
|vpiParent:
\_cont_assign: , line:4:8, endln:4:13
|vpiName:a
|vpiFullName:[email protected]
|vpiActual:
\_logic_net: ([email protected]), 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.
- 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: ([email protected]), 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:[email protected]
|vpiNetType:36 <--- inconsistent concequence
|vpiNet: <---- vpiVariables ?
\_logic_net: ([email protected]), 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:[email protected]
|vpiNet: <---- vpiVariables ?
\_logic_net: ([email protected]), 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:[email protected]
See chapter 6.8 :
@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
