Skip to content
Projects
Groups
Snippets
Help
Loading...
Sign in
Toggle navigation
M
Mock Turtle
Project
Project
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
1
Issues
1
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
Wiki
Wiki
image/svg+xml
Discourse
Discourse
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
Projects
Mock Turtle
Commits
5e7c1f14
Commit
5e7c1f14
authored
Sep 10, 2018
by
Dimitris Lampridis
Browse files
Options
Browse Files
Download
Plain Diff
Merge branch 'master' into proposed_master
parents
0aed2e03
5c0d2ab3
Hide whitespace changes
Inline
Side-by-side
Showing
49 changed files
with
175 additions
and
134 deletions
+175
-134
README.rst
README.rst
+16
-1
mt_defconfig
demos/alarm_clock/firmware/fw-01/configs/mt_defconfig
+1
-0
mt_defconfig
demos/data_generator/firmware/fw-01/configs/mt_defconfig
+1
-0
mt_defconfig
...spec-carrier/software/firmware/fw-01/configs/mt_defconfig
+1
-0
mt_defconfig
...spec-carrier/software/firmware/fw-02/configs/mt_defconfig
+1
-0
mt_defconfig
...svec-carrier/software/firmware/fw-01/configs/mt_defconfig
+1
-0
mt_defconfig
...svec-carrier/software/firmware/fw-02/configs/mt_defconfig
+1
-0
mt_defconfig
demos/hello_world/firmware/fw-01/configs/mt_defconfig
+1
-0
mt_defconfig
...hello_world_framework/firmware/fw-01/configs/mt_defconfig
+2
-0
Makefile
doc/Makefile
+6
-4
architecture.rst
doc/architecture.rst
+17
-16
conf.py
doc/conf.py
+1
-0
fmc-spec-carrier.rst
doc/demos/fmc-spec-carrier.rst
+1
-1
fmc-svec-carrier.rst
doc/demos/fmc-svec-carrier.rst
+1
-1
index.rst
doc/demos/index.rst
+3
-0
glossary.rst
doc/glossary.rst
+1
-1
index.rst
doc/hdl/index.rst
+4
-4
firmware-framework.rst
doc/software/firmware-framework.rst
+8
-8
firmware-library.rst
doc/software/firmware-library.rst
+1
-1
index-fw.rst
doc/software/index-fw.rst
+1
-1
index.rst
doc/software/index.rst
+5
-5
linux-driver.rst
doc/software/linux-driver.rst
+14
-25
linux-library.rst
doc/software/linux-library.rst
+5
-5
linux-python.rst
doc/software/linux-python.rst
+1
-1
protocol.rst
doc/software/protocol.rst
+8
-8
mockturtle-buffer.rst
doc/tools/mockturtle-buffer.rst
+1
-1
mockturtle-ping.rst
doc/tools/mockturtle-ping.rst
+1
-1
mockturtle-variable.rst
doc/tools/mockturtle-variable.rst
+1
-1
svec_mt_demo.ucf
hdl/syn/svec_mt_demo/svec_mt_demo.ucf
+11
-8
svec_mt_demo.vhd
hdl/top/svec_mt_demo/svec_mt_demo.vhd
+14
-19
CONTRIBUTING.md
software/CONTRIBUTING.md
+0
-1
LICENSE
software/LICENSE
+0
-1
Kconfig.mt
software/firmware/Kconfig.mt
+11
-3
mockturtle-framework.c
software/firmware/framework/mockturtle-framework.c
+1
-1
mockturtle.h
software/include/mockturtle.h
+2
-2
mockturtle-hmq.c
software/kernel/mockturtle-hmq.c
+1
-1
libmockturtle-rt-msg.c
software/lib/libmockturtle-rt-msg.c
+4
-4
libmockturtle.c
software/lib/libmockturtle.c
+15
-9
mt_defconfig
tests/firmware/config_rom/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/cpu-byte-addressing/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/cpu-loop/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/cpu-notify/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/hmq-async-recv/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/hmq-async-send/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/hmq-purge/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/rmq-udp-send/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/rt-frm/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/serial/configs/mt_defconfig
+1
-0
mt_defconfig
tests/firmware/sim-verif/configs/mt_defconfig
+1
-0
No files found.
README.rst
View file @
5e7c1f14
...
...
@@ -102,7 +102,7 @@ external world because it’s already part of the Mock Turtle framework.
.. _introduction:when-do-not-consider-mock-turtle:
When
D
o Not Consider Mock Turtle
When
T
o Not Consider Mock Turtle
--------------------------------
The Mock Turtle soft-CPUs have limited computation power, this precludes
...
...
@@ -112,3 +112,18 @@ If you really want to use Mock Turtle for dsp analysis, please consider
the development of a dedicated gateware core to perform the dsp analysis
and to use the Mock Turtle as a control system for the dsp gateware
core.
Where To Get Mock Turtle
========================
Mock Turtle is officially hosted on the `Open Hardware Repository`_:
`Mock Turtle`_. This project is distributed as a git repository which can
be cloned using the following command::
git clone https://@ohwr.org/gitolite/hdl-core-lib/mock-turtle.git
In it you can find all sources: HDL, software, demos, tests and this
documentation.
.. _`Open Hardware Repository`: https://www.ohwr.org/
.. _`Mock Turtle`: https://www.ohwr.org/projects/mock-turtle/repository
demos/alarm_clock/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/data_generator/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/fmc-spec-carrier/software/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/fmc-spec-carrier/software/firmware/fw-02/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/fmc-svec-carrier/software/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/fmc-svec-carrier/software/firmware/fw-02/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/hello_world/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
demos/hello_world_framework/firmware/fw-01/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,8 @@ CONFIG_FPGA_APPLICATION_ID=0
CONFIG_RT_APPLICATION_ID=0
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
doc/Makefile
View file @
5e7c1f14
...
...
@@ -45,12 +45,14 @@ else
endif
# List of Doxygen folders to consider
DOXINPUT
=
../software/lib ../software/firmware ../software/include
DOXEXCL
=
../software/firmware/scripts ../software/lib/PyMockTurtle ../software/kernel
DOXINPUT
:=
../software/lib
DOXINPUT
+=
../software/firmware/lib
DOXINPUT
+=
../software/firmware/framework
DOXINPUT
+=
../software/include
DOXEXCL
:=
../software/lib/PyMockTurtle
# List of actual Doxygen source files
FINDEXCL
=
$
(
foreach xdir,
$(DOXEXCL)
,
!
-path
"
$(xdir)
"
)
DOXSRC
=
$(
shell
find
$(DOXINPUT)
-type
f
$(FINDEXCL))
DOXSRC
=
$(
shell
find
$(DOXINPUT)
-type
f
-name
'*.[chS]'
)
.doxystamp
:
$(DOXSRC)
GIT_VERSION
=
$(GIT_VERSION)
DOXINPUT
=
"
$(DOXINPUT)
"
DOXEXCL
=
"
$(DOXEXCL)
"
doxygen ./doxygen-trtl-config
...
...
doc/architecture.rst
View file @
5e7c1f14
...
...
@@ -17,20 +17,20 @@ The following figure shows an overview over the Mock Turtle architecture.
Mock Turtle Architecture Overview. The blue and orange blocks are
Mock Turtle components (respectively software and gateware cores).
Gr
a
y blocks are external components (gateware cores or software)
Gr
e
y blocks are external components (gateware cores or software)
developed by the user. In purple any external world communication
over the network.
This document tries to provide a big overview of what Mock Turtle offers
and what is important to know when designing a Mock Turtle application.
For more information read the dedicated chapt
s for the different parts
For more information read the dedicated chapt
ers for the different parts.
Mock Turtle Core
==================
Mock Turtle can have one or more core
. A single cor e
is made of the following
Mock Turtle can have one or more core
s. A single core
is made of the following
components: soft-CPU, Serial console and message queues.
Soft-CPU
...
...
@@ -41,12 +41,12 @@ just a CPU without any sort of integrated peripheral. This is where the firmware
runs. Any kind of bus controller, or device must be connected externally as a
:ref:`device peripheral<arch:dp>` and driven from the firmware.
Memory size for code and data is :ref:`configurable at synthesis time <hdl:cfg>`
The memory size for code and data is :ref:`configurable at synthesis time <hdl:cfg>`.
.. _uRV processor: https://www.ohwr.org/projects/urv-core
.. _`RISC-V`: https://riscv.org/
For more information about how to handle cores from software read:
For more information about how to handle cores from software
, please
read:
- :ref:`Linux Library - Cores Management<sw:lnx:lib:cpu>`
...
...
@@ -82,7 +82,7 @@ This is used to send string messages from the running firmware to the host syste
Message Queue
----------------
Mock Turtle firmware
s
can communicate with external agents using
Mock Turtle firmware can communicate with external agents using
*message queues*; as the name suggests, this is a message queue with
FIFO priority. Each soft-CPU has two sets of private message queues:
one set is for host communication (*host message queue*), the other one is
...
...
@@ -116,13 +116,14 @@ Host message queues are connected to the host system. The host receives an
interrupt whenever an input queue contains at least one message; while
for output it receives an interrupt when a queue has at least one free entry.
Remote message queues do not have interrupt. They must be connected to an
*end-point* that provides connection to the external world. Their task is
to pack and unpack messages according to the type of network on which are
connected. End-point implementation is application specific and outside
the Mock Turtle scope.
Remote message queues are not handled by the host system. They must be
connected to an *end-point* that provides a connection to the external world.
Their task is to pack and unpack messages according to the type of network to
which are connected. The end-point implementation is application specific and
outside the Mock Turtle scope. Mock Turtle offers a set of generic end-points
that you can use.
For more information about how to access it from software read:
For more information about how to access it from software
, please
read:
- :ref:`Firmware Library - Message Queue<sw:fw:lib:mq>`
...
...
@@ -166,7 +167,7 @@ how to access it from software read:
.. _`arch:dp`:
Device Peripheral
Device Peripheral
s
==================
Device peripherals are external components connected to a Mock Turtle core.
...
...
@@ -191,14 +192,14 @@ to address the device.
}
subgraph core1 {
graph [nodesep=1];
c1 -- c
or
ssbar -- "I2C master";
c1 -- c
or
ssbar -- "SPI master";
c1 -- c
ro
ssbar -- "I2C master";
c1 -- c
ro
ssbar -- "SPI master";
}
{rank=same; c1; c2}
{rank=same; "Custom Logic"; "I2C master"; "SPI master"}
}
For more information about how to access it from software read:
For more information about how to access it from software
, please
read:
- :ref:`Firmware Library - Memory Location<sw:fw:lib:mem>`
doc/conf.py
View file @
5e7c1f14
...
...
@@ -84,6 +84,7 @@ pygments_style = 'sphinx'
# If true, `todo` and `todoList` produce output, else they produce nothing.
todo_include_todos
=
True
numfig
=
True
# -- Options for HTML output ----------------------------------------------
...
...
doc/demos/fmc-spec-carrier.rst
View file @
5e7c1f14
...
...
@@ -98,7 +98,7 @@ The expected output from the simulation is::
Software
=========
This demo has two firmware
s
. One is named *blinker* (fw-01), the other
This demo has two firmware. One is named *blinker* (fw-01), the other
*controller* (fw-02).
The *blinker* firmware runs autonomously without any communication with the host
...
...
doc/demos/fmc-svec-carrier.rst
View file @
5e7c1f14
...
...
@@ -105,7 +105,7 @@ The expected output from the simulation is::
Software
=========
This demo has two firmware
s
. One is named *autosvec* (fw-01), the other
This demo has two firmware. One is named *autosvec* (fw-01), the other
*manualsvec* (fw-02).
The *autosvec* firmware runs autonomously without any communication with the host
...
...
doc/demos/index.rst
View file @
5e7c1f14
...
...
@@ -7,6 +7,9 @@ The Demos
This is a collection of demo applications which main purpose is to
introduce the users to the Mock Turtle development. In the following
demos you will find some example code to run and test the applications.
Unless it is explicitly specified, these demos can run on **any** Mock Turtle
instance, in other words they do not depends on a specific HDL or hardware
design.
You will notice the usage of environment variable; these variables, of
course, depend of your environment. Here a list of used variable
...
...
doc/glossary.rst
View file @
5e7c1f14
...
...
@@ -40,7 +40,7 @@ Glossary
It is the system that hosts the hardware in use.
Host Application
It is a
n
user space program running on the host system.
It is a user space program running on the host system.
HMQ
Host Message Queue
...
...
doc/hdl/index.rst
View file @
5e7c1f14
...
...
@@ -146,7 +146,7 @@ If a **t_mt_config** is not provided, a default one will be used::
shared_mem_size => 2048
);
The default configuration instantiates two soft CPUs, each with 32K
B of memory, plus 8K
B of shared
The default configuration instantiates two soft CPUs, each with 32K
iB of memory, plus 8Ki
B of shared
memory. Each CPU will have default host and remote message queue configurations defined as::
constant c_MT_DEFAULT_MQUEUE_CONFIG : t_mt_mqueue_config :=
...
...
@@ -230,7 +230,7 @@ clk_i
is the system clock.
rst_n_i
is an active-low reset input, which is expected to be sync
rh
onous to the system clock.
is an active-low reset input, which is expected to be sync
hr
onous to the system clock.
sp_master_i, sp_master_o
they form the *Shared Peripheral (SP)* Wishbone bus. Wishbone peripherals attached to these ports
...
...
@@ -253,7 +253,7 @@ host_slave_i, host_slave_o
.. important::
When mapping the MT address area to the host, users should keep in mind that the
whole MT address space is 128KB (0x20000).
whole MT address space is 128K
i
B (0x20000).
**t_wishbone_master_out**, **t_wishbone_master_in** and their respective arrays, as well as
**t_wishbone_slave_out** and **t_wishbone_slave_in** are VHDL record types declared in the
...
...
@@ -374,7 +374,7 @@ default/dummy constant as::
cycles => (others => '0'),
aux_locked => (others => '0'));
For an explanation of these fields, please refer to `White Rabbit PTP core`_ manual.
For an explanation of these fields, please refer to
the
`White Rabbit PTP core`_ manual.
gpio_o, gpio_i
These are the 32-bit inputs and outputs to the GPIO registers of each configured MT soft
...
...
doc/software/firmware-framework.rst
View file @
5e7c1f14
...
...
@@ -14,7 +14,7 @@ This API is available by including ``mockturtle-framework.h`` in your source fil
#include <mockturtle-framework.h>
We recommend this framework to develop Mock Turtle firmware
s
. You should
We recommend this framework to develop Mock Turtle firmware. You should
consider alternatives if you see that it’s consuming too much memory or
the performances are not enough for your application.
...
...
@@ -83,7 +83,7 @@ Here an example.::
};
The Mock Turtle is FPGA based, this means that the firmware
s
are
The Mock Turtle is FPGA based, this means that the firmware are
typically loaded by the host. The procedure is error prone, so it may
happen to load the wrong firmware with unpredictable consequences. To
limit the damage, the ``fpga_id_compat`` can be used to declare a
...
...
@@ -273,7 +273,7 @@ In chapter :ref:`sw:lnx:lib:hmq` you can find the correspondent host API,
which in few words consists in two function: :c:func:`trtl_fw_variable_set`
and :c:func:`trtl_fw_variable_get`.
What we have seen
til
l now it is handled automatically by this framework.
What we have seen
unti
l now it is handled automatically by this framework.
The user can send, asynchronously, variables of choice using the function
:c:func:`trtl_fw_mq_send_buf`.
...
...
@@ -289,7 +289,7 @@ the host system. The buffers must be declared using the
:c:type:`trtl_fw_buffer` and then exported in your
:c:type:`trtl_fw_application`.
The mean of buffer in this context is extended to any contiguous memory
The mean
ing
of buffer in this context is extended to any contiguous memory
location.
The framework handles the buffer exchange as a special action.
...
...
@@ -357,11 +357,11 @@ From the host you can read/write the buffer by using the
.. highlight:: c
In chapter :ref:`sw:lnx:lib:hmq` you can find the correspondent host API
,
which in few words consists in
two function: :c:func:`trtl_fw_buffer_set`
In chapter :ref:`sw:lnx:lib:hmq` you can find the correspondent host API
;
in a few words consists of
two function: :c:func:`trtl_fw_buffer_set`
and :c:func:`trtl_fw_buffer_get`.
What we have seen
til
l now it is handled automatically by this framework.
What we have seen
unti
l now it is handled automatically by this framework.
The user can send, asynchronously, buffer of choice using the function
:c:func:`trtl_fw_mq_send_buf`.
...
...
@@ -370,7 +370,7 @@ The user can send, asynchronously, buffer of choice using the function
Utilities
=========
This is a collection of miscellaneous function that can be of some helpers.
This is a collection of miscellaneous function
s
that can be of some helpers.
.. doxygenfunction:: trtl_fw_time
...
...
doc/software/firmware-library.rst
View file @
5e7c1f14
...
...
@@ -343,7 +343,7 @@ function :c:func:`puts()` to send the strings over the serial interface.
Host Notification
=================
Mock Turtle has a mechanism that allows firmware
s
to send arbitrary interrupts
Mock Turtle has a mechanism that allows firmware to send arbitrary interrupts
to the host system. This mechanism is used by Mock Turtle software to deliver
special notifications; but this mechanism can be used as well by the user to
deliver custum notifications to their support layer.
...
...
doc/software/index-fw.rst
View file @
5e7c1f14
...
...
@@ -4,7 +4,7 @@
Firmware Development
======================
This section explains how to write firmware
s
using the Mock Turtle API.
This section explains how to write firmware using the Mock Turtle API.
The Mock Turtle offers 2 API for the firmware development:
:ref:`sw:fw:lib` and :ref:`sw:fw:frm`.
...
...
doc/software/index.rst
View file @
5e7c1f14
...
...
@@ -18,9 +18,9 @@ the :ref:`sw:fw` and the :ref:`sw:lnx`
The Mock Turtle software stack is made of different layers which main
objectives are:
- to manage the Mock Turtle cores from the host
;
- to manage the Mock Turtle cores from the host
- to allow firmware
s to access Mock Turtle resources;
- to allow firmware
to access Mock Turtle resources
- to provide a communication infrastructure between firmware and host
...
...
@@ -32,7 +32,7 @@ Mock Turtle API.
On the other hand, the development of a software support layer on the
host depends on your needs. If you need a custumized control/monitor
infrastructure for firmware
s
, then it is recommended to develop
infrastructure for firmware, then it is recommended to develop
your software support layer(s) on top of the Mock Turtle ones.
Keep in mind that :ref:`tools` can be used for basic control/monitor
operations. This means that for basic requirements you can directly use
...
...
@@ -41,8 +41,8 @@ the tools without developing any support layer.
We strongly recommend you to start the develpment of a new Mock Turtle
project by using the :ref:`tools:mockturtle-project-creator`.
Following a list of generic topics which are not specific to Linux
development
of firmware development
.
Following a list of generic topics which are not specific to Linux
or firmware
development.
.. toctree::
:maxdepth: 1
...
...
doc/software/linux-driver.rst
View file @
5e7c1f14
...
...
@@ -8,7 +8,7 @@ The Linux Device Driver
The Mock Turtle device driver is a software component that exposes the
Mock Turtle gateware core to the host. Any interaction with the Mock
Turtle gateware core pass trought the device driver. This implies that
Turtle gateware core pass
es
trought the device driver. This implies that
if the driver does not support a Mock Turtle feature, neither the other
layers (the library or the Python module) will do.
...
...
@@ -80,31 +80,20 @@ development of a Linux module or the DeviceTree.
This driver handles all platform_device instances which name is one of
the following: "mock-turtle", "mockturtle".
The Mock Turtle device driver expects
5
``resources`` from the platform
The Mock Turtle device driver expects
five
``resources`` from the platform
device.
memory
address
The gateware core base address within the virtual addres
space.
- memory address: The gateware core base address within the virtual
address
space.
hmq IRQ input
The Linux IRQ number to use for the hmq input.
- hmq IRQ input: The Linux IRQ number to use for the hmq input.
hmq IRQ output
The Linux IRQ number to use for the hmq output.
- hmq IRQ output: The Linux IRQ number to use for the hmq output.
console IRQ
The Linux IRQ number to use for the serial interface.
- console IRQ: The Linux IRQ number to use for the serial interface.
notification IRQ
The Linux IRQ number to use for Mock Turtle cores notifications.
Since not all developer knows how to write such module, you can use the
*platform-device-loader* [2]_. This application is part of the CERN BE-CO-HT tools
collection, you may need special permission to access the repository.
If you are not sure about how to write the Linux module to load your
platform device, consider to have a look at the source code templates
from the *platform-device-loader* tool.
- notification IRQ: The Linux IRQ number to use for Mock Turtle cores
notifications.
Interfaces
==========
...
...
@@ -150,7 +139,7 @@ The Mock Turtle driver exports a *char device* for each Mock Turtle core.
All core instances will appear as child of a :ref:`sw:drv:dev`; in
*/dev/mockturtle* you will have devices named *trtl-%04x-%02d``*
(trtl-<device-id>-<cpu-index>). The main purpose of this interface is to
program (or rarely useful dump) firmware
s
into cores. These devices are
program (or rarely useful dump) firmware into cores. These devices are
bidirectional, so you can: ``write(2)`` to program a firmware, ``read(2)``
to dump a firmware; ``lseek(2)`` to move to different memory locations.
...
...
@@ -163,8 +152,9 @@ The same command can be used also to dump the memory content.::
dd if=/dev/mockturtle/trtl-0001-00 of=firmwaredump.bin
In both cases (loading and dumping) the driver automatically put in *reset*
the core. This means that after your operation you need to *unreset* the
In both cases (loading and dumping) the driver automatically puts the core
in *reset* state.
This means that after your operation you need to *unreset* the
core in order to make it running again.::
echo 0 > /sys/class/mockturtle/trtl-0001-00/reset
...
...
@@ -216,7 +206,7 @@ Host Message Queue
The Mock Turtle driver exports a *char device* for each Mock Turtle HMQ.
All HMQ instances will appear as child of a :ref:`sw:drv:core`; in
*/dev/mockturtle/* you will have devices named ``trtl-%04x-%02d-%02d``
(trtl-<device-id>-<cpu-index>-<hmq-index>). The main purpose
s
of this
(trtl-<device-id>-<cpu-index>-<hmq-index>). The main purpose of this
interface is to exchange messages and configure filters. These devices
are bidirectional, so you can: ``write(2)`` to send messaged;
``read(2)`` to receive messages; ``poll(2)`` or ``select(2)`` to wait
...
...
@@ -278,4 +268,3 @@ This is typically used by driver developers for debugging purposes.
Do not consider this as a stable interface.
.. [1] https://www.kernel.org/doc/Documentation/driver-model/platform.txt
.. [2] https://gitlab.cern.ch/cohtdrivers/coht-tools/tree/master/drivers/platform-device-loader
doc/software/linux-library.rst
View file @
5e7c1f14
...
...
@@ -62,7 +62,7 @@ While in the compilation command you have to provide the following options
The example above assumes that you are compiling from the Mock Turtle
git repository or a copy of it; if on your environment libraries and header
files are in different location, then fix the above code accordingly.
files are in different location
s
, then fix the above code accordingly.
Initialization
==============
...
...
@@ -147,16 +147,16 @@ messages to/from them.
Whenever you need to remove all the messages from the HMQ you can use
the function :c:func:`trtl_hmq_flush()`. The host system does not have
access to the RMQ. If what you want to achive is a complete flush of
access to the RMQ. If what you want to achi
e
ve is a complete flush of
all the message queues (host and remote) you should do it on firmware
side so that the complete flush happens synchronously.
.. doxygenfunction:: trtl_hmq_flush
The Mock Turtle driver has a basic message filtering mechanism. Each
user can add a set of filter on any host message queue. Mock Turtle
user can add a set of filter
s
on any host message queue. Mock Turtle
will deliver to the user only those messages which pass the filter.
Rembember that this is user filter, this means that on the same
Rembember that this is
a
user filter, this means that on the same
host message queue, different users can have different filters.
.. doxygenfunction:: trtl_hmq_filter_add
...
...
@@ -168,7 +168,7 @@ host message queue, different users can have different filters.
.. doxygenstruct:: trtl_msg_filter
:members:
Then, there are the functions to exchange messages with firmware
s
Then, there are the functions to exchange messages with firmware
running on Mock Turtle. This API offers a minimum set of function
to allow users to send/receive synchronous/asynchronous messages.
This library does not have any knowledge about the message content,
...
...
doc/software/linux-python.rst
View file @
5e7c1f14
...
...
@@ -103,7 +103,7 @@ Then, it exports a set of *ctype* data structures used to exchange
information with the Mock Turtle layers.
.. note::
Since this Py
ht
on module is nothing more than a wrapper on top of
Since this Py
th
on module is nothing more than a wrapper on top of
a C library, we suggest you to have a look at :ref:`sw:lnx:library`
for a better understanding of this API
...
...
doc/software/protocol.rst
View file @
5e7c1f14
...
...
@@ -13,7 +13,7 @@ Configuration ROM
The *configuration ROM* is, indeed, a ROM where at synthesis time we put
information about the synthesis configuration. This configuration is the one
used to tailor Mock Turtle to fit users needs. The configuration can be read,
with different APIs, by both host system and firmware
s
.
with different APIs, by both host system and firmware.
.. doxygenstruct:: trtl_config_rom
:members:
...
...
@@ -32,20 +32,20 @@ with different APIs, by both host system and firmwares.
Host Message Queue Protocol
==============================
When exchanging messages between two entities it is always handy
to have a protocol. Any Mock Turtle message queue has an header part and
a payload part. It is within the header part that users put the informatio
n
to handle the choosen
protocol.
A protocol in necessary in order to exchange messages between two entities.
Any Mock Turtle message queue has a header part and a payload part. It is
within the header part that users put the information to handle the choose
n
protocol.
In order to standardize the message exchange between host and firmware
s
In order to standardize the message exchange between host and firmware
a message header has been defined. This header is expected to be in the
message queue header buffer.
Different Mock Turtle layers make
a
different use of this message header.
Different Mock Turtle layers make different use of this message header.
The HDL code does not process the header, while the driver uses the
:c:member:`trtl_hmq_header.len` to optimize the amount of data copied.
This protocol is mostly used by libraries and firmware
s
, which are the
This protocol is mostly used by libraries and firmware, which are the
two end-points of Host Message Queue communication channel.
...
...
doc/tools/mockturtle-buffer.rst
View file @
5e7c1f14
...
...
@@ -5,4 +5,4 @@ Mock Turtle Buffer
The Mock Turtle buffer application(\ *mockturtle-buffer*) allows the
user to read/write the buffers that a firmware exports. The tool works
only with those firmware
s
developed using :ref:`sw:fw:frm`.
only with those firmware developed using :ref:`sw:fw:frm`.
doc/tools/mockturtle-ping.rst
View file @
5e7c1f14
...
...
@@ -8,4 +8,4 @@ The purpose of the Mock Turtle Ping application (*mockturtle-ping*) is
to be able to verify that a firmware is running. In addition, the
mockturtle-ping application provides information about the firmware
version running on a Mock Turtle soft-cpu. The tool works only with
those firmware
s
developed using :ref:`sw:fw:frm`.
those firmware developed using :ref:`sw:fw:frm`.
doc/tools/mockturtle-variable.rst
View file @
5e7c1f14
...
...
@@ -6,4 +6,4 @@ Mock Turtle Variable
The Mock Turtle variable application(\ *mockturtle-variable*) allows the
user to read/write the variables that a firmware exports. The tool works
only with those firmware
s
developed using :ref:`sw:fw:frm`.
only with those firmware developed using :ref:`sw:fw:frm`.
hdl/syn/svec_mt_demo/svec_mt_demo.ucf
View file @
5e7c1f14
...
...
@@ -256,14 +256,17 @@ NET "fp_gpio2_a2b_o" IOSTANDARD="LVCMOS33";
NET "fp_gpio34_a2b_o" LOC=V28;
NET "fp_gpio34_a2b_o" IOSTANDARD="LVCMOS33";
NET "fp_gpio_in[0]" LOC=R30;
NET "fp_gpio_in[0]" IOSTANDARD="LVCMOS33";
NET "fp_gpio_in[1]" LOC=T28;
NET "fp_gpio_in[1]" IOSTANDARD="LVCMOS33";
NET "fp_gpio_in[2]" LOC=U29;
NET "fp_gpio_in[2]" IOSTANDARD="LVCMOS33";
NET "fp_gpio_in[3]" LOC=V27;
NET "fp_gpio_in[3]" IOSTANDARD="LVCMOS33";
NET "fp_gpio1_b" LOC=R30;
NET "fp_gpio1_b" IOSTANDARD="LVCMOS33";
NET "fp_gpio2_b" LOC=T28;
NET "fp_gpio2_b" IOSTANDARD="LVCMOS33";
NET "fp_gpio3_b" LOC=U29;
NET "fp_gpio3_b" IOSTANDARD="LVCMOS33";
NET "fp_gpio4_b" LOC=V27;
NET "fp_gpio4_b" IOSTANDARD="LVCMOS33";
NET "clk_125m_pllref_n_i" TNM_NET = clk_125m_pllref_n_i;
TIMESPEC TS_clk_125m_pllref_n_i = PERIOD "clk_125m_pllref_n_i" 8 ns HIGH 50%;
...
...
hdl/top/svec_mt_demo/svec_mt_demo.vhd
View file @
5e7c1f14
...
...
@@ -56,7 +56,10 @@ entity svec_mt_demo is
fp_gpio1_a2b_o
:
out
std_logic
;
fp_gpio2_a2b_o
:
out
std_logic
;
fp_gpio34_a2b_o
:
out
std_logic
;
fp_gpio_b
:
inout
std_logic_vector
(
3
downto
0
);
fp_gpio1_b
:
inout
std_logic
;
fp_gpio2_b
:
inout
std_logic
;
fp_gpio3_b
:
inout
std_logic
;
fp_gpio4_b
:
inout
std_logic
;
-- Bypass VME core, useful only in simulation
-- synthesis translate_off
sim_wb_i
:
in
t_wishbone_slave_in
:
=
cc_dummy_slave_in
;
...
...
@@ -167,11 +170,6 @@ architecture arch of svec_mt_demo is
signal
powerup_rst_n
:
std_logic
:
=
'0'
;
signal
sys_locked
:
std_logic
;
signal
fp_gpio_in
:
std_logic_vector
(
3
downto
0
);
attribute
keep
:
string
;
attribute
keep
of
fp_gpio_in
:
signal
is
"true"
;
begin
-- architecture arch
U_Buf_CLK_PLL
:
IBUFGDS
...
...
@@ -382,19 +380,16 @@ begin -- architecture arch
fp_gpio34_a2b_o
<=
cpu_gpio_oen
(
2
);
-- FP GPIO bidir in/out (3 and 4 share the same direction line)
fp_gpio_gen
:
for
i
in
0
to
3
generate
fp_gpio_b
(
i
)
<=
cpu_gpio_out
(
i
)
when
cpu_gpio_oen
(
i
)
=
'1'
else
'Z'
;
fp_gpio_in
(
i
)
<=
fp_gpio_b
(
i
);
gpio_sync_ffs
:
gc_sync_ffs
port
map
(
clk_i
=>
clk_sys
,
rst_n_i
=>
rst_n_sys
,
data_i
=>
fp_gpio_in
(
i
),
synced_o
=>
cpu_gpio_in
(
i
));
end
generate
fp_gpio_gen
;
fp_gpio1_b
<=
cpu_gpio_out
(
0
)
when
cpu_gpio_oen
(
0
)
=
'1'
else
'Z'
;
fp_gpio2_b
<=
cpu_gpio_out
(
1
)
when
cpu_gpio_oen
(
1
)
=
'1'
else
'Z'
;
fp_gpio3_b
<=
cpu_gpio_out
(
2
)
when
cpu_gpio_oen
(
2
)
=
'1'
else
'Z'
;
fp_gpio4_b
<=
cpu_gpio_out
(
3
)
when
cpu_gpio_oen
(
2
)
=
'1'
else
'Z'
;
-- gpio inputs (same for both CPUs)
cpu_gpio_in
(
0
)
<=
fp_gpio1_b
;
cpu_gpio_in
(
1
)
<=
fp_gpio2_b
;
cpu_gpio_in
(
2
)
<=
fp_gpio3_b
;
cpu_gpio_in
(
3
)
<=
fp_gpio4_b
;
cpu_gpio_in
(
23
downto
4
)
<=
cpu_gpio_out
(
23
downto
4
);
...
...
software/CONTRIBUTING.md
deleted
120000 → 0
View file @
0aed2e03
doc/CONTRIBUTING.md
\ No newline at end of file
software/LICENSE
deleted
120000 → 0
View file @
0aed2e03
doc/LICENSE
\ No newline at end of file
software/firmware/Kconfig.mt
View file @
5e7c1f14
...
...
@@ -27,13 +27,21 @@ config CFLAGS_EXTRA
help
Extra flags to be passed to the compiler
config MOCKTURTLE_SIMULATION
bool "It enables the simulation mode"
default n
help
It compiles the firmware in order to run it in simulation mode.
This removes some delay in the framework and in the library; it
can be used by any firmware to be compiled for different targets.
comment "Mock Turtle framework configuration"
config MOCKTURTLE_FRAMEWORK_ENABLE
bool "Enable Mock Turtle framework"
default y
help
It enables the Mock Turtle firmware framework. This framework
provides a well structured way to develop Mock turtle firmware
s
provides a well structured way to develop Mock turtle firmware
as wall as helpers for the most common operations.
config MOCKTURTLE_FRAMEWORK_DEBUG_ENABLE
...
...
@@ -72,14 +80,14 @@ config MOCKTURTLE_FRAMEWORK_PING_ENABLE
depends on MOCKTURTLE_FRAMEWORK_ACTION_ENABLE
default y
help
It enables the API to send ping message to firmware
s
.
It enables the API to send ping message to firmware.
config MOCKTURTLE_FRAMEWORK_VERSION_ENABLE
bool "Enable version message in Mock Turtle framework"
depends on MOCKTURTLE_FRAMEWORK_ACTION_ENABLE
default y
help
It enables the API to send version message to firmware
s
.
It enables the API to send version message to firmware.
config MOCKTURTLE_FRAMEWORK_VALUE_SEND_ENABLE
bool "Enable value message send in Mock Turtle framework"
...
...
software/firmware/framework/mockturtle-framework.c
View file @
5e7c1f14
...
...
@@ -465,7 +465,7 @@ int trtl_fw_mq_send_buf(enum trtl_mq_type type,
/**
* It get the current time from the internal TRTL timer
* It get
s
the current time from the internal TRTL timer
* @param[out] seconds
* @param[out] cycles
*/
...
...
software/include/mockturtle.h
View file @
5e7c1f14
...
...
@@ -7,7 +7,7 @@
#ifndef __TRTL_USER_H__
#define __TRTL_USER_H__
/** @file mock
-
turtle.h */
/** @file mockturtle.h */
#ifndef __KERNEL__
#include <string.h>
...
...
@@ -166,7 +166,7 @@ struct trtl_tlv {
/**
* @enum trtl_smem_modifier
* Shared memory operation modifier. This is a list of operation modifier
* Shared memory operation modifier. This is a list of operation modifier
s
* that you can use to access the shared memory.
*/
enum
trtl_smem_modifier
{
...
...
software/kernel/mockturtle-hmq.c
View file @
5e7c1f14
...
...
@@ -839,7 +839,7 @@ static ssize_t trtl_hmq_read(struct file *f, char __user *ubuf,
/**
* It filters out messages until a valid one
* @usr: pointer to a
n
user HMQ instance
* @usr: pointer to a user HMQ instance
*/
static
void
trtl_hmq_user_filter
(
struct
trtl_hmq_user
*
usr
)
{
...
...
software/lib/libmockturtle-rt-msg.c
View file @
5e7c1f14
...
...
@@ -149,10 +149,10 @@ static int __trtl_fw_variable(struct trtl_dev *trtl,
* VAL is the associated value
*
* By setting the flag 'sync' you will send a synchronous message, otherwise
* it is async
rh
onous. When synchronous the 'variables' field will be
* overwritten by the sync
rh
onous answer; the answer contains the read back
* it is async
hr
onous. When synchronous the 'variables' field will be
* overwritten by the sync
hr
onous answer; the answer contains the read back
* values for the requested variable after the set operation. You can use
* this to verify. You can use synchro
u
nous messages to verify that you
* this to verify. You can use synchronous messages to verify that you
* variable are properly set.
* This function will change the header content, in particular it will change
* the following fields: msg_id, len
...
...
@@ -191,7 +191,7 @@ int trtl_fw_variable_set(struct trtl_dev *trtl,
* VAL is the associated value
*
* This kind of message is always synchronous. The 'variables' field will be
* overwritten by the sync
rh
onous answer; the answer contains the read back
* overwritten by the sync
hr
onous answer; the answer contains the read back
* values for the requested variables.
* This function will change the header content, in particular it will change
* the following fields: msg_id, flags, len
...
...
software/lib/libmockturtle.c
View file @
5e7c1f14
...
...
@@ -580,7 +580,9 @@ int trtl_cpu_load_application_raw(struct trtl_dev *trtl,
{
struct
trtl_desc
*
wdesc
=
(
struct
trtl_desc
*
)
trtl
;
char
path
[
TRTL_PATH_LEN
];
int
fd
,
i
=
0
;
int
fd
;
ssize_t
ret
;
size_t
i
=
0
;
snprintf
(
path
,
TRTL_PATH_LEN
,
"%s/%s-%02d"
,
wdesc
->
path
,
wdesc
->
name
,
index
);
...
...
@@ -589,12 +591,16 @@ int trtl_cpu_load_application_raw(struct trtl_dev *trtl,
return
-
1
;
lseek
(
fd
,
offset
,
SEEK_SET
);
do
{
i
+=
write
(
fd
,
code
,
length
);
}
while
(
i
<
length
);
errno
=
ENOMEM
;
while
(
i
<
length
)
{
ret
=
write
(
fd
,
code
,
length
);
if
(
ret
<=
0
)
break
;
i
+=
ret
;
}
close
(
fd
);
return
i
;
return
ret
<=
0
?
ret
:
i
;
}
...
...
@@ -822,7 +828,7 @@ int trtl_smem_write(struct trtl_dev *trtl, uint32_t addr, uint32_t *data,
/**
* It enables a CPU; in other words, it clear the reset line of a CPU.
* It enables a CPU; in other words, it clear
s
the reset line of a CPU.
* This function is a wrapper of trtl_cpu_reset_set() that allow you to safely
* enable a single CPU.
* @param[in] trtl device token
...
...
@@ -840,7 +846,7 @@ int trtl_cpu_enable(struct trtl_dev *trtl, unsigned int index)
/**
* It disables a CPU; in other words, it sets the reset line of a CPU.
* This function is a wrapper of trtl_cpu_reset_set() that allow you to safely
* This function is a wrapper of trtl_cpu_reset_set() that allow
s
you to safely
* disable a single CPU.
* @param[in] trtl device token
* @param[in] index CPU index
...
...
@@ -1050,8 +1056,8 @@ int trtl_msg_async_send(struct trtl_dev *trtl,
* @param[in] timeout like poll(2)
* @return 0 on success, otherwise -1 and errno is set appropriately
*
* This function configure
some filters, so it does some bit magic which have been
* tested on a little-endian host.
* This function configure
s some filters, so it does some bit magic which have
*
been
tested on a little-endian host.
*/
int
trtl_msg_sync
(
struct
trtl_dev
*
trtl
,
unsigned
int
idx_cpu
,
...
...
tests/firmware/config_rom/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/cpu-byte-addressing/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/cpu-loop/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/cpu-notify/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/hmq-async-recv/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/hmq-async-send/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/hmq-purge/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/rmq-udp-send/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/rt-frm/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-O0"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/serial/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
# CONFIG_MOCKTURTLE_SIMULATION is not set
#
# Mock Turtle framework configuration
...
...
tests/firmware/sim-verif/configs/mt_defconfig
View file @
5e7c1f14
...
...
@@ -14,6 +14,7 @@ CONFIG_RT_APPLICATION_ID=0
#
CONFIG_CFLAGS_OPT="-Os"
CONFIG_CFLAGS_EXTRA="-ggdb"
CONFIG_MOCKTURTLE_SIMULATION=y
#
# Mock Turtle framework configuration
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment