Forum Discussion
Wrong mapping of overloaded functions in Quartus 24.1 Pro
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.
9 Replies
- sstrell
Super Contributor
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
Occasional Contributor
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_altera
Super Contributor
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
Occasional Contributor
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
Occasional Contributor
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_altera
Super Contributor
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
Occasional Contributor
Ok, understand. Thanks for reporting it Sheng. For now, I will continue with the workaround.
- sstrell
Super Contributor
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
Occasional Contributor
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.