forked from M-Labs/artiq
doc: Split installing page (#2495)
Co-authored-by: architeuthidae <am@m-labs.hk>
This commit is contained in:
architeuthidae
GitHub
parent
8a6a6042fd
commit
5aee0df9f0
|
|
@ -0,0 +1,123 @@
|
|||
Networking and configuration
|
||||
============================
|
||||
|
||||
Setting up core device networking
|
||||
---------------------------------
|
||||
|
||||
For Kasli, insert a SFP/RJ45 transceiver (normally included with purchases from M-Labs and QUARTIQ) into the SFP0 port and connect it to an Ethernet port in your network. If the port is 10Mbps or 100Mbps and not 1000Mbps, make sure that the SFP/RJ45 transceiver supports the lower rate. Many SFP/RJ45 transceivers only support the 1000Mbps rate. If you do not have a SFP/RJ45 transceiver that supports 10Mbps and 100Mbps rates, you may instead use a gigabit Ethernet switch in the middle to perform rate conversion.
|
||||
|
||||
You can also insert other types of SFP transceivers into Kasli if you wish to use it directly in e.g. an optical fiber Ethernet network. Kasli-SoC already directly features RJ45 10/100/1000 Ethernet.
|
||||
|
||||
IP address and ping
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you purchased a Kasli or Kasli-SoC device from M-Labs, it will arrive with an IP address already set, normally the address requested in the web shop at time of purchase. If you did not specify an address at purchase, the default IP M-Labs uses is ``192.168.1.75``. If you did not obtain your hardware from M-Labs, or if you have just reflashed your core device, see :ref:`networking-tips` below.
|
||||
|
||||
Once you know the IP, check that you can ping your device: ::
|
||||
|
||||
$ ping <IP_address>
|
||||
|
||||
If ping fails, check that the Ethernet LED is ON; on Kasli, it is the LED next to the SFP0 connector. As a next step, try connecting to the serial port to read the UART log. See :ref:`connecting-UART`.
|
||||
|
||||
Core management tool
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The tool used to configure the core device is the command-line utility ``artiq_coremgmt``. In order for it to connect to your core device, it is necessary to supply it somehow with the correct IP address for your core device. This can be done directly through use of the ``-D`` option, for example in: ::
|
||||
|
||||
$ artiq_coremgmt -D <IP_address> log
|
||||
|
||||
.. note::
|
||||
This command reads and displays the core log. If you have recently rebooted or reflashed your core device, you should see the startup logs in your terminal.
|
||||
|
||||
Normally, however, the core device IP is supplied through the *device database* for your system, which comes in the form of a Python script called ``device_db.py`` (see also :ref:`device-db`). If you purchased a system from M-Labs, the ``device_db.py`` for your system will have been provided for you, either on the USB stick, inside ``~/artiq`` on your NUC, or sent by email.
|
||||
|
||||
Make sure the field ``core_addr`` at the top of the file is set to your core device's correct IP address, and always execute ``artiq_coremgmt`` from the same directory the device database is placed in.
|
||||
|
||||
Once you can reach your core device, the IP can be changed at any time by running: ::
|
||||
|
||||
$ artiq_coremgmt [-D old_IP] config write -s ip <new_IP>
|
||||
|
||||
and then rebooting the device: ::
|
||||
|
||||
$ artiq_coremgmt [-D old_IP] reboot
|
||||
|
||||
Make sure to correspondingly edit your ``device_db.py`` after rebooting.
|
||||
|
||||
.. _networking-tips:
|
||||
|
||||
Tips and troubleshooting
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
For Kasli-SoC:
|
||||
If the ``ip`` config is not set, Kasli-SoC firmware defaults to using the IP address ``192.168.1.56``.
|
||||
|
||||
For ZC706:
|
||||
If the ``ip`` config is not set, ZC706 firmware defaults to using the IP address ``192.168.1.52``.
|
||||
|
||||
For Kasli or KC705:
|
||||
If the ``ip`` config field is not set or set to ``use_dhcp``, the device will attempt to obtain an IP address and default gateway using DHCP. The chosen IP address will be in log output, which can be accessed via the :ref:`UART log <connecting-UART>`.
|
||||
|
||||
If a static IP address is preferred, it can be flashed directly (OpenOCD must be installed and configured, as in :doc:`flashing`), along with, as necessary, default gateway, IPv6, and/or MAC address: ::
|
||||
|
||||
$ artiq_mkfs flash_storage.img [-s mac xx:xx:xx:xx:xx:xx] [-s ip xx.xx.xx.xx/xx] [-s ipv4_default_route xx.xx.xx.xx] [-s ip6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xx] [-s ipv6_default_route xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]
|
||||
$ artiq_flash -t [board] -V [variant] -f flash_storage.img storage start
|
||||
|
||||
On Kasli or Kasli-SoC devices, specifying the MAC address is unnecessary, as they can obtain it from their EEPROM. If you only want to access the core device from the same subnet, default gateway and IPv4 prefix length may also be ommitted. On any board, once a device can be reached by ``artiq_coremgmt``, these values can be set and edited at any time, following the procedure for IP above.
|
||||
|
||||
Regarding IPv6, note that the device also has a link-local address that corresponds to its EUI-64, which can be used simultaneously to the (potentially unrelated) IPv6 address defined by using the ``ip6`` configuration key.
|
||||
|
||||
.. _core-device-config:
|
||||
|
||||
Configuring the core device
|
||||
---------------------------
|
||||
|
||||
.. note::
|
||||
The following steps are optional, and you only need to execute them if they are necessary for your specific system. To learn more about how ARTIQ works and how to use it first, you might skip to the next page, :doc:`rtio`. For all configuration options, the core device generally must be restarted for changes to take effect.
|
||||
|
||||
Flash idle and/or startup kernel
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The *idle kernel* is the kernel (that is, a piece of code running on the core device; see :doc:`the next page <rtio>` for further explanation) which the core device runs in between experiments and whenever not connected to the host. It is saved directly to the core device's flash storage in compiled form. Potential uses include cleanup of the environment between experiments, state maintenance for certain hardware, or anything else that should run continuously whenever the system is not otherwise occupied.
|
||||
|
||||
To flash an idle kernel, first write an idle experiment. Note that since the idle kernel runs regardless of whether the core device is connected to the host, remote procedure calls or RPCs (functions called by a kernel to run on the host) are forbidden and the ``run()`` method must be a kernel marked with ``@kernel``. Once written, you can compile and flash your idle experiment: ::
|
||||
|
||||
$ artiq_compile idle.py
|
||||
$ artiq_coremgmt config write -f idle_kernel idle.elf
|
||||
|
||||
The *startup kernel* is a kernel executed once and only once immediately whenever the core device powers on. Uses include initializing DDSes and setting TTL directions. For DRTIO systems, the startup kernel should wait until the desired destinations, including local RTIO, are up, using ``self.core.get_rtio_destination_status`` (:meth:`~artiq.coredevice.core.Core.get_rtio_destination_status`).
|
||||
|
||||
To flash a startup kernel, proceed as with the idle kernel, but using the ``startup_kernel`` key in the ``artiq_coremgmt`` command.
|
||||
|
||||
.. note::
|
||||
Subkernels (see :doc:`using_drtio_subkernels`) are allowed in idle (and startup) experiments without any additional ceremony. ``artiq_compile`` will produce a ``.tar`` rather than a ``.elf``; simply substitute ``idle.tar`` for ``idle.elf`` in the ``artiq_coremgmt config write`` command.
|
||||
|
||||
Select the RTIO clock source
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The core device may use any of an external clock signal, its internal clock with external frequency reference, or its internal clock with internal crystal reference. Clock source and timing are set at power-up. To find out what clock signal you are using, check the startup logs with ``artiq_coremgmt log``.
|
||||
|
||||
The default is to use an internal 125MHz clock. To select a source, use a command of the form: ::
|
||||
|
||||
$ artiq_coremgmt config write -s rtio_clock int_125 # internal 125MHz clock (default)
|
||||
$ artiq_coremgmt config write -s rtio_clock ext0_synth0_10to125 # external 10MHz reference used to synthesize internal 125MHz
|
||||
|
||||
See :ref:`core-device-clocking` for availability of specific options.
|
||||
|
||||
Set up resolving RTIO channels to their names
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This feature allows you to print the channels' respective names alongside with their numbers in RTIO error messages. To enable it, run the ``artiq_rtiomap`` tool and write its result into the device config at the ``device_map`` key: ::
|
||||
|
||||
$ artiq_rtiomap dev_map.bin
|
||||
$ artiq_coremgmt config write -f device_map dev_map.bin
|
||||
|
||||
More information on the ``artiq_rtiomap`` utility can be found on the :ref:`Utilities <rtiomap-tool>` page.
|
||||
|
||||
Enable event spreading
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This feature changes the logic used for queueing RTIO output events in the core device for a more efficient use of FPGA resources, at the cost of introducing nondeterminism and potential unpredictability in certain timing errors (specifically gateware :ref:`sequence errors<sequence-errors>`). It can be enabled with the config key ``sed_spread_enable``. See :ref:`sed-event-spreading`.
|
||||
|
||||
Load the DRTIO routing table
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are using DRTIO and the default routing table (for a star topology) is not suitable to your needs, you will first need to prepare and load a different routing table. See :ref:`Using DRTIO <drtio-routing>`.
|
||||
|
|
@ -10,7 +10,7 @@ While it is possible to use the other parts of ARTIQ (controllers, master, GUI,
|
|||
Flash storage
|
||||
-------------
|
||||
|
||||
The core device contains some flash storage space which is used to store configuration data and the idle/startup kernels. It is one sector (typically 64 kB) large and organized as a list of key-value records, accessible either through ``artiq_mkfs`` and ``artiq_flash`` or (preferable in most cases) the ``config`` option of the ``artiq_coremgmt`` core management tool (see below). Information can be stored to keys of any name, but the specific keys currently used and referenced by ARTIQ are summarized below:
|
||||
The core device contains some flash storage space which is used to store configuration data. It is one sector (typically 64 kB) large and organized as a list of key-value records, accessible either through ``artiq_mkfs`` and ``artiq_flash`` or, preferably in most cases, the ``config`` option of the ``artiq_coremgmt`` core management tool (see below). Information can be stored to keys of any name, but the specific keys currently used and referenced by ARTIQ are summarized below:
|
||||
|
||||
``idle_kernel``
|
||||
Stores (compiled ``.tar`` or ``.elf`` binary of) idle kernel. See :ref:`miscellaneous_config_core_device`.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,129 @@
|
|||
(Re)flashing your core device
|
||||
=============================
|
||||
|
||||
.. note::
|
||||
If you have purchased a pre-assembled system from M-Labs or QUARTIQ, the gateware and firmware of your devices will already be flashed to the newest version of ARTIQ. Flashing your device is only necessary if you obtained your hardware in a different way, or if you want to change your system configuration or upgrade your ARTIQ version after the original purchase. Otherwise, skip straight to :doc:`configuring`.
|
||||
|
||||
.. _obtaining-binaries:
|
||||
|
||||
Obtaining board binaries
|
||||
------------------------
|
||||
|
||||
If you have an active firmware subscription with M-Labs or QUARTIQ, you can obtain firmware for your system that corresponds to your currently installed version of ARTIQ using the ARTIQ firmware service (AFWS). One year of subscription is included with most hardware purchases. You may purchase or extend firmware subscriptions by writing to the sales@ email. The client ``afws_client`` is included in all ARTIQ installations.
|
||||
|
||||
Run the command::
|
||||
|
||||
$ afws_client <username> build <afws_director> <variant>
|
||||
|
||||
Replace ``<username>`` with the login name that was given to you with the subscription, ``<variant>`` with the name of your system variant, and ``<afws_directory>`` with the name of an empty directory, which will be created by the command if it does not exist. Enter your password when prompted and wait for the build (if applicable) and download to finish. If you experience issues with the AFWS client, write to the helpdesk@ email.
|
||||
|
||||
For certain configurations (KC705 or ZC706 only) it is also possible to source firmware from `the M-Labs Hydra server <https://nixbld.m-labs.hk/project/artiq>`_ (in ``main`` and ``zynq`` respectively).
|
||||
|
||||
Without a subscription, you may build the firmware yourself from the open source code. See the section :doc:`building_developing`.
|
||||
|
||||
Installing and configuring OpenOCD
|
||||
----------------------------------
|
||||
|
||||
.. warning::
|
||||
These instructions are not applicable to Zynq devices (Kasli-SoC or ZC706), which do not use the utility ``artiq_flash`` to reflash. If your core device is a Zynq device, skip straight to :ref:`writing-flash`.
|
||||
|
||||
ARTIQ supplies the utility ``artiq_flash``, which uses OpenOCD to write the binary images into an FPGA board's flash memory. For both Nix and MSYS2, OpenOCD are included with the installation by default. Note that in the case of Nix this is the package ``artiq.openocd-bscanspi`` and not ``pkgs.openocd``; the second is OpenOCD from the Nix package collection, which does not support ARTIQ/Sinara boards.
|
||||
|
||||
.. note::
|
||||
|
||||
With Conda, install ``openocd`` as follows: ::
|
||||
|
||||
$ conda install -c m-labs openocd
|
||||
|
||||
Some additional steps are necessary to ensure that OpenOCD can communicate with the FPGA board:
|
||||
|
||||
On Linux
|
||||
^^^^^^^^
|
||||
|
||||
First ensure that the current user belongs to the ``plugdev`` group (i.e. ``plugdev`` shown when you run ``$ groups``). If it does not, run ``$ sudo adduser $USER plugdev`` and re-login.
|
||||
|
||||
If you installed OpenOCD on Linux using Nix, use the ``which`` command to determine the path to OpenOCD, and then copy the udev rules: ::
|
||||
|
||||
$ which openocd
|
||||
/nix/store/2bmsssvk3d0y5hra06pv54s2324m4srs-openocd-mlabs-0.10.0/bin/openocd
|
||||
$ sudo cp /nix/store/2bmsssvk3d0y5hra06pv54s2324m4srs-openocd-mlabs-0.10.0/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d
|
||||
$ sudo udevadm trigger
|
||||
|
||||
NixOS users should configure OpenOCD through ``/etc/nixos/configuration.nix`` instead.
|
||||
|
||||
Linux using Conda
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are using a Conda environment ``artiq``, then execute the statements below. If you are using a different environment, you will have to replace ``artiq`` with the name of your environment::
|
||||
|
||||
$ sudo cp ~/.conda/envs/artiq/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d
|
||||
$ sudo udevadm trigger
|
||||
|
||||
On Windows
|
||||
^^^^^^^^^^
|
||||
|
||||
A third-party tool, `Zadig <http://zadig.akeo.ie/>`_, is necessary. It is also included with the MSYS2 offline installer and available from the Start Menu as ``Zadig Driver Installer``. Use it as follows:
|
||||
|
||||
1. Make sure the FPGA board's JTAG USB port is connected to your computer.
|
||||
2. Activate Options → List All Devices.
|
||||
3. Select the "Digilent Adept USB Device (Interface 0)" or "FTDI Quad-RS232 HS" (or similar)
|
||||
device from the drop-down list.
|
||||
4. Select WinUSB from the spinner list.
|
||||
5. Click "Install Driver" or "Replace Driver".
|
||||
|
||||
You may need to repeat these steps every time you plug the FPGA board into a port it has not previously been plugged into, even on the same system.
|
||||
|
||||
.. _writing-flash:
|
||||
|
||||
Writing the flash
|
||||
-----------------
|
||||
|
||||
First ensure the board is connected to your computer. In the case of Kasli, the JTAG adapter is integrated into the Kasli board; for flashing (and debugging) you can simply connect your computer to the micro-USB connector on the Kasli front panel. For Kasli-SoC, which uses ``artiq_coremgmt`` to flash over network, an Ethernet connection and an IP address, supplied either with the ``-D`` option or in your :ref:`device database <device-db>`, are sufficient.
|
||||
|
||||
For Kasli-SoC or ZC706:
|
||||
::
|
||||
|
||||
$ artiq_coremgmt [-D 192.168.1.75] config write -f boot [afws_directory]/boot.bin
|
||||
$ artiq_coremgmt reboot
|
||||
|
||||
If the device is not reachable due to corrupted firmware or networking problems, extract the SD card and copy ``boot.bin`` onto it manually.
|
||||
|
||||
For Kasli:
|
||||
::
|
||||
|
||||
$ artiq_flash -d [afws_directory]
|
||||
|
||||
For KC705:
|
||||
::
|
||||
|
||||
$ artiq_flash -t kc705 -d [afws_directory]
|
||||
|
||||
The SW13 switches need to be set to 00001.
|
||||
|
||||
Flashing over network is also possible for Kasli and KC705, assuming IP networking has already been set up. In this case, the ``-H HOSTNAME`` option is used; see the entry for ``artiq_flash`` in the :ref:`Utilities <flashing-loading-tool>` reference.
|
||||
|
||||
.. _connecting-uart:
|
||||
|
||||
Connecting to the UART log
|
||||
--------------------------
|
||||
|
||||
A UART is a peripheral device for asynchronous serial communication; in the case of core device boards, it allows the reading of the UART log, which is used for debugging, especially when problems with booting or networking disallow checking core logs with ``artiq_coremgmt log``. If you had no issues flashing your board you can proceed directly to :doc:`configuring`.
|
||||
|
||||
Otherwise, ensure your core device is connected to your PC with a data micro-USB cable, as above, and wait at least fifteen seconds after startup to try to connect. To help find the correct port to connect to, you can list your system's serial devices by running: ::
|
||||
|
||||
$ python -m serial.tools.list_ports -v
|
||||
|
||||
This will give you the list of ``/dev/ttyUSBx`` or ``COMx`` device names (on Linux and Windows respectively). Most commonly, the correct option is the third, i.e. index number 2, but it can vary.
|
||||
|
||||
On Linux:
|
||||
Run the commands: ::
|
||||
|
||||
stty 115200 < /dev/ttyUSBx
|
||||
cat /dev/ttyUSBx
|
||||
|
||||
When you restart or reflash the core device you should see the startup logs in the terminal. If you encounter issues, try other ``ttyUSBx`` names, and make certain that your user is part of the ``dialout`` group (run ``groups`` in a terminal to check).
|
||||
|
||||
On Windows:
|
||||
Use a program such as PuTTY to connect to the COM port. Connect to every available COM port at first, restart the core device, see which port produces meaningful output, and close the others. It may be necessary to install the `FTDI drivers <https://ftdichip.com/drivers/>`_ first.
|
||||
|
||||
Note that the correct parameters for the serial port are 115200bps 8-N-1 for every core device.
|
||||
|
|
@ -23,15 +23,15 @@ As a very first step, we will turn on a LED on the core device. Create a file ``
|
|||
|
||||
The central part of our code is our ``LED`` class, which derives from :class:`~artiq.language.environment.EnvExperiment`. Almost all experiments should derive from this class, which provides access to the environment as well as including the necessary experiment framework from the base-level :class:`~artiq.language.environment.Experiment`. It will call our :meth:`~artiq.language.environment.HasEnvironment.build` at the right time and provides the :meth:`~artiq.language.environment.HasEnvironment.setattr_device` we use to gain access to our devices ``core`` and ``led``. The :func:`~artiq.language.core.kernel` decorator (``@kernel``) tells the system that the :meth:`~artiq.language.environment.Experiment.run` method is a kernel and must be compiled for and executed on the core device (instead of being interpreted and executed as regular Python code on the host).
|
||||
|
||||
Before you can run the example experiment, you need to supply ARTIQ with the device database for your system. This comes in the form of a Python script typically called ``device_db.py`` (see also the page :ref:`device-db`). If you purchased a system from M-Labs, the ``device_db.py`` for your system will normally already have been provided to you (either on the USB stick, inside ``~/artiq`` on the NUC, or by email). If you have the system description file for your configuration on hand, you can use the ARTIQ front-end tool ``artiq_ddb_template`` to generate a matching device database file. Otherwise, examples are available in the ``examples`` folder of ARTIQ, sorted into corresponding subfolders by core device, which you can edit to match your system.
|
||||
Before you can run the example experiment, you will need to supply ARTIQ with the device database for your system, just as you did when configuring the core device. Make sure ``device_db.py`` is in the same directory as ``led.py``. Check once again that the field ``core_addr``, placed at the top of the file, matches the current IP address of your core device.
|
||||
|
||||
If you don't have a ``device_db.py`` for your system, consult :ref:`device-db` to find out how to construct one. You can also find example device databases in the ``examples`` folder of ARTIQ, sorted into corresponding subfolders by core device, which you can edit to match your system.
|
||||
|
||||
.. note::
|
||||
To access the examples, you can find where the ARTIQ package is installed on your machine with: ::
|
||||
To access the examples, find where the ARTIQ package is installed on your machine with: ::
|
||||
|
||||
python3 -c "import artiq; print(artiq.__path__[0])"
|
||||
|
||||
Make sure ``device_db.py`` is in the same directory as ``led.py``. The field ``core_addr``, placed at the top of the file, needs to match the current IP address of your core device in order for your host machine to contact it. If you purchased a pre-assembled system and haven't changed the IP address it is normally already set correctly.
|
||||
|
||||
Run your code using ``artiq_run``, which is one of the ARTIQ front-end tools: ::
|
||||
|
||||
$ artiq_run led.py
|
||||
|
|
|
|||
|
|
@ -13,6 +13,8 @@ ARTIQ manual
|
|||
:maxdepth: 2
|
||||
|
||||
installing
|
||||
flashing
|
||||
configuring
|
||||
developing
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@ -3,21 +3,25 @@ Installing ARTIQ
|
|||
|
||||
ARTIQ can be installed using the Nix (on Linux) or MSYS2 (on Windows) package managers. Using Conda is also possible on both platforms but not recommended.
|
||||
|
||||
.. _installing-nix-users:
|
||||
|
||||
Installing via Nix (Linux)
|
||||
--------------------------
|
||||
|
||||
First, install the Nix package manager. Some distributions provide a package for the Nix package manager, otherwise, it can be installed via the script on the `Nix website <http://nixos.org/nix/>`_. Make sure you get Nix version 2.4 or higher.
|
||||
First install the Nix package manager. Some distributions provide a package for it; otherwise, it can be installed via the script on the `Nix website <http://nixos.org/nix/>`_. Make sure you get Nix version 2.4 or higher. Prefer a single-user installation for simplicity.
|
||||
|
||||
Once Nix is installed, enable Flakes: ::
|
||||
Once Nix is installed, enable flakes, for example by running: ::
|
||||
|
||||
$ mkdir -p ~/.config/nix
|
||||
$ echo "experimental-features = nix-command flakes" > ~/.config/nix/nix.conf
|
||||
$ echo "experimental-features = nix-command flakes" >> ~/.config/nix/nix.conf
|
||||
|
||||
The easiest way to obtain ARTIQ is then to install it into the user environment with ``$ nix profile install git+https://github.com/m-labs/artiq.git``. Answer "Yes" to the questions about setting Nix configuration options. This provides a minimal installation of ARTIQ where the usual commands (``artiq_master``, ``artiq_dashboard``, ``artiq_run``, etc.) are available.
|
||||
See also the different options for enabling flakes on `the NixOS wiki <https://nixos.wiki/wiki/flakes>`_.
|
||||
|
||||
This installation is however quite limited, as Nix creates a dedicated Python environment for the ARTIQ commands alone. This means that other useful Python packages that you may want (pandas, matplotlib, ...) are not available to them.
|
||||
The easiest way to obtain ARTIQ is to install it into the user environment with ::
|
||||
|
||||
$ nix profile install git+https://github.com/m-labs/artiq.git
|
||||
|
||||
Answer "Yes" to the questions about setting Nix configuration options (for more details see 'Troubleshooting' below.) You should now have a minimal installation of ARTIQ, where the usual front-end commands (``artiq_run``, ``artiq_master``, ``artiq_dashboard``, etc.) are all available to you.
|
||||
|
||||
This installation is however quite limited, as Nix creates a dedicated Python environment for the ARTIQ commands alone. This means that other useful Python packages, which ARTIQ is not dependent on but which you may want to use in your experiments (pandas, matplotlib...), are not available.
|
||||
|
||||
Installing multiple packages and making them visible to the ARTIQ commands requires using the Nix language. Create an empty directory with a file ``flake.nix`` with the following contents:
|
||||
|
||||
|
|
@ -39,6 +43,7 @@ Installing multiple packages and making them visible to the ARTIQ commands requi
|
|||
(pkgs.python3.withPackages(ps: [
|
||||
# List desired Python packages here.
|
||||
artiq.artiq
|
||||
#ps.misoc # to access UART logs
|
||||
#ps.paramiko # needed if and only if flashing boards remotely (artiq_flash -H)
|
||||
#artiq.flake8-artiq
|
||||
#artiq.dax
|
||||
|
|
@ -47,8 +52,6 @@ Installing multiple packages and making them visible to the ARTIQ commands requi
|
|||
# The NixOS package collection contains many other packages that you may find
|
||||
# interesting. Here are some examples:
|
||||
#ps.pandas
|
||||
#ps.numpy
|
||||
#ps.scipy
|
||||
#ps.numba
|
||||
#ps.matplotlib
|
||||
# or if you need Qt (will recompile):
|
||||
|
|
@ -56,11 +59,13 @@ Installing multiple packages and making them visible to the ARTIQ commands requi
|
|||
#ps.bokeh
|
||||
#ps.cirq
|
||||
#ps.qiskit
|
||||
# Note that NixOS also provides packages ps.numpy and ps.scipy, but it is
|
||||
# not necessary to explicitly add these, since they are dependencies of
|
||||
# ARTIQ and available with an ARTIQ install anyway.
|
||||
]))
|
||||
#artiq.korad_ka3005p
|
||||
#artiq.novatech409b
|
||||
# List desired non-Python packages here
|
||||
#artiq.openocd-bscanspi # needed if and only if flashing boards
|
||||
# Other potentially interesting non-Python packages from the NixOS package collection:
|
||||
#pkgs.gtkwave
|
||||
#pkgs.spyder
|
||||
|
|
@ -78,14 +83,16 @@ Installing multiple packages and making them visible to the ARTIQ commands requi
|
|||
};
|
||||
}
|
||||
|
||||
.. note::
|
||||
You might consider adding matplotlib and numba in particular, as these are required by certain ARTIQ example experiments.
|
||||
|
||||
Then spawn a shell containing the packages with ``$ nix shell``. The ARTIQ commands with all the additional packages should now be available.
|
||||
You can now spawn a shell containing these packages by running ``$ nix shell`` in the directory containing the ``flake.nix``. This should make both the ARTIQ commands and all the additional packages available to you. You can exit the shell with Control+D or with the command ``exit``. A first execution of ``$ nix shell`` may take some time, but for any future repetitions Nix will use cached packages and startup should be much faster.
|
||||
|
||||
You can exit the shell by typing Control-D. The next time ``$ nix shell`` is invoked, Nix uses the cached packages so the shell startup is fast.
|
||||
You might be interested in creating multiple directories containing different ``flake.nix`` files which represent different sets of packages for different purposes. If you are familiar with Conda, using Nix in this way is similar to having multiple Conda environments.
|
||||
|
||||
You can create directories containing each a ``flake.nix`` that correspond to different sets of packages. If you are familiar with Conda, using Nix in this way is similar to having multiple Conda environments.
|
||||
To find more packages you can browse the `Nix package search <https://search.nixos.org/packages>`_ website. If your favorite package is not available with Nix, contact M-Labs using the helpdesk@ email.
|
||||
|
||||
If your favorite package is not available with Nix, contact us using the helpdesk@ email.
|
||||
.. _installing-troubleshooting:
|
||||
|
||||
Troubleshooting
|
||||
^^^^^^^^^^^^^^^
|
||||
|
|
@ -93,9 +100,7 @@ Troubleshooting
|
|||
"Do you want to allow configuration setting... (y/N)?"
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
When installing and initializing ARTIQ using commands like ``nix shell``, ``nix develop``, or ``nix profile install``, you may encounter prompts to modify certain configuration settings. These settings correspond to the ``nixConfig`` flag within the ARTIQ flake:
|
||||
|
||||
::
|
||||
When installing and initializing ARTIQ using commands like ``nix shell``, ``nix develop``, or ``nix profile install``, you may encounter prompts to modify certain configuration settings. These settings correspond to the ``nixConfig`` flag within the ARTIQ flake: ::
|
||||
|
||||
do you want to allow configuration setting 'extra-sandbox-paths' to be set to '/opt' (y/N)?
|
||||
do you want to allow configuration setting 'extra-substituters' to be set to 'https://nixbld.m-labs.hk' (y/N)?
|
||||
|
|
@ -103,15 +108,11 @@ When installing and initializing ARTIQ using commands like ``nix shell``, ``nix
|
|||
|
||||
We recommend accepting these settings by responding with ``y``. If asked to permanently mark these values as trusted, choose ``y`` again. This action saves the configuration to ``~/.local/share/nix/trusted-settings.json``, allowing future prompts to be bypassed.
|
||||
|
||||
Alternatively, you can also use the option `accept-flake-config <https://nix.dev/manual/nix/stable/command-ref/conf-file#conf-accept-flake-config>`_ by appending ``--accept-flake-config`` to your nix command:
|
||||
|
||||
::
|
||||
Alternatively, you can also use the option `accept-flake-config <https://nix.dev/manual/nix/stable/command-ref/conf-file#conf-accept-flake-config>`_ by appending ``--accept-flake-config`` to your nix command, for example: ::
|
||||
|
||||
nix develop --accept-flake-config
|
||||
|
||||
Or add the option to ``~/.config/nix/nix.conf`` to make the setting more permanent:
|
||||
|
||||
::
|
||||
Or add the option to ``~/.config/nix/nix.conf`` to make the setting more permanent: ::
|
||||
|
||||
extra-experimental-features = flakes
|
||||
accept-flake-config = true
|
||||
|
|
@ -122,26 +123,18 @@ Or add the option to ``~/.config/nix/nix.conf`` to make the setting more permane
|
|||
"Ignoring untrusted substituter, you are not a trusted user"
|
||||
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
|
||||
|
||||
If the following message displays when running ``nix shell`` or ``nix develop``
|
||||
|
||||
::
|
||||
If the following message displays when running ``nix shell`` or ``nix develop`` ::
|
||||
|
||||
warning: ignoring untrusted substituter 'https://nixbld.m-labs.hk', you are not a trusted user.
|
||||
Run `man nix.conf` for more information on the `substituters` configuration option.
|
||||
|
||||
and Nix proceeds to build some packages from source, this means that you are using `multi-user mode <https://nix.dev/manual/nix/stable/installation/multi-user>`_ in Nix, for example when Nix is installed via ``pacman`` in Arch Linux.
|
||||
|
||||
By default, users accessing Nix in multi-user mode are "unprivileged" and cannot use untrusted substituters. To change this, edit ``/etc/nix/nix.conf`` and add the following line (or append to the key if the key already exists):
|
||||
|
||||
::
|
||||
and Nix proceeds to build some packages from source, this means that you are using `multi-user mode <https://nix.dev/manual/nix/stable/installation/multi-user>`_ in Nix, which may be the case for example when Nix is installed via ``pacman`` in Arch Linux. By default, users accessing Nix in multi-user mode are "unprivileged" and cannot use untrusted substituters. To change this, edit ``/etc/nix/nix.conf`` and add the following line (or append to the key if the key already exists): ::
|
||||
|
||||
trusted-substituters = https://nixbld.m-labs.hk
|
||||
|
||||
This will add the substituter as a trusted substituter for all users using Nix.
|
||||
|
||||
Alternatively, add the following line:
|
||||
|
||||
::
|
||||
Alternatively, add the following line: ::
|
||||
|
||||
trusted-users = <username> # Replace <username> with the user invoking `nix`
|
||||
|
||||
|
|
@ -154,8 +147,7 @@ This will set your user as a trusted user, allowing the use of any untrusted sub
|
|||
Installing via MSYS2 (Windows)
|
||||
------------------------------
|
||||
|
||||
We recommend using our `offline installer <https://nixbld.m-labs.hk/job/artiq/extra-beta/msys2-offline-installer/latest>`_, which contains all the necessary packages and no additional configuration is needed.
|
||||
After installation, launch ``MSYS2 with ARTIQ`` from the Windows Start menu.
|
||||
We recommend using our `offline installer <https://nixbld.m-labs.hk/job/artiq/extra-beta/msys2-offline-installer/latest>`_, which contains all the necessary packages and requires no additional configuration. After installation, simply launch ``MSYS2 with ARTIQ`` from the Windows Start menu.
|
||||
|
||||
Alternatively, you may install `MSYS2 <https://msys2.org>`_, then edit ``C:\MINGW64\etc\pacman.conf`` and add at the end: ::
|
||||
|
||||
|
|
@ -165,24 +157,26 @@ Alternatively, you may install `MSYS2 <https://msys2.org>`_, then edit ``C:\MING
|
|||
|
||||
Launch ``MSYS2 CLANG64`` from the Windows Start menu to open the MSYS2 shell, and enter the following commands: ::
|
||||
|
||||
pacman -Syy
|
||||
pacman -S mingw-w64-clang-x86_64-artiq
|
||||
$ pacman -Syy
|
||||
$ pacman -S mingw-w64-clang-x86_64-artiq
|
||||
|
||||
If your favorite package is not available with MSYS2, contact us using the helpdesk@ email.
|
||||
As above in the Nix section, you may find yourself wanting to add other useful packages (pandas, matplotlib, etc.). MSYS2 uses a port of ArchLinux's ``pacman`` to manage (add, remove, and update) packages. To add a specific package, you can simply use a command of the form: ::
|
||||
|
||||
Installing via Conda (Windows, Linux) [DEPRECATED]
|
||||
--------------------------------------------------
|
||||
$ pacman -S <package name>
|
||||
|
||||
For more see the `MSYS2 documentation <https://www.msys2.org/docs/package-management/>`_ on package management. If your favorite package is not available with MSYS2, contact M-Labs using the helpdesk@ email.
|
||||
|
||||
Installing via Conda [DEPRECATED]
|
||||
---------------------------------
|
||||
|
||||
.. warning::
|
||||
Installing ARTIQ via Conda is not recommended. Instead, Linux users should install it via Nix and Windows users should install it via MSYS2. Conda support may be removed in future ARTIQ releases and M-Labs can only provide very limited technical support for Conda.
|
||||
|
||||
First, install `Anaconda <https://www.anaconda.com/download>`_ or the more minimalistic `Miniconda <https://conda.io/en/latest/miniconda.html>`_.
|
||||
|
||||
After installing either Anaconda or Miniconda, open a new terminal (also known as command line, console, or shell and denoted here as lines starting with ``$``) and verify the following command works::
|
||||
First, install `Anaconda <https://www.anaconda.com/download>`_ or the more minimalistic `Miniconda <https://conda.io/en/latest/miniconda.html>`_. After installing either Anaconda or Miniconda, open a new terminal and verify that the following command works::
|
||||
|
||||
$ conda
|
||||
|
||||
Executing just ``conda`` should print the help of the ``conda`` command. If your shell does not find the ``conda`` command, make sure that the Conda binaries are in your ``$PATH``. If ``$ echo $PATH`` does not show the Conda directories, add them: execute ``$ export PATH=$HOME/miniconda3/bin:$PATH`` if you installed Conda into ``~/miniconda3``.
|
||||
Executing just ``conda`` should print the help of the ``conda`` command. If your shell cannot find the ``conda`` command, make sure that the Conda binaries are in your ``$PATH``. If ``$ echo $PATH`` does not show the Conda directories, add them: execute e.g. ``$ export PATH=$HOME/miniconda3/bin:$PATH`` if you installed Conda into ``~/miniconda3``.
|
||||
|
||||
Controllers for third-party devices (e.g. Thorlabs TCube, Lab Brick Digital Attenuator, etc.) that are not shipped with ARTIQ can also be installed with this script. Browse `Hydra <https://nixbld.m-labs.hk/project/artiq>`_ or see the list of NDSPs in this manual to find the names of the corresponding packages, and list them at the beginning of the script.
|
||||
|
||||
|
|
@ -204,14 +198,11 @@ After the installation, activate the newly created environment by name. ::
|
|||
|
||||
This activation has to be performed in every new shell you open to make the ARTIQ tools from that environment available.
|
||||
|
||||
.. note::
|
||||
Some ARTIQ examples also require matplotlib and numba, and they must be installed manually for running those examples. They are available in Conda.
|
||||
|
||||
Upgrading ARTIQ
|
||||
---------------
|
||||
|
||||
.. note::
|
||||
When you upgrade ARTIQ, as well as updating the software on your host machine, it may also be necessary to reflash the gateware and firmware of your core device to keep them compatible. New numbered release versions in particular incorporate breaking changes and are not generally compatible. See :ref:`reflashing-core-device` below for instructions on reflashing.
|
||||
When you upgrade ARTIQ, as well as updating the software on your host machine, it may also be necessary to reflash the gateware and firmware of your core device to keep them compatible. New numbered release versions in particular incorporate breaking changes and are not generally compatible. See :doc:`flashing` for instructions.
|
||||
|
||||
Upgrading with Nix
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -223,13 +214,12 @@ To rollback to the previous version, respectively use ``$ nix profile rollback``
|
|||
Upgrading with MSYS2
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Run ``pacman -Syu`` to update all MSYS2 packages including ARTIQ. If you get a message telling you that the shell session must be restarted after a partial update, open the shell again after the partial update and repeat the command. See the MSYS2 and Pacman manual for information on how to update individual packages if required.
|
||||
Run ``pacman -Syu`` to update all MSYS2 packages, including ARTIQ. If you get a message telling you that the shell session must be restarted after a partial update, open the shell again after the partial update and repeat the command. See the `MSYS2 <https://www.msys2.org/docs/updating/>`__ and `Pacman <https://wiki.archlinux.org/title/Pacman>`_ manuals for more information, including how to update individual packages if required.
|
||||
|
||||
Upgrading with Conda
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When upgrading ARTIQ or when testing different versions it is recommended that new Conda environments are created instead of upgrading the packages in existing environments.
|
||||
As a rule, keep previous environments around unless you are certain that they are no longer needed and the new environment is working correctly.
|
||||
When upgrading ARTIQ or when testing different versions it is recommended that new Conda environments are created instead of upgrading the packages in existing environments. As a rule, keep previous environments around unless you are certain that they are no longer needed and the new environment is working correctly.
|
||||
|
||||
To install the latest version, simply select a different environment name and run the installation commands again.
|
||||
|
||||
|
|
@ -238,194 +228,3 @@ Switching between Conda environments using commands such as ``$ conda deactivate
|
|||
You can list the environments you have created using::
|
||||
|
||||
$ conda env list
|
||||
|
||||
.. _reflashing-core-device:
|
||||
|
||||
Reflashing core device gateware and firmware
|
||||
--------------------------------------------
|
||||
|
||||
.. note::
|
||||
If you have purchased a pre-assembled system from M-Labs or QUARTIQ, the gateware and firmware of your devices will already be flashed to the newest version of ARTIQ. These steps are only necessary if you obtained your hardware in a different way, or if you want to change your system configuration or upgrade your ARTIQ version after the original purchase.
|
||||
|
||||
|
||||
Obtaining the board binaries
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you have an active firmware subscription with M-Labs or QUARTIQ, you can obtain firmware for your system that corresponds to your currently installed version of ARTIQ using AFWS (ARTIQ firmware service). One year of subscription is included with most hardware purchases. You may purchase or extend firmware subscriptions by writing to the sales@ email.
|
||||
|
||||
Run the command::
|
||||
|
||||
$ afws_client [username] build [afws_directory] [variant]
|
||||
|
||||
Replace ``[username]`` with the login name that was given to you with the subscription, ``[variant]`` with the name of your system variant, and ``[afws_directory]`` with the name of an empty directory, which will be created by the command if it does not exist. Enter your password when prompted and wait for the build (if applicable) and download to finish. If you experience issues with the AFWS client, write to the helpdesk@ email.
|
||||
|
||||
For certain configurations (KC705 or ZC705 only) it is also possible to source firmware from `the M-Labs Hydra server <https://nixbld.m-labs.hk/project/artiq>`_ (in ``main`` and ``zynq`` respectively).
|
||||
|
||||
Without a subscription, you may build the firmware yourself from the open source code. See the section :ref:`Developing ARTIQ <developing-artiq>`.
|
||||
|
||||
.. _installing-configuring-openocd:
|
||||
|
||||
Installing and configuring OpenOCD
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
.. note::
|
||||
These instructions are not applicable to Kasli-SoC, which does not use the utility ``artiq_flash`` to reflash. If your core device is a Kasli SoC, skip straight to :ref:`writing-flash`.
|
||||
|
||||
ARTIQ supplies the utility ``artiq_flash``, which uses OpenOCD to write the binary images into an FPGA board's flash memory.
|
||||
|
||||
* With Nix, add ``aqmain.openocd-bscanspi`` to the shell packages. Be careful not to add ``pkgs.openocd`` instead - this would install OpenOCD from the NixOS package collection, which does not support ARTIQ boards.
|
||||
|
||||
* With MSYS2, ``openocd`` and ``bscan-spi-bitstreams`` are included with ``artiq`` by default.
|
||||
|
||||
* With Conda, install ``openocd`` as follows::
|
||||
|
||||
$ conda install -c m-labs openocd
|
||||
|
||||
Some additional steps are necessary to ensure that OpenOCD can communicate with the FPGA board:
|
||||
|
||||
* On Linux, first ensure that the current user belongs to the ``plugdev`` group (i.e. ``plugdev`` shown when you run ``$ groups``). If it does not, run ``$ sudo adduser $USER plugdev`` and re-login.
|
||||
|
||||
If you installed OpenOCD on Linux using Nix, use the ``which`` command to determine the path to OpenOCD, and then copy the udev rules: ::
|
||||
|
||||
$ which openocd
|
||||
/nix/store/2bmsssvk3d0y5hra06pv54s2324m4srs-openocd-mlabs-0.10.0/bin/openocd
|
||||
$ sudo cp /nix/store/2bmsssvk3d0y5hra06pv54s2324m4srs-openocd-mlabs-0.10.0/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d
|
||||
$ sudo udevadm trigger
|
||||
|
||||
NixOS users should of course configure OpenOCD through ``/etc/nixos/configuration.nix`` instead.
|
||||
|
||||
If you installed OpenOCD on Linux using Conda and are using the Conda environment ``artiq``, then execute the statements below. If you are using a different environment, you will have to replace ``artiq`` with the name of your environment::
|
||||
|
||||
$ sudo cp ~/.conda/envs/artiq/share/openocd/contrib/60-openocd.rules /etc/udev/rules.d
|
||||
$ sudo udevadm trigger
|
||||
|
||||
* On Windows, a third-party tool, `Zadig <http://zadig.akeo.ie/>`_, is necessary. It is also included with the MSYS2 offline installer and available from the Start Menu as ``Zadig Driver Installer``. Use it as follows:
|
||||
|
||||
1. Make sure the FPGA board's JTAG USB port is connected to your computer.
|
||||
2. Activate Options → List All Devices.
|
||||
3. Select the "Digilent Adept USB Device (Interface 0)" or "FTDI Quad-RS232 HS" (or similar)
|
||||
device from the drop-down list.
|
||||
4. Select WinUSB from the spinner list.
|
||||
5. Click "Install Driver" or "Replace Driver".
|
||||
|
||||
You may need to repeat these steps every time you plug the FPGA board into a port where it has not been plugged into previously on the same system.
|
||||
|
||||
.. _writing-flash:
|
||||
|
||||
Writing the flash
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
First ensure the board is connected to your computer. In the case of Kasli, the JTAG adapter is integrated into the Kasli board; for flashing (and debugging) you simply need to connect your computer to the micro-USB connector on the Kasli front panel. For Kasli-SoC, which uses ``artiq_coremgmt``, an IP address supplied either with the ``-D`` option or in a correctly specified ``device_db.py`` suffices.
|
||||
|
||||
* For Kasli-SoC::
|
||||
|
||||
$ artiq_coremgmt [-D 192.168.1.75] config write -f boot [afws_directory]/boot.bin
|
||||
|
||||
If the Kasli-SoC won't boot due to nonexistent or corrupted firmware, extract the SD card and copy ``boot.bin`` onto it manually.
|
||||
|
||||
* For Kasli::
|
||||
|
||||
$ artiq_flash -d [afws_directory]
|
||||
|
||||
* For the KC705 board::
|
||||
|
||||
$ artiq_flash -t kc705 -d [afws_directory]
|
||||
|
||||
The SW13 switches need to be set to 00001.
|
||||
|
||||
Flashing over network is also possible for Kasli and KC705, assuming IP networking has already been set up. In this case, the ``-H HOSTNAME`` option is used; see the entry for ``artiq_flash`` in the :ref:`Utilities <flashing-loading-tool>` reference.
|
||||
|
||||
.. _core-device-networking:
|
||||
|
||||
Setting up the core device IP networking
|
||||
----------------------------------------
|
||||
|
||||
For Kasli, insert a SFP/RJ45 transceiver (normally included with purchases from M-Labs and QUARTIQ) into the SFP0 port and connect it to an Ethernet port in your network. If the port is 10Mbps or 100Mbps and not 1000Mbps, make sure that the SFP/RJ45 transceiver supports the lower rate. Many SFP/RJ45 transceivers only support the 1000Mbps rate. If you do not have a SFP/RJ45 transceiver that supports 10Mbps and 100Mbps rates, you may instead use a gigabit Ethernet switch in the middle to perform rate conversion.
|
||||
|
||||
You can also insert other types of SFP transceivers into Kasli if you wish to use it directly in e.g. an optical fiber Ethernet network.
|
||||
|
||||
Kasli-SoC already directly features RJ45 10/100/1000T Ethernet, but the same is still true of its SFP ports.
|
||||
|
||||
If you purchased a Kasli or Kasli-SoC device from M-Labs, it usually comes with the IP address ``192.168.1.75``. Once you can reach this IP, it can be changed by running: ::
|
||||
|
||||
$ artiq_coremgmt -D 192.168.1.75 config write -s ip [new IP]
|
||||
|
||||
and then rebooting the device
|
||||
|
||||
$ artiq_coremgmt reboot
|
||||
|
||||
* For Kasli-SoC:
|
||||
|
||||
If the ``ip`` config is not set, Kasli-SoC firmware defaults to using the IP address ``192.168.1.56``. It can then be changed with the procedure above.
|
||||
|
||||
* For Kasli or KC705:
|
||||
|
||||
If the ``ip`` config field is not set or set to ``use_dhcp``, the device will attempt to obtain an IP address and default gateway using DHCP. If a static IP address is nonetheless wanted, it can be flashed directly (OpenOCD must be installed and configured, as above), along with, as necessary, default gateway, IPv6, and/or MAC address: ::
|
||||
|
||||
$ artiq_mkfs flash_storage.img [-s mac xx:xx:xx:xx:xx:xx] [-s ip xx.xx.xx.xx/xx] [-s ipv4_default_route xx.xx.xx.xx] [-s ip6 xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/xx] [-s ipv6_default_route xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]
|
||||
$ artiq_flash -t [board] -V [variant] -f flash_storage.img storage start
|
||||
|
||||
On Kasli or Kasli SoC devices, specifying the MAC address is unnecessary, as they can obtain it from their EEPROM. If you only want to access the core device from the same subnet, default gateway and IPv4 prefix length may also be ommitted. Regardless of board, once a device is reachable by ``artiq_coremgmt``, any of these fields can be accessed using ``artiq_coremgmt config write`` and ``artiq_coremgt config read``; see also :ref:`Utilities <core-device-management-tool>`.
|
||||
|
||||
If DHCP has been used the address can be found in the console output, which can be viewed using: ::
|
||||
|
||||
$ python -m misoc.tools.flterm /dev/ttyUSB2
|
||||
|
||||
Check that you can ping the device. If ping fails, check that the Ethernet link LED is ON - on Kasli, it is the LED next to the SFP0 connector. As a next step, look at the messages emitted on the UART during boot. Use a program such as flterm or PuTTY to connect to the device's serial port at 115200bps 8-N-1 and reboot the device. On Kasli, the serial port is on FTDI channel 2 with v1.1 hardware (with channel 0 being JTAG) and on FTDI channel 1 with v1.0 hardware. Note that on Windows you might need to install the `FTDI drivers <https://ftdichip.com/drivers/>`_ first.
|
||||
|
||||
Regarding use of IPv6, note that the device also has a link-local address that corresponds to its EUI-64, which can be used simultaneously to the IPv6 address defined by using the ``ip6`` configuration key, which may be of arbitrary nature.
|
||||
|
||||
.. _miscellaneous_config_core_device:
|
||||
|
||||
Miscellaneous configuration of the core device
|
||||
----------------------------------------------
|
||||
|
||||
These steps are optional, and only need to be executed if necessary for your specific purposes. In all cases, the core device generally needs to be restarted for changes to take effect.
|
||||
|
||||
Flash idle or startup kernel
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The idle kernel is the kernel (that is, a piece of code running on the core device; see :ref:`next topic <connecting-to-the-core-device>` for more information about kernels) which the core device runs whenever it is not connected to the host via Ethernet. This kernel is therefore stored immediately in the :ref:`core device configuration flash storage <core-device-flash-storage>`.
|
||||
|
||||
To flash the idle kernel, first compile an idle experiment. Since the core device is not connected to the host, RPCs (calling Python code running on the host from the kernel) are forbidden, and its ``run()`` method must be a kernel, marked correctly with the ``@kernel`` decorator. Write the compiled experiment to the core device configuration flash storage, under the key ``idle_kernel``: ::
|
||||
|
||||
$ artiq_compile idle.py
|
||||
$ artiq_coremgmt config write -f idle_kernel idle.elf
|
||||
|
||||
The startup kernel is the kernel executed once immediately whenever the core device powers on. Uses include initializing DDSes, setting TTL directions etc. Proceed as with the idle kernel, but using the ``startup_kernel`` key in the ``artiq_coremgmt`` command.
|
||||
|
||||
For DRTIO systems, the startup kernel should wait until the desired destinations (including local RTIO) are up, using :meth:`~artiq.coredevice.core.Core.get_rtio_destination_status`.
|
||||
|
||||
Select the RTIO clock source
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The core device may use any of: an external clock signal, its internal clock with external frequency reference, or its internal clock with internal crystal reference. Clock source and timing are set at power-up. To find out what clock signal you are using, check startup logs with ``artiq_coremgmt log``.
|
||||
|
||||
The default is to use an internal 125MHz clock. To select a source, use a command of the form: ::
|
||||
|
||||
$ artiq_coremgmt config write -s rtio_clock int_125 # internal 125MHz clock (default)
|
||||
$ artiq_coremgmt config write -s rtio_clock ext0_synth0_10to125 # external 10MHz reference used to synthesize internal 125MHz
|
||||
|
||||
See :ref:`core-device-clocking` for availability of specific options.
|
||||
|
||||
Set up resolving RTIO channels to their names
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This feature allows you to print the channels' respective names alongside with their numbers in RTIO error messages. To enable it, run the ``artiq_rtiomap`` tool and write its result into the device config at the ``device_map`` key: ::
|
||||
|
||||
$ artiq_rtiomap dev_map.bin
|
||||
$ artiq_coremgmt config write -f device_map dev_map.bin
|
||||
|
||||
.. note:: More information on the ``artiq_rtiomap`` utility can be found on the :ref:`Utilities <rtiomap-tool>` page.
|
||||
|
||||
Enabling event spreading
|
||||
------------------------
|
||||
|
||||
This feature changes the logic used for queueing RTIO output events in the core device for a more efficient use of FPGA resources, at the cost of introducing nondeterminism and potential unpredictability in certain timing errors (specifically gateware :ref:`sequence errors<sequence-errors>`). It can be enabled with the config key ``sed_spread_enable``. See :ref:`sed-event-spreading`.
|
||||
|
||||
Load the DRTIO routing table
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you are using DRTIO and the default routing table (for a star topology) is not suitable to your needs, you will first need to prepare and load a different routing table. See :ref:`Using DRTIO <drtio-routing>`.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue