Programmable hardware is increasingly deployed in large, physically distributed control systems. Hard real-time systems especially benefit from the determinism and low latency of purpose-built hardware. As reconfigurable hardware components replace traditional software-based systems, those hardware components must often communicate directly, over longer distances. While traditional protocols like CORBA and SOAP provide an excellent abstraction for software-to-software communication, they are a poor fit for hardware-to-hardware communication. Hardware components typically transfer information in read/write bus cycles as opposed to the procedure calling interfaces seen in software.

The Etherbone protocol takes an existing bus standard (Wishbone) and extends this bus to run over the network. A concrete bus standard was chosen, because different bus protocols often differ enough that conversion reduces fidelity. Wishbone was chosen because it is an open standard, simple, and pipelining. The underlying transport protocol is left open, as Etherbone’s requirements are easily met. This specification defines Etherbone for UDP and TCP.

Etherbone’s key features are:

• Bus-cycle interface
• Deterministic latency
• Simple hardware implementation
• Cut-through/wormhole operation
• Compatible with software implementations
• Separate config/control address space
• Negotiable bus/address widths

Etherbone leaves these issues to the lower transport layer:

• Exactly once delivery (TCP or reliable layer 2)
• Cut-through switching
• Authentication (physical access or TLS)
• Confidentiality

Etherbone was designed for the following use cases:

• High-precision system control
• Sensor data acquisition
• System diagnostics
• Remote debugging
• Distributed bus bridging

Contact