Standard compatibility questions

[caryr]

It looks like when we added all this we missed the following:

Certain restrictions apply to the data type of a net. A valid data type for a net shall be one of the following:
a) A 4-state integral type, including a packed array or packed structure.
b) A fixed-size unpacked array or unpacked structure, where each element has a valid data type for a net.

At least one simulator allows 4-state enums, though they are not explicitly mentioned above. Maybe it is really considered a 4-state integral type.

I know we did wire real before we even started looking at SystemVerilog and it was needed for behavioural modelling. It seems like we need to fix this, but before we can do that we have to implement nettype so we can actually declare nets with the alternative types. My concern is this is going to create a break in the test bench unless we create two forms for each test that is using the incorrect format. That seems like it's going to be a lot of work, but I don't see any other alternative.

Thoughts?

[martinwhitaker]

Enums are explicitly included in the definition of integral types - see 1800-2012 section 6.1.11.

The ability to specify other data types for nets is documented as an Icarus extension in extensions,txt. That needs updating to note that SystemVerilog only supports a subset of the functionality. Tests that use the Icarus extensions should be included in regress-ivl1.list and specify -gxtypes.

[caryr]

-gxtypes is not needed since we support this by default, of course maybe things need to be changed so that this is only supported when using -gxtypes.

I changed the title since I have a bunch of different things to discuss and I think it would be better to have all this in one place instead of spread across many different conversations. For example some other simulators allow variables in classes to be declared after the function, but do not allow variables declared in modules to be after their use. I believe we should fix the later cases (module), but since a big name simulator supports this in classes we can keep this in the normal SV test section or should we create a special group for these defacto items?

Also should we change ivl1 to better indicate it is for Icarus specific and ivl2 that it is strict. ivl1 and ivl2 seem very arbitrary. For example regress-ivlonly, regress-strict, regress-defacto (if needed). I think the rest have descriptive names.

[caryr]

I just checked and it appears at least one commercial tools supports variables declared in modules to be after their use so maybe that all belongs as defacto items.

[martinwhitaker]

Unlike IEEE 1364, IEEE 1800 does explicitly state that variables must be declared before they are used, e.g. section 6.21 "A variable declaration shall precede any simple reference (non-hierarchical) to that variable" and section 6.5 "Data shall be declared before they are used, apart from implicit nets".

ivl2 is for Icarus-specific behaviour too. It is applied when not being strict. If you wanted to, I guess you could merge ivl1 and ivl2.

[caryr]

Here's another one. What should the macro expansion of an undefined value be. For example we treat `empty as an expansion to nothing with a warning. Commercial tools prohibit this. Should this be an error? The rational for treating this as empty can be found in the `undef description:

An undefined text macro has no value, just as if it had never been defined.

Thoughts?

[martinwhitaker]

Another one...

iverilog rejects the following code:

module test(v);
output v;
reg [7:0] v;
endmodule

This was made an error in response to pr1704013 (https://sourceforge.net/p/iverilog/bugs/232/). The rationale is that 1364-2005 states

If a port declaration does not include a net or variable type, then the port can be again declared in a net or
variable declaration. If the net or variable is declared as a vector, the range specification between the two
declarations of a port shall be identical.

However, section 12.3.7 of 1364-2005 includes the following example

module driver (net_r);
 output net_r;
 real r;
 wire [64:1] net_r = $realtobits (r);
endmodule 

suggesting the rule only applies if the port declaration includes a range.

No other Verilog compiler I've tried considers this an error.

iverilog also rejects the following code:

module test(i);
output i;
integer i;
endmodule

which I think is definitely a bug.