Riviera / MATLAB Cosim with OSVVM Scripting

[Brad Adam]

Hey,

So I’ve run into a bit of an issue with the usual OSVVM scripted flow and a testbench which aims to use some MATLAB cosim features. In short, I can successfully cosim if I don’t use RunTest or any of the TestName/analyze/simulate flow. In my experience the code coverage enabled via SetCoverageAnalyzeEnable/Set CoverageSimulateEnable only generates reports when using the OSVVM script commands but in this case RunTest encounters errors with the aldec_matlab_cosim.dll provided by Aldec.

I’ve referred back to the Script_User_guide documentation but I’m not seeing anything that seems to address an issue like this. Is it possible to generate the coverage reports without using the RunTest command? Or where might I find more information on the tool commands that ‘RunTest’ calls for Riviera-PRO?

If it helps, the error from riviera is:

# VHPI: Loading library ‘$ALDEC/bin/aldec_matlab_cosim.dll’
# VHPI: The target platform of the “$ALDEC/bin/aldec_matlab_cosim.dll” library cannot be identified. The library may be missing, corrupted, or its format is incorrect.
# VHPI: Could not register tasks from ‘$ALDEC/bin/aldec_matlab_cosim’ library.

Any additional insight is greatly appreciated.

[Brad Adam]

Actually, I found the RunTest code in OsvvmProjectScripts.tcl, and the best way to add additional options for this would be following Example_LocalScriptsDefaults.tcl I assume?

[Jim Lewis]

Hi Brad,
First thing to determine is what switches you need set to vcom and vsim.

If you look at the log or html log, you can determine what OSVVM is currently doing – or you can read the OsvvmProjectScripts.tcl (older releases) or OsvvmScriptsCore.tcl (renamed in 2024.05 to support future refactoring).

You can use SetExtendedAnalyzeOptions or SetVhdlAnalyzeOptions to add to what is passed to vcom. You can use SetExtendedSimulateOptions to add to what is passed to vsim.

Keep me updated as to how it goes. When you get it working, we would welcome a blog post on it.

Best Regards,
Jim

[Brad Adam]

Hey, I appreciate the insight and I actually worked my way to this action after noticing that the simulate command called vsim. I guess one more question to make sure I’m understanding these scripts correctly.

Currently, I know the following script will allow my to run my test and see the results:

SetCoverageSimulateEnable true

analyze $PATH_TO_TEST/testcase_file.vhd
vsim -dbg -t 0 -ieee_nowarn -dataset {$PATH_TO_SIM_DIR/sim} -datasetname {sim} -loadvhpi $aldec/bin/aldec_matlab_cosim.dll:ml2hdl work.testcase_file -acdb -acdb_cov sbm -cc_all

run -all

SetCoverageSimulateEnable false

I’ve generalized some of the path names and there is some setup scripted before such as building the osvvm profile and some test specific profiles. However, that above command set allows me to run the test and I can see coverage results in Riviera but no reports are generated by osvvm in the CodeCoverage directory.

If I change the above flow to the following I will encounter errors in trying to run the test:

SetExtendedSimulateOptions “-dbg -t 0 -ieee_nowarn -dataset {$PATH_TO_SIM_DIR/sim} -datasetname {sim} -loadvhpi $aldec/bin/aldec_matlab_cosim.dll:ml2hdl work.testcase_file -acdb -acdb_cov sbm -cc_all”

SetCoverageSimulateEnable true

RunTest $PATH_TO_TEST/testcase_file.vhd

SetCoverageSimulateEnable false

Is RunTest required for generation of the coverage report? Since the first option above runs the cosim and I can verify in Riviera that code coverage is highlighted in the code what I am most interested in here is how exactly the usual OSVVM scripted flow generates the output report.

Until now I’ve just always used RunTest so this is the first time I’ve needed to dig into the mechanisms behind the report generation.

Thanks,
Brad

[Jim Lewis]

Hi Brad,
Short answer: yes you must run either simulate or RunTest to get the coverage reports

Behind the scenes when simulate finishes it saves the code coverage data base. When a test suite finishes, the code coverage from each test case is merged together. When the build finishes, it merges together the coverage from each test suite and creates the merged build coverage database. From the merged build coverage database, the html reports are created.

RunTest is just a short hand for: TestName ; analyze .vhd ; simulate test

Look in the directory logs// for either _log.html or .log. Find how the vsim arguments were put together.

I suspect that you will find some of the information is repeated. I think you need:
SetExtendedSimulateOptions “-dbg -t 0 -ieee_nowarn -dataset {$PATH_TO_SIM_DIR/sim} -datasetname {sim} -loadvhpi $aldec/bin/aldec_matlab_cosim.dll:ml2hdl”

The part “work.testcase_file” is added by RunTest/simulate – but instead as: -lib work testcase_file

The part “-acdb_cov sbm -cc_all” is already added by “SetCoverageSimulateEnable true”.

Let me know if that works. If you check the log files you will note that it composes the simulate in a different order – I don’t think that would cause problems, but it is possible.

Jim

