Overview
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
Architecture
Etherbone (EB) connects two Wishbone (WB) buses together as shown in the figure below. The WB Intercon is a local bus, for example a crossbar interconnect. When a WB master wishes to write to a remote slave, it writes to the EB bridge, which is a local WB slave. The bridge, acting as an EB master, translates the request into an EB frame and routes it to the receiving EB slave. That slave decodes the request and executes the write over Wishbone. Finally, the WB interconnect routes the write to the correct slave.
Either or both of the devices may be replaced by software, as shown in the figure below. In this scenario, the operating system buffers and sends Etherbone frames as requested by the Etherbone software library. Client applications may use this library for remote access to any slave attached to an Etherbone equipped wishbone bus. This facilitates such tasks as debugging, firmware updates, and monitoring from a dekstop system. Applications may also attach devices to a virtual wishbone bus, perhaps to capture bus cycles or trigger an alarm. These virtual devices may be mapped into the Wishbone bus of other Etherbone nodes, hardware or software.
Introduction
Etherbone is an FPGA-core that connects Ethernet to internal on-chip
wishbone buses permitting any core to talk to any other across Ethernet.
A software library is provided that permits any computer with an
Ethernet card to easily communicate with remote cores on the Etherbone
network. The Etherbone core implements a wishbone master and a wishbone
slave bus controller. With this scheme, any number of Etherbone
FPGA-cores and application software tasks can be connected together to
implement hybrid distributed networks of arbitrary complexity such as
field-buses, timing systems, or testbeds for hardware debugging.
Etherbone provides basic read, write and addressing functions. Etherbone
data transfers are initiated either by FPGA cores connected to the
Etherbone wishbone buses or by application software via the library. It
is within in these Etherbone Accessible Devices (EAD) that specific
cores may implement other levels of abstraction on top of Etherbone as
required. More information is available in the Document document.
Ebinternals.png
Work so far
Date | Event |
19-08-2010 | Project start. |
11-10-2010 | First functional spec draft released for comments. |
Outlook
The target date for a first implementation is March 2011. The functional spec should be approved at the end of October 2010 and the technical spec should be ready by December 2010.