Skip to content

Add support for verilog/vhdl files with custom file endings #207

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

micprog
Copy link
Member

@micprog micprog commented May 1, 2025

This PR adds support for custom file endings of vhdl, verilog, or systemverilog files. This is relevant for scripts generated directly for custom tools, e.g., to import encrypted files that have endings such as .svp, .vp, or .e (or anything else you could think of). Custom file endings can now be allocated a file type as follows:

  # Source files can have custom fileendings
  - sv: vendor/encrypted_sv_src.svp
  - v: vendor/encrypted_v_src.vp
  - vhd: vendor/encrypted_vhd_src.e

@micprog micprog requested a review from fischeti May 1, 2025 10:52
@micprog
Copy link
Member Author

micprog commented May 1, 2025

Replaces assumptions proposed in #194.

Copy link
Contributor

@fischeti fischeti left a comment

Choose a reason for hiding this comment

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

LGTM! The only suggestion I have is that the new keys sv, v and vhd could be nested instead of being equal to files. For instance, something like this would make a bit more sense to me:

sources:
  # Individual source files are simple string entries:
  - src/package.sv
  - src/file1.vhd
  - src/file2.vhd

  # Source files can be grouped:
  - files:
      - src/stuff/pkg.sv
      - src/stuff/top.sv
      - sv: vendor/encrypted_sv_src.svp
      - v: vendor/encrypted_v_src.vp
      - vhd: vendor/encrypted_vhd_src.e

Comment on lines +278 to +279
// /// A SystemVerilog file.
// SystemVerilog,
Copy link
Contributor

Choose a reason for hiding this comment

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

Can be removed?

@micprog
Copy link
Member Author

micprog commented May 5, 2025

LGTM! The only suggestion I have is that the new keys sv, v and vhd could be nested instead of being equal to files. For instance, something like this would make a bit more sense to me:

sources:
  # Individual source files are simple string entries:
  - src/package.sv
  - src/file1.vhd
  - src/file2.vhd

  # Source files can be grouped:
  - files:
      - src/stuff/pkg.sv
      - src/stuff/top.sv
      - sv: vendor/encrypted_sv_src.svp
      - v: vendor/encrypted_v_src.vp
      - vhd: vendor/encrypted_vhd_src.e

This should already be supported. The sv/v/vhd keys can be used in place of a sourcefile (or a sourcegroup), so even within sourcegroups we can use these keys. These sourcegroups and sourcefiles can be nested hierarchically as desired. Let me know if this doesn't work for you, or do you want to exclude the option of providing a format-specific file at the top hierarchy?

@fischeti
Copy link
Contributor

fischeti commented May 7, 2025

This should already be supported. The sv/v/vhd keys can be used in place of a sourcefile (or a sourcegroup), so even within sourcegroups we can use these keys. These sourcegroups and sourcefiles can be nested hierarchically as desired. Let me know if this doesn't work for you, or do you want to exclude the option of providing a format-specific file at the top hierarchy?

Ah no that's already enough. I think I got the impression from the code that sv etc. are on the same level as files. But in that case LGTM!

@fischeti fischeti self-requested a review May 7, 2025 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants