1.. _nsim:
2
3DesignWare ARC nSIM and HAPS FPGA boards
4########################################
5
6Overview
7********
8
9This platform can be used to run Zephyr RTOS on the widest possible range of ARC processors in
10simulation with `Designware ARC nSIM`_ or run same images on FPGA prototyping platform `HAPS`_. The
11platform includes the following features:
12
13* ARC processor core, which implements ARCv2 or ARCv3 ISA, please refer to
14  :ref:`here <hardware_arch_arc_support_status>` for a complete list of ARC processor families which
15  currently supported
16* Virtual serial console (a standard ``ns16550`` UART model)
17
18ARC processors are known for being highly customizable and some but not all of the configurations
19are currently supported in the Zephyr RTOS for ARC, again please refer to
20:ref:`here <hardware_arch_arc_support_status>` for a complete list of supported features.
21
22There are multiple supported sub-configurations for that platform. Some but not all of currently
23available configurations are listed below:
24
25* ``nsim/nsim_em`` - ARC EM core v4.0 with two register banks, FastIRQ's, MPUv2, DSP options and
26  XY-memory
27* ``nsim/nsim_em7d_v22`` - ARC EM core v3.0 with one register bank and FastIRQ's
28* ``nsim/nsim_em11d`` - ARC EM core v4.0 with one register bank, no FastIRQ's, MPUv2, DSP options and
29  XY-memory
30* ``nsim/nsim_sem`` - ARC EM core v4.0 with secure features (thus "SEM", i.e. Secure EM) and MPUv4
31* ``nsim/nsim_hs`` - ARCv2 HS core v2.1 with two register banks, FastIRQ's and MPUv3
32* ``nsim/nsim_hs/smp`` - Dual-core ARCv2 HS core v2.1 with two register banks, FastIRQ's and MPUv3
33* ``nsim/nsim_vpx5`` - ARCv2 VPX5 core, close to vpx5_integer_full template
34* ``nsim/nsim_hs5x`` - 32-bit ARCv3 HS core with rich set of options
35* ``nsim/nsim_hs6x`` - 64-bit ARCv3 HS core with rich set of options
36* ``nsim/nsim_hs5x/smp/12cores`` - SMP 12 cores 32-bit ARCv3 HS platform
37* ``nsim/nsim_hs6x/smp/12cores`` - SMP 12 cores 64-bit ARCv3 HS platform
38
39.. _board_arc_nsim_prop_args_files:
40
41It is recommended to look at precise description of a particular sub-configuration in either
42``.props`` or ``.args`` files in :zephyr_file:`boards/snps/nsim/support/` directory to understand
43which options are configured and so will be used on invocation of the simulator.
44
45In case of single-core configurations it would be ``.props`` file which contains configuration
46for nSIM simulator and ``.args`` file which contains configuration for MetaWare debugger (MDB).
47Note that these files contain identical HW configuration and meant to be used with the corresponding
48tool: ``.props`` file for nSIM simulator and ``.args`` file for MDB (which internally uses nSIM for
49simulation anyway).
50
51.. hint::
52   If different behavior is observed during execution or debugging of a particular application
53   (especially after creation of a new board or modification of the existing one) make sure features
54   defined in ``.props`` and ``.args`` are semantically identical (unfortunately options of
55   nSIM & MDB don't exactly match, so care should be taken).
56
57I.e. for the single-core ``nsim/nsim_hs5x`` platform there are
58:zephyr_file:`boards/snps/nsim/support/nsim_hs5x.props` and
59:zephyr_file:`boards/snps/nsim/support/mdb_hs5x.args`.
60
61For the multi-core configurations there is only ``.args`` file as the multi-core configuration
62can only be instantiated with help of MDB.
63
64I.e. for the multi-core ``nsim/nsim_hs5x/smp`` platform there is only
65:zephyr_file:`boards/snps/nsim/support/mdb_hs5x_smp.args`.
66
67.. warning::
68   All nSIM/MDB configurations are used for demo and testing purposes. They are not meant to
69   represent any real system and so might be renamed, removed or modified at any point.
70
71Programming and Debugging
72*************************
73
74Required Hardware and Software
75==============================
76
77To run single-core Zephyr RTOS applications in simulation on this board,
78either `DesignWare ARC nSIM`_ or `DesignWare ARC Free nSIM`_ is required.
79
80To run multi-core Zephyr RTOS applications in simulation on this board,
81`DesignWare ARC nSIM`_ and MetaWare Debugger from `ARC MWDT`_ are required.
82
83To run Zephyr RTOS applications on FPGA-based `HAPS`_ platform,
84MetaWare Debugger from `ARC MWDT`_ is required as well as the HAPS platform itself.
85
86Building & Running Sample Applications
87======================================
88
89Most board sub-configurations support building with both GNU and ARC MWDT toolchains, however
90there might be exceptions from that, especially for newly added targets. You can check supported
91toolchains for the sub-configurations in the corresponding ``.yaml`` file.
92
93I.e. for the ``nsim/nsim_hs5x`` board we can check :zephyr_file:`boards/snps/nsim/nsim_nsim_hs5x.yaml`
94
95The supported toolchains are listed in ``toolchain:`` array in ``.yaml`` file, where we can find:
96
97* **zephyr** - implies ARC GNU toolchain from Zephyr SDK. You can find more information about
98  Zephyr SDK :ref:`here <toolchain_zephyr_sdk>`.
99* **cross-compile** - implies ARC GNU cross toolchain, which is not a part of Zephyr SDK. Note that
100  some (especially new) sub-configurations may declare ``cross-compile`` toolchain support without
101  ``zephyr`` toolchain support because corresponding target CPU support hasn't been added to Zephyr
102  SDK yet. You can find more information about its usage here: :ref:`here <other_x_compilers>`.
103* **arcmwdt** - implies proprietary ARC MWDT toolchain. You can find more information about its
104  usage here: :ref:`here <toolchain_designware_arc_mwdt>`.
105
106.. note::
107   Note that even if both GNU and MWDT toolchain support is declared for the target some tests or
108   samples can be only built with either GNU or MWDT toolchain due to some features limited to a
109   particular toolchain.
110
111Use this configuration to run basic Zephyr applications and kernel tests in
112nSIM, for example, with the :zephyr:code-sample:`synchronization` sample:
113
114.. zephyr-app-commands::
115   :zephyr-app: samples/synchronization
116   :host-os: unix
117   :board: nsim_em
118   :goals: flash
119
120This will build an image with the synchronization sample app, boot it using
121nSIM, and display the following console output:
122
123.. code-block:: console
124
125      *** Booting Zephyr OS build zephyr-v3.2.0-3948-gd351a024dc87 ***
126      thread_a: Hello World from cpu 0 on nsim!
127      thread_b: Hello World from cpu 0 on nsim!
128      thread_a: Hello World from cpu 0 on nsim!
129      thread_b: Hello World from cpu 0 on nsim!
130      thread_a: Hello World from cpu 0 on nsim!
131
132
133.. note::
134   To exit the simulator, use :kbd:`Ctrl+]`, then :kbd:`Ctrl+c`
135
136.. _board_arc_nsim_verbose_build:
137
138.. tip::
139   You can get more details about the building process by running build in verbose mode. It can be
140   done by passing ``-v`` flag to the west: ``west -v build -b nsim_hs samples/synchronization``
141
142You can run applications built for ``nsim`` board not only on nSIM simulation itself, but also on
143FPGA based HW platform `HAPS`_. To run previously built application on HAPS do:
144
145.. code-block:: console
146
147   west flash --runner mdb-hw
148
149.. note::
150   To run on HAPS, in addition to proper build and flash Zephyr image, you need setup HAPS itself
151   as well as flash proper built FPGA image (aka .bit-file). This instruction doesn't cover those
152   steps, so you need to follow HAPS manual.
153
154Debugging
155=========
156
157.. _board_arc_nsim_debugging_mwdt:
158
159Debugging with MDB
160------------------
161
162.. note::
163   We strongly recommend to debug with MetaWare debugger (MDB) because it:
164
165   * Supports wider range of ARC hardware features
166   * Allows to debug both single-core and multi-core ``nsim`` targets.
167   * Allows to debug on `HAPS`_ platform.
168
169You can use the following command to start GUI debugging when running application on nSIM simulator
170(regardless if single- or multi-core configuration is used):
171
172.. code-block:: console
173
174   west debug --runner mdb-nsim
175
176You can use the following command to start GUI debugging when running application on `HAPS`_
177platform:
178
179.. code-block:: console
180
181   west debug --runner mdb-hw
182
183.. tip::
184   The ``west debug`` (as well as ``west flash``) is just a wrapper script and so it's possible to
185   extract the exact commands which are called in it by running it in verbose mode. For that you
186   need to pass ``-v`` flag to the wrapper. For example, if you run the following command:
187
188   .. code-block:: console
189
190      west -v debug --runner mdb-nsim
191
192   it will produce the following output (the ``nsim/nsim_hs5x/smp`` configuration was used for that
193   example):
194
195   .. code-block:: console
196
197       < *snip* >
198      -- west debug: using runner mdb-nsim
199      runners.mdb-nsim: mdb -pset=1 -psetname=core0 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/snps/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
200      runners.mdb-nsim: mdb -pset=2 -psetname=core1 -prop=download=2 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/snps/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
201      runners.mdb-nsim: mdb -multifiles=core1,core0 -OKN
202
203   From that output it's possible to extract MDB commands used for setting-up the GUI debugging
204   session:
205
206   .. code-block:: console
207
208      mdb -pset=1 -psetname=core0 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/snps/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
209      mdb -pset=2 -psetname=core1 -prop=download=2 -nooptions -nogoifmain -toggle=include_local_symbols=1 -nsim @/path/zephyr/boards/snps/nsim/support/mdb_hs5x_smp.args /path/zephyr/build/zephyr/zephyr.elf
210      mdb -multifiles=core1,core0 -OKN
211
212   Then it's possible to use them directly or in some machinery if required.
213
214   .. warning::
215      It is strongly recommended to not rely on the mdb command line options listed above but
216      extract it yourself for your configuration.
217
218   .. note::
219      In case of execution or debugging with MDB on multi-core configuration on nSIM
220      simulator without ``west flash`` and ``west debug`` wrappers it's necessary to
221      set :envvar:`NSIM_MULTICORE` environment variable to ``1``. If you are using ``west flash`` or
222      ``west debug`` it's done automatically by wrappers.
223
224      Without :envvar:`NSIM_MULTICORE` environment variable set to 1, MDB will simulate 2 separate
225      ARC cores which don't share any memory regions with each other and so SMP-enabled code won't
226      work as expected.
227
228Debugging with GDB
229------------------
230
231.. note::
232   Debugging on nSIM via GDB is only supported on single-core configurations (which use standalone
233   nSIM). However if it's possible to launch application on multi-core nsim target that means you
234   can simply :ref:`debug with MDB debugger <board_arc_nsim_debugging_mwdt>`.
235   It's the nSIM with ARC GDB restriction, real HW multi-core ARC targets can be debugged with ARC
236   GDB.
237
238.. note::
239   Currently debugging with GDB is not supported on `HAPS`_ platform.
240
241.. note::
242   The normal ``west debug`` command won't work for debugging applications using nsim boards
243   because both the nSIM simulator and the debugger (either GDB or MDB) use the same console for
244   input / output.
245   In case of GDB debugger it's possible to use a separate terminal windows for GDB and nSIM to
246   avoid intermixing their output. For the MDB debugger simply use GUI mode.
247
248After building your application, open two terminal windows. In terminal one, use nSIM to start a GDB
249server and wait for a remote connection with following command:
250
251.. code-block:: console
252
253   west debugserver --runner arc-nsim
254
255In terminal two, connect to the GDB server using ARC GDB. You can find it in Zephyr SDK:
256
257* for the ARCv2 targets you should use :file:`arc-zephyr-elf-gdb`
258* for the ARCv3 targets you should use :file:`arc64-zephyr-elf-gdb`
259
260This command loads the symbol table from the elf binary file, for example the
261:file:`build/zephyr/zephyr.elf` file:
262
263.. code-block:: console
264
265   arc-zephyr-elf-gdb  -ex 'target remote localhost:3333' -ex load build/zephyr/zephyr.elf
266
267Now the debug environment has been set up, and it's possible to debug the application with gdb
268commands.
269
270Modifying the configuration
271***************************
272
273If modification of existing nsim configuration is required or even there's a need in creation of a
274new one it's required to maintain alignment between
275
276* Zephyr OS configuration
277* nSIM & MDB configuration
278* GNU & MWDT toolchain compiler options
279
280.. note::
281   The ``.tcf`` configuration files are not supported by Zephyr directly. There are multiple
282   reasons for that. ``.tcf`` perfectly suits building of bare-metal single-thread application -
283   in that case all the compiler options from ``.tcf`` are passed to the compiler, so all the HW
284   features are used by the application and optimal code is being generated.
285   The situation is completely different when multi-thread feature-rich operation system is
286   considered. Of course it is still possible to build all the code with all the
287   options from ``.tcf`` - but that may be far from optimal solution. For example, such approach
288   require so save & restore full register context for all tasks (and sometimes even for
289   interrupts). And for DSP-enabled or for FPU-enabled systems that leads to dozens of extra
290   registers save and restore even if the most of the user and kernel tasks don't actually use
291   DSP or FPU. Instead we prefer to fine-tune the HW features usage which (with all its pros)
292   require us to maintain them separately from ``.tcf`` configuration.
293
294
295Zephyr OS configuration
296=======================
297
298Zephyr OS configuration is defined via Kconfig and Device tree. These are non ARC-specific
299mechanisms which are described in :ref:`board porting guide <board_porting_guide>`.
300
301It is advised to look for ``<board_name>_defconfig``, ``<board_name>.dts`` and
302``<board_name>.yaml`` as an entry point for board configuration.
303
304nSIM configuration
305==================
306
307nSIM configuration is defined in :ref:`props and args files <board_arc_nsim_prop_args_files>`.
308Generally they are identical to the values from corresponding ``.tcf`` configuration with few
309exceptions:
310
311* The UART model is added (to both ``.props`` and ``.args`` files).
312* Options to fine-tuned MDB behavior are added (to ``.args`` files only) to disable MDB profiling
313  and fine-tune MDB behavior on multi-core systems.
314
315GNU & MWDT toolchain compiler options
316=====================================
317
318The hardware-specific compiler options are set in corresponding SoC cmake file. For ``nsim`` board
319it is :zephyr_file:`soc/snps/nsim/CMakeLists.txt`.
320
321For the GNU toolchain the basic configuration is set via ``-mcpu`` which is defined in generic code
322and based on the selected CPU model via Kconfig. It still can be forcefully set to required value
323on SoC level.
324
325For the MWDT toolchain all hardware-specific compiler options are set directly in SoC
326``CMakeLists.txt``.
327
328.. note::
329   The non hardware-specific compiler options like optimizations, library selections, C / C++
330   language options are still set in Zephyr generic code. It could be observed by
331   :ref:`running build in verbose mode <board_arc_nsim_verbose_build>`.
332
333References
334**********
335
336.. _Designware ARC nSIM: https://www.synopsys.com/dw/ipdir.php?ds=sim_nsim
337.. _DesignWare ARC Free nSIM: https://www.synopsys.com/cgi-bin/dwarcnsim/req1.cgi
338.. _HAPS: https://www.synopsys.com/verification/prototyping/haps.html
339.. _ARC MWDT: https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware
340