Stats

  • Locked Locked
  • Replies 20
  • Subscribers 40
  • Views 35299
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

vr_ad register definition utility

StephenH

Hi All.

I put together a small Perl script to generate vr_ad register definitions from SPIRIT (IP-XACT) XML.
If you've got not idea what IP-XACT is, have a look here www.spiritconsortium.org/, then start pestering your design manager to use it :-)

The script can filter out registers and override R/W access types if needed.

An example XML file is included with the package so that you can play with it, and there's a detailed README.txt as well.

Here's an example of the generated e code:

// Automatically generated from xdmac.xml
// DO NOT EDIT, or your changes may be lost
<'

import vr_ad/e/vr_ad_top;

// Component = XDMAC
// memoryMap = xdmac
extend vr_ad_map_kind : [XDMAC];

// addressBlock = dma_eth
extend vr_ad_reg_file_kind : [DMA_ETH];

extend DMA_ETH vr_ad_reg_file {
  keep size == 20;
  keep addressing_width_in_bytes == 4;
};

// Register = command
// Reset    = 0x00
reg_def COMMAND DMA_ETH 0x0 {
  // Field resv3 = command[31:29]
  reg_fld resv3 : uint(bits:3) : R : 0 : cov ;
  // Field transfer_size = command[28:19]
  reg_fld transfer_size : uint(bits:10) : RW : 0 : cov ;
  // Field dma_transfer_target = command[18:14]
  reg_fld dma_transfer_target : uint(bits:5) : RW : 0 : cov ;
  // Field resv2 = command[13:10]
  reg_fld resv2 : uint(bits:4) : R : 0 : cov ;
  // Field transmit_receive = command[9:9]
  reg_fld transmit_receive : uint(bits:1) : RW : 0 : cov ;
  // Field resv1 = command[8:5]
  reg_fld resv1 : uint(bits:4) : R : 0 : cov ;
  // Field dest_address_enable = command[4:4]
  reg_fld dest_address_enable : uint(bits:1) : RW : 0 : cov ;
  // Field source_address_enable = command[3:3]
  reg_fld source_address_enable : uint(bits:1) : RW : 0 : cov ;
  // Field word_size = command[2:0]
  reg_fld word_size : uint(bits:3) : R : 0 : cov ;
};

// Register = queue_exec
// Reset    = 0x00
reg_def QUEUE_EXEC DMA_ETH 0x10 {
  // Field resv = queue_exec[31:1]
  reg_fld resv : uint(bits:31) : R : 0 : cov ;
  // Field exec = queue_exec[0:0]
  reg_fld exec : uint(bits:1) : RW : 0 : cov ;
};

extend XDMAC vr_ad_map {
  dma_eth : DMA_ETH vr_ad_reg_file;

  post_generate() is also {
    add_with_offset(0x00, dma_eth);
    dma_eth.reset();
  };
}
'>

 

Any comments, please feed them back to me so I can enhance the script.
Note that this forum forces me to post a .zip file rather than .tgz, please be careful to unpack the file under Linux, not Windows, else the DOS linefeeds will corrupt the Perl and XML files.

Steve

ipxact2vrad-0.7.zip
Parents

  • Hi Thoufiq.

    We (Cadence) are making improvements to vr_ad at the moment so it's a good time to make feature requests, but can I please ask you to do so via the official support system (i.e. contact a Cadence AE directly or file a support ticket at http://support.cadence.com). The reason for this is it helps us if we can track who the requests come from so we know how to get back in touch to clarify anything and so we can keep you informed of progress.

    As regards the pre-defined access policies, I agree that uvm_reg defines several that are not in vr_ad, and it does makes sense to align them. However vr_ad does define all the common types; you're the first person I've heard asking for W0C registers in 10 years! Where there is a real need for features, they will get added. However we tend not to worry about making 100% alignment with features just for the sake of it, so for example even if RW0C is defined in uvm_reg we may ignore it in vr_ad if no designs ever need this feature.

    Note that vr_ad and uvm_reg have some philosophical differences in the way you do verification with them, so it isn't possible to completely align their features as they do different jobs. I'm not aware of a document that lists pros and cons of either package, you might do better to talk to your local Cadence AE about what you want to verify and they will be able to give you advice on what's the best fit for that task.

    vr_ad has built-in sequences covering reset-value checks, random read/write etc, have a look at the vr_ad/examples directory. 

Reply

  • Hi Thoufiq.

    We (Cadence) are making improvements to vr_ad at the moment so it's a good time to make feature requests, but can I please ask you to do so via the official support system (i.e. contact a Cadence AE directly or file a support ticket at http://support.cadence.com). The reason for this is it helps us if we can track who the requests come from so we know how to get back in touch to clarify anything and so we can keep you informed of progress.

    As regards the pre-defined access policies, I agree that uvm_reg defines several that are not in vr_ad, and it does makes sense to align them. However vr_ad does define all the common types; you're the first person I've heard asking for W0C registers in 10 years! Where there is a real need for features, they will get added. However we tend not to worry about making 100% alignment with features just for the sake of it, so for example even if RW0C is defined in uvm_reg we may ignore it in vr_ad if no designs ever need this feature.

    Note that vr_ad and uvm_reg have some philosophical differences in the way you do verification with them, so it isn't possible to completely align their features as they do different jobs. I'm not aware of a document that lists pros and cons of either package, you might do better to talk to your local Cadence AE about what you want to verify and they will be able to give you advice on what's the best fit for that task.

    vr_ad has built-in sequences covering reset-value checks, random read/write etc, have a look at the vr_ad/examples directory. 

Children
No Data

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.