Register Bits

Meeting and talking with customers about their register needs and requirements is one of my favorite things to do.  Not too long ago I met with an embedded firmware guru over coffee and we discussed various topics about registers and register management tooling.  We discussed registers in the context of multi-processor system on chips (MPSoCs) with a lot of different interconnect channels or bridges and buses. In such a system, where there is concurrent software that may access the same registers, we discussed the pains of read-modify-write and how to reduce the need for such operations.  Some of our conclusions on this are discussed in this posting, which was spurred by one Gary Strigham’s recent Embedded Bridge issues.  Gary has hinted that his upcoming issue will discuss “an atomic register design that provides robust support for concurrent driver access to common registers” and I’m curious to see how his techniques compare to the ones discussed herein.

What is  a register read-modify-write operation?

Firmware often needs to modify only one single bit or bit-field of an addressable register without modifying other bits in the register.  This requires the firmware to read the register, change the desired bit(s), then write the register back.

Problem 1: Atomicity for register read-modify-write operation

In a system that has concurrent software accessing the registers, read-modify-writes are a real concern.  Without proper inter-process synchronization (using mutexes or some other form of guaranteed atomicity) there is a danger of race conditions.  These dangers are well described in Issue #37 of Gary Stringham’s Embedded Bridge.

Problem 2: Latency of read-modify-write operations

In a complex MPSoC, with a complex interconnect fabric, register read operations can be painfully slow when compared to pure register write operations.  System performance can be greatly improved by reducing the number of read operations required.

How to trade register read-modify-write transactions with a single register write

The trick to replacing the need for read-modify-write of a register with a register write operation is to create additional CLEAR and SET write-only registers.

Consider the following FLAGS register as an example which uses 8 bit registers for simplicity sake.

Without any supporting CLEAR/SET registers, to modify flag_f would require a read-modify-write operation. However, when we add the supporting CLEAR and SET write-only registers and related RTL logic then each bit can be set or cleared independently.  The flag_f bit can be set by writing 0×04 to FLAGS_SET and cleared by writing ox04 to the FLAG_CLEAR register.  The following table shows how the three related registers would look.

Here the complexities of read-modify-write in a concurrent software environment are traded for additional complexity within the Verilog or VHDL RTL code, and the related verification code. A register management tool like SpectaReg can be setup to allow easy specification of such register patterns in a graphical environment and auto-generation of the related RTL, verification code, and the firmware abstraction of the bits. With such a register management tool, the related work is greatly simplified when compared to the tedious and error-prone process of doing it manually.  An additional advantage relates to architectural exploration - with an automated path between the specification and generation it’s much easier to switch between the two techniques: i) a single read/write register requiring read-modify-write, and ii) a read only register with supporting SET and CLEAR registers.

In addition to register read-modify-writes discussed at the coffee talk with the firmware guru, we also chatted about how specialized hardware registers offer valuable diagnostics, performance profiling, optimization and debugging of MPSoC systems - perhaps a good topic for a future posting so stay tuned.

Lastly, if you have any thoughts to contribute, be sure to leave a comment.

A quick snapshot on the poll described in my previous posting: “for System-on-Chip developers, where is the greatest hardware/software register interface pain?”

Of the 71 votes thus far, 59% indicated that synchronizing the firmware, RTL, hardware verification, and documentation was the greatest pain.  Then 16% voted for register documentation and 16% for hardware verification (like SystemVerilog, Vera, e, SystemC).  The RTL (like Verilog & VHDL) for coding the register-map hardware logic was a pain for 4% of voters and firmware was a pain for 2%.  The live version of the poll is available here, and below is a screenshot of the graph.

Snapshot of LinkedIn poll graph

 
That only 2% voted for firmware is surprising to me since when asked where greatest value was received, a SpectaReg.com register-map automation customer indicated that 50% of the value was provided to the firmware developer.  As a result, I would expect that anyone without a register code generation solution would experience a lot of firmware pain.  Perhaps that’s a synchronization pain and the proper solution provides more value for firmware than any other aspect as a result of cross-team synchronization.

