Skip to content

Wrong object class and mode for to_string(call_path ...)

This issue was reported in https://opensource.ieee.org/vasg/Packages/-/issues/1 by @paebbels :

As reported by Abhijit Chakrabarty via email/reflector on 26.11.2020: https://grouper.ieee.org/groups/1076/email/msg01356.html

Hi Team, We are facing this issue while implementing vhdl-19. Please help us.

Regards, Abhijit

Package std.env in Vhdl 2019 has following subprogram specification:

type CALL_PATH_VECTOR_PTR is access CALL_PATH_VECTOR;
impure function TO_STRING (call_path : CALL_PATH_VECTOR_PTR; Separator : STRING := "" & LF ) return STRING;

For the first argument, call_path, both the object class (signal/variable/constant) and the mode (in/out/inout) are not specified. We take class constant and mode in.

1076-2019 Section 4.2.2 describes the formal parameters for subprograms.

Section 4.2.2.1 NOTE1 says:

NOTE 1 — Variable class parameters of access and protected types are allowed for procedures and impure functions.

So it is only allowed when object class is variable. As call_path is constant, we error out.

env.vhdl(255): ERROR: formal constant 'call_path' cannot be of an access type

To infer the object class and mode:

Section 4.2.2.1:
For those parameters with modes, the only modes that are allowed for formal parameters of a procedure or an impure function are in, inout, and out. If the mode is in and no object class is explicitly specified, constant is assumed.

For those parameters with modes, the only mode that is allowed for formal parameters of a pure function is the mode in (whether this mode is specified explicitly or implicitly). The object class shall be constant, signal, or file. If no object class is explicitly given, constant is assumed.

It does not explicitly mention the default mode and object class for impure function. We take mode in and class constant.

Answer from @JimLewis via email/reflector on 26.11.2020: https://grouper.ieee.org/groups/1076/email/msg01358.html

Hi Abhijit,
I agree with your analysis. It was an oversight. It is hard to do some of this since we did not have a parser to check code that is compliant with the new standard, but not previous versions.

Luckily the packages are now open source and we can update things like this in the repository for all vendors in a timely fashion.

It is a holiday here in US, so I will do this based on what I remember.

The only object currently allowed to hold an access value is a variable. Since parameter defaults are not explicitly stated for impure functions, they must follow what is already defined for pure functions.

I would have to check on the mode rules for access types, but if they match protected types (and I suspect that the do) then the parameter mode should be inout.

Hence, the function declaration needs to be modified to be:

  impure function TO_STRING (variable call_path : inout CALL_PATH_VECTOR_PTR; Separator
  : STRING := "" & LF ) return STRING;

Can someone who is not on holiday today file this as an issue in GitLab against the open source code (and not the LRM).

Lars has been asking the WG to wake up and do some other activities on the packages. Might as well as do those and these at the same time. We might have to find a time where Lars can attend meetings since he has been coordinating the code maintenance efforts.

Best Regards,
Jim

Edited by umarcor
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information