vr_ad register definition utility 

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 http://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

 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. 

Hi Stephan,

Thanks for your info!

Basically  am working for STMicro , and already contacted local cadence support guy for  additional features request. We recently download 12.1 latest version vr_ad.

 And am tryingt o integrate with AHB lite0, where I followed the steps for integration given in vr_ad examples directory. When I try to run a simple  test to write & read reg. The compilation goes well when it comes to run it,s throwing an error something like this

     *** Warning: WARN_GEN_SAMPLING_FAILURE_IN_HARD: The sampling of the

input: value(driver.addr_map.kind), has failed.

To debug, run with 'br error'. To get the relevant generation data, run additionally with 'br gen error' and use 'gtree' to open the Gen Debugger.

        at line 114 in @vr_ad_sequence_h

       keep map_kind == value(driver.addr_map.kind);

        To change the severity, type:

     set notify -severity=IGNORE|NOTE|WARNING|ERROR

      WARN_GEN_SAMPLING_FAILURE_IN_HARD

    *** Error: struct is NULL - cannot access field 'addr_map'

        at line 114 in @vr_ad_sequence_h

       keep map_kind == value(driver.addr_map.kind);

 My concern here is , have cross checked address mapping and reg files, for me seems everything okay as per instructions.

 Do you have any idea about the above error? 

 One more query, the access policies support in your script file, do they all supported directly by vr_ad? 

Many Thanks

Thoufiq 

 Hello tauf,

I encountered the same error as you have and traced the cause to the RSD (Register Sequence Driver) not being properly connected to the BFM Sequence Drivers.
Take a closer look over possible pointer connections between sequence drivers, especially if you are using Virtual Sequence Drivers in combination with layered RSD and other BFM SDs.

Hope I was of help

Ionut Ciocirlan

Hi Stephan,

I am currently using vr_ad reg model in my environment, in one of my register bits are define as "Uninitialized" with 'U'. And it described in spec that it is read only and by doing read operation it should return 'U'.  It,s like unknow value X.

But according to vr_ad , all I can see is don,t care for reserved or unused bit which will return  either '0' or '1' by executing read operation.

Could you please tell me , is this policy possible i.e returning 'U' during read operation for that particular bit. 

Thanks

Thoufiq 

 updating the reg model from the testbench.