|
| 1 | +.. _nsim_arc_v: |
| 2 | + |
| 3 | +DesignWare RISC-V nSIM and HAPS FPGA boards |
| 4 | +########################################### |
| 5 | + |
| 6 | +Overview |
| 7 | +******** |
| 8 | + |
| 9 | +This platform can be used to run Zephyr RTOS on the widest possible range of Synopsys RISC-V processors in |
| 10 | +simulation with `Designware ARC nSIM`_ or run same images on FPGA prototyping platform `HAPS`_. The |
| 11 | +platform includes the following features: |
| 12 | + |
| 13 | +* RISC-V processor core, which implements riscv32 ISA |
| 14 | +* Virtual serial console (a standard ``ns16550`` UART model) |
| 15 | + |
| 16 | +Supported board targets for that platform are listed below: |
| 17 | + |
| 18 | +* ``nsim_arc_v/rmx100`` - Synopsys RISC-V RMX100 core |
| 19 | + |
| 20 | +.. _board_nsim_arc_v_prop_files: |
| 21 | + |
| 22 | +It is recommended to look at precise description of a particular board target in ``.props`` |
| 23 | +files in :zephyr_file:`boards/snps/nsim_arc_v/support/` directory to understand |
| 24 | +which options are configured and so will be used on invocation of the simulator. |
| 25 | + |
| 26 | +.. warning:: |
| 27 | + All nSIM targets are used for demo and testing purposes. They are not meant to |
| 28 | + represent any real system and so might be renamed, removed or modified at any point. |
| 29 | + |
| 30 | +Programming and Debugging |
| 31 | +************************* |
| 32 | + |
| 33 | +Required Hardware and Software |
| 34 | +============================== |
| 35 | + |
| 36 | +To run single-core Zephyr RTOS applications in simulation on this board, |
| 37 | +either `DesignWare ARC nSIM`_ or `DesignWare ARC Free nSIM`_ is required. |
| 38 | + |
| 39 | +Building & Running Sample Applications |
| 40 | +====================================== |
| 41 | + |
| 42 | +Most board targets support building with GNU toolchains, however |
| 43 | +there might be exceptions from that, especially for newly added targets. You can check supported |
| 44 | +toolchains for the board targets in the corresponding ``.yaml`` file. |
| 45 | + |
| 46 | +I.e. for the ``nsim_arc_v/rmx100`` board we can check :zephyr_file:`boards/snps/nsim_arc_v/nsim_arc_v_rmx100.yaml` |
| 47 | + |
| 48 | +The supported toolchains are listed in ``toolchain:`` array in ``.yaml`` file, where we can find: |
| 49 | + |
| 50 | +* **zephyr** - implies RISC-V GNU toolchain from Zephyr SDK. You can find more information about |
| 51 | + Zephyr SDK :ref:`here <toolchain_zephyr_sdk>`. |
| 52 | +* **cross-compile** - implies RISC-V GNU cross toolchain, which is not a part of Zephyr SDK. Note that |
| 53 | + some (especially new) board targets may declare ``cross-compile`` toolchain support without |
| 54 | + ``zephyr`` toolchain support because corresponding target CPU support hasn't been added to Zephyr |
| 55 | + SDK yet. You can find more information about its usage here: :ref:`here <other_x_compilers>`. |
| 56 | +* **arcmwdt** - implies proprietary ARC MWDT toolchain. You can find more information about its |
| 57 | + usage here: :ref:`here <toolchain_designware_arc_mwdt>`. Not yet supported: work in progress. |
| 58 | + |
| 59 | +Use this configuration to run basic Zephyr applications and kernel tests in |
| 60 | +nSIM, for example, with the :zephyr:code-sample:`synchronization` sample: |
| 61 | + |
| 62 | +.. zephyr-app-commands:: |
| 63 | + :zephyr-app: samples/synchronization |
| 64 | + :host-os: unix |
| 65 | + :board: nsim_arc_v/rmx100 |
| 66 | + :goals: flash |
| 67 | + |
| 68 | +This will build an image with the synchronization sample app, boot it using |
| 69 | +nSIM, and display the following console output: |
| 70 | + |
| 71 | +.. code-block:: console |
| 72 | +
|
| 73 | + *** Booting Zephyr OS build zephyr-v3.2.0-3948-gd351a024dc87 *** |
| 74 | + thread_a: Hello World from cpu 0 on nsim_arc_v! |
| 75 | + thread_b: Hello World from cpu 0 on nsim_arc_v! |
| 76 | + thread_a: Hello World from cpu 0 on nsim_arc_v! |
| 77 | + thread_b: Hello World from cpu 0 on nsim_arc_v! |
| 78 | + thread_a: Hello World from cpu 0 on nsim_arc_v! |
| 79 | +
|
| 80 | +.. note:: |
| 81 | + To exit the simulator, use :kbd:`Ctrl+]`, then :kbd:`Ctrl+c` |
| 82 | + |
| 83 | +.. _board_nsim_arc_v_verbose_build: |
| 84 | + |
| 85 | +.. tip:: |
| 86 | + You can get more details about the building process by running build in verbose mode. It can be |
| 87 | + done by passing ``-v`` flag to the west: ``west -v build -b nsim_hs samples/synchronization`` |
| 88 | + |
| 89 | +Debugging |
| 90 | +========= |
| 91 | + |
| 92 | +.. _board_nsim_arc_v_debugging_gdb: |
| 93 | + |
| 94 | +Debugging with GDB |
| 95 | +------------------ |
| 96 | + |
| 97 | +.. note:: |
| 98 | + Debugging on nSIM via GDB is only supported on single-core targets (which use standalone |
| 99 | + nSIM). |
| 100 | + |
| 101 | +.. note:: |
| 102 | + The normal ``west debug`` command won't work for debugging applications using nsim boards |
| 103 | + because both the nSIM simulator and the debugger use the same console for |
| 104 | + input / output. |
| 105 | + In case of GDB debugger it's possible to use a separate terminal windows for GDB and nSIM to |
| 106 | + avoid intermixing their output. |
| 107 | + |
| 108 | +After building your application, open two terminal windows. In terminal one, use nSIM to start a GDB |
| 109 | +server and wait for a remote connection with following command: |
| 110 | + |
| 111 | +.. code-block:: console |
| 112 | +
|
| 113 | + west debugserver --runner arc-nsim |
| 114 | +
|
| 115 | +In terminal two, connect to the GDB server using RISC-V GDB. You can find it in Zephyr SDK: |
| 116 | + |
| 117 | +* you should use :file:`riscv64-zephyr-elf-gdb` |
| 118 | + |
| 119 | +This command loads the symbol table from the elf binary file, for example the |
| 120 | +:file:`build/zephyr/zephyr.elf` file: |
| 121 | + |
| 122 | +.. code-block:: console |
| 123 | +
|
| 124 | + riscv64-zephyr-elf-gdb -ex 'target remote localhost:3333' -ex load build/zephyr/zephyr.elf |
| 125 | +
|
| 126 | +Now the debug environment has been set up, and it's possible to debug the application with gdb |
| 127 | +commands. |
| 128 | + |
| 129 | +Modifying the configuration |
| 130 | +*************************** |
| 131 | + |
| 132 | +If modification of existing nsim configuration is required or even there's a need in creation of a |
| 133 | +new one it's required to maintain alignment between |
| 134 | + |
| 135 | +* Zephyr OS configuration |
| 136 | +* nSIM configuration |
| 137 | +* GNU toolchain compiler options |
| 138 | + |
| 139 | +.. note:: |
| 140 | + The ``.tcf`` configuration files are not supported by Zephyr directly. There are multiple |
| 141 | + reasons for that. ``.tcf`` perfectly suits building of bare-metal single-thread application - |
| 142 | + in that case all the compiler options from ``.tcf`` are passed to the compiler, so all the HW |
| 143 | + features are used by the application and optimal code is being generated. |
| 144 | + The situation is completely different when multi-thread feature-rich operation system is |
| 145 | + considered. Of course it is still possible to build all the code with all the |
| 146 | + options from ``.tcf`` - but that may be far from optimal solution. For example, such approach |
| 147 | + require so save & restore full register context for all tasks (and sometimes even for |
| 148 | + interrupts). And for DSP-enabled or for FPU-enabled systems that leads to dozens of extra |
| 149 | + registers save and restore even if the most of the user and kernel tasks don't actually use |
| 150 | + DSP or FPU. Instead we prefer to fine-tune the HW features usage which (with all its pros) |
| 151 | + require us to maintain them separately from ``.tcf`` configuration. |
| 152 | + |
| 153 | + |
| 154 | +Zephyr OS configuration |
| 155 | +======================= |
| 156 | + |
| 157 | +Zephyr OS configuration is defined via Kconfig and Device tree. These are non RISC-V-specific |
| 158 | +mechanisms which are described in :ref:`board porting guide <board_porting_guide>`. |
| 159 | + |
| 160 | +It is advised to look for ``<board_name>_defconfig``, ``<board_name>.dts`` and |
| 161 | +``<board_name>.yaml`` as an entry point for board target. |
| 162 | + |
| 163 | +nSIM configuration |
| 164 | +================== |
| 165 | + |
| 166 | +nSIM configuration is defined in :ref:`props files <board_nsim_arc_v_prop_files>`. |
| 167 | +Generally they are identical to the values from corresponding ``.tcf`` configuration with few |
| 168 | +exceptions: |
| 169 | + |
| 170 | +* The UART model is added |
| 171 | +* CLINT model is added |
| 172 | + |
| 173 | +GNU toolchain compiler options |
| 174 | +===================================== |
| 175 | + |
| 176 | +The hardware-specific compiler options are set in corresponding SoC cmake file. For ``nsim_arc_v`` board |
| 177 | +it is :zephyr_file:`soc/snps/nsim/arc_v/CMakeLists.txt`. |
| 178 | + |
| 179 | +For the GNU toolchain the basic configuration is set via ``-march`` which is defined in generic code |
| 180 | +and based on the selected CPU model via Kconfig. It still can be forcefully set to required value |
| 181 | +on SoC level. |
| 182 | + |
| 183 | +.. note:: |
| 184 | + The non hardware-specific compiler options like optimizations, library selections, C / C++ |
| 185 | + language options are still set in Zephyr generic code. It could be observed by |
| 186 | + :ref:`running build in verbose mode <board_nsim_arc_v_verbose_build>`. |
| 187 | + |
| 188 | +References |
| 189 | +********** |
| 190 | + |
| 191 | +.. _Designware ARC nSIM: https://www.synopsys.com/dw/ipdir.php?ds=sim_nsim |
| 192 | +.. _DesignWare ARC Free nSIM: https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi |
| 193 | +.. _HAPS: https://www.synopsys.com/verification/prototyping/haps.html |
| 194 | +.. _ARC MWDT: https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware |
0 commit comments