The register and memory package vr_ad for Specman is used in pretty much every verification environment. In most cases today, the register specification is captured in an IPXACT description and the register e-file can be automatically generated from it.
The vr_ad package comes with a variety of pre-defined register access policies, which cover the typical register usage.
However, many users have the need for special access policies which are not supported by vr_ad by default. Implementing these custom policies can be done in two ways:
1. Define the specific behavior for each register through extensions and customization of the register itself
2. Define a new access policy
To illustrate the two solutions, we use an example register which holds four fields. One field is reserved, the other three (f0, f1 and f2) have custom access policies:
f0: SELF_CLEAR: Field clears itself after one clock cycle upon WRITE access
f1: WRITE_CLEARS: Field clears itself with the 2nd (or more) write access
f2: READ_CLEARS: Field clears itself with the 2nd (or more) read access
The next section illustrates the pros and cons of the two implemenations.
Defining the specific behavior for each register through extensions and customization of the register itself
Typically one can give full write-read access to the register field (if no access is given, the conversion script ipxact2vrad.pl treats the field as Write-Read). One can then extend the register for specific behavior using, for instance, the predefined method post_access()
IPXACT description of register reg2: 
Corresponding e-code:
In post_access() we are using the set_field() method to
change the value of a specific field
Note:
The set_field() method itself calls update() which again triggers post_access(). This would result in an endless loop and/or wrong behavior. To overcome this, Cadence enhanced the vr_ad package. The default behavior of set_field() remains, but it can be overridden by a third parameter (perform_post_access with default value TRUE). When set to FALSE, the call to update() will be suppressed. In our case, this is required.
This enhancement will be available from Incisive 13.10-s020 and 13.20-s006.
When using an older version, the user has to implement a
locking mechanism to avoid bad behavior. A code snippet is below:
The extension file has to be imported after the register definitions
Define a new access policy
The vr_ad package provides specific hooks to implement user-defined behavior. To define a new access policy, the user has to first create a new enum value for the policy:
The IPXACT file needs to make use of the vendorExtensions (access_policy attribute) to define the new access policy.
Note: The venderExtensions will not overwrite any
access policy specified in the IPXACT, so make sure there is no regular policy
specified.
Note: The IPXACT standard supports the definition of user-defined access policies. However, this description is not yet supported by the ipxact2vrad.pl conversion script.
Using the new access enum values, the corresponding subtype
of the vr_ad_reg_field_info struct can be customized to the desired behavior:
The extension file has to be imported prior to the register definitions.
Summary
The vr_ad package provides many hooks to implement custom access policies.
While the register extension makes the flow independent of the IPXACT file and the vendorExtensions, there could be quite some coding required - The policy has to be implemented for each register subtype.
Using vendor extensions in the IPXACT description makes the flow more natural and probably requires less code, but relies on vendorExtensions.
Hans Zander