XML provides language for hardware specification

We propose the use of XML for specifying and designing hardware. Many different methods for the specification of hardware designs are in use. The majority of these are based on either closed markup languages (word processors) or uncommon programming languages.

We recognize the need to formally express hardware specifications in a format that can be easily understood and shared by different teams having different functions. Hence, we adopt the universally accepted data interchange format XML.

A novel feature of our approach is that we can build a number of disparate applications that use XML as their central specification repository. In this paper we will discuss tools that we have created to automatically generate RTL and software code from the XML based hardware design specifications. We will also discuss a tool to display the entire design specification using a platform independent web-based GUI.

1 Introduction

Traditionally, hardware is specified using a word processing program. This has the following issues:

• The documentation is platform dependent. For example, when Microsoft Word is used as the documentation program, the user has to work on a Windows platform and can not view the data directly from the Unix environment.
• For large designs, the document becomes unmanageable. We currently have a design that is documented in two documents that total more than 15 MB in size. This is slow to load and to browse electronically.
• Because the data is stored in a closed markup language it is difficult for 3rd party tools to extract data from these documents.

We are proposing the use of an open markup language for documenting hardware. We have chosen XML as our format. XML stands for extensible markup language. It is based on an industry standard and is designed to overcome some of the limitations of HTML. The choice for XML connects well with the logical transition that is happening in the Web design community to transition from HTML to the more formal and better structured XHTML. With the use of XML the user may define new elements, for example hardware block, register or bitfield. XML is well defined by the World Wide Web Consortium and embraced and supported by IT organizations and software developers. Data can be viewed using standard web browsers that work on the different platforms such as Netscape, Internet Explorer, Mozilla, or Firefox.

Advantages of this approach are:

• It is platform independent and works in Unix, Linux, Apple OS X, and Windows. The data may be displayed on a variety of devices such as PCs, PDA's and other display devices.
• The use of a web application allows sharing of data with other organizations around the globe.
• The use of a standard facilitates data exchange between different groups or between customers and suppliers. It is easier to share data.
• The use of an open markup language usage allows access with 3rd party or in house developed tools.
• Crisp performance, even with large databases.
• XML is well suited to applications in which hierarchy exists. Chips are typically designed using this kind of hierarchy as depicted in Figure 1.

Figure 1 — Design hierarchy

Most hardware engineers are very familiar with Microsoft Word. At our site, they currently create the specification as a Word document. The document is then saved as a text file and a PERL program is used to extract the data and generate the XML database.

Other utilities access this database to create C/C++ include files that contain register and bit field declarations, Verilog code files that contain register and memory address label definitions, and assembly code files that contains register and bit field equate statements.

3 The structure of the XML database

The XML database for an IC consists of four separate but interrelated lists. These are described here.

The IC List contains specification information for the IC as a whole. This includes internal data bus widths, the name of the specification file, and a list of the memory (and register) blocks in the IC, referencing the Memory Block list.

The Memory Block List is a list containing each register and memory block in the IC with information specific to that block. Information in this list includes the block size (address space), the type of memory (RAM, ROM, Registers), bit width of a single access to the block, and a list of the registers in that block, referencing the Register List.

The Register List is a list of all the registers in the IC. Each entry in this list contains information specific to that register. Information in this list includes the parent register block, reset value, and text description of the register. This also includes a list of the bit fields in the register that references the Bit Field List.

The Bit Field List is a list of all the bit fields in the IC. Each entry contains information specific to that bit field. The information includes the bit field name, size, position, and access type (read-only, write-one-to-clear). Additionally, this database also contains functional information regarding the functionality of bit fields. For example, a certain bit field may act as a write enable bit for a register or for a different bit field.

The database is structured in such a way that each list references the other list. The bit field list entries, for example, know who their parent register is so data about the register can be obtained for a specific bit field.

The database, in this format, can be used by our intelligent Web interface to allow users to view the specification for the design. This means that a specification change can be made immediately available to engineers and customers at remote sites provided they have access to the web site that maintains the database.

Additionally, this data is used by utility programs to construct automatically generated and updated Verilog, C, C++, and assembly code for the IC. This means that, during the early development stages of the design, a change to the hardware can be reflected in the testbench, firmware, and assembly code by updating the specification, generating the database, and running the code generation utilities. Changes to the hardware, which occur often in the early stages, result in a minimal delay before the firmware and test bench also contain those changes. Previous to the use of this database, changes to hardware were extensive.

It was difficult to update the testbench and firmware dependent upon the update. Sometimes hardware changes would not be properly communicated to the testbench and firmware organizations, resulting in days of delay to debug an unexpected change in the hardware.

Figure 2 shows the relationship between design, XML and the various outputs from XML.

Figure 2 — The use of XML

Figure 3 has a sample of XML code as it is currently used:

Figure 3 — Sample XML code

4 Intelligent user interface for hardware specifications

Once the data is in XML format, we can think about how to best display it on a client's machine. One question is: Do we use client or server side data filtering and processing?

We assume that the data is stored in a central location, in our case a Unix based server. The data that the user wants to see is a subset of the database, for example the list of hardware blocks in the design or the list of registers in a block. This requires processing and filtering of the data.

After some experimentation we found that the client side processing, where the entire data base is sent from server to client to server and then processed on the client machine, is not practical. The transportation time for large data files is not acceptable.

Secondly, web browsers literally "freeze" when a large file is presented. The solution is to have all processing and filtering take place at a fast server, serve up the filtered data and use the browser for display in a nice form.

A second question that comes up is: Do we use declarational or procedural processing?

Declarational processing is where the data selection and filtering is described in a formal declaration, for example in an XSL file. We experimented with embedding an XSL directive in the XML file and then use XSLT (XSL transformation) to selectively filter and display the data. We observed that instead of using 3rd party XSL (XSLT) processors, the use of simple PERL scripts to process and filter the data is advantageous from a performance standpoint.

The result is a crisp user interface that uses a centralized database and serves the data up in a fraction of second. The user may see a screen that shows all the hardware blocks in a design or all the registers in a hardware block as demonstrated in Figure 4.

Figure 4 — Registers in a block

When the user clicks on the highlighted section, a request for a specific register is sent to the server, which then filters out the respective data and presents the following details of that register to the browser as shown in Figure 5:

Figure 5 — Register description

5 Directions for future development
We have shown a method that improves the documentation for increasingly complex chip designs. Our approach to date uses an intermediate step, where we take the data from an existing document and transform it to XML. In the future, when proficient XML editors are available, XML is the format of choice for the design specification.

In conclusion, we strongly believe that the use of open markup language standards such as XML have great advantages over more traditional documentation systems, and allow us to cope with larger designs while improving shared access to the data.

Leo Grassens is a senior staff engineer working for the Systems Verification group of the Storage Products Division at LSI Logic Corp. Leo graduated with a MSME from Technical University Eindhoven in the Netherlands and has been active in servo system design and storage device development for over 20 years.

Shankar Ranganathan worked as a systems engineer for the Systems Verification group of the Storage Products Division at LSI Logic Corp. He has a master's degree in Computer Science from the University of Kansas, and he specializes in data and information management. Currently, Shankar works for Verizon Data Services Inc, Irving, Texas.

David Fechser is a senior staff engineer working for the Systems Verification group of the Storage Products Division at LSI Logic Corp. He graduated with a BSEE from BYU and has been active in the ASIC Design and Verification for 22 years.