• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification Shared Code
  3. vr_ad register definition utility

Stats

  • Locked Locked
  • Replies 20
  • Subscribers 40
  • Views 35305
  • 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
StephenH over 16 years ago

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
  • Cancel
Parents
  • tauf
    tauf over 13 years ago

    Hi Steve,

    Thanks for your quick reply!

    I will send my company ID soon. I have few more queries on vr_ad reg, hope I am not interrupting you:)

    1) I feel uvm_reg supports almost all reg access policies directly rather than indirect methods such as post_access() etc. Does your R& D team is improving vr_ad  to match the functionalities of  uvm_reg?

    2) And have no idea, does all the features supported by uvm_reg will be supported by vr_ad as well?

    3) is their any link to see the latest update ( new features add-ons) to vr_ad?  

    4) How can we compare uvm_reg & vr_ad supported features, is their any documentation for differences, pros & cons etc or both support same set of features..?

    As I quickly gone through uvm_reg doc, seems many built in sequences like bit-bash etc & wide number of access policies which I hardly see in vr_ad documents ( in vr_ad they stated that they support only  RW,R,W,RC,RW1C directly), rest all we need to follow some indirect approach (means need to add soem mroe code).....is it correct? 

     Waiting for your response.

     Many Thanks

     Thoufiq 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • tauf
    tauf over 13 years ago

    Hi Steve,

    Thanks for your quick reply!

    I will send my company ID soon. I have few more queries on vr_ad reg, hope I am not interrupting you:)

    1) I feel uvm_reg supports almost all reg access policies directly rather than indirect methods such as post_access() etc. Does your R& D team is improving vr_ad  to match the functionalities of  uvm_reg?

    2) And have no idea, does all the features supported by uvm_reg will be supported by vr_ad as well?

    3) is their any link to see the latest update ( new features add-ons) to vr_ad?  

    4) How can we compare uvm_reg & vr_ad supported features, is their any documentation for differences, pros & cons etc or both support same set of features..?

    As I quickly gone through uvm_reg doc, seems many built in sequences like bit-bash etc & wide number of access policies which I hardly see in vr_ad documents ( in vr_ad they stated that they support only  RW,R,W,RC,RW1C directly), rest all we need to follow some indirect approach (means need to add soem mroe code).....is it correct? 

     Waiting for your response.

     Many Thanks

     Thoufiq 

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information