Bus Arbitration

[See Notes, below.]

Bus Arbitration: Manners Between Devices

We just had a fairly involved discussion involving how to manage a multi-mastering I2C bus with the addition of devices that aren't powered from the bus and can't detect when power is removed from the bus.

The original arbitration pretty much followed the ACCESS.bus spec with our own proprietary twists, one of which involved a host that could kill the whole bus and restart all the devices by restoring power to the bus. The host was king, and traffic on the bus would continue until something violated the conditions permitted by the host. No device could just yammer, since the host would kill the power. If a device misbehaved every time the power was applied, the reset reports would attract the attention of the dreaded maintenance personnel.

We came up with a number of conversational protocol tweaks to allow well-behaved participation by a mixture of bus-powered and self-powered devices.

The host could no longer kill the power to reset everyone. The resulting protocol was much more "democratic" (oh, please, don't use that word) and the host was now only king because the other citizens of the bus allowed it. The interaction became much (!) messier and much more state had to be tracked, and each device had to be more sensitive to the "body language" of the others.

Yes, this is boring to those who don't have to manage the signaling of I2C or USB, but it drew my attention of the whole business of manners in general.

Which (of course) led to wiki manners.

What we discovered in the bus arbitration discussions [hmmm, meta-arbitration] was that, when no single device has life-and-death control of the bus, useful traffic and error recovery is only achieved when all the devices on the bus cooperate and behave according to the rules. A much higher degree of "device personal responsibility" is required when there's no king to kill the offenders. A single misbehaving device can render the whole bus useless.

None of this has any bearing on wiki.

At all.

No, really. (tm)

-- GarryHamilton

In the tradition of "so well factored we no longer think about it at our level" BusArbitration is one of those things that SystemsDesigners? and DeviceDriver writers worry about, but that software engineers and programmers don't.

The basics of bus arbitration are visible in things as simple as the "hallway" between rows in a CubeFarm, where people have to step aside to allow others to pass.

Bus arbitration has many of the same requirements as task and thread management in multi-everything systems.

In the end, it's an almost mathematical expression of manners.

May I humbly suggest it's a topic worthy of more attention that it gets.

NOTES:

Some think this page is mildly interesting, but doesn't fit into the C2 sphere of discussion.
The alternative agument to the above is that bus arbitration is the basis of hardware/firmware resolution to concurrency conflicts. As such, it is an important part of the "science" of Computer Science, and a topic worthy of study and discussion.

CategoryHardware