Xcelium simulator is not running when vhpi application is loaded.

The following is the vhpi application followed by the vhdl test case.

Here is an example of the how I invoke the simulator.

The function is loaded via -vhpiload.
It seems to load and run and then after it exits the simulator runs.

Is there some other way I should be calling a function to drive the simulation?

xmsim -loadvhpi /full_path_to_shared_object_directory/full_adder_tb:full_adder_tb full_adder

Can you try adding some time-consuming VHDL code, e.g. a simple clock generator in VHDL? I'm not seeing anything in your code that would cause time to advance, so the simulator is simply exiting at time 0 because there are no events to process.

You might also need to add the xrun option "-access +rw" so that nets can be driven from VHPI, though in this trivial case it's likely that the nets won't get optimised without this switch.

I tried to add a simple clock generator and did not see any affect but will try more if you think that is the issue after reading the following.

I am wondering if my basic misunderstanding is this.

I was sort of expecting to find a vhpi_evaluate_model() function, but there does not seem to be one,  so I assumed that this was automatic.

For example I assumed this was happening.

I assumed vhpi_put_value() was a blocking call that would return after the simulator completed updating the model with the new value applied.

Is this my incorrect assumption?

I was able to get some results but I had to follow this process using callbacks.

I create a callback function that fires after a specified delay

In that function I set the call vhpi_put_value() on a set of signals

At the end of that function,  I register a new callback that fires after another specified delay.

This new callback makes further updates using calls to vhpi_put_value() and also registers another callback that fires after a specified delay.

I would the repeat this process until my test bench is done.

Which if any of these assumptions are correct?

1. vhpi_put_value() is blocking and waits for the for the simulator to evaluate the update.
2. There is some other blocking function that I can call to tell the simulator to evaluate the model with the current inputs
3. There is no blocking function and I need to use callbacks to get control back from the simulator after some event, like a delay

To be honest, this is the first time I've ever (in 18 years doing this job) come across anyone trying to build a testbench in VHPI, so this is testing my knowledge! Most users use the VHDL or SystemVerilog language for testbench creation and only use VHPI or VPI for connecting bespoke models into an HDL testbench...

That aside, here are some thoughts which may help you...

• The simulator doesn't automatically wind time forwards, you need to schedule events for some future time so that time will advance. This is why I suggested adding a clock generator in the VHDL code.
• If you did create a clock generator in VHDL, you should be able to observe time advancing (e.g. in batch mode, use the "run 10us" command to run for 10 microseconds. If you have no VHDL statements that actually cause future events, time will remain at 0 and the simulator will tell you that the simulation has finished. If your clock generator works, you should find that time advances to 10us.
• Registering a VHPI callback on a time doesn't (I think) actually schedule an event to happen at that time, so the callback won't itself cause time to advance.

Registering a VHPI callback on a time doesn't (I think) actually schedule an event to happen at that time, so the callback won't itself cause time to advance.

This seems to be true,  time is advanced only if the values I set affect the model.  I still do seem to get control back even if the values I set don't affect the model.

In case you'd not found this in the docs, there is an example of driving values here.

I see there is also a function vhpi_schedule_transaction() which schedules a future transaction; I would assume that this would have the effect of causing simulation time to advance, because it's putting an event into a future time slot in the simulator's event list. The call wouldn't advance time itself, it simply tells the simulator to schedule an event for a future time, much like a delayed assignment in HDL code.

yes I did see vhpi_schedule_transaction(),  I will try that next to see how that works.