Using the Value Change Link (VCL)

Using the Value Change Link (VCL)

The tf_i Routines

If you are required to call a tf_ routine that relates to a specific instance of a system task within your consumer routine, you must perform the following two steps:

1.Save the instance pointer for the system task in the checktf routine or calltf routine.

2.Use this instance specific (tf_i) form of these routines in the consumer routine.

The toggle test application does not call any of the tf_routines from the consumer routine.

Miscellaneous VCL Tasks

In a VCL application—as with any PLI application that has activity associated with it beyond the time in which it is invoked—you must write your own code to support the $save and $restart system tasks if your application must support these operations.

When you execute the $save system task, Verilog-XL does not save any information related to the objects that are being monitored by the VCL. Much of the data that the VCL deals with—such as object handles, the pointer to the consumer routine, and the user_data information—is sensitive to the way that Verilog-XL is loaded into the memory on a machine. The memory location can change when Verilog-XL is restarted.

All PLI applications must perform the following actions to support $save and $restart:

■Save the state of the data structures when a $save system task is done

■Reallocate and reload those data structures when a $restart system task is performed

A VCL application also needs to perform two additional actions:

■Save information that indicates the objects that are currently being monitored with VCL when a $save is performed

■Restart the VCL monitoring for these objects through calls to acc_vcl_add when a $restart is performed

In the toggle test application when a Verilog-XL $restart is performed, VCL monitoring is restarted for all nets that have not toggled. This is shown in Figure 1-9 on page 29 .

Using the Value Change Link (VCL)

Using the Value Change Link (VCL)

Figure 1-9 tg_restore_net_info routine

/* tg_restore_net_info()

*

*This routine restores information for a net that was saved in a

*save file when a ’$save’ was performed. It also restarts VCL

*monitoring of the net if the net has not toggled.

*

*/ tg_restore_net_info(net) p_tg_net net;

{

int num_chars; int i;

p_tg_name curr_port;

/* restore net structure information */ tf_read_restart(net,sizeof(s_tg_net));

/* retrieve number of characters in name of net, allocate storage for name, and restore name of net */

tf_read_restart(&num_chars,sizeof(int));

net->full_name = (char *) malloc((num_chars + 1)*sizeof(char)); tf_read_restart(net->full_name,num_chars); (net->full_name)[num_chars] = ’\0’;

if ((!(net->one_to_zero)) || (!(net->zero_to_one))) acc_vcl_add(net->net_handle,tg_process_toggle,(char *) net,

vcl_verilog_logic);

}

As mentioned in “Using VCL to Monitor Value Changes” on page 6 , you cannot monitor the following objects using the VCL:

■Bit-selects of unexpanded vector nets or registers

■Part-selects

Using the Value Change Link (VCL)

Using the Value Change Link (VCL)

■Memories

■Expressions (such as a+b)

It is not possible to monitor changes in memories using any of the available PLI capabilities.

There are three ways you can handle unsupported bit-selects and part-selects in your application:

■Monitor the entire object that contains the bit-select or part-select using the VCL, and extract the data you need from within your application.

■Use the previously available PLI monitoring mechanism that is initiated with a call to the tf_asynchon utility routine.

■For expressions, you must use the PLI monitoring mechanism that is initiated with a call to the tf_asynchon routine. See the PLI 1.0 User Guide and Reference for more information on how to use this routine.