Skip to content

M
Mock Turtle
Commit 4aed5504 authored by Konstantinos Blantos's avatar Konstantinos Blantos Committed by Dimitris Lampridis
Browse files
Options

Resolve "Document external RMQ interface"

parent b177b614
Hide whitespace changes
Inline Side-by-side
Showing with 84 additions and 5 deletions
.reuse/dep5
View file @ 4aed5504
......@@ -3,7 +3,7 @@ Upstream-Name: Mock Turtle
Upstream-Contact: Federico Vaga <federico.vaga@cern.ch>
Source: https://www.ohwr.org/project/mock-turtle
Files: doc/conf.py doc/*.rst doc/*.svg doc/*.cdr doc/*.txt doc/*.tex doc/*.eps
Files: doc/conf.py doc/*.rst doc/*.svg doc/*.cdr doc/*.txt doc/*.tex doc/*.eps doc/*.png
Copyright:2019 CERN (home.cern)
License: CC-BY-SA-4.0+
......
doc/hdl/index.rst
View file @ 4aed5504
......@@ -44,11 +44,16 @@ structure the command: ``git submodule``.
The output of this command should look something like this::
8e7e01ef56a4af08f29fbe86f0166edd30ab903d hdl/ip_cores/general-cores (wrpc-v4.2-32-g8e7e01e)
e7cd73db41ba056ed4b27731c21a3b2aa53eaa51 hdl/ip_cores/gn4124-core (v2.0-21-ge7cd73d)
f692bc83f42ffd54496f9e0da571c6f9dfcf2335 hdl/ip_cores/ddr3-sp6-core (v2.0.1)
b84c76be1eee1e987a0ff9947b5627d58e935f3f hdl/ip_cores/general-cores (Master)
d265dc5d0cbfe84bd5d310982e1a319a26bb53b2 hdl/ip_cores/gn4124-core (v3.1.1)
134759b20e8fa5241d3a3424393c6fbdfb66c6df hdl/ip_cores/urv-core (v0.9-32-g134759b)
a120e2262e1cb23fa611dddb7fa3727b520a125c hdl/ip_cores/vme64x-core (v2.0-6-ga120e22)
d4b42139d3cf88ebbc3bb78eb718db9f5dcce305 hdl/ip_cores/wr-cores (wrpc-v4.2-2-gd4b4213)
a0ca042e1f3c19a81c3594477c0c811ac761aaa4 hdl/ip_cores/vme64x-core (v2.2)
63d6e85c292e57360fe106acfd08de66d3c0acb7 hdl/ip_cores/wr-cores (wrpc-proposed-master)
c91efa5e378b0b65a0f4fff9729079007d99ba57 hdl/ip_cores/svec (v3.0.0)
affb718e16fd0336f262441bf9f7ae7e570d55c6 hdl/ip_cores/spec (v3.0.0)
65e80de29a85668bdf2f60539a413fe2889b5141 hdl/ip_cores/urv-core (urv-v1.1)
.. important::
Even if you do not intend to follow the same approach in your project, you
......@@ -387,6 +392,9 @@ VHDL records, defined in **mock_turtle_pkg** (for the first array dimension) and
subtype t_mt_stream_source_in is t_mt_stream_sink_out;
subtype t_mt_stream_source_out is t_mt_stream_sink_in;
For an example of the RMQ protocol and how the signals should be in order to write and read a frame
in the RMQ, have a look at the waveforms presented in `Remote Message Queues`_ section.
For an example of an end-point, please have a look at the provided Ethernet end-point, available
under *hdl/rtl/endpoint/mt_ep_ethernet_single.vhd*.
......@@ -440,6 +448,77 @@ console_irq_o
See also the :ref:`demo projects<demo>` for actual examples of MT instantiation.
Remote Message Queues
=====================
Remote Message Queues (RMQ) are used to allow MockTurtle CPUs to communicate
with the external world (e.g. over a communication link). In order to use them,
you have to connect the ``rmq_endpoint`` signals when you instantiate the
MockTurtle core. An example connection with 2 CPUs and each CPU having one slot
is shown below::
p_multiple_rmq_assign : process (rmq_endpoint_out, rmq_snk_out, rmq_src_out, index)
begin
case index is
when x"00" =>
rmq_src_in <= rmq_endpoint_out.snk_out(0)(0);
rmq_endpoint_in.snk_in(0)(0) <= rmq_src_out;
rmq_endpoint_in.src_in(0)(0) <= rmq_snk_out(0)(0);
when x"01" =>
rmq_src_in <= rmq_endpoint_out.snk_out(1)(0);
rmq_endpoint_in.snk_in(1)(0) <= rmq_src_out;
rmq_endpoint_in.src_in(1)(0) <= rmq_snk_out(1)(0);
when others =>
rmq_src_in <= rmq_endpoint_out.snk_out(0)(0);
rmq_endpoint_in.snk_in(0)(0) <= rmq_src_out;
rmq_endpoint_in.src_in(0)(0) <= rmq_snk_out(0)(0);
end case;
end process p_multiple_rmq_assign;
-- RMQ signals coming from MT
rmq_snk_in(0)(0) <= rmq_endpoint_out.src_out(0)(0);
rmq_snk_in(1)(0) <= rmq_endpoint_out.src_out(1)(0);
.. figure:: ../img/write-to-rmq.png
:name: fig-rmq-wr
:align: center
Write to RMQ.
:numref:`Figure %s <fig-rmq-wr>` shows how to send data to a MockTurtle CPU
through an RMQ, from the point of view of the remote device attached to the RMQ.
The `valid` flag should be asserted when either the `hdr` or the `dat` contains
valid data. The `last` flag is used to indicate the end of a frame. In case of
an error, you should assert the `error` flag (while maintaining the `valid` flag
asserted) to discard the full frame. The MockTurtle CPU will use `ready` to
indicate whether it can accept new data (`pkt_ready` is currently not used).
.. important:: Even though the `hdr` and `dat` fields in :numref:`fig-rmq-wr`
are 32 bits, only the last 16 bits are valid, the upper 16 bits will
always contain zeros.
Similar behavior can be seen also in the read from RMQ case as it is shown in
the below figure:
.. figure:: ../img/read-from-rmq.png
:name: fig-rmq-rd
:align: center
Read from RMQ.
:numref:`Figure %s <fig-rmq-rd>` shows how to receive data from a MockTurtle CPU
through an RMQ, again from the point of view of the remote device attached to
the RMQ. The protocol is mostly the same as in the previous case. The only two
differences are that:
a) The `hdr` is always only one clock cycle long.
b) All 32 bits in the `hdr` field are used. If the firmware running in the
MockTurtle CPU needs to send a longer header, the remaining bytes should be
placed in the payload. Note that `dat` still only uses the lower 16 bits, as
in the previous case.
White Rabbit Support
====================
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment