function parameter not correctly parsed

[CaulyKan]

Consider following verilog:

    function [7:0] my_function (input [9:0] a, b, inout c [0:5]);
    endfunction

the parse_sv gives following result for port b:

              TfPortItem
               DataTypeOrImplicit
                DataType
                 ClassType
                  PsClassIdentifier
                   ClassIdentifier
                    Identifier
                     SimpleIdentifier
                      Token: 'b' @ line:56

[DaveMcEwan]

@CaulyKan We need a bit more information here:

1. What do you expect?
2. Can you share your full testcase so I can reproduce what you see.

FWIW those fragments look good to me.

[CaulyKan]

Hi, thanks for the reply.

full testcase:

module foo();

    function [7:0] my_function (input [9:0] a, b, inout c [0:5]);
    endfunction

endmodule

use example/parse_sv -t from latest master will reproduce the result.

the 2017 standards defines that:

tf_port_item23 ::=
{ attribute_instance }
[ tf_port_direction ] [ var ] data_type_or_implicit
[ port_identifier { variable_dimension } [ = expression ] ] 

Where data_type_or_implicit and port_identifier can both be inferred to empty. So b should be data_type_or_implicit because it's no enclosed in a bracket?

However, from grammar's point of view, it seems more sensible that b is a port_identifier, with implicit data type logic.

Not sure if this is an issue of sv-parser, or this work should be done in back-end.

[DaveMcEwan]

You're right, this is confusing. @vasilissoti and I have seen a similar issue in svdata. I think this needs to be handled further downstream because sv-parser adheres closely to the BNF. In my opinion, this is an issue with IEEE1800-2017, but there's not much to be done about that here. @vasilissoti, would you mind pointing us to the equally confusing section in svdata where you deal with this for module ports?

[vasilissoti]

I also believe that the issue is related with IEEE1800-2017 and more specifically due to the lack of clarity in section 23.2.2.3

Since port b does not include an explicit direction, data kind, data type, signing or packed dimension declaration, all this information can be inherited/inferred from the previous port i.e. a (since b is not the first port).

SvData utilises a function which returns a bool on whether a "full" inheritance should be made. If true, SvData only searches for the port identifier and unpacked dimensions (if any).

https://github.com/DaveMcEwan/svdata/blob/a2acfd8a2a2f79bbbabfa0a160a0361d2b4dfd50/src/sv_port.rs#L13