[BUG/CLARIFICATION/FEATURE] Record as generic type triggers mismatched_kinds error despite valid VHDL

[nselvara]

Bug/Clarification/Feature Request

Hi there,
Thanks again for the recent fixes in issues #348 and #379. I believe I’ve encountered a related edge case or possibly a follow-up issue.

When passing a record type as a generic, I receive the following warning: Type 'test_settings_t' may not be the prefix of a selected name [vhdl_ls(mismatched_kinds)]

As per AMD's clarification, this construct is valid VHDL. However, it seems the analyser doesn't resolve the generic type correctly and fails to trace its fields - possibly due to limitations in how generic types are resolved or internally tracked.

---

Minimal Reproducible Example (MRE)

Package:

library ieee;
use ieee.std_logic_1164.all;

package custom_types is
    type test_settings_t is record
        mode: std_ulogic;
        bits: std_ulogic_vector(2 downto 0);
    end record;
end package;

generic_record_consumer:

library ieee;
use ieee.std_logic_1164.all;
use work.custom_types.all;

entity generic_record_consumer is
    generic (
        type test_config_t -- Generic record type
    );
    port (
        config: in test_config_t;
        some_out: out std_ulogic
    );
end entity;

architecture rtl of generic_record_consumer is
begin
    process (config)
    begin
        -- Accessing record field, triggers `mismatched_kinds`
        some_out <= config.mode;
    end process;
end architecture;

Instantiation:

library ieee;
use ieee.std_logic_1164.all;
use work.custom_types.all;

entity top is end entity;
architecture test of top is
    signal my_cfg : test_settings_t := (
        mode => '1',
        bits => "000"
    );
begin
    uut: entity work.generic_record_consumer
        generic map (
            test_config_t => test_settings_t
        )
        port map (
            config => my_cfg,
            some_out => open
        );
end architecture;

[Schottkyc137]

I'm not sure this should be supported, unless I'm misunderstanding generic types in VHDL.
Once declared using

entity generic_record_consumer is
    generic (
        type test_config_t -- Generic record type
    );
end entity;

I'm not sure about the assumption that test_config_t always is a record type. May I ask what leads to this assumption? AFAIK generics in vhdl are not like C++ generics in that you need to constraint them appropriately in order to call methods.

The example you provided only shows that generics can be used as types, not that members can be used on generic types. Could you clarify this for me?

[nselvara]

I'll check tomorrow whether this compiles and simulates properly.
As far as I know, passing a generic array as a type is not allowed in VHDL, but passing records should be valid.

By the way, even if the type is generic:
Would it be possible to work around this by outsourcing the record write logic to a helper function? That way, we could abstract away operations on the generic record type.

-- Define a generic record type through a generic parameter
entity generic_record_test is
    generic (
        type record_t
    );
    port (
        rec_in : in record_t;
        rec_out : out record_t
    );
end entity;

architecture rtl of generic_record_test is

    -- This function is defined outside the entity
    -- but can be reused across generic record types
    function set_mode(input : record_t; value : std_ulogic) return record_t is
        variable temp : record_t := input;
    begin
        -- This line assumes the generic record has a field called 'mode'
        -- Some tools might reject it unless record_t is constrained
        temp.mode := value;
        return temp;
    end function;

begin
    process (rec_in)
    begin
        rec_out <= set_mode(rec_in, '1');
    end process;
end architecture;

[Schottkyc137]

I don't think this is directly possible, but you could add a generic subprogram to do the work:

library ieee;
use ieee.std_logic_1164.all;

entity generic_record_test is
    generic (
        type record_t;
        function set_mode(input : record_t; value : std_ulogic) return record_t
    );
    port (
        rec_in : in record_t;
        rec_out : out record_t
    );
end entity;

architecture rtl of generic_record_test is
begin
    process (rec_in)
    begin
        rec_out <= set_mode(rec_in, '1');
    end process;
end architecture;

library ieee;
use ieee.std_logic_1164.all;

package custom_types is
    type test_settings_t is record
        mode: std_ulogic;
        bits: std_ulogic_vector(2 downto 0);
    end record;
end package;

library ieee;

use work.custom_types.test_settings_t;
use ieee.std_logic_1164.all;

entity top is end entity;
architecture test of top is
    signal my_cfg, my_cfg_out : test_settings_t := (
        mode => '1',
        bits => "000"
    );

    function set_mode(input : test_settings_t; value : std_ulogic) return test_settings_t is
        variable temp : test_settings_t := input;
    begin
        temp.mode := value;
        return temp;
    end function;
begin
    uut: entity work.generic_record_test
        generic map (
            record_t => work.custom_types.test_settings_t,
            set_mode => set_mode
        )
        port map (
            rec_in => my_cfg,
            rec_out => my_cfg_out
        );
end architecture;

See also this stack overflow answer

In theory, there is also the function set_mode(input : record_t; value : std_ulogic) return record_t is <> syntax which was mentioned in the answer, but the correct analysis is not implemented yet in vhdl_ls.

[nselvara]

Hi, sorry that it took me so long to reply. I checked again - and you’re absolutely right. I misunderstood the generics of VHDL. 😅
Your trick with passing a generic function works perfectly. I just tested it, and everything compiles and simulates as expected.
So I think we can close this issue. At least one issue less to worry about. 😄
Thanks again for the great explanation - and sorry for any confusion I caused!