VPI: is vpi_handle_by_name() a good substitute for vpiLowConn?

[gatk555]

I have a VPI module that acts as a bridge between VVP running a simulation and a larger simulation that contains it. That means that it acts very like a testbench written inside the VPI module. It is intended to be rather general, so contains no information about the Verilog source code.

To make that work, early on it must scan the ports of the top-level module and set up the means to send inputs and capture outputs. From the standard docs, the way to do that seems to be to call vpiHandle(vpiLowConn, port) to get access to the internal variable that represents the value on the port. Then force values or set callbacks on it.

But vpiLowConn is not implemented. Instead, I have this code, that works so far.

``

/* Get the ports. */

iter = vpi_iterate(vpiPort, top);
while ((item = vpi_scan(iter))) {
    PLI_INT32  direction;
    char      *name;
    vpiHandle  namesake;

    direction = vpi_get(vpiDirection, item);
    name = vpi_get_str(vpiName, item);

    /* Assume that there is an object with the same name as the port
     * whose value may be read or set as needed.  This is an assumption
     * about how code for VVP is generated.
     */

    namesake = vpi_handle_by_name(name, top);
    if (direction == vpiOutput) {
        static struct t_vpi_time  time = {.type = vpiScaledRealTime};
        static struct t_vpi_value val = { .format = vpiIntVal };

        /* Put a watch on it. */

        cb->reason = cbValueChange;
        cb->cb_rtn = output_cb;
        cb->obj = namesake;
        cb->time = &time;
        cb->value = &val;
        if (!vpi_register_cb(cb))
            DBG("No callback\n");
    } else {
        static struct t_vpi_value val = { .format = vpiIntVal };

        // Set initial value.
        
        vpi_put_value(namesake, &val, NULL, vpiForceFlag);

``
My question, for anyone still reading: is this the best way to do it? If so, can it be expected to continue to work in future releases?

Thanks,

Giles

[caryr]

While we try to make improvements and fixes to the VPI as we can I doubt we would change it in a way that breaks existing code. anytime soon.