Skip to content

Make run_vtr_task/run_vtr_flow/config.txt all support directories with multiple files per benchmark #1774

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
vaughnbetz opened this issue Jun 10, 2021 · 3 comments
Assignees

Comments

@vaughnbetz
Copy link
Contributor

Right now the script infrastructure for regtests, running suites of designs etc. in vtr assumes each benchmark consists of one file. We're slightly weakening that by allowing .vh include files, but it would be good to allow benchmarks to include an arbitrary list of files as that is usually how they are created. Right now we have to concatenate all the hdl into one big file, purely for script convenience.

Proposed Behaviour

Allow run_vtr_task, run_vtr_flow and config.txt to all take an argument of either:

  • a single benchmark hdl file (e.g. ch_intrinsics.v) or
  • a circuit_directory/filelist.txt (e.g. ch_intrinsics/filelist.txt). filelist.txt would specify the names of the source hdl files, within that directory. The circuit name would be given by the circuit_directory in this case, and that would be the default name for the output files etc.
  • I am not sure how Odin-II would handle this; I believe it can already take a list of files, in which case this wouldn't require changes to Odin-II. @sdamghan : can you confirm that?

Current Behaviour

Right now, after a benchmark circuit is created (usually in multiple hdl files) they have to all be concatenated into one big file before putting into the vtr regtest/qor suites. That makes the benchmark structure less than ideal if we want to later change it more.

Possible Solution

See above.

Context

Having to concatenate everything hasn't caused huge problems, but it is annoying if the design is "live" and being modified by a developer rather than just used to test the CAD tools.

Copy link

github-actions bot commented May 9, 2025

This issue has been inactive for a year and has been marked as stale. It will be closed in 15 days if it continues to be stale. If you believe this is still an issue, please add a comment.

@github-actions github-actions bot added the Stale label May 9, 2025
Copy link

This issue has been marked stale for 15 days and has been automatically closed.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale May 25, 2025
@vaughnbetz
Copy link
Contributor Author

I think this would be good to discuss at a future VTR meeting ... re-opening and put @AlexandreSinger and @jgoeders as owners for now so we can discuss.

@vaughnbetz vaughnbetz reopened this May 25, 2025
@github-actions github-actions bot removed the Stale label May 26, 2025
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

No branches or pull requests

3 participants