[Brad Adam]

Okay, that was helpful and after comparing the logs I’m reasonably confident that I am supplying the needed switches to the SetExtendedSimulateOptions.

At this point the remaining failure when using RunTest seems to be in the load libraries steps, specifically the libraries from Aldec. In the below console output, systf.dll and aldec_matlab_cosim.dll are in the same directory but for aldec_matlab_cosim $ALDEC is in the path. I’m trying to track down at what point these libraries are loaded after calling RunTest. I see mention of ALDEC in the OsvvmLibraries\CoSim\code directory but I’m not seeing where/how ALDEC is set specifically beyond the ‘#ifndef ALDEC’ in OsvvmVSchedPli.h.

# PLI: Loading library ‘C:\Aldec\Riviera-PRO-2022.10-x64\bin\systf.dll’
# VHPI: Loading library ‘systf.dll’
# VHPI: Loading library ‘$ALDEC/bin/aldec_matlab_cosim.dll’
# VHPI: The target platform of the “$ALDEC/bin/aldec_matlab_cosim.dll” library cannot be identified. The library may be missing, corrupted, or its format is incorrect.
# VHPI: Loading library ‘$ALDEC/bin/aldec_matlab_cosim.dll’

Is it possible that I am missing a step to define $ALDEC as that seems to be the cause of not finding the aldec_matlab_cosim.dll.

Thanks.
Brad

[Brad Adam]

Hey, Jim!

So I’ve been working with Aldec as well on this and we’ve tracked down the root cause of OSVVMs failure to correctly call the $ALDEC variable.

Turns out that we needed to add “global aldec” to the VendorScripts_RivieraPro.tcl within the vendor_simulate process.

I don’t think there is a way to add images on these forms to show you but I just added this line of code near the top of the process under the variable declarations. My test environment was able to properly find the $ALDEC variable for the MATLAB library path and I am now running the CoSim with the usual flow which has allowed me to generate code coverage reports.

For now I’ll apply this fix on our side but do you think it is possible to add this ‘global aldec’ fix to the VendorScripts_RivieraPro.tcl script for a future release? This CoSim flow is not common but the current script does lack the ability to support it.

Thanks,
Brad

[Jim Lewis]

Hi Brad,
Cool. If we end up needing that, it will be added. However, that said, I am curious as to why it is needed. Normally variable expansion is done in the calling scripts.

So if I do:
SetExtendedSimulateOptions "-dbg -t 0 -ieee_nowarn -dataset {./sim} -datasetname {sim} -loadvhpi $aldec/bin/aldec_matlab_cosim.dll:ml2hdl"

Then I do:
GetExtendedSimulateOptions

The results are:
-dbg -t 0 -ieee_nowarn -dataset {./sim} -datasetname {sim} -loadvhpi C:/tools/Aldec/Riviera-PRO-2023.10-x64/bin/aldec_matlab_cosim.dll:ml2hdl

What I see here is that the $aldec variable was expanded when the parameter of the call referenced it.

If you are doing something that is deferring the variable expansion until later, then reference the aldec variable as $::aldec. The “::” prefix specifies to access the variable from the global space.

In a similar fashion, you can access any variable from the OSVVM space by prefixing it with ::osvvm. So the following does the same as GetExtendedSimulateOptions:
puts $::osvvm::ExtendedSimulateOptions

If that does not work for some reason, then we will add the variable to the aldec vendor script.

Best Regards,
Jim
P.S. Once you get the flow going, if you are interested in doing a blog post on OSVVM.org, just let me know.

[Brad Adam]

Hey,

I totally agree. This is part of what was so confusing to me. I could see that when using $aldec and running the test the variable would be properly expanded as you show, however, a bit further into the run, when attempting to load the aldec_matlab_cosim.dll the path would still show an unexpanded variable $ALDEC in the path.

I actually wasn’t aware of the “::” prefix and I just gave it a shot but ran into the same issue. Without the “global aldec” line included in the vendor script tcl $ALDEC will fail to expand when the tool attempts to load the library further into simulation.

—

I would be happy to help detail the CoSim process with MATLAB. As I build out this current work I will document useful info and some considerations in my free time for a blog post.

Thanks,
Brad

[Jim Lewis]

Hi Brad,
Did you add “global aldec” or “global ALDEC”? Your note above seemed to indicate that it is lower case. OTOH, the error messages are referencing an upper case $ALDEC. I should note if I do “puts $aldec” it works. If I do “puts $ALDEC” it does not work.

There is no “$aldec” in $PATH_TO_SIM_DIR right?

Cheers,
Jim

[Brad Adam]

I did “global aldec”, all lower case.

The error message was referencing an all uppercase $ALDEC but “global aldec” fixed this issue. I noticed the same thing with “puts $aldec” vs “puts $ALDEC” as you describe.

No, there is no $aldec used in the $PATH_TO_SIM_DIR on my machine, that just points to the project directory on my C:/ drive.

Thanks,
Brad

[Jim Lewis]

Thanks. I will get the updates in OSVVM scripting.

[Author]

Posts