VPI: Persistent data structure for simulation lifetime.

[Charles Gardiner]

Hi,

for a BFM I am trying to do the following:
I would like to have the USER test program running from a single initial task,
something like:

initial begin
$config1(...)
$config2(....)
$config3(....)
$config1(...)
$reada(...)
$writeb(...)
$reada(...)
$stop_test()
end

The problem is that most of the hardware operations behind the above are split
transactions. My idea was to define a c++ object containing a queue. Each call to
the above puts a new entry in the queue, the incoming responses are checked
against the scoreboard and the entries then removed. The outgoing requests would
essentially initiate a chain of callbacks (wait_for_grant(), start_xfer(),
emit_data(), generate_xfer_end() etc.) when each one gets shifted to the head of
the outbound queue

But where can I store the reference to the c++ root object? As far as I can see,
vpi_get/put_userdata() is only persistent across calls to the _same_ system
function. vpi_get/put_data() don't seem to be designed for accessing persistent
data at all. The way I read the spec, an interleaved (but possibly staggered)
sequence of vpi_put_data() and vpi_get_data() is expected which is no use to me
either.

Changing the above to:

initial begin
$wrapper(config1, ...)
$wrapper(config2, ....)
$wrapper(config3, ....)
$wrapper(config1, ...)
$wrapper(reada, ...)
$wrapper(writeb, ...)
$wrapper(reada, ...)
$wrapper(stop_test())
end

wouldn't really solve things either. Where does the VPI application handle live
when stop_test() has returned? The simulation itself and the hardware activity
initiated by the test sequence will still be running for quite a while. I'm
pretty sure (without having tried it) that having a C++ method looping until a
callback has fired will hang the simulator and I don't see any vpi synchronisation
methods for passing control back to the simulation with returning from a
user-defined system function.

Grateful for any helpfull suggestions.

 

[Charles Gardiner]

Just for interest, I think I have found at least a partial solution. I define a
callback on a dummy signal with reason cbValueChange. The dummy signal never
changes so there is no unneeded application load. I can put a pointer to my
application structure in the user_data field of the t_cb_data structure. The
structure can be accessed anytime (and hence the application data structures
found) by iterating over the vpi_ objects referenced by the dummy signal.

But, still open for any better ideas.

 

[Stephen Williams]

Charles Gardiner wrote:

Just for interest, I think I have found at least a partial solution. I define a
callback on a dummy signal with reason cbValueChange. The dummy signal never
changes so there is no unneeded application load. I can put a pointer to my
application structure in the user_data field of the t_cb_data structure. The
structure can be accessed anytime (and hence the application data structures
found) by iterating over the vpi_ objects referenced by the dummy signal.

But, still open for any better ideas.

Method 1: Have your functions take an extra argument, a reg, that
you use as a state handle, much like the "random" functions have
a seed variable.

Method 2: Use a global variable. (You've essentially defined your
interface this was, anyhow, so might as well admit it and use the
global.)


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."