Register Bits

In engaging with companies about register-map automation, it amazes me how many engineers think that because they have an in-house register solution, or because they could build one, that this route makes the most sense. Although there are some people that get it, quite often engineers fail to take opportunity cost into consideration (sunk costs too, but I’ll cover that in another posting). I’ll explain via an example…

Picture this; an engineering team needs a register automation tool for developing a new ASIC that is the highest performance XYZ. Their options are:

1. License one of the commercially available register tools
2. Build a register generation tool from scratch, or
3. Do the registers manually

The engineering manager estimates the costs of the different options using an hourly rate per engineer vs. the licensing costs for the commercial tool. Due to the fact that the commercial tool is shared among several companies who subsidize its ongoing development, it’s priced lower than the cost of creating an in-house solution. For argument sake, though, let’s assume that somehow the manager estimates that option 2 is cheaper by some accounting magic. Forget about option 3, the ASIC has way too many registers to do manually, so that’s out of the question.

The engineering manager chooses option 2 because, in this strange, imaginary, upside down world of magical accounting, the cost of building an in-house tool is less than the cost of buying a commercial one. Reasonable right?

Wait a minute, maybe not…

The company’s core competency is building high-performance XYZ products, not building, testing and supporting tools. That tool building dilutes focus. What is the cost of forgoing the opportunity to focus as intensely as possible on building the best and highest possible performance XYZ? That’s a bit harder to quantize, but it is a cost. That’s the opportunity cost!

What happens if the competition chooses option 1, and smokes the company in terms of performance? How much does that cost in the long run?

If the manager had decided to go with option 1 — licensing a commercial register tool — that would enable the team to focus more effort on building a better, higher performance XYZ product. That extra focus would enable the company to be more differentiated from their competition, ensuring their dominance and their ability to demand higher profit margins. It’s this differentiation that provides competitive advantage in the marketplace.

One other way to think about it is that differentiating value-added efforts have a greater return on investment (ROI) than non-differentiating efforts.

Something to think about, next time you have an option that would enable more intense focus on differentiating core competencies.

Stay tuned for more postings on the economics of build vs. buy engineering decisions.

This posting examines how object-oriented typing of BitFields abstracts implementation details, and provides extensibility and simplicity.  This is the second in a series of postings.  The first posting provided background info on using object orientation for register specification and code generation.

With SpectaReg, one of the questions that always comes up is “how do I specify the type of register?”

How does one specify that a particular BitField is a read-only status bit, vs. a read-write flop-based control BitField vs. some other type?  With the SpectaReg register generation tool…

1. Register type selection is easily done using the web GUI (or through XML)
2. Register typing is generally done at a BitField-level of granularity
3. Types are defined in an object oriented hierarchy
4. Types can have custom attributes including references to other instances
5. New types/classes can easily be added with some open Python
6. The code generation layer works at the most abstract level that is applicable, to maximize core reuse (thanks to inheritance and polymorphism)

A clarifying example:

To keep things simple, assume an SoC team only uses three types of BitFields in their register maps as defined by the following table.  In reality there would be many more types.

Now, in SpectaReg’s Specification Object Model (SOM) these types of BitFields would be mapped into the following class hierarchy, all inheriting from the BitField base class (i.e. the IP-XACT field element).

Register BitField Class Hierarchy

The WatchedExportedFlopBitField is a specialized type of ExportedFlopBitField, which is a type of ReadWriteBitField, which is a FlopBitField, which is a type of BitField.  As is typical for object orientation, “is a” represents inheritance relationships.

Say the user wants to create a new WatchedExportedFlopBitField in an unused bit-space of an existing register.  The user would create a new BitField and tag it with the specific WatchedExportedFlopBitField class using the GUI widget shown in the following screen shot.

BitField Class/Type Selection Widget

At the code generation layer, such inheritance-based typing really simplifies things.  For creating the synthesizable Verilog and VHDL RTL code, the generation layer needs to know specific class typing to create the implementation of the WatchedExportedFlopBitField.  For the firmware and documentation generation, such detail is not required, so the code generation can work at a more abstract ReadWriteBitField classification level.  This is the beauty of polymorphism — the code-generation templates that need specifics can get into the details whereas the ones that don’t can keep it simple.  Keeping it abstract leads to more re-use and less complexity.

Of course, SpectaReg supports many different types/classes of BitFields other than those dicsussed here.  What Register and BitField types do you use in your design?

A SpectaReg.com customer, generally happy with the user experience and beneficial value of the register-map tool, indicated that if we want to win more customers, we should think about improving the styling.

Before restyling.

“It looks like an engineer styled it,” the customer said.  “It needs more rounded corners.”

Being a practical engineer, all that really matters is functionality… right?

Well, not entirely.  To get that first date, one needs a bit of style.  Certainly, a company like Apple spends a good deal of time and money on style, and they get results.  In the world of snowboarding, skateboarding, and surfboarding, style is paramount — executing the most difficult move doesn’t earn street credit without style.

“There were surfers with good style… and there were surfers that we would call cockroach style, or no style,” said Jim Muir in the legendary skateboard documentary Dogtown and Z-Boys. “If you had a bad style… right there you had one mark against you…”

Our user was telling us that we had one point against us, so a web style consultant was challenged to help improve SpectaReg’s style without requiring radical changes to the underlying code.

After Some Restyling -- rounded tabs, new icons to replace text links, etc.

A little time and effort on style really made a big difference — we don’t want cockroach style and we’re improving on it more and more.

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!

In the center of the `School of Athens' by Raphael are Aristotle and Plato, Aristotle's hand level to the Earth symbolizing his realism view of Nature; Plato's hand pointed towards the heaven symbolizing the mystical nature to his view of the Universe. This image symbols the sharp change in the meaning of how `natural philosophy' or physics will be done for the 2,200 years.

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.

Specification Object Model (SOM) base classes from IP-XACT

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.