Confusing error message for "input reg"

[shirriff]

If I use "input reg", the resulting error message claims that I declared the variable as a wire, when I declared it as a reg. This is confusing.

I ran iverilog on this code:

module foo(input reg i, output reg o);
  always @* begin
    i <= o;
  end
endmodule

It produces the error:

bad.v:3: error: 'i' is not a valid l-value for a procedural assignment.
bad.v:1:      : 'i' is declared here as a wire.
Elaboration failed

Expected behavior: I should get an error, but the error shouldn't claim that I declared the variable as a wire when I didn't. (Presumably, the message happens because the compiler changes the variable to a wire behind the scenes.)

I'm using Icarus Verilog version 13.0 (devel) (s20250103)

[martinwhitaker]

You don't say what Verilog generation you are compiling for. By default, or if you explicitly request a standard Verilog generation (-g2005 or earlier), this is invalid syntax and the compiler should reject it. It doesn't, so that is a bug.

If you have explicitly requested a SystemVerilog generation (-g2005-sv or later), then the meaning of reg is changed. It no longer indicates a variable (var is used for that), but is instead a data type (a synonym for logic). Input ports default to being nets unless declared as variables, so in that case the error message is correct.

[shirriff]

I'm using the default compilation.

[caryr]

Maybe you need to look at your code a little closer. You are assigning the output to the input. When you swap the order and assign the input to the output things work as you expect. A better error message would be nice, but adding these are often not as easy as you would expect.

Marking this as an enhancement not a bug.

[caryr]

FYI this functionality is specified in 1800-2023 section 23.2.2.3:

— If the port kind is omitted:
    • For input and inout ports, the port shall default to a net of default net type. The default net
      type can be changed using the `default_nettype compiler directive (see 22.8).
    • For output ports, the default port kind depends on how the data type is specified:
        — If the data type is omitted or declared with the implicit_data_type syntax, the port kind
          shall default to a net of default net type.
        — If the data type is declared with the explicit data_type syntax, the port kind shall default to
          variable.

If you declare the input as a var (only allowed in SystemVerilog) this will compile without an error or warning, but it will likely not work as expected since you have the input/output swapped/the output is undriven. We likely need a better error message when var is used in pre-SystemVerilog generations. It's currently reported as a syntax error.

It may be good to issue a warning when output ports are not driven, but this needs more thought.

[martinwhitaker]

Yes, but @shirriff replied that he is using the default compilation options, so is compiling for standard Verilog (IEEE 1364). As I commented earlier, input reg is illegal syntax in standard Verilog, so the compiler should be rejecting the code at the parser stage.

[caryr]

Okay, if the parser accepts this and then generates an error message for Verilog generations stating this is SystemVerilog behavior that seems appropriate. We need to check if this is enabled because of the extended types. This all points to a number of places where the error reporting could be improved.

• The validity in SystemVerilog versus Verilog
• SystemVerilog input port with just a datatype being used as a variable
• var being used in Verilog is just denoted as a syntax error, not something that is valid in SystemVerilog

The problem with the last one is we want to detect the var, but don't want it as a keyword. There are a couple other places in the parser where this kind of checking should be done. I guess we likely need an extra identifier that is flagged as a syntax error unless the identifier matches a keyword in a later generation and then reports this as a syntax error, but is valid when using a later generation.

[caryr]

I'll also add, if you want to use SystemVerilog constructs just use a SystemVerilog generation. I think the problem is many searches, AI or maybe even common sense return SystemVerilog syntax and unless you know how to rewrite it you end up with an amalgamation where it's not clear why things are breaking. Maybe working on error/warning messages would be a good focus for version 14.