... | ... | @@ -130,14 +130,14 @@ sequence of WWWW...RRRR... operations in the pipeline without waiting. |
|
|
Alternatively, it might also use the sequence WRWRWR... to confirm each
|
|
|
word immediately after writing it. In both cases, the application can
|
|
|
issue all of the operations without waiting. This would not be possible
|
|
|
if the application were to iterate a remote function.
|
|
|
Suppose the application wants to compute f(f(f(...f(x)...))) using a
|
|
|
remote WB slave to calculate function f.
|
|
|
Here, the aplication writes x to the remote slave and reads back y =
|
|
|
f(x). Then the application writes y to the remote slave and reads back z
|
|
|
= f(y). The write pattern WRWRWR... is the same as the firmware loader,
|
|
|
but here we can only pipeline a single write-read operation pair
|
|
|
together. Until we have received the result f(x), we cannot issue f(y).
|
|
|
if the application were to iterate a remote function. Suppose the
|
|
|
application wants to compute f(f(f(...f(x)...))) using a remote WB slave
|
|
|
to calculate function f. Here, the aplication writes x to the remote
|
|
|
slave and reads back y = f(x). Then the application writes y to the
|
|
|
remote slave and reads back z = f(y). The write pattern WRWRWR... is the
|
|
|
same as the firmware loader, but here we can only pipeline a single
|
|
|
write-read operation pair together. Until we have received the result
|
|
|
f(x), we cannot issue f(y).
|
|
|
|
|
|
In Wishbone, several operations can be grouped into a single bus cycle.
|
|
|
A particularly bad situation that can occur is when dependencies appear
|
... | ... | @@ -157,69 +157,54 @@ addressed in the different implementation options described later. |
|
|
|
|
|
## Config Space
|
|
|
|
|
|
In addition to remote bus access,
|
|
|
Etherbone also provides a configuration space.
|
|
|
This config space is used to specify transmission parameters,
|
|
|
recover bus error status codes,
|
|
|
and match read results to the requests.
|
|
|
In addition to remote bus access, Etherbone also provides a
|
|
|
configuration space. This config space is used to specify transmission
|
|
|
parameters, recover bus error status codes, and match read results to
|
|
|
the requests.
|
|
|
|
|
|
The config space is an complementary 16-bit wide address space attached
|
|
|
to every EB slave.
|
|
|
EB requests can read/write to this configuration space in addition the
|
|
|
the normal WB bus.
|
|
|
The config space is divided up into two regions: the register space and
|
|
|
the implementation space.
|
|
|
All addresses in the register space correspond to EB control
|
|
|
registers,
|
|
|
specified in this document.
|
|
|
The register space spans addresses 0x0-0x7FFF.
|
|
|
The implementation space is guaranteed to be free for whatever use
|
|
|
a hardware/software implementation chooses.
|
|
|
The implementation space spans 0x8000-0xFFFF.
|
|
|
|
|
|
Two important registers in the address space include the error status
|
|
|
to every EB slave. EB requests can read/write to this configuration
|
|
|
space in addition the the normal WB bus. The config space is divided up
|
|
|
into two regions: the register space and the implementation space. All
|
|
|
addresses in the register space correspond to EB control registers,
|
|
|
specified in this document. The register space spans addresses
|
|
|
0x0-0x7FFF. The implementation space is guaranteed to be free for
|
|
|
whatever use a hardware/software implementation chooses. The
|
|
|
implementation space spans 0x8000-0xFFFF.
|
|
|
|
|
|
Two important registers in the address space include the error status
|
|
|
register, which reports WB error status codes, and the WB device map
|
|
|
pointer,
|
|
|
which provides information about the slaves attached to a remote bus.
|
|
|
The implementation space is typically used by an EB master to receive
|
|
|
the data which it read.
|
|
|
Reads to an EB device trigger a write back to the source EB device.
|
|
|
Those writebacks are often sent to the implementation space
|
|
|
where they can be handled by the EB core/code and invisible to the WB
|
|
|
bus.
|
|
|
|
|
|
\\subsection{Bus Widths}
|
|
|
|
|
|
In Wishbone,
|
|
|
a bus may have a port width that is 8/16/32/64 bits wide.
|
|
|
Thus, a master in one WB bus might write 32-bits at a time,
|
|
|
while a slave in another WB bus expects 16-bits at a time.
|
|
|
Etherbone makes no attempt to convert between differing port widths,
|
|
|
because converting a 32-bit write into two 16-bit writes might change
|
|
|
semantics.
|
|
|
|
|
|
However,
|
|
|
Etherbone does negotiate which port widths are acceptable to both
|
|
|
devices.
|
|
|
This mostly affects software,
|
|
|
which can meaningfully support access with different port widths.
|
|
|
Hardware implementations will typically advertise and accept only one
|
|
|
width.
|
|
|
|
|
|
Address spaces in WB are conceptually infinite,
|
|
|
but in practice are constrained to a fixed width.
|
|
|
Address width conversion, as oppposed to port width conversion,
|
|
|
is relatively straight-forward.
|
|
|
Address 0x0400 is that same as 0x00000400.
|
|
|
If a 32-bit device is accessed by a 16-bit device,
|
|
|
the 16-bit device can only see the low 16-bits of the larger device's
|
|
|
address space.
|
|
|
pointer, which provides information about the slaves attached to a
|
|
|
remote bus. The implementation space is typically used by an EB master
|
|
|
to receive the data which it read. Reads to an EB device trigger a write
|
|
|
back to the source EB device. Those writebacks are often sent to the
|
|
|
implementation space where they can be handled by the EB core/code and
|
|
|
invisible to the WB bus.
|
|
|
|
|
|
## Bus Widths
|
|
|
|
|
|
In Wishbone, a bus may have a port width that is 8/16/32/64 bits wide.
|
|
|
Thus, a master in one WB bus might write 32-bits at a time, while a
|
|
|
slave in another WB bus expects 16-bits at a time. Etherbone makes no
|
|
|
attempt to convert between differing port widths, because converting a
|
|
|
32-bit write into two 16-bit writes might change semantics.
|
|
|
|
|
|
However, Etherbone does negotiate which port widths are acceptable to
|
|
|
both devices. This mostly affects software, which can meaningfully
|
|
|
support access with different port widths. Hardware implementations will
|
|
|
typically advertise and accept only one width.
|
|
|
|
|
|
Address spaces in WB are conceptually infinite, but in practice are
|
|
|
constrained to a fixed width. Address width conversion, as oppposed to
|
|
|
port width conversion, is relatively straight-forward. Address 0x0400 is
|
|
|
that same as 0x00000400. If a 32-bit device is accessed by a 16-bit
|
|
|
device, the 16-bit device can only see the low 16-bits of the larger
|
|
|
device's address space.
|
|
|
|
|
|
Address width is negotiated by Etherbone simply to determine the amount
|
|
|
of
|
|
|
space to reserve for message exchanges.
|
|
|
A hardware implementation is free to only advertise address widths
|
|
|
whose message alignment is convenient to them.
|
|
|
of space to reserve for message exchanges. A hardware implementation is
|
|
|
free to only advertise address widths whose message alignment is
|
|
|
convenient to them.
|
|
|
|
|
|
# Work remaining
|
|
|
|
... | ... | |