Different flows for UVM Register Generation

The UVM register model is an essential component of the UVM based verification for modern designs. In this article we discuss the various paths to create UVM register model. We at Agnisys help teams automatically generate the register model and over the years many teams have started using our tools. Often one of the first questions is for a team to decide what format to use. In this short article we describe the points to consider when choosing the format for data entry for the register specification. The article is written in a way that will enable you to quickly understand your options.

Do you have legacy data?

If you have legacy data, then your options are limited. The merit of the existing format has to be considered as more and more behavioral properties of register fields are added to the register specification.

Do you want to maintain the same format as the legacy data?

One of the reasons for keeping the legacy format and not attempting to move to a newer format could be the familiarity aspect. Perhaps you have scripts and other tools that consume that format. If you cannot instrument a change, then your options are limited.

If, however, you are free to change the format then, pick a format that is most suitable to you based on this article.

How important is ease of use?

Often ease of use is very important for something as basic as register data. For ease of use you may prefer Word or Spreadsheet data formats instead of requiring the team to learn a new language and its intricacies. Going to a GUI based solution may work for very small design size. However, most GUI solutions that require user to click a lot to get anything entered. More importantly lack of cut-copy-paste-search etc. make it quite hard to use.

Do you already use MS Word for specifications?

Microsoft Word is widely used in the semiconductor industry. Small teams to large use Microsoft Word for creating functional specifications. It is very convenient to have the register specification inside the functional specification. IDSWord can be the preferable choice because it is an add-in into Microsoft Word.

Do you have a very large number of registers/fields?

IDSExcel is a good option to quickly enter a large number of registers and fields in a systematic tabular manner. Excel’s powerful formulas and several editing aids help in quickly creating a register spec. You can also use CSV (Comma Separated Values), however, the advantage of Excel is that it can have several sheets in one work book, in CSV that’s not possible. All ASCII formats are useful for large number of data.

Do you need the team to enter data simultaneously?

This is a very important criterion to choose the format and the platform. Basically there are three possible options:

1. Use ASCII text file. An ASCII text file can be edited simultaneously by multiple people if a version control system is used – like Git, CVS, SVN etc. This is possible because the version control system can do diff and merge on the ASCII files. IDesignSpec supports several ASCII text file formats like SystemRDL, IP-XACT, RALF, CSV, XML, etc.
2. Use Google Sheet or Google Docs. Google Sheet and Google docs natively support simultaneous edits. IDesignSpec supports both Google Sheets and Google Docs (currently in beta).
3. Word and Excel can also be used for simultaneous edits. One generic option is to use SharePoint for multiple and simultaneous edits for both IDSWord and IDSExcel files.

Another option is to break up the spec into top level Word or Excel document and low level IPs also in a separate Word or Excel file. This way multiple users can work simultaneously on the system specification. Excel 2013 files can themselves be edited simultaneously by putting the files on a shared file system and selecting Review->Share Workbook.

Enabling simultaneous edits in various formats is one of the major features of IDS Enterprise Edition (IDS EE).

Do you mind learning a new language specifically for registers?

If you don’t mind learning a new language for registers then you can start with SystemRDL. SystemRDL is currently being revised by Accellera. However, IDesignSpec adds a lot of properties for describing the behavior of the registers/fields using the concept of User Defined Properties (UDP).

Are different IP specs coming from different sources?

It is possible that as an SoC developer your team gets IP specs in different formats from different sources. In that case it is important to understand what the format options are. For example, its quite likely that you will get IP specs in IP-XACT format. It is also possible that some legacy IP is described in Excel or in XML. In that case, you can either choose to convert all the formats to a single one of your choice, or choose a top level format to Reference the various formats without the conversion step. Note that if a format conversion is done, then every time the IP vendor or group makes a change, the conversion will have to be done again, however, if the IP is referenced, then the conversion step can be avoided. A top level format that can reference other types of formats is Word and Excel which does not require any conversion step. If a conversion is carried out then any top level format can be chosen.

What OS do you want to use?

Two aspects need to be considered here. The OS for creation of the spec and the OS for generation of the outputs. The following table describes the various outputs.

Bottom Line

As is evident in this article, IDesignSpec suite of tools is very versatile and could easily fulfill a lot of your requirements.

Glossary

ASCII : Plain text file. For registers this can be SystenRDL, IP-XACT, RALF, CSV, XML or any other proprietary format.
CSV : Comma Seperated Values is an ASCII format that can be hand edited (with a lot of pain) or generated using Excel or some script.
IDS : Refers to IDesignSpec – a tool created by Agnisys specifically for Addressable Registers and Memories.

IDS Batch : A tool which is World’s most versatile register generation tool. IDSBatch is available as a command line tool on all OS platforms (Windows, Linux (Red Hat, Ubuntu etc. ), Mac OS.

IDS Word : This is an Add-in for Microsoft Word. It helps the user create register specification in a hierarchical format inside Word and generate outputs from within Word. Word files created by IDSWord are 100% normal Word files. Outputs can be generated from these files using IDSBatch in a command line mode on any platform including Linux.
IDS Excel : This is an Add-in for Microsoft Excel. It helps user to create register specification in a hierarchical format inside Excel and generate outputs from within Excel. Excel files created by IDSExcel are 100% normal Excel files. Outputs can be generated from these files using IDSBatch in a command line mode on any platform including Linux.
IDS Cal : This is an Add-in for OpenOffice Calc – the spreadsheet tool for Open Source OpenOffice and LibraOffice Projects. Files created by IDSCal are 100% normal OpenOffice files. Outputs can be generated from these files using IDSBatch in a command line mode on any platform including Linux.
IDS EE : IDesignSpec Enterprise Edition
IDS FM : IDS add-in for FrameMaker
IDS gDocs : IDS for Google Docs.
IDS gSheets : IDS for Google Sheets.

IDS Mac/IDS WordMac : IDS for Word on Mac

IDS Mac/IDS ExcelMac : IDS for Excel on Mac
IP-XACT : Its an industry standard created by Accellera for storing information about IP and SoC. Information can be about Registers, IO, interfaces etc.

SharePoint : Microsoft’s platform for sharing files.
SystemRDL : Its and industry standard created by Accellera for only register information about IP and SoC. This standard is going thru and upgrade.
RALF : This is a register standard created by Synopsys. It has a Tcl – based Syntax.

XML : eXtensible Markup language. It’s an extensible format for storing arbitrary information in ASCII text format. It is typically used behind the scenes by the tools and not meant for direct edit by the user.