Named associaton in function calls

[embediver]

First of all, I'm a total beginner at VHDL (my code is only for learning purposes till now) and this might be a limitation I'm not aware of.

Description

When calling a function, using named association seems to be buggy. Doing a straight signal association doesn't seem to be a problem, but specifically ranges won't work correctly.

Expected behaviour When, for example, using a subrange of a bit_vector as a function parameter, beeing able to specify the corresponding function signal (with range).

How to reproduce? Following is a working example which demonstrates the first of the two bugs I encountered. As shown A(3 downto 0 => A(3 downto 0) throws a exception when analyzing.

use work.pack_RC_Add_n_F.all;

entity RC_Add_n_F is
    generic(n : natural := 4);
    port(A, B : in bit_vector(n-1 downto 0); Cin: in bit; Sum: out bit_vector(n-1 downto 0); Cout: out bit);
end RC_Add_n_F;

architecture Arch_RC_Add_n_F of RC_Add_n_F is
    signal result: bit_vector(n downto 0);
begin
    -- result <= RC_Add_n(A(3 downto 0), B, Cin);                               Works
    -- result <= RC_Add_n(A => A(3 downto 0), B => B, Cin => Cin);              Works
    result <= RC_Add_n(A(3 downto 0) => A(3 downto 0), B => B, Cin => Cin);     -- Throws exception when analyzing
    Sum <= result(n-1 downto 0);
    Cout <= result(n);
end Arch_RC_Add_n_F;

package pack_RC_Add_n_F is
    function RC_Add_n( A, B :bit_vector; Cin : bit) return bit_vector;
end pack_RC_Add_n_F;

package body pack_RC_Add_n_F is
    function RC_Add_n( A, B :bit_vector; Cin : bit) return bit_vector is
        variable C:bit := Cin;
        variable SUM:bit_vector(A'length downto 0);
    begin
        loop_add_m: for I in 0 to A'length-1 loop
            SUM(I) := (A(I) xor B(I)) xor C;
            C := (A(I) and B(I)) or (C and (A(I) xor B(I) ));
        end loop loop_add_m;
        SUM(A'length) := C;
        return SUM;
    end RC_Add_n;
end pack_RC_Add_n_F;

ghdl -a rcaddfn.vhd ent.vhd

Second bug: In a other exercise I did, the following function call causes some problems: Accv(8 downto 4) := RC_Add_n(A(3 downto 0) => Acc(7 downto 4), B => Mcand, Cin=> '0'); Which throws following error when running that code. error: slice direction doesn't match index direction at mult4x4_2.vhd:42

The second example mainly was the usecase where I wanted to use this notation. Since this is really similar to the first example it surprised me that the error is different and it's probably not only my lack of skill.

Context Please, provide the following information:

• OS: Fedora 33 (Workstation Edition)
• Origin:
  • [x] Package manager

    GHDL 1.0-dev () [Dunoon edition]
    Compiled with GNAT Version: 10.2.1 20200804 (Red Hat 10.2.1-
    GCC back-end code generator

If a GHDL Bug occurred block is shown in the log, please paste it here:

******************** GHDL Bug occurred ***************************
Please report this bug on https://github.com/ghdl/ghdl/issues
GHDL release: 1.0-dev () [Dunoon edition]
Compiled with GNAT Version: 10.2.1 20200804 (Red Hat 10.2.1-
Target: x86_64-redhat-linux
/mnt/srvmarvin/Studium/Master/Entwicklung Integrierter Systeme/vhdl_projects/rcaddfn/
Command line:
/usr/libexec/gcc/x86_64-fedora_ghdl-linux/10/ghdl1 --ghdl--std=93c -P/usr/lib/ghdl/ieee/v93/ -P/usr/lib/ghdl/ -quiet -o rcaddfn_ent.s rcaddfn_ent.vhd
Exception TYPES.INTERNAL_ERROR raised
Exception information:
raised TYPES.INTERNAL_ERROR : vhdl-errors.adb:32
Call stack traceback locations:
0x6a489d 0x6fbcf3 0x6fc1c8 0x6feb5c 0x6ff22d 0x6f6134 0x7a05ca 0x7313bc 0x642098 0xbd4e82 0x637fa1 0x64711d 0x7a0aa9 0x635c84 0x7fda2c65d1e0 0x63cf5c 0xfffffffffffffffe
******************************************************************

[tgingold]

Do you have a reproduction for the second bug ? In particular how Acc is declared.

[embediver]

First thanks @tgingold for the fast response!

Folow up: I did a build of the latest master commit (009f0b955b5084594b6912d261405fd1936750f9) and tried my example again. As expected this fixed the exception when analysing.

But now I get the exact behaviour described for the second bug when running the provided example.

For completion, following is the exact output when running ghdl -r RC_Add_n_F:

ghdl:error: slice direction doesn't match index direction at rcaddfn_ent.vhd:13
in process .rc_add_n_f(arch_rc_add_n_f).P0
  from: process work.rc_add_n_f(arch_rc_add_n_f).P0 at rcaddfn_ent.vhd:13
ghdl:error: simulation failed

If desired I can also open a new Issue for this.

[tgingold]

Yes, please open a new issue with a reproducer.