Lines Matching full:and
17 This page covers the design, architecture and rationale, of the
18 nrf5x_bsim boards and other similar bsim boards.
21 These boards use the `native simulator`_ and the :ref:`POSIX architecture<Posix arch>` to build
22 and execute the embedded code natively on Linux.
24 Particular details on the :ref:`nRF52<nrf52_bsim>`, :ref:`nRF5340<nrf5340bsim>` and
34 .. _Architecture of HW models used for FW development and testing:
60 without the need for real HW, and in a deterministic/reproducible fashion.
63 peripherals, and their execution is independent of the host load, or timing.
65 These boards are also designed to be used as prototyping and development environments,
70 Different types of tests and how the bsim boards relate to them
76 further on the differences, benefits and drawbacks of different testing
77 methodologies normally employed by embedded SW developers and how they relate
86 components that may be too dependent on the exact HW particularities, and
90 test in general not being reproducible, and in many cases failures
93 - Integration tests on workstation (what the POSIX arch and these boards enable)
97 it is possible to test the components interactions and their integration.
100 For ex. how a left and a right earbud synchronize and exchange data and
101 audio over their radio link, and how they interact with a mobile phone.
102 - Using bsim boards, and the `EDTT`_ framework: With the EDTT framework we can
106 and an embedded application that handles the RPC calls themselves, while
112 be used with or without Zephyr's ztest system and twister.
114 and native simulator runner with the bsim boards.
116 - Zephyr's ztest infrastructure and Zephyr's twister:
118 The embedded test application is responsible for driving the tests and check
119 the results on its own, and provide a test result to a PC which directs the
128 Relationship between Zephyr, the native simulator, the nRF HW models and BabbleSim
132 nrf_bsim targets, you are using the `native simulator`_, which is being built together with and
134 Your application is first built and linked with the Zephyr kernel and any subsystems and network
137 And then both the embedded SW and runner are linked together to produce a Linux executable.
141 :alt: nrf_bsim boards and the native simulator
144 Relationship between Zephyr, the native simulator, the nRF HW models and BabbleSim.
148 kernel and subsystems are built and linked first, and finally assembled all together with the native
151 Layering: Zephyr's arch, soc and board layers
157 - The architecture, SOC and board components of Zephyr are replaced with
161 The SOC layer is ``inf_clock``. And the board layer is dependent on
168 and the handling of control between the "CPU simulation" (Zephyr threads) and the
172 busy wait API (see :ref:`posix_busy_wait<posix_busy_wait>`), and Zephyr's printk backend.
173 Note that in a normal Zephyr target interrupt handling and a custom busy wait
174 would be provided by the SOC layer, but abusing Zephyr's layering, and for the
177 functionality like bs_tests hooks, trace control, etc, and
179 program, command line argument handling, and the overall time scheduling of
181 Note that the POSIX arch and ``inf_clock`` soc expect a set of APIs being provided by
183 controller and interrupt handling APIs, :c:func:`posix_exit`,
184 and :c:func:`posix_get_hw_cycle` (see :file:`posix_board_if.h` and :file:`posix_soc_if.h`).
194 Important limitations and unsupported features
197 All native and bsim boards share the same set of
199 are inherited from the POSIX arch and ``inf_clock`` design.
206 Threading and overall scheduling of CPU and HW models
209 The threading description, as well as the general SOC and board architecture
211 :ref:`POSIX arch architecture<posix_arch_architecture>` and on the
215 `Architecture of HW models used for FW development and testing`_
216 a general introduction to the babblesim HW models and their scheduling are provided.
221 Time and the time_machine
228 as needed to the next scheduled HW event, and does not progress while
232 and the simulation results will not be affected in any way by the
238 "search for next event", "advance time to next event and execute it" loop,
241 they are not registered dynamically for simplicity and speed.
247 `Architecture of HW models used for FW development and testing`_.
249 The communication between a Zephyr device and other simulated devices is
256 :alt: Communication between a Zephyr device and other simulated devices
259 Communication between a Zephyr device and other simulated devices
273 and will with all likelihood cause all kind of difficult to debug issues.
276 and not dependent on it.
283 posix_print and nsi_print backends
287 ARCH and ``inf_clock`` code, and for the ``nsi_print`` API expected by the native simulator.
290 Any message printed to these APIs, and by extension by default to Zephyr's ``printk``,
300 This allows tests to be defined (registered), and for each of these tests to
304 These tests are built together with the embedded SW, and are present in the
306 From the command line the user can query what tests are present, and select
311 and Zephyr OS, a hook to process possible command line arguments, and, a hook
329 bs tests will probably be built with the same application, and that therefore
336 its own separate ``bs_tests`` built with that MCU. You can select if and what test is used
346 simulation device number and simulation id (when connected to a phy), etc.
353 print which are available, and pass arguments to the tests themselves.
356 from Babblesim's base/libUtilv1 library. And basic arguments definitions that
366 Note that Zephyr code is be written to support both big and little endian.
370 accurate structures layout in memory and therefore better reproduce possible