Skip to content

[BUG] False warning when mapping generic function in entity instantiation #379

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nselvara opened this issue Apr 25, 2025 · 2 comments · May be fixed by #382
Open

[BUG] False warning when mapping generic function in entity instantiation #379

nselvara opened this issue Apr 25, 2025 · 2 comments · May be fixed by #382
Labels
bug Something isn't working VHDL Relates to the language front-end for VHDL

Comments

@nselvara
Copy link

nselvara commented Apr 25, 2025

Bug description:

Hi there,
Stemming from this related issue: #378

I’m getting the following warnings from VHDL LS when using a generic function (such as rising_edge or falling_edge) in a generic map:

  • No declaration of 'active_spi_edge' vhdl ls(unresolved) (left side of the =>)
  • Could not resolve 'rising_edge' vhdl ls(unresolved) (right side of the =>)
  • Missing association of signal 's' : in (right side of the =>)

This happens when a function is passed via a generic map - which should be valid VHDL according to synthesis documentation.
See: Functions in Generics – Xilinx UG901

Expected behaviour:
The analyser should accept passing a function to a generic map without warning. This is supported VHDL and is synthesised correctly by tools like Vivado.

Thanks yaa!

Screenshots:

Image

Image


Minimal reproducible example (MRE):

generic_clk_edge_function_warning:

library ieee;
use ieee.std_logic_1164.all;

entity generic_clk_edge_function_warning is
    generic (
        -- Function when generic mapped, which triggers the warning
        function active_edge(signal s: std_ulogic) return boolean
    );
    port (
        clk: in std_ulogic;
        data_out: out std_ulogic
    );
end entity;

architecture behavioural of generic_clk_edge_function_warning is
    signal internal_signal: std_ulogic := '0';
begin
    process (clk)
    begin
        if active_edge(clk) then  -- Trigger: function call via generic
            internal_signal <= not internal_signal;
        end if;
    end process;

    data_out <= internal_signal;
end architecture;

generic_clk_edge_function_warning_wrapper:

library ieee;
use ieee.std_logic_1164.all;

entity generic_clk_edge_function_warning_wrapper is
    port (
        clk: in std_ulogic;
        data_out: out std_ulogic
    );
end entity;

architecture behavioural of generic_clk_edge_function_warning_wrapper is
begin
    generic_clk_edge_function_warning_inst: entity work.generic_clk_edge_function_warning
        generic map (
            active_edge => rising_edge
--              ^                ^         Warnings reported here: `No declaration`..,  `Could not resolve`... & `Missing association...`
        )
        port map (
            clk => clk,
            data_out => data_out
        );
end architecture;

EDIT:

  • I've updated the MRE, as user @gco-bmx pointed out. But I also included the actual entity that has the definition of generic_clk_edge_function_warning which was defined in the aforementioned issue - so one can copy paste it directly.
  • Updated the error messages
  • Added some screenshots
@gco-bmx
Copy link

gco-bmx commented Apr 26, 2025

I'm assume the MRE is a mistake?
a function can't be passed to a port map,
a function can be passed to a generic map
(as per the attatched link)
I assume it should be something like?

generic_clk_edge_function_warning_inst: entity work.generic_clk_edge_function_warning
        generic map (
            active_edge => rising_edge
        )
        port map(
            clk => clk,
            data_out => data_out
        );

@nselvara
Copy link
Author

nselvara commented Apr 26, 2025

Ahh yess, my mistake, you're right. This also didn’t work for me though. I quickly created this MRE from my actual model, which I unfortunately can't share.

EDIT: I've updated the MRE, as user @gco-bmx pointed out.

@Schottkyc137 Schottkyc137 linked a pull request May 4, 2025 that will close this issue
@Schottkyc137 Schottkyc137 added bug Something isn't working VHDL Relates to the language front-end for VHDL labels May 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working VHDL Relates to the language front-end for VHDL
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants