|
# Overview
|
|
# Overview
|
|
|
|
|
|
Programmable hardware is increasingly deployed in large, physically
|
|
Programmable hardware is increasingly deployed in large, physically
|
|
distributed control systems.
|
|
distributed control systems. Hard real-time systems especially benefit
|
|
Hard real-time systems especially benefit from the determinism and low
|
|
from the determinism and low latency of purpose-built hardware. As
|
|
latency of purpose-built hardware.
|
|
reconfigurable hardware components replace traditional software-based
|
|
As reconfigurable hardware components replace traditional software-based
|
|
systems, those hardware components must often communicate directly, over
|
|
systems,
|
|
longer distances. While traditional protocols like CORBA and SOAP
|
|
those hardware components must often communicate directly, over longer
|
|
provide an excellent abstraction for software-to-software communication,
|
|
distances.
|
|
they are a poor fit for hardware-to-hardware communication. Hardware
|
|
While traditional protocols like CORBA and SOAP
|
|
components typically transfer information in read/write bus cycles as
|
|
provide an excellent abstraction for software-to-software
|
|
opposed to the procedure calling interfaces seen in software.
|
|
communication,
|
|
|
|
they are a poor fit for hardware-to-hardware communication.
|
|
The Etherbone protocol takes an existing bus standard (Wishbone) and
|
|
Hardware components typically transfer information in read/write bus
|
|
extends this bus to run over the network. A concrete bus standard was
|
|
cycles
|
|
chosen, because different bus protocols often differ enough that
|
|
as opposed to the procedure calling interfaces seen in software.
|
|
conversion reduces fidelity. Wishbone was chosen because it is an open
|
|
|
|
standard, simple, and pipelining. The underlying transport protocol is
|
|
The Etherbone protocol takes an existing bus standard (Wishbone)
|
|
left open, as Etherbone's requirements are easily met. This
|
|
and extends this bus to run over the network.
|
|
specification defines Etherbone for UDP and TCP.
|
|
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:
|
|
Etherbone's key features are:
|
|
|
|
|
... | @@ -54,38 +46,30 @@ Etherbone was designed for the following use cases: |
... | @@ -54,38 +46,30 @@ Etherbone was designed for the following use cases: |
|
|
|
|
|
# Architecture
|
|
# Architecture
|
|
|
|
|
|
Etherbone (EB) connects two Wishbone (WB) buses together as shown in
|
|
Etherbone (EB) connects two Wishbone (WB) buses together as shown in the
|
|
the figure below.
|
|
figure below. The WB Intercon is a local bus, for example a crossbar
|
|
The WB Intercon is a local bus, for example a crossbar interconnect.
|
|
interconnect. When a WB master wishes to write to a remote slave, it
|
|
When a WB master wishes to write to a remote slave,
|
|
writes to the EB bridge, which is a local WB slave. The bridge, acting
|
|
it writes to the EB bridge,
|
|
as an EB master, translates the request into an EB frame and routes it
|
|
which is a local WB slave.
|
|
to the receiving EB slave. That slave decodes the request and executes
|
|
The bridge, acting as an EB master,
|
|
the write over Wishbone. Finally, the WB interconnect routes the write
|
|
translates the request into an EB frame and routes it to
|
|
to the correct
|
|
the receiving EB slave.
|
|
slave.
|
|
That slave decodes the request and executes the write over Wishbone.
|
|
|
|
Finally, the WB interconnect routes the write to the correct slave.
|
|
![](/uploads/4c176d2f9bc9c9639617b7c38411a8cf/software.jpg)
|
|
|
|
|
|
attached\_image
|
|
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
|
|
Either or both of the devices may be replaced by software,
|
|
sends Etherbone frames as requested by the Etherbone software library.
|
|
as shown in the figure below.
|
|
Client applications may use this library for remote access to any slave
|
|
In this scenario,
|
|
attached to an Etherbone equipped wishbone bus. This facilitates such
|
|
the operating system buffers and sends Etherbone frames as requested by
|
|
tasks as debugging, firmware updates, and monitoring from a dekstop
|
|
the
|
|
system. Applications may also attach devices to a virtual wishbone bus,
|
|
Etherbone software library.
|
|
perhaps to capture bus cycles or trigger an alarm. These virtual devices
|
|
Client applications may use this library for remote access to
|
|
may be mapped into the Wishbone bus of other Etherbone nodes, hardware
|
|
any slave attached to an Etherbone equipped wishbone bus.
|
|
or software.
|
|
This facilitates such tasks as debugging, firmware updates, and
|
|
|
|
monitoring from a
|
|
hardware.jpg
|
|
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.
|
|
|
|
|
|
|
|
attached\_image
|
|
|
|
|
|
|
|
# Introduction
|
|
# Introduction
|
|
|
|
|
... | | ... | |