Register Bits

In English Bay off West Point Grey in Vancouver lies an ideal spot for catching Dungeness Crabs - a wonderful delight to eat.  My first experience crabbing was dropping a trap off a friend’s boat en route to Chinook Salmon fishing in the Geogria Straight.  It’s not unusual to catch your limit on Spanish Banks if you know what you’re doing and to buy the equivalent at the local fish market will cost you almost $100.

View Larger Map

Dungeness Crabs

This summer some friends and I went out in Kayaks and were quite successful at catching our limits.  Google maps on the iPhone helped us to locate the trap after a paddle around the bay.  Being on the water with a 3G connected smartphone is pretty handy.

On another occasion, while trolling on a Salmon fishing mission after having dropped the trap, we pondered how many crabs had entered the trap. At the same time internet radio streamed care of the iPhone’s 3G internet. I got thinking how cool it would be if we had a 3G link to a web camera down below to show us what was inside.  Next thing you know I was drawing up plans for an autonomous crabbing vessel.

Continue reading…

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.

This is a technical posting for the firmware readership.

One of the most elegant ways of expressing register bit-fields in C/C++ firmware is using a union of a struct with a register word.  The problem with this is that there is no standard way for representing the bit field packing/ordering in C/C++, which restricts portability across compilers and architectures.  For the simple traffic light controller (TLC) example with the register-map shown here, the LightState Register’s Green, Amber and Red bit-fields can be represented as shown below, assuming most to least significant bit packing.

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned : 29;
        volatile unsigned green : 1;
        volatile unsigned amber : 1;
        volatile unsigned red : 1;
    } fields;
    volatile u32 reg;
};

If the bit-order packing is reversed, then it needs to look as follows:

union TLC_STATUSREGISTERS_LIGHTSTATE {
    struct {
        volatile unsigned red : 1;
        volatile unsigned amber : 1;
        volatile unsigned green : 1;
        volatile unsigned : 29;
    } fields;
    volatile u32 reg;
};

The reversal of the bit fields can be done using auto-generation based on a bit-ordering condition with a register automation tool like SpectaReg.  For non-generated static code, it can be accomplished using #ifdefs, and sometimes compiler pragmas.

The most portable way to deal with register bits in C/C++ is NOT to use this struct/union fanciness — instead do the required masking (and possibly shifting) using bitwise operators.  SpectaReg produces both the struct/union format and also the shift/mask format. How does the RegisterBits readership do it?