Initial value of automatic function return value

[udif]

Describe the bug Not sure if this is a bug, and what to do about it.

To Reproduce

module t;
  function automatic [31:0] test();
    for (int i = 0; i < 3; i++) begin
      test = test + i;
    end
  endfunction

  generate
    $info("%d", test());
  endgenerate
endmodule

Additional context slang returns X for the code above. 2 other commercial tools are split between x and 3. I haven't checked yet what the IEEE1800-2023 LRM says. For my code I have simply initialized test to 0, but it was caught only by slang, while our simulator happily accepted it with no error.

Can we issue an explicit warning if a constant function is evaluating a local variable without initializing it first?

[MikePopoloski]

All four commercial tools I tried return 'x. This is correct according to the LRM; the return type of the function is logic[31:0], and logic has a default value of 'x.

I would like to have warnings for cases like this in slang; it belongs to a class of issues that require data flow analysis to do properly, and I'm probably going to have a lowering step via something like MLIR and perform the DFA on that instead of trying to shoehorn it into the AST.

[udif]

Try this with all 4, you will be surprised (set SV mode ofcourse)...

module t;
  function automatic [31:0] test();
    for (int i = 0; i < 3; i++) begin
      test = test + i;
    end
  endfunction

  generate
    $info("%d", test());
  endgenerate

  initial
    $info("%d", test());

endmodule

[MikePopoloski]

I tried it; RivieraPro, Xcelium, Questa, and VCS all print x twice. Not sure what you were expecting to happen?

[udif]

I don't like mentioning vendor names, but ...

Look at the output from the $info() call, yielding 3 instead of x (I don't know if I can mark something within a code section in MD).

slang actually caught this while Xcelium silently generated good code for the wrong reasons. You have to remove all the compiled files because it happens only inside generate sections at compile time.

Anyway, from what you describe, this is definitely an Xcelium bug, given that this behavior is seen by a single simulator at a specific corner case, and it seems to contradict what we expect according to thew standard.

% cat t.v
module t;
  function automatic [31:0] test();
    for (int i = 0; i < 3; i++) begin
      test = test + i;
    end
  endfunction

  generate
    $info("%d", test());
  endgenerate

  initial
    $info("%d", test());

endmodule

% rm -rf xcelium.d/
% xrun -sv t.v
TOOL:   xrun    23.03-s005: Started on Apr 11, 2024 at XX:XX:XX XXX
xrun: 23.03-s005: (c) Copyright 1995-2023 Cadence Design Systems, Inc.
file: t.v
    module worklib.t:v
        errors: 0, warnings: 0
        Caching library 'worklib' ....... Done
    Elaborating the design hierarchy:
    Top level design units:
        t
         3 
    $info("%d", test());
        |
xmelab: *N,INFOIE (./t.v,9|8): Elaboration encountered a $info at t.
    Building instance overlay tables: .................... Done
    Generating native compiled code:
        worklib.t:v <0x4b68a494>
            streams:   2, words:   858
    Building instance specific data structures.
    Loading native compiled code:     .................... Done
    Design hierarchy summary:
                 Instances  Unique
        Modules:         1       1
        Registers:       4       2
        Initial blocks:  1       1
    Writing initial simulation snapshot: worklib.t:v
Loading snapshot worklib.t:v .................... Done
xcelium> source /apps/tools/Cadence/XCELIUMMAIN/23.03.005/tools/xcelium/files/xmsimrc
xcelium> run
xmsim: *N,INFSEV (./t.v,13): (time 0 FS).
t
         x
xmsim: *W,RNQUIE: Simulation is complete.
xcelium> exit
TOOL:   xrun    23.03-s005: Exiting on Apr 11, 2024 at XX:XX:XX XXX  (total: 00:00:00)

[MikePopoloski]

Yeah, it seems like a regression in Xcelium; might be worth filing a bug with them. An older version of Xcelium doesn't have this problem:

TOOL:   xrun    20.09-s003: Started on Apr 11, 2024 at 11:04:01 EDT
xrun: 20.09-s003: (c) Copyright 1995-2020 Cadence Design Systems, Inc.
    Top level design units:
        t
xmelab: *W,DSEMEL: This SystemVerilog design will be simulated as per IEEE 1800-2009 SystemVerilog simulation semantics. Use -disable_sem2009 option for turning off SV 2009 simulation semantics.
         x 
    $info("%d", test());
        |
xmelab: *N,INFOIE (./testbench.sv,11|8): Elaboration encountered a $info at t.
Loading snapshot worklib.t:sv .................... Done
xmsim: *W,DSEM2009: This SystemVerilog design is simulated as per IEEE 1800-2009 SystemVerilog simulation semantics. Use -disable_sem2009 option for turning off SV 2009 simulation semantics.
xcelium> source /xcelium20.09/tools/xcelium/files/xmsimrc
xcelium> run
xmsim: *N,INFSEV (./testbench.sv,15): (time 0 FS).
t
         x
xmsim: *W,RNQUIE: Simulation is complete.
xcelium> exit
TOOL:   xrun    20.09-s003: Exiting on Apr 11, 2024 at 11:04:03 EDT  (total: 00:00:02)

[MikePopoloski]

Going to close this as it's not a slang bug. The data flow analysis work doesn't need to be tracked by this issue, it's a much broader project.