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

Dependency scanning missing package dependencies #884

Closed
barri opened this issue Jan 5, 2023 · 1 comment
Closed

Dependency scanning missing package dependencies #884

barri opened this issue Jan 5, 2023 · 1 comment

Comments

@barri
Copy link
Contributor

barri commented Jan 5, 2023

I've had this bug report lying around since the 18th November of 2020 so this might've been fixed. If that's the case then just trash this issue. The version of VUnit used was fairly updated as of the writing of the bug report.

VUnit in combination with Questa simulator seem to miss package depencies.

The issue occurs when you have a package in a different library than the using entity/package.

If you only use full path references when using the functions in the package without having a use-clause, the dependency is not picked up.

This will cause a compilation error when the using package/entity is compiled before the dependency.

A code example explains it better than text.

Library foo:

Package foo_pkg is

  Procedure p_foo (constant p : in string);

End package;

 

Package body foo_pkg is

  Procedure p_foo (constant p : in string) is

  Begin

    Report p;

 End procedure;

End package body;

 

Library bar:

Library foo;

 

Package bar_pkg is

  Procedure p_bar(constant p : in string);

End package;

 

Package body bar_pkg is

  Procedure p_bar(constant p : in string) is

  Begin

   -- This is not picked up as a dependency

    Foo.foo_pkg.p_foo(p)

  End procedure;

End package body;
@LarsAsplund
Copy link
Collaborator

Correct, this is one of the simplifications we have made to avoid falling too deep into the VHDL parsing rabbit hole. The workaround is to add use foo.foo_pkg; to bar_pkg. In the future we may switch to using some external and fast open source parser that will support this. Parser requests unlikely to be solved unless that happens (like this one) are closed and collected in #1080.

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