Register interfaces are an essential pattern in chip design. They provide a way for sequential software to get information into and out of parallel hardware using memory address reads and writes. At conference many years ago (can’t recall if it was DAC or DesignCon) a panel was asked “what is the best way to measure the complexity of a chip?” One proxy mentioned was “the number of pages in the user documentation.” The register section is often the majority of the firmware programmers’ manual… confirming what you probably know… register interfaces are complex in a variety of dimensions. For the average hardware RTL coder, the register interface is typically not viewed as an object oriented model. We believe that IT SHOULD BE!
Object Oriented Programming (OOP) is well known for its ability to abstract complexity. A quote from Grady Booch (co-founder of Rational Software, IBM Fellow, and widely respected authority on software methodology) puts this into perspective:
… objects for me provide a means for dealing with complexity. The issue goes back to Aristotle: do you view the world as processes or as objects? Prior to the OO movement, programming focused on processes — structured methods for example. However, that system reached a point of complexity beyond which it could not go. With objects, we can build bigger, more complex systems by raising the level of abstraction — for me the real win of the object-oriented programming movement.[source]
If you took CompSci 101 you may have learned about the following principles of OOP:
- Inheritance - Classes of objects can be extended and specialized to reuse and override existing code. For example, an InterruptBitfield inherits from BitField to extend it to have specific attributes and behaviour.
- Encapsulation - Classes of objects have data and methods that they encapsulate. For example, a BitField has a bitWidth attribute.
- Polymorphism - Specific classes of objects should be able to play general roles. For example, an InterruptBitField instance can also play the role of a general BitField
Certainly most SystemVerilog users for design verification will be familiar with OOP, but I’m not sure about the RTL camp.
In building a data structure for modeling the hardware register interface, an OOP language is preferred. We chose Python since it’s interpreted with decent object orientation. It’s encouraging to hear that python is one of the 3 “official languages” at Google, alongside C++ and Java.
Another consideration with register automation, is how the specifications get persisted and exchanged? We were asking ourselves this question in 2004 when we learned of the SPIRIT Consortium which has a standard now know as IP-XACT, a XML Schema Definition (XSD) for SoC and IP metadata. For OOP based register specification, we infer from IP-XACT the classes of objects shown in the following SpectaReg Specification Object Model (SOM) diagram. The diagram is a UML class diagram that uses UpperCamelCase for defining the classes. We’ll use this convention for referencing classes in this blog.
This diagram of the SOM doesn’t show the new RegisterFile class of object which we’ll talk about another time.
In English the diagram reads as follows: A Component is composed of MemoryMaps which are composed of AddressBlocks, which are composed of Registers, which are composed of BitFields. Or in the other direction BitFields exist within Registers, and so on.
There are many different “types” of Registers in the universe of hardware/software Register interface specifications. The type of a Register’s contained BitFields specifies how the Register behaves in software and hardware. Such granular typing permits BitFields in the same Register to have different types.
We’ll continue this discussion in an upcoming posting to illustrate how the SOM simplifies the complexity of register implementation for both RTL and software engineers. This exists today at SpectaReg.com without requiring the user to write or install any software or feed any code into the register automation tool.