I’m working on upstreaming a small set of Verific-related frontend options
that already exist in a downstream fork and are used to control Verific
elaboration behavior.
The changes are intentionally scoped and independent, and include options
such as:
disabling translate_off/on handling
relaxed checking
relaxed file extension and library extension handling
explicit module ignore lists
VHDL default library path configuration
optimization
My intent is to upstream these as a series of small, self-contained PRs
(one option per PR), without changing default behavior unless an option
is explicitly used.
I wanted to align with maintainers on:
whether this general direction is acceptable upstream
whether splitting these into individual PRs is preferred (vs batching)
any concerns about exposing these controls via the verific frontend
Think we can agree that some features here are and can be useful for different use cases, but it would be good to have a different user interface for these new options. Main issue is that if we keep adding them it will become much harder to track options availability and also how to use them from user side.
We talked about this internally and think that similarly to “cfg” option that sets Verific internal flags, “set” option could be created, that would allow setting certain Yosys-Verific option to a specific value, also then it could be possible to check what values have been set by default and change them. It would require creating dict of known “set” options and default values (some may be on/off but some require strings) but existance of each option (and it’s implementation) may depend of compile flags.
Right now (with code you have provided) options are usable only in specific run, since “veri_file” will reset to defaults after import, but others are general flags, so it may be confusing for user why some things work after import and some don’t.
For “relaxed file extension and library extension handling” part my main concern is that options are very specific for Silimate usecase so making this more generic and allowing user to provide comma separated list of extensions instead could have more general use.
So what I would suggest is for you is creating new PR with proposed general interface and as examples options in it adding translate and relaxed file ext options for example (just since they are simple but require different parameter types), and when we agree about interface porting the rest should be trivial.
Based on your suggestion, I’ll proceed by preparing a new PR that introduces
a general verific -set <option>=<value> interface, including:
a small registry of known options with default values
basic type handling (e.g. boolean and comma-separated lists)
compile-time guarding where appropriate
As examples, I’ll port only a minimal subset (e.g. translate handling and a
generic relaxed file extension option) to validate the interface before
touching the rest.
Please let me know if this approach sounds good or if there are additional
constraints I should keep in mind.
Think it is sufficient for start, but probably registry of known options should also include description that can be later shown in help call. Other than that, no additional comments for now.