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

[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
reg_def SOURCE_ADDRESS DMA_ETH 0x4 {
  // 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);
    dma_eth.reset();
  };
};

Happy register testing everyone!

Steve Hobbs
Application Engineer
Cadence UK