Wrong mapping of overloaded functions in Quartus 24.1 Pro

[c-thaler]

Hi,

I'm stuck with a weird error in the new Quartus 24.1.0 Build 115 SC Pro Edition.

I defined two functions with the same name but a different signature:

pure function from_my_bool_a(data : in my_bool_at) return std_logic_vector is
    variable res_v : std_logic_vector(data'length*1-1 downto 0);
  begin
    res_v := (others => '0');
    for idx4_v in data'range loop
      res_v(idx4_v) := data(idx4_v);
    end loop;
    return res_v;
  end function;
  
  pure function from_my_bool_a(data : in my_bool_at; size : in integer) return std_logic_vector is -- line 27: warning occurs here
    variable data_v : std_logic_vector(size-1 downto 0);
  begin
    data_v := (others => '0'); -- line 30: error occurs here
    data_v(0 downto 0) := from_my_bool_a(data);
    return data_v;
  end function;

I use one of them to connect a std_logic_vector signal to the output of a module like this:

U_MODULE: entity work.module
    generic map (
		port_width => port_width
	 )
	port map (
		in_a(0) => a,
		from_my_bool_a(out_b) => b
	);

When compiling, this leads to the following warning and error:

Warning(16759): VHDL warning at top_level.vhd(27): formal port or parameter "size" has no actual or default value 
Error(13736): VHDL aggregate error at top_level.vhd(30): OTHERS choice used in aggregate for unconstrained record or array type is not supported 

It seems that Quartus tries to use the function with the additional size parameter here. Which is wrong in my oppinion.
Strangely, the project compiles fine when I change the order in which I define the two functions.

What's wrong here? Is this a compiler bug?

I added a minimal working example to this post.

[sstrell]

Perhaps this is a solution for you: https://community.intel.com/t5/Intel-Quartus-Prime-Software/VHDL-Function-Overloading-not-working/m-p/1326672

[c-thaler]

Thanks for the link. But I think this won't apply here since the functions have a distinct signature. One has two arguments, the other has only one. It is not an ambigious function call.

[ShengN_Intel]

Hi,

The problem at line 28 variable data_v : std_logic_vector(size-1 downto 0); where the size can't fetch a proper value which cause the unconstrained array type issue.

At lines 11 and 27:

pure function from_my_bool_a(data : in my_bool_at; size : in integer) return std_logic_vector

swap the data : in my_bool_at and size : in integer like below:

pure function from_my_bool_a(size : in integer; data : in my_bool_at) return std_logic_vector;

The synthesis will pass.

Thanks,

Regards,

Sheng

[c-thaler]

Thanks for the workaround. But I'm afraid I cannot apply it in my case.

Almost all types in my project and the conversion functions like from_my_bool_a are generated by a code generation tool. So I cannot simply change the parameter order.

BTW: The same code works flawlessly with Quartus 22.1 Standard. That is why I am suspecting a problem with the compiler.

[c-thaler]

I now use the following workaround:

I defined an additional signal with the same type as the module output port.
The conversion is then done in a separate assignment outside of the entity instantiation.

architecture RTL of top_level is
  signal sig_out_b : my_bool_at(port_width-1 downto 0);
begin
  U_MODULE: entity work.module
    generic map (
		port_width => port_width
	 )
	port map (
		in_a(0) => a,
		--from_my_bool_a(out_b) => b
		out_b => sig_out_b
	);
	b <= from_my_bool_a(sig_out_b);
end architecture;

Now Quartus selects the correct function.

[ShengN_Intel]

Hi,

I had done testing in Quartus Standard version. This mostly like a legit bug, will report to internal team for debugging.

Thanks,

Regards,

Sheng

[c-thaler]

Ok, understand. Thanks for reporting it Sheng. For now, I will continue with the workaround.

[sstrell]

It may not be a bug.  Pro follows the IEEE rules for HDL languages much more strictly than Standard.  This could be one of those instances.

[c-thaler]

I don't think that's the case here. The IEEE VHDL93 standard says that in an ambiguous case (when it's not clear which overloaded function applies) it's considered an error. (But the above error is about OTHERS used with an unconstrained array type).
In my case, however, it is clear which function applies.

Also, I'm sure the order of the functions' definitions shouldn't determine which one applies. But it does. It seems that the most recently defined function is always the one that is applied. If I change the order of the definitions of the two from_my_bool_a functions, everything works fine.

I think this can be a really nasty thing in development. This behaviour can cause an FPGA implementation to behave differently than a RTL simulation or ASIC implementation.