Lines Matching +full:bsim +full:- +full:tests
3 Bsim boards
6 **Available bsim boards**
18 nrf5x_bsim boards and other similar bsim boards.
20 (shortened bsim), to simulate the radio environment.
50 The main purpose of these bsim boards is to be test-benches for
58 These tests are run in workstation, that is, without using real embedded HW.
59 The intention being to be able to run tests much faster than real time,
62 Unlike :ref:`native_sim <native_sim>`, bsim boards do not interact directly with any host
70 Different types of tests and how the bsim boards relate to them
80 - Unit tests:
81 Typical unit tests frameworks provide unit testing
84 these bsim boards.
85 - Integration tests on real HW: Allows testing with the real SW
92 They otherwise serve a very similar purpose to simulation integration tests.
93 - Integration tests on workstation (what the POSIX arch and these boards enable)
95 - Using bsim boards: Allow testing the embedded SW (or a subset), including
98 - Using bsim boards with the BabbleSim Physical layer simulation allows
102 - Using bsim boards, and the `EDTT`_ framework: With the EDTT framework we can
108 - Using Zephyr's :ref:`native_sim <native_sim>` board: It also allows integration testing of
111 that platform. Just like the bsim boards, this Zephyr target board can
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
123 these are fully supported with the bsim boards.
142 :figclass: align-center
156 - The `native simulator`_ runner is used to execute the code in your host.
157 - The architecture, SOC and board components of Zephyr are replaced with
159 - The architecture (arch) is the Zephyr :ref:`POSIX architecture<Posix arch>`
163 - The POSIX architecture provides an adaptation from the Zephyr arch API
167 - The SOC ``inf_clock`` layer provides an adaptation to the native simulator CPU "simulation"
170 - The board layer provides all SOC/ IC specific content, including
188 :alt: Zephyr layering in native & bsim builds
189 :figclass: align-center
191 Overall architecture in a Zephyr application in an embedded target vs a bsim
197 All native and bsim boards share the same set of
212 `native simulator design documentation`_ apply to the bsim boards.
218 In case of the nRF bsim boards, more information can be found in the
224 Simulated time in bsim boards is in principle fully decoupled from
225 real wall-clock time. As described in
246 The same considerations as for the HW models apply to the bsim boards, see
250 handled over the bsim libPhyCom libraries. For the radio activity the figure
257 :figclass: align-center
261 Test code may also communicate with other devices' test code using the bsim
269 Note that even though part of the bsim board code is linked with the Zephyr kernel,
278 result in a call back into the board code (the bsim specific printk backend)
286 The bsim board provides a backend for the ``posix_print`` API which is expected by the posix
289 These simply route this API calls into the ``bs_trace`` bsim API.
298 The bsim boards provide also the bs_tests facility.
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
316 :c:func:`bst_main` when running in the bsim board.
328 Note when writing the tests with ``bs_tests`` one needs to be aware that other
329 bs tests will probably be built with the same application, and that therefore
330 the tests should not be registering initialization or callback functions using
342 bsim boards need to handle command line arguments. There are several sets of
345 - Basic arguments: to enable selecting things like trace verbosity, random seed,
347 This follow as much as possible the same convention as other bsim
349 - The HW models command line arguments: The HW models will expose which
350 arguments they need to have processed, but the bsim board as actual
352 - Test (bs_tests) control: To select a test for each embedded CPU,
353 print which are available, and pass arguments to the tests themselves.
362 - Endianness: Code will be built for the host target architecture, which is
367 - WordSize: The bsim targets, as well as normal embedded targets are 32 bit
368 targets. In the case of the bsim targets this is done by explicitly targeting