Skip to content
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

[Feature] Make check_equal a generic procedure #1030

Open
nselvara opened this issue Jun 17, 2024 · 5 comments
Open

[Feature] Make check_equal a generic procedure #1030

nselvara opened this issue Jun 17, 2024 · 5 comments

Comments

@nselvara
Copy link

nselvara commented Jun 17, 2024

Hey there, I thought to make the testing even more powerful. I'd suggest to make check_equal a generic procedure in order to make it easier to define a new one for any other type.

Suggested code:

package example_pkg is
    procedure check_equal_generic
        generic (
            type type_t;
            function to_string(data: type_t) return string
        )
        parameter (
            got: in type_t;
            expected: in type_t;
            msg: in string := check_result_tag;
            level: in log_level_t := null_log_level;
            path_offset: in natural := 1;
            line_num: in natural := 0;
            file_name: in string := ""
        );

    type test_t is (st_1, st_2);
    procedure check_equal is new check_equal_generic generic map (type_t => test_t, to_string => to_string); -- to_string is implicitly defined
end package;

package body example_pkg is
    -- Overloaded generic check_equal procedures for custom checks
    procedure check_equal_generic
        generic (
            type type_t;
            function to_string(data: type_t) return string
        )
        parameter (
            got: in type_t;
            expected: in type_t;
            msg: in string := check_result_tag;
            level: in log_level_t := null_log_level;
            path_offset: in natural := 1;
            line_num: in natural := 0;
            file_name: in string := ""
        )
    is
        constant checker: checker_t := default_checker;
    begin
        -- pragma translate_off
        if got = expected then
            if is_pass_visible(checker) then
                passing_check(
                    checker,
                    p_std_msg(
                        "Equality check passed", msg,
                        "Got " & to_string(got) & "."
                    ),
                    path_offset + 1, line_num, file_name
                );
            else
                passing_check(checker);
            end if;
        else
            failing_check(
                checker,
                p_std_msg(
                    "Equality check failed", msg,
                    "Got " & to_string(got) & ". " &
                    "Expected " & to_string(expected) & "."
                ),
                level, path_offset + 1, line_num, file_name
            );
        end if;
    end;
end package body;
@LarsAsplund
Copy link
Collaborator

I think that would be interesting. Today we generate check equal subprograms for common types and we will continue to do that to support VHDL-93 and less mature VHDL-2008 implementation. However, generics could be a way of supporting custom types.

@nselvara
Copy link
Author

Ohh yeah the old version shit also exists 😫, my bad, sry.
For the argument sake, if there's time to implement also 2008 feature, I'd really appreciate that, as it would heavily reduce boilerplate code. However, I guess, maintaining 2 sets of the same function would be also pain in the ass and adds just more boilerplate code...

@LarsAsplund
Copy link
Collaborator

I don't think it would be much to maintain. It's more of a priority thing. If you want, you can give it a try. The "template" can be found in the script that generates the check equal subprograms we have today: https://github.com/VUnit/vunit/blob/master/vunit/vhdl/check/tools/generate_check_equal.py

@nselvara
Copy link
Author

nselvara commented Jun 18, 2024

Oki doki, I give it a try.

A couple of questions though:

  • generate_check_equal.py: Running this will create check.vhd, right?
  • $xy_type: Is going to be replaced by the elements of combinations tuple?
  • From a maintainability perspective, should I let this stay as it is and rename the file to something like check_1993.vhd and the new one creates a new file called check_2008.vhd.

@abaebae
Copy link
Contributor

abaebae commented Aug 28, 2024

Checks for ufixed/sfixed types do already exist

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants