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 Request: Add Support for Input Filelist Option #4456

Open
tarik-ibrahimovic opened this issue Jun 15, 2024 · 8 comments
Open

Feature Request: Add Support for Input Filelist Option #4456

tarik-ibrahimovic opened this issue Jun 15, 2024 · 8 comments

Comments

@tarik-ibrahimovic
Copy link

tarik-ibrahimovic commented Jun 15, 2024

Currently, Yosys requires specifying each file individually in the command line or script for synthesis or formal analysis. This can be cumbersome for large projects with many files. I propose the addition of an input filelist option, where Yosys can read a file containing a list of Verilog source files to be included in the synthesis run. This feature would streamline the process, especially for larger projects or those with many dependencies.

@chili-chips-ba
Copy link

chili-chips-ba commented Jun 16, 2024

... -f <filelist> option is typical for simulators. Verilator also has it, which then naturally ties into Yosys Formal Verification side.

Our project is currently using a simple script to bridge this gap from straight filelist to a Makefile list.

@Ravenslofty
Copy link
Collaborator

Well, the most literal interpretation of this isn't possible:

    -f frontend
        use the specified frontend for the input files on the command line

and I use -f verilog quite frequently, so I'm going to take the liberty of removing the specific flag suggestion.

@Ravenslofty Ravenslofty changed the title Feature Request: Add Support for Input Filelist -f Option Feature Request: Add Support for Input Filelist Option Jun 30, 2024
@whitequark
Copy link
Member

It sounds to me that the functionality is already provided in read -f command, via Verific: https://yosyshq.readthedocs.io/projects/yosys/en/latest/cmd/verific.html.

@chili-chips-ba
Copy link

chili-chips-ba commented Jun 30, 2024

Verific is indeed great, and also used within many proprietary tools, including Vivado. It is however not opensource.

  • Should then the reference to it be looked at as a suggestion that the -f support is made available only for the non-free Yosys tier?!

BTW, while Verific (unfortunately 😢) seems the only Yosys recourse for proper SV support, the -f seems too tiny of a target for the lofty gun that Verific is.
image

@whitequark
Copy link
Member

If someone implements the read -f functionality in the open source codebase (which any interested party can simply submit a PR for), they should take care to be compatible with the Verific syntax, since (as far as I can tell) that's where the syntax definition comes from. I.e. it is not merely a list of files but rather a specific language.

@chili-chips-ba
Copy link

chili-chips-ba commented Jun 30, 2024

@Ravenslofty any suggestions on a better suggestion?

Would -F make sense?

Let's note that -v and -y are also liberally used and, since de-facto standard for simulation tools, would be nice to support in Yosys too.

@Ravenslofty
Copy link
Collaborator

-F is available, yes.

I'd be happy to try to find a quick workaround. Is your intention to re-use this file for other commands, like to pass to a simulator?

@chili-chips-ba
Copy link

Yes.

A typical part of the Reuse Methodology is to have one-and-only-one filelist that brings in all RTL files of the entire design, or an IP block. This filelist is then used for all downstream tools that process the design RTL, from Linter on.

Note that -f is typically nested and hierarchical in the sense that the filelist that represents higher-level designs can -f into itself a list that represent an IP component, which may also -f a list of smaller building blocks...

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

4 participants