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

Add possibility to use a scripts settings file that is defined inside project directory. #48

Open
KrzysztofZyla opened this issue Aug 18, 2023 · 5 comments

Comments

@KrzysztofZyla
Copy link

I'm using Riviera-Pro with ./Scripts in the installation directory. Hence I cannot alter it by creating LocalScriptDefaults.tcl inside. In general it would be nice to be able to declare a settings file per project. I have two ideas how it may be done but I'm not so sure about them as I'm no tcl expert.

  • In project directory create a settings .tcl file (based on Example_LocalScriptDefaults.tcl) and source it after "source ./Scripts/StartUp.tcl". Seems to work for some variables like VhdlLibraryDirectory, VhdlLibrarySubdirectory, but I guess that calling it after StartUp may overwrite some dependencies and lead to problems.
source ...../Scripts/StartUp.tcl
source ScriptSettings.tcl
  • Modify StartUpShared.tcl to check e.g. an env variable and load settings from the path it defines. Something like:
# Load OSVVM Defaults and then User Defaults (LocalScriptDefaults)
# Dependencies in here depend on VendorScripts_???.tcl
source ${::osvvm::OsvvmScriptDirectory}/OsvvmDefaultSettings.tcl
# Load User Settings if they exist
if {[file exists ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl]} {
 source ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl
}
# Load Settings from file pointed by env OSVVM_SCRIPTS_SETTINGS variable
if {[file exists $::env(OSVVM_SCRIPTS_SETTINGS)]} {
 source $::env(OSVVM_SCRIPTS_SETTINGS)
}

By modifying OSVVM_SCRIPTS_SETTINGS user can point to preferred settings file before calling StartUp.tcl.

I'm not sure which approach is better but for sure using a project local settings file would enhanced OSVVM scripting.

@JimLewis
Copy link
Member

I have been thinking about how to handle supporting multiple OSVVM Projects, but have not reached a final answer for yet. It is good to have some input on it.

Certainly having an environment variable, such as CURRENT_OSVVM_PROJECT_DIRECTORY would be helpful. This would allow someone to establish a default work area and maybe even CD to there before the scripts start. If someone wants to switch projects without exiting the simulator, having an API command would be helpful. A change project API command would first call the undocumented StartUp API command to reestablish all default settings and then load the new project settings. Maybe the environment variable would be read in StartUp and then StartUpShared would do the handling of it - which would facilitate changing it with ChangeProject API command.

Worry more about what you want out of the feature. I will worry about sorting out the priorities among the OSVVM packages. Keep in mind that everything done in the LocalDefaultSettings can also be done from API commands - which would be necessary if they are done later in the process than where LocalDefaultSettings is done.

I would like to be specifying a directory for OSVVM project configuration stuff rather than a file. There are a number of things I would like to put there. For example, currently we are putting the package body OsvvmScriptSettingsPkg_generated.vhd in OsvvmLibraries/Scripts. As soon as we acknowledge that projects then we need to acknowledge that different projects may want different settings. So then it would need to go there.

Soon there will be an additional configuration VHDL file. I am thinking it may be called OsvvmVersionSettings.vhd. Its purpose will be to allow someone to minimize the impact of version changes. For example, in Summer of 2021 we introduced new seed capabilities. It is activated with by an additional parameter with a default setting. The default setting was set to maintain backward compatibility - as using it will change the result of every randomization a test does. My thought then is to instead provide the default for these type of things in OsvvmVersionSettings.vhd. With project settings, we can keep the version settings with a project and in the compile scripts if the file exists, then use it rather than using the one in the OSVVM directory.

Using constants in this way may also be a good way to deal with the capability we have in OsvvmGlobalPkg in a more efficient manner. That capability allows things to be changed dynamically, but that results in unneeded overhead.

@JimLewis
Copy link
Member

JimLewis commented Aug 18, 2023

As we start thinking about Projects, we also need to think about how to select a particular OSVVM revision among multiple different installed revisions. Often a project will select a version of a library and freeze on it so that library changes will not negatively impact a project.

Maybe this is selected by the tool environment variable since the tool autoloads a particular version - however, maybe we need some flexibility - and perhaps redirection capability on this - such as the environment variable loads a release independent script (StartUp.tcl) which then looks a environment variables and loads the appropriate next layer scripts (StartUpCommon - but could be in the release area of a different version of OSVVM).

@JimLewis
Copy link
Member

It is an interesting problem as there are circular dependencies - a project for example should be able to set an OSVVM version. Somewhere in the OSVVM version it should load environment variables into settings. Newer version of OSVVM releases may use additional environment variables (hopefully not, but it needs to be accounted for in the architecture of the settings)

@KrzysztofZyla
Copy link
Author

Worry more about what you want out of the feature.

For starters the same functionality that LocalScriptDefaults.tcl gives with the ability to specify a file outside ./Scripts :)

@KrzysztofZyla
Copy link
Author

I've modified StartUpShared.tcl:

(...)
# Load OSVVM Defaults and then User Defaults (LocalScriptDefaults)
# Dependencies in here depend on VendorScripts_???.tcl
source ${::osvvm::OsvvmScriptDirectory}/OsvvmDefaultSettings.tcl
# Load User Settings if they exist
if {[file exists ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl]} {
 source ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults.tcl
}
# Simulator specific defaults
if {[file exists ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults_${::osvvm::ScriptBaseName}.tcl]} {
 source ${::osvvm::OsvvmScriptDirectory}/LocalScriptDefaults_${::osvvm::ScriptBaseName}.tcl
}

# Load Local Project Settings if they exist
if {[info exists ::env(CURRENT_OSVVM_PROJECT_DIRECTORY)]} {
 if {[file exists ${::env(CURRENT_OSVVM_PROJECT_DIRECTORY)}/ProjectScriptDefaults.tcl]} {
   source ${::env(CURRENT_OSVVM_PROJECT_DIRECTORY)}/ProjectScriptDefaults.tcl
 }
}

In my main script I set this variable before calling StartUp:

set ::env(CURRENT_OSVVM_PROJECT_DIRECTORY) design_path
source .../Scripts/StartUp.tcl

Didn't test this for all options but seems to work for those I'm using.

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