Home > Community > Blogs > Functional Verification > implementing user defined register access policies with vr ad and ipxact
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Implementing User-Defined Register Access Policies with vr_ad and IPXACT

Comments(0)Filed under: Incisive Enterprise Simulator (IES), Specman, vr_ad, debug, Funcional Verification, AF, e code, ipxact

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


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.


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


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.