Lines Matching +full:bsim +full:- +full:test +full:- +full:results
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
52 Integration testing in the sense that the code under test will, at the very
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:
84 these bsim boards.
85 - Integration tests on real HW: Allows testing with the real SW
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)
95 - Using bsim boards: Allow testing the embedded SW (or a subset), including
97 it is possible to test the components interactions and their integration.
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
103 test the embedded code under test while controlling the test from external
104 python test scripts. This is supported by compiling the embedded code with
107 the python test scripts provide the test logic.
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:
117 Based on dedicated embedded test applications build with the code under test.
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
120 test.
122 with a very dedicated test application,
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
176 The board layer provides other test specific
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
232 and the simulation results will not be affected in any way by the
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
262 backchannels. These provide a direct, reliable pipe between devices which test code
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.
301 use a number of special test hooks which are present only in these simulated
307 which test (if any) should be executed. When a test is selected its registered
316 :c:func:`bst_main` when running in the bsim board.
319 dedicated test "task". This will be executed in the HW models thread context,
322 ticks. When these ticks occur a registered test tick function will be called.
323 This can be used to support the test logic, like run checks or perform actions
325 to build quite complex test tasks which can wait for a given amount of time,
332 will execute even if the test is not selected.
336 its own separate ``bs_tests`` built with that MCU. You can select if and what test is used
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,
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