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

Fix some Vivado issues (SystemVerilog support, space in file name, environment variable) #871

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

oscargus
Copy link
Contributor

@oscargus oscargus commented Nov 7, 2022

Closes #686
Closes #796
Closes #811

Not sure where it can be tested. Didn't really find a test file for vivado.py?

The vivado module is not in the documentation? So not really clear where I should document the environment variable. (But I can improve the documentation for run_vivado.

@oscargus oscargus force-pushed the vivadofixes branch 2 times, most recently from f87ce3e to 56ee9ad Compare November 7, 2022 11:57
@LarsAsplund
Copy link
Collaborator

Yes, please do something about the documentation. vivado.py started out more as an example as we generally do not maintain tool integrations other than what's related to simulators and we generally do not document the examples that much. Since this is becoming more than just an example I suggest that it also gets some documentation.

@oscargus oscargus force-pushed the vivadofixes branch 3 times, most recently from fbd9cbf to 746b483 Compare November 7, 2022 14:53
@oscargus
Copy link
Contributor Author

oscargus commented Nov 7, 2022

Now there is some sort of documentation for the functions in the module. Located at the bottom of the "Documentation" section (below "Examples").

@oscargus oscargus force-pushed the vivadofixes branch 2 times, most recently from 4f457d8 to 30d9da6 Compare November 7, 2022 18:41
@oscargus
Copy link
Contributor Author

oscargus commented Dec 2, 2022

Sorry to bother you @LarsAsplund , but can you please see if anything else is required (or if you prefer the Vivado menu entry elsewhere).

docs/index.rst Outdated Show resolved Hide resolved
vunit/vivado/vivado.py Show resolved Hide resolved
@eine eine added this to the v4.7.0 milestone Dec 8, 2022
@eine eine modified the milestones: v4.7.0, v4.8.0, v5.0.0 Apr 19, 2023
@oscargus
Copy link
Contributor Author

Sorry for letting this slip. Will try to find some time "soon" to complete it.

@oscargus
Copy link
Contributor Author

oscargus commented Sep 9, 2023

Finally got around to this. Not sure this is exactly what you wanted, but at least a "Tool Integration" menu item and then Vivado shows up there. Not clear to me how the "dynamic menus" work and if this will be an entry there (or if that it a better solution).

@SzymonHitachi
Copy link

Hello, bump on this one @oscargus @LarsAsplund . Any chance this could get pulled into mainline? This is very useful for using with Verification IPs

Copy link
Member

@umarcor umarcor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR seems to address multiple issues in a single commit. @oscargus can you please split it into three commits so it's easier to review? It's ok to keep them in a single PR tho.

@@ -113,7 +114,7 @@
# -- InterSphinx --------------------------------------------------------------

intersphinx_mapping = {
"python": ("https://docs.python.org/3.8/", None),
"python": ("https://docs.python.org/3/", None),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This belongs to a separated PR or, at least, to a separated commit within this PR.

@@ -30,6 +30,7 @@

extensions = [
"sphinx.ext.autodoc",
"sphinx.ext.autosummary",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where is the .. autosummary:: used in the docs. Is this extension used anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are correct. I probably thought it was required for automodule at the time.

@@ -13,3 +13,5 @@
add_from_compile_order_file,
create_compile_order_file,
)

__all__ = ["run_vivado", "add_from_compile_order_file", "create_compile_order_file"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I am aware, the purpose of __all__ seems to be to reduce the number of imported elements when from <module> import * is used. However, doing so is generally considered a not good programming practice. In fact, we recently merged a PR to reduce the "catch them all" imports in VHDL (#992). Therefore, I'm not sure we want to support/enforce those kind of imports in Python.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I remember correctly: this will also make the documentation clearer, but I'll play around with it and see if it is actually the case.

for library_name, file_name in compile_order:
is_verilog = file_name.endswith(".v") or file_name.endswith(".vp")
is_verilog = file_name.endswith(verilog_file_endings)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than using .endswith, I would suggest using Pathlib's .suffix (https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.suffix) because semantically we are cheking the extension of a filename not the end of an arbitrary string. At the same time, since the tuple/list is used once only, the declaraction of the variable feels redundant. I would suggest Path(file_name).suffix in ['.v', '.vp', '.sv'].

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Part of fixing #796

with Path(file_name).open("r", encoding="utf-8") as ifile:
for line in ifile.readlines():
library_name, file_type, file_name = line.strip().split(",", 2)

if file_type not in ("Verilog", "VHDL", "Verilog Header"):
if file_type not in valid_file_types:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use a list instead of a tuple.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a concrete reason for that? I tend to go for tuples as there is a (minor) performance benefit of those.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There lines fix #796

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conceptually, I understand the tuples as an array of a fixed size, while a list is kind of expected to grow/reduce. Hence, I tend to use lists in other places of the codebase.

However, if there is a performance benefit, it is ok to use tuples here, and I will take it into account when touching other parts of the codebase. It's always nice to learn something!


print(cmd)
# shell=True is important in Windows where Vivado is just a bat file.
check_call(cmd, cwd=cwd, shell=True)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not to be done in this PR, but check_call's args parameter can be either a list of a string: https://docs.python.org/3/library/subprocess.html#subprocess.CompletedProcess.args.
I feel it would be cleaner if we managed cmd as a list, so we could append tcl_args without explicitly using " ".join. See https://docs.python.org/3/library/subprocess.html#converting-an-argument-sequence-to-a-string-on-windows.

@oscargus
Copy link
Contributor Author

I'll see what I can do in terms of splitting it. It's been a while.

str(Path(vivado_path).resolve() / "bin" / "vivado")
if vivado_path is not None
else environ.get("VUNIT_VIVADO_PATH", "vivado")
)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is easier to comment line by line.

This line introduces the environment variable (documented above).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixes #811

if vivado_path is not None
else environ.get("VUNIT_VIVADO_PATH", "vivado")
)
cmd = f'"{vivado}" -nojournal -nolog -notrace -mode batch -source "{Path(tcl_file_name).resolve()}"'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This gets rid of redundant str in f-string and quotes the location of vivado (in case of spaces).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and below fixes #686

if tcl_args is not None:
cmd += " -tclargs " + " ".join([str(val) for val in tcl_args])
cmd += " -tclargs " + " ".join([f'"{val}"' for val in tcl_args])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More quoting of stuff in case of spaces.

:param compile_order_file: Filename for to write compile-order file.
:param vivado_path: Path to Vivado install directory. If ``None``, the
environment variable ``VUNIT_VIVADO_PATH`` is used if set. Otherwise,
rely on that ``vivado`` is in the path.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better documentation related to environment variable.

:param compile_order_file: Compile-order file (from :func:`create_compile_order_file`)
:param dependency_scan_defaultlib: Whether to do VUnit scanning of ``xil_defaultlib``.
:param fail_on_non_hdl_files: Whether to fail on non-HDL files.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation of parameters/arguments.

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