This week Accellera announced the formation of the Verification Intellectual Property (VIP) Subcommittee, http://edageek.com/2008/05/06/accellera-vip-tsc/, which is chartered to define standard technology and/or methods to realize a modular, scalable and reusable generic verification environment. While this charter may be a mouthful, the goal of this effort is all about making VIP easier to use. With VIP becoming a standard part of a verification engineer’s toolbox in their quest to achieve functional verification goals, this work by Accellera has come at an opportune time. Personally I am looking forward to working with the other members of the Accellera VIP Subcommittee as this we establish a standard VIP use model.

Some questions came in recently about the OCP coverage, and whether the user could modify the coverage we provide. What was our answer?

YES !!!

This post gives an overview of some of the possibilities, focusing on the OCP dataflow signals and the related state, meta, and cross coverage groups. Similar options are also available for the coverage provided for sideband signals.

The OCP coverage was designed to try and make it as easy as possible to re-use the coverage capabilities, but to also have some ability to control “whats there” and to add to it as desired. Here are some of the design features which OCP VIP users can, and hopefully do, take advantage of.

1) All of the dataflow coverage is based off of the dataflow_activity_chan_cov callback on the monitor. If the user wants to “start at the bottom”, they should therefore extend from the svt_ocp_monitor_callbacks class and create their own dataflow_activity_chan_cov implementation to implement their “new” or “modified” coverage. The event to trigger the coverage would be the callback call, which will occur every time a transaction completes. Any instance of this user created callback class would need to be appended to the monitor coverage callback list.

2) Moving up a level, we provide an svt_ocp_monitor_callbacks extension, svt_ocp_monitor_def_df_cov_data_callbacks, which basically converts the dataflow_activity_chan_cov call into several sample events. These sample events are basically more conducive for use with coverage groups, etc., and this class therefore takes away another level of responsibility from the user. In this extended class dataflow_activity_chan_cov basically (a) loads up data fields and (b) generates sample events. The fields correspond to the basic transaction data fields, e.g.

           protected bit [SVT_OCP_MAX_ADDR_WDTH-1:0] m_bv_maddr;

The sample events correspond to many of the processing points for the transaction. For example calling the dataflow_activity_chan_cov method for this class actually results in multiple m_ev_df_request_phase_sample sample events, one for each of the request phases within the transaction. These sample events are generated in conjunction with filling in the data fields to go with that sample. For example the m_bv_maddr field is filled in once for each request phase, prior to the triggering of the m_ev_df_request_phase_sample for that request phase.

So the user can extend this class, creating groups based on the data fields and sample events, append the callback to the monitor, and the user’s new or modified groups will be included in the coverage. This allows the user to include their own coverage groups without having to actually implement anything other than the group definitions.

3) The user can also extend one of the default coverage callback classes. These classes were organized to make it easy for the user to pick and choose exactly which ’sets’ of coverage they want to use. The following can all be added (or not) on an individual basis.

svt_ocp_monitor_def_df_man_state_cov_callbacks — to get the mandatory dataflow state coverage, as defined by the protocol
svt_ocp_monitor_def_df_opt_state_cov_callbacks — to get the optional dataflow state coverage, as defined by the protocol
svt_ocp_monitor_def_df_opt_meta_cov_callbacks — to get the optional dataflow signal meta coverage, as defined by the protocol
svt_ocp_monitor_def_df_man_trans_cross_cov_callbacks — to get the mandatory dataflow transaction cross coverage, as defined by the protocol
svt_ocp_monitor_def_df_opt_trans_cross_cov_callbacks — to get the optional dataflow transaction cross coverage, as defined by the protocol
svt_ocp_monitor_def_df_opt_trans_meta_cov_callbacks — to get the optional dataflow transaction meta coverage, as defined by the protocol

Note that all of these classes are extensions of the svt_ocp_monitor_def_df_cov_data_callbacks class. As such they use, and have access to, all of the data and event fields in this class.

4) With the 1.30a release we updated the default coverage classes listed above to selectively enable/disable the groups based on the configuration. So if the configuration indicates that a signal is not part of the system (e.g., addr == 0), the corresponding state and meta coverage group(s) are not included. If the signal is part of a cross coverage group definition, then it will result in the set of coverage bins being cut back accordingly.

Which means the user can modify the coverage just by providing an explicit configuration to the constructor for the built-in callback class.

5) Based on the code changes done to provide (4), its now possible for the user to exclude or replace built-in coverage groups. One of the main requirements of (4) is that the user needs to provide the class constructor with a configuration. This is used to decide which groups should or should not be enabled.The underlying assumption is that is the “official” design configuration. But this doesn’t really need to be the case.

In this instance the configuration is only used in deciding how to construct the groups. It doesn’t have any impact on how the callbacks work, how the data fields are filled in, or how the events are generated. It just impacts the group construction.

Which means that to extend from  svt_ocp_monitor_def_df_opt_state_cov_callbacks, replacing the existing MAddr coverage, you could:

a) extend from svt_ocp_monitor_def_df_opt_state_cov_callbacks adding your modified signal_state_MAddr group
b) implement this new signal_state_MAddr group to use the m_bv_maddr and m_ev_df_request_phase_sample data members
c) implement the constructor in the new class to take in a cfg parameter and to:¼br>     1) copy the original cfg, creating an internal cfg
    2) set addr = 0 in this internal cfg
    3) pass the internal cfg to the super
d) create an instance of this new class, providing it with the official cfg, and attaching this instance to the monitor

The ‘extended’ class can also look at the addr setting in the “official” cfg to decide if the modified signal_state_MAddr group should be included or not. If not, then the constructor would avoid doing the ‘new’ for the group. This would allow this extended coverage class to be used for all OCP ports, regardless of whether they have addr enabled.

For more detail on the above take a look at the monitor section of the OCP VIP SV documentation. SV is where you get the majority of the flexibility, so the SV documentation is where you will find the most detail on how to accomplish the above.