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 a 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?

Considering the merit of the existing format becomes crucial as the register specification incorporates more and more behavioral properties to the register fields, limiting your options when dealing with legacy data

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 make 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 the 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 a very small design size. However, most GUI solutions require users to click a lot to get anything entered. More importantly, the lack of cut-copy-paste-search, etc. makes 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 to 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 workbook, in CSV that’s not possible. All ASCII formats are useful for large numbers of data.

Do you need the team to enter data simultaneously?

This is a very important criterion to choose the format and the platform. 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 Sheets or Google Docs. Google Sheets 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 documents and low-level IPs in a separate Word or Excel file. This way multiple users can work simultaneously on the system specification. Excel 2013 files can 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, it's 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 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. If you perform a format conversion, you will need to redo it each time the IP vendor or group makes a change. However, referencing the IP can help avoid the need for the conversion step. 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 is for the creation of the spec and the OS is for the generation of the outputs. The following table describes the various outputs.

Bottom Line

As is evident in this article, the 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 SystemRDL, IP-XACT, RALF, CSV, XML, or any other proprietary format.
CSV: Comma Separated 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 the 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 specifications 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 users to create register specifications 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 can generate outputs from these files in 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 LibreOffice 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 sheets: IDS for Google Sheets.

IDS Mac/IDS WordMac : IDS for Word on Mac

IDS Mac/IDS ExcelMac : IDS for Excel on Mac
IP-XACT: It's 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: It's an industry standard created by Accellera for only registering information about IP and SoC. This standard is going through an upgrade.
RALF: This is a register standard created by Synopsys. It has a Tcl – 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 editing by the user.