Home > Community > Blogs > Functional Verification > new aeware generate vr ad definitions for ip xact xml ip blocks
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: *

New AEware: Generate vr_ad Definitions for IP-XACT XML IP Blocks

Comments(2)Filed under: e, Specman, Spirit, Register Package, vr_ad, IP-XACT

[Please welcome guest blogger Steve Hobbs, an Application Engineer in our Field Organization]

Hands-up those of you who hate creating and maintaining your vr_ad register definitions!

Pretty much all of you, I see...

No surprise really, as register maps get bigger and bigger, and with highly configurable design IP, you end up having several versions on the boil at once, each with a similar but not identical address map. Pretty much every company has a standard format for capturing their address maps in either some form of editor (Word, Excel, FrameMaker, etc.) or SQL.  Some people have the whole flow sorted out, building C/C++ headers, Verilog include files and documentation from their company format. All very nice but proprietary and no EDA tool will support the home-brew standards, there are simply too many!

For me the big surprise is how long it's taking for people to sort out this mess.  However, the industry has had a vendor-neutral standard for IP exchange for a few years now, in the form of SPIRIT XML (now known as IP-XACT).  EDA vendors have by and large adopted this in their system-design tools, but outside of the big semi firms few have heard of SPIRIT or IP-XACT.

Well, it's time for that to change! Design IP vendors are shipping IP-XACT descriptions with their RTL kits, making it quick and easy for systems integrators to plug the latest USB host controller into their SoC. The tools handle the hook-up and checking, and can even generate documentation and datasheets.  Unfortunately, verification has, as usual, been left behind, partly because tools haven't supported IP-XACT, but perhaps partly because the poor overloaded verification engineer doesn't have the time to play with new toys while his/her latest project is holding up tape-out...

I can feel this situation changing though, perhaps it's the start of a new era for verification automation?  In the space of just a few weeks, I've had requests for IP-XACT to vr_ad generators, from 3 different customers.  Thus, to address their needs I created a utility to parse the IP-XACT XML and produce a vr_ad register definitions file.  Like all good customers they threw it right back with a list of enhancement requests    That now done, I can offer the world at large a much enhanced translator -- stuff in an IP-XACT XML file at one end, and collect a nice fresh vr_ad file at the other, ready to run.

In fact it even generates a little test file to load in Specview to explore your shiny new model.

There are a number of options: you may filter out registers, in case you have lots of reserved registers defined in the XML.

You can also override any read/write access mode for a register or field to use any of the vr_ad access kinds, since not all of these are supported in IP-XACT.

Wait -- I hear a dissenting voice at the back saying "I don't have an XML file to use". Well, no matter!  IP-XACT is a pretty simple format, and whilst I wouldn't want to enter loads of registers by hand in that format, it's pretty easy to generate it from a script.  (And the more companies that build a parser between their proprietary formats and IP-XACT, the better.  After all, no EDA vendor can justify spending R&D time to develop custom translators, but they are all supporting industry standard formats like IP-XACT.)

I hope this inspires you, even if all you do is to bug your design manager and ask him/her why their team isn't delivering an IP-XACT file with their RTL...

To use the translator, download the ZIP file from the Cadence community site here: ipxact2vrad-0.7.zip

and uncompress it under Linux / Solaris (don't use Windows or it'll corrupt the files):

%> unzip ipxact2vrad-0.7.zip

Next, put the resulting ipxact2vrad-0.7 directory on your PATH variable.

In the package you'll find a RunMe.sh which runs a simple demo, translating the supplied XML file to vr_ad, then opening it in Specview.

There's a detailed README.txt too or you can run "ipxact2vrad.pl -help".

Finally, here's an example of the generated code, as you can see, it's pretty clean, in case you do end up editing it by hand!

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
// Parent   = DMA_ETH
// Offset   = 0x0
// Reset    = 0x00
reg_def COMMAND DMA_ETH 0x0 {
  // Field resv3 = command[31:29]; Read Only; resets to 0; coverage enabled
  reg_fld resv3 : uint(bits:3) : R : 0 : cov ;
  // Field transfer_size = command[28:19]; Read Write; resets to 0; coverage enabled
  reg_fld transfer_size : uint(bits:10) : RW : 0 : cov ;
  // Field dma_transfer_target = command[18:14]; Read Write; resets to 0; coverage enabled
  reg_fld dma_transfer_target : uint(bits:5) : RW : 0 : cov ;
  // Field resv2 = command[13:10]; Read Only; resets to 0; coverage enabled
  reg_fld resv2 : uint(bits:4) : R : 0 : cov ;
  // Field transmit_receive = command[9:9]; Read Write; resets to 0; coverage enabled
  reg_fld transmit_receive : uint(bits:1) : RW : 0 : cov ;
  // Field resv1 = command[8:5]; Read Only; resets to 0; coverage enabled
  reg_fld resv1 : uint(bits:4) : R : 0 : cov ;
  // Field dest_address_enable = command[4:4]; Read Write; resets to 0; coverage enabled
  reg_fld dest_address_enable : uint(bits:1) : RW : 0 : cov ;
  // Field source_address_enable = command[3:3]; Read Write; resets to 0; coverage enabled
  reg_fld source_address_enable : uint(bits:1) : RW : 0 : cov ;
  // Field word_size = command[2:0]; Read Only; resets to 0; coverage enabled
  reg_fld word_size : uint(bits:3) : R : 0 : cov ;

// Register = source_address
// Parent   = DMA_ETH
// Offset   = 0x4
// Reset    = 0x00
  // No fields defined in the XML
  // Field data = source_address[31:0]; Read Write; resets to 0x00; coverage enabled
  // Automatically added to fill undeclared bits
  reg_fld data : uint(bits:32) : RW : 0x00 : cov ;

extend XDMAC vr_ad_map {
  dma_eth : DMA_ETH vr_ad_reg_file;

  post_generate() is also {
    add_with_offset(0x00, dma_eth);

Happy register testing everyone!

Steve Hobbs
Application Engineer
Cadence UK


By Mike Smith on January 23, 2009
I agree completely with Steve that auto generation is the way to go, but for many an IP-XACT file is not that easy to create, as well formed IP-XACT XML is not that straight forward.

So instead of in-house scripts, why not consider commercial tools (such as Duolog:Bitwise, Beach:EASITools) that will do this for you?

They will give the added benefits of checking your data for syntactic and semantic errors, visualisation and easy capture, and ability to generate many other design views from the same data. They also mean you can concentrate on verification - rather than script writing and maintenance.  

By verifier on February 3, 2009
I would be surprised if any ASIC/SoC/Semi company that has register files/address maps worth thousands of pages does not use some sort of automation to generate the vr_ad register file(s).  We use XML as the data format that can be used to publish register documents, RTL code as well as vr_ad 'e' register files, and even address map generations using a register data automation standard and a custom TCL script. This automation process is very _critical_ when you have 40 million gates SoCs to verify that involve two dozen subsystems, and even more unit level blocks with their own register files.

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.