Community Forums Functional Verification Shared Code vr_ad register definition utility

Stats

  • Locked Locked
  • Replies 20
  • Subscribers 43
  • Views 1159943
  • 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

  •  Hello there

     In your script you have mentioned lot more  reg types than defined by vr_ad documentation.

     Can you help me in guiding , how can i emulate rwh behaviour, where h means field can be updated by hardware also

    Also if i can modify the write behaviour of any field to be dependent on some other field of other register ?

    Thanks & Regards

    Deepak

     

  • Hi Deepak.

    I don't know what RWH means, but I assume you mean the reg can be read and written by software and also modified by the hardware, e.g. a self-clearing bit. This can and should be done by the reference model in the e code. You update the register's value directly at the right moment when you expect the hardware to have changed it, then when the sw reads the reg again, the bus data will be compared agains the vr_ad model and the two should match.

    As for the side effects question, you should use the post_access() method to extend the controlling register. For example if reg A is controlled by a value in reg B:

    extend B vr_ad_reg {
      post_access(direction:vr_ad_rw_t) is also {
        if direction == WRITE {
          var a_reg : vr_ad_reg = get_parents()[0].as_a(vr_ad_reg_file).get_reg_by_kind(A);
          if a_reg != NULL {
            if X { // controlling condition for A write access
              a_reg.as_a(A vr_ad_reg).set_wmask( 0xffffffff );
            } else { // sets a read-only
              a_reg.as_a(A vr_ad_reg).set_wmask( 0x00000000 );
            };
          };
        };
      };
    };

    Please note I have not tested this code, it may not load into Specman, it's just meant to give you an idea to work from.

    Steve.
           

  • Thanks Stephen

     I found another alternative for rwh behaviour : 

     This is listed in vr_ad documentation , 4.6.4.3 Monitoring Internal Changes 

    This uses  set_backdoor_auto_update() to activate the automatic update mechanism

    Regards

     

     

  • The backdoor update just makes the model reflect the RTL, it does not verify that the h/w update is correct.

    You can only verify the h/w update by putting a bit of effort into creating the prediction and updating the reg model from the testbench.

  •  This really helped a lot to me. Thank you

  • Hello Steve,

     

    In your script you have mentioned many reg access policies then described in vr_ad ref document. I am using your script as well to generate the set of registers for my verif.

    I come across the situation that , when particular bit is set by H/W( or  modified by H/W, and read by S/W and by writing '0' to clear by S/W ). Something RW0C (read and write zero to clear). I see it,s missing in your script file & even in vr_ad documentation.

    Can you guide me how to achieve this access policy in my generation?

     

    Thanks

    Thoufiq 

  • Hi Steve,

    In my last post, I asked for RW0C access policy, but basically I Mean W0C.

    Please let me know how to achieve write zero to clear (W0C) in  one of my fields of reg.

     

    Thanks

    Thoufiq 

  • Hello Thoufiq.

    This is a valid enhancement request for vr_ad so I'll pass that on to R&D. Can you send me your work email via a private message, so I can link the request to you?

    Luckily, even though it's not implemented in vr_ad directly, you can model it by extending the post_access() method in your vr_ad_reg_file subtype for that register. post_access() tells you the direction of the access, so you can detect a write. Then calculate the correct value using the written data (i.e. what came over the bus as the clear mask) and the previous data (via get_prev_value()).

    Steve. 

  • 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 

  • 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. 

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.