vendor_simulate logic for debug flag is not ideal

[dbee-lumacron]

I was very impressed when using the generic on RunTest that I could set a generic that was not on a top-level entity. However, I was dismayed to find out that it didn't work when I tried to run in CLI/batch mode. I figured that it may be because I only SetInteractiveMode when I'm in GUI mode, so I tried SetDebug prior to runTest for by batch run. However, this had no effect when I re-ran.

After doing some digging, I can see that Debug is ignored if we've got NoGui. In at least Questasim's case, the +acc flag gives design visibility that was allowing me to set generics that were not top level.

OSVVM-Scripts/VendorScripts_Siemens.tcl

Line 310 in efeea2a

if {($::osvvm::NoGui) || !($::osvvm::Debug)} {

I also suspect that if I had external aliases set up to dive deep into the hierarchy, I might need debug visibility (I haven't tried).

I believe this user experience can be improved, it's not ideal to have an explicit setting (SetDebug) ignored, resulting in behaviour mismatch between GUI runs and batch runs.

I accept that a reasonable default for Debug is false for NoGui, but I believe that is already the default. I don't see what the gain is to enforce a check for NoGui at the vendor simulate stage.

If I've told the simulator to have debug visibility via SetDebug, I don't think OSVVM should disallow this.

If we really want the default behaviour to ignore Debug if NoGui, then we should add user feedback / warnings / errors when they try to SetDebug.

However, I think we should instead change the default behaviour to respect the Debug flag, regardless of GUI mode. We should then give a warning when NoGui, indicating that simulation will be slower and take up more memory etc.

I have a simple workaround to just wire that generic up to lop level. Perhaps I could also manually provide the +acc option as an argument.

P.S. the PDF documentation for RunTest was out of date and didn't mention that I can give [generic ] as an option.

[JimLewis]

Hi Daniel
Thanks for the issue report.

One easy thing you can do is:
SetExtendedSimulateOptions "+acc"

To keep your scripts generic, you could turn this on only when running Questa in your OsvvmSettingsLocal.tcl. See OsvvmSettings_user_guide.pdf for how this file works and where it goes. The format for this in Tcl is below. This is something from my settings file as I like turning on -quiet so it prints less.

namespace eval ::osvvm {
# . . . 
    if {($ToolVendor eq "Siemens") || ($ToolVendor eq "Aldec")} {
      SetExtendedAnalyzeOptions  "-quiet"
      SetExtendedSimulateOptions "-quiet"
    } 
# . . .
}

If you just want this for one RunTest, break out your RunTest as shown below. Unfortunately for other reasons, RunTest does not pass its last argument down to simulate.

# RunTest T1.vhd [generic g1 gvalue]
analyze T1.vhd
simulate T1.vhd [generic g1 gvalue] "+acc"

If we really want the default behaviour to ignore Debug if NoGui, then we should add user feedback / warnings / errors when they try to SetDebug.

However, I think we should instead change the default behaviour to respect the Debug flag, regardless of GUI mode. We should then give a warning when NoGui, indicating that simulation will be slower and take up more memory etc.

I think I agree with this. The 2025.06 release is almost done (release expected late June/early July). I like running with something like this in my own environment and testing it to see if there are any unexpected side-effects for a little bit of time before including it in a release. It would help if you removed the check in your VendorScripts_Siemens.tcl and reported back if there were any issues in removing it.

The VendorScripts_Siemens.tcl settings for simulation are due for an upgrade. I would like to see a boost in performance in Questa. It may require keeping the old version for older simulator versions and creating a new one. This is not difficult to handle in the scripts since we have access to the version information.

There are other options here too, such as below. Any thoughts on these?

• Turn on "+acc" any time generics are set
• Have a global setting that tells the simulator to turn on +acc when generics are set.
• Have a setting that applies to the next simulation that turns on +acc when generics are set.

I have a simple workaround to just wire that generic up to lop level. Perhaps I could also manually provide the +acc option as an argument.

Hopefully the above works well for you and you don't have to go to that effort.

P.S. the PDF documentation for RunTest was out of date and didn't mention that I can give [generic ] as an option.

Thanks for this. I have edited the documentation and it will be updated in 2025.06.

Cheers,
Jim

[dbee-lumacron]

Many thanks for the quick reply Jim!

One easy thing you can do is: SetExtendedSimulateOptions "+acc"

This is a good workaround too, I really appreciate the snippet for making it tool-specific.

If we really want the default behaviour to ignore Debug if NoGui, then we should add user feedback / warnings / errors when they try to SetDebug.

However, I think we should instead change the default behaviour to respect the Debug flag, regardless of GUI mode. We should then give a warning when NoGui, indicating that simulation will be slower and take up more memory etc.

I think I agree with this. The 2025.06 release is almost done (release expected late June/early July). I like running with something like this in my own environment and testing it to see if there are any unexpected side-effects for a little bit of time before including it in a release. It would help if you removed the check in your VendorScripts_Siemens.tcl and reported back if there were any issues in removing it.

I changed it to the following and it seemed to work ok (in my limited set of tests, ran Osvvm DemoTests and my current test suite). Note we still want to keep SiemensSimulateOptions because it has -batch stuff for running in CLI.

  set SimulateOptions $::osvvm::SiemensSimulateOptions

  if {$::osvvm::Debug} {
    set SimulateOptions [concat $SimulateOptions "-voptargs=$::osvvm::DebugOptions"]
  }

There are other options here too, such as below. Any thoughts on these?

• Turn on "+acc" any time generics are set
• Have a global setting that tells the simulator to turn on +acc when generics are set.
• Have a setting that applies to the next simulation that turns on +acc when generics are set.

I think this would work, however when the generics are at the top level, you don't need +acc for the additional visibility. So users may complain for the cases where a simple top-level generic would suffice, they don't want to add +acc overhead. Perhaps a note/warning by default saying that to add additional visibility for generics, please use SetDebug true or something. When I ran my testsuite with +acc, I noticed ~40% increase in time taken, so having Debug as default doesn't seem ideal.

If we assume we'll need debug as the most common usecase, then we could provide an override to turn it off.
But it feels like a clunky workaround

set myGeneric [generic gg wp]
SetDebug false; # overwrite default debug true 
RunTest myTest.vhd $myGeneric

#vs 
SetDebug true; # once at the start of the script
RunTest myTest.vhd [generic gg wp]

# possibility?
RunTest myTest.vhd [genericNoDebug gg wp]

Note, even though I use a configuration as the 'top', I can still use the TestHarness generic without requiring +acc, but I couldn't use my ControlEntity generic without +acc.

Another potential problem that may be specific to Modelsim/Questa, we have two different syntaxes for generics. -g or -G. I can see that OSVVM uses the lowercase version, but the two have quite similar but different behaviours that both could be misunderstood to mean osvvm::generic. Perhaps a flag to generic could be added, if this is a common usecase across tools. Otherwise, I think having a simulator specific extendedSim option is totally fine.

Perhaps even a [genericOverride gg wp] which results in -G.

I haven't played around with this a lot, but, in my TestHarness, my CtrlE had a component declaration that included the generic with a default value. -g did not work because questa thinks I'm writing to it, even though I didn't actually assign the generic. I had to use -G or remove the generic from the component declaration. I hesitate from suggesting -G should be the default, mostly from lack of experience and the worry you'd unintentionally overwrite a generic deeper in the design than you intended.

Questa User Manual Snippet:

(optional) Same as -g (see above) except that -G also overrides generics/parameters that received explicit values in generic maps, instantiations, or from defparams.
This argument provides the only way for you to alter the generic/parameter, such as its length, (other than its value) after the design has been loaded.
Lastly, you can use this argument to override parameters for boundary elements.