vpi_get_time() and vpiTimeQueue problems

[gblake@beigebag.com]

Hi,

I'm trying to extract the next scheduled event time from the simulation
time queue and it does not seem to be working. I need to access this
information because I am interfacing an analog simulator with the
Verilog simulation, and I need to keep them synched up properly.

I'm using the following VPI code with GPL CVer under Cygwin:

GetTimeofNextEvent()
{
vpiHandle nxt_event_itr, nxt_event;
s_vpi_time next_event_time;

nxt_event_itr = vpi_iterate(vpiTimeQueue, NULL);
if (nxt_event_itr == NULL)
{ vpi_printf("ERROR: No time queue\n"); }
nxt_event = vpi_scan(nxt_event_itr);
next_event_time.type = vpiScaledRealTime;
vpi_get_time(nxt_event, &next_event_time);
vpi_printf("Next event time: %lf\n", next_event_time.real);
}

It always gets a NULL iterator and will just return the current
simulation time. Any help would be appreciated. I believe I'm
interpretting the IEEE diagrams correctly.
Thanks,

Geoff Blake

 

It is likely that they have not implemented this rarely-used capability
in their VPI.

 

[gblake@beigebag.com]

After looking through the source for GPL CVer, that is indeed the case,
the functionality does not exist.
Is there by any chance another way to accomplish this? I really need
to know in advance how long to run the analog simulator before Verilog
is scheduled to do another simulation time step.

Thanks,
Geoff Blake

 

[gblake@beigebag.com]

I've done some research into some other simulators I can find in depth
info on so far about the vpiTimeQueue option, and it seems to not be
supported. I've looked at Cver, Icarus Verilog, ModelSim, and VCS. Is
there a simulator out there that does support this functionality?

Just to bounce some ideas off some others, I had the idea of
checkpointing the simulator state to get around not being able to see
into the future of the Verilog simulation. This way, I can step the
Verilog and Analog simulators an arbitrary time step, and if something
on the analog side changes, I can back track the Verilog state and
restart the simulation. Does checkpointing appear to be a feasible
solution? I know it will probably be arbitrarily slow depending on how
large the design is that is being simulated in Verilog.

Thanks,
Geoff Blake

 

Checkpointing seems terribly expensive for this. Wouldn't it be more
efficient to set a time callback in the Verilog simulator, for the
longer of the Verilog timeprecision or the analog stepsize? Then you
don't have to backtrack the Verilog simulator. It would be slow, but
probably not as slow as checkpointing. It would depend on the ratio N
between this minimal stepsize and your larger arbitrary time step. If
you can do N time callbacks in the time it takes to do a checkpoint,
then it would be faster to use the callbacks. As you make the
arbitrary time step larger, the checkpoints get more efficient, until
you reach the point that you start having to backtrack the Verilog
state often.

I would think you would want to do something like the following: solve
the analog side for some reasonable future time, until an analog output
that is an input to the digital side crosses a threshold voltage or
some upper time limit is reached. Set a time callback for that time,
and run the Verilog simulator. If it reaches that time callback, then
both the analog and digital sides are synched up. If the Verilog
simulator gives you a callback on a digital signal that is an input to
the analog side before that, then you have to back up the analog side
to that point (since your analog calculations are wrong from that
point). Then both sides are synched up at that point. Note that this
assumes you are using value callbacks on the Verilog signals to detect
when inputs to the analog side change.