For the 41% that did not vote for synchronization, perhaps they have no register map code generation solution, whether it be commercial or homemade.  Perhaps their solution does not sufficiently provide enough value for the option that they voted for.

For the 59% that voted for synchronization, I wonder:

• How many have a common machine readable data format for specifying registers that can used to generate code?
• How many auto-generate all deliverables from a common source at the same time using the same code generation (metaprogramming) engine.
• How many have an in-house vs. commercial solution (like our SpectaReg.com/SpectaReg Onsite or Duolog’s BitWise, Delani’s Blueprint, or Semifore’s CSRCompiler).

Many more polls could be created on these topics.

People are very passionate and opinionated when it comes to in-house tools, open source, register specification file formats, and register-map methodologies in general.   There was heated discussions on LinkedIn about the following topics, which make for good future blog posts:

• Open source tooling for register address maps, could it work?
• Is SystemRDL really needed in addition to IP-XACT?
• Which comes first, the code or the spec?
• With an in-house register solution, where’s the pain? (relates to Opportunity cost in build vs. buy decisions

If you have thoughts to share, be sure to leave a comment for discussion.  There is some good meat here for future RegisterBits.com postings so stay tuned.

Did you know that LinkedIn allows users to create polls?  I discovered this today and created my first poll to ask my network of SoC developers where their greatest hardware/software register interface pain lies.  Is it the firmware, RTL, hardware verification, documentation, or is it synchronizing all the different perspectives around the common specification?

Click on the below image or link to have your say!  Tell your colleagues too, and of course if you have a comment for discussion post it here.

LinkedIn SoC Register Interface pain poll.

http://polls.linkedin.com/p/31486/ovmia

Update: Someone mentioned that they don’t understand the poll because they have an in-house solution that solves these pains. For those with an in-house solution, read the poll as “where is the greatest value from your in-house solution?” I suppose a sixth option, “my in-house solution is the biggest pain” should have also been an option too, especially now that there are commercial solutions available.

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.

We’ve decided to start a corporate blog at PDTi.  This inaugural posting is about something that’s near and dear to our hearts – using Software as a Service (SaaS) web applications for solving chip-development register automation needs. The most compelling benefits in using a SaaS business model for EDA include:

• Simplified use, support and maintenance
• Lower cost structure
• Expanded collaboration

By register automation, I’m referring to a class of tools that takes in addressable register specifications for defining the hardware interface.  This is the hardware interface that gets read and written by software.  This type of register interface goes by many different names.

Simplified use, support, and maintenance benefits come from the fact that the SaaS user can run the tool using a web-browser.  Users simply point their trusty browser to a URL, and login.  The tool vendor has complete control of the server hardware and software.  The vendor can add enhancements and fixes seamlessly, saving the end user a lot of work.

One obvious constraint with the SaaS model is data transfer requirements.  For the front-end of chip design, file sizes are not such a big issue since plain text VHDL, Verilog, SystemVerilog, and C/C++ files are relatively small.  For transferring larger files, like back-end physical design databases, the average HTTPS client/server connection may not be ideal.

Another factor that always comes up with SaaS is security.  One benefit with web-applications is that a lot of big enterprises have put a lot of money and time into how to secure web servers, and there is a lot of common knowledge in this area.  An enormous number of transactions per day occur securely over HTTPS around the world.

Intense vendor specialization and economies of scale provide the benefit of a lower cost structure.  Vendors know how to best develop, run, and maintain the tools they build.  With the vendor actively maintaining the tool, the cost structure can be lower for all parties.  Sharing the server-side compute resources among many users maximizes utility, reducing the compute nodes per user/project/company.  This also reduces the environmental costs of having un-utilized servers running.

The need for better collaboration in the chip-dev supply-chain is growing and SaaS helps to expand collaboration.   More companies are buying IP, selling IP, outsourcing work, using open-source projects, and in general collaborating with customers, partners, and suppliers.  The client/server architecture of web applications makes it possible to formalize this collaboration and make it consistently repeatable.

We have no doubts that register design automation is well suited for a SaaS business model.  In future postings we’ll examine what other types of existing and future EDA tools align with the SaaS model. If you have any thoughts on this leave a comment and let us know what you think.