0

I have the following scenario : I have a vpi callback that is triggered when an assertion is triggered. In this callback I want to call an export system verilog function I tried to setSvScope before the export but simulator gives me some errors.

Greg
  • 18,111
  • 5
  • 46
  • 68
Viktorinox
  • 120
  • 1
  • 9

2 Answers2

0

Usually when vpi invokes a callback function, there is no DPI contents available at this time. So, you need to look it up before calling the exported dpi:

svScope scope = svGetScopeFromName("path.to.your.export.scope");
svSetScope(scope);

where the scope is the one which exports the function. For the exports from the global scope the $unit could be used for the scope name.

Serge
  • 11,616
  • 3
  • 18
  • 28
  • Yes vpi callback does not have context information so you have to set it explictly as I understood I do the following at the beginning of the callback svSetScope(svGetScopeFromName("common_pkg::")); My export is defined in the common_pkg – Viktorinox Jan 10 '18 at 15:47
0

Calling an DPI exported routine from a routine that has not been DPI imported is left undefined by the 1800-2012 LRM (See section 35.5.3 Context tasks and functions)

The exported DPI routine when called needs two key pieces of information to behave like any other routine that would have been called by SystemVerilog instead of C. It needs a scope context and a process context.

For the scope, it’s possible to have multiple DPI exports with the same name. In fact, it is possible to have a DPI import/export pair in a module, and that module gets instantiated multiple times. Even though the import calls the same C code, its context gets set from the caller’s scope and that scope gets matched with the exported scope. The DPI provides a svSetScope routine to do this explicitly if the implicit DPI imported routine does not.

For the process, there are many things you can do like disable, or suspend it. The DPI provides no mechanism to set this explicitly.

Some tools(like Questa) do provide a mechanism to do this for a limited set of use cases. For example, you can only call a DPI exported function from non-DPI imported C/C++ code. A task cannot be called because it has the potential to block, and that interferes with any process context.

dave_59
  • 39,096
  • 3
  • 24
  • 63
  • Thanks for you help dave_59. I was not aware of this process context. The tool I'm using is ncsim I have to check if it's possible to explicitly set this process context. My export is a function – Viktorinox Jan 10 '18 at 16:16