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

[KrzysztofZyla]

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]

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]

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]

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]

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]

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.