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

Enhancement: Rivierapro extra vsim arguments #143

Closed
joshrsmith opened this issue Mar 8, 2016 · 7 comments
Closed

Enhancement: Rivierapro extra vsim arguments #143

joshrsmith opened this issue Mar 8, 2016 · 7 comments

Comments

@joshrsmith
Copy link
Contributor

Similar to Modelsim, it would be good to allow generic arguments to be passed through to Rivierapro simulator interface. The documentation appears to indicate that you might be able to do with with vsim_extra_args, but it does not appear that the rivierapro interface makes use of this.

@kraigher
Copy link
Collaborator

kraigher commented Mar 9, 2016

I pushed a branch where I added:
rivierapro_vcom_flags, rivierapro_vlog_flags, rivierapro_vsim_extra_args, rivierapro_vsim_extra_args.gui

Could you try it?

@joshrsmith
Copy link
Contributor Author

It appears to be working. I tested rivierapro_vsim_extra_args, rivierapro_vsim_extra_args.gui and rivierapro_vcom_flags.

One thing I noticed that could be improved in the documentation is adding an example of what the vsim extra args looks like. It is confusing because vcom options are specified as an array of options ['-opt1','-opt2'], but for vsim it appears to be specified altogether as a string "-opt1 arg -opt2"

A couple examples would clear this up.

On a related note: Is it possible to pull vsim extra arguments from the environment, such that you could have a global setting across all run.py? An example use case here would be related to licensing. Riviera defaults to using the LVT license (if available), unless you specify vsim -license lv. If not, it can easily be set on the project-level in the run.py.

@joshrsmith
Copy link
Contributor Author

The Riviera acceptance tests also pass (2015.06).

@kraigher
Copy link
Collaborator

@joshrsmith I think I will redo the options a bit such that they all are list of strings for consistency. I will also rename the old modelsim related flags and give them a prefix as well. I will have to add a deprecated alias for those for a while until a I remove them completely.

Anyway since run.py ist just a Python script you could implement that such as:

ui.set_sim_option("rivierapro_vsim_extra_args", os.environ["RIVIERAPRO_VSIM_EXTRA_ARGS"])

@kraigher
Copy link
Collaborator

@joshrsmith I have pushed an update now where I made the flags more consistent in naming and behavior.

Also BTW in rivierapro the -dbg flag to vcom is always added. This was before there where any set_compile_option and the -dbg flag is needed to be able to step through the code in the Riviera PRO gui. I would propose that we remove the -dbg flag and instead let it be up to the user to set it as a compile option if they want? I guess some users might not want the the -dbg and maybe not for all files?

@joshrsmith
Copy link
Contributor Author

I will check out the updates later today. I took a brief look at the changes and I appreciate the consistency between simulators and options!

Regarding -dbg - I use that flag a lot, but just because I use it a lot doesn't mean I want it always. If VUnit can function without it and the user can specify it manually via the public interface, then it should probably be dropped from the core code.

If you think -dbg is an important part to --gui functionality, then perhaps it could be an extra option included by default. If the user specifies any vcom arguments, then they would need to specify -dbg. If they don't specify any options, then it would be included by default. In this way there can be some "hand-holding" to get a configuration that works well with the VUnit flow by default, but ultimately the control is given to the user if they want to specify their own flags. Of course, anything that is required for VUnit to work should stay hard-coded as a simulation/compilation flag.

@kraigher
Copy link
Collaborator

I think I will remove -dbg from the pre-defined flags.

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

2 participants