BORA SOM/BELK-L/General/Logical structure of BELK

Logical structure of BELK

BELK starting from version 4.0.0 / BXELK starting from version 2.0.0

These kits introduce some significant differences with respect to the previous versions. The characterizing items are:

• FSBL is no longer used as the first-stage bootloader. It is replaced by U-Boot SPL.
• Yocto build system is fully integrated into the kit and it is used to build all the software running on the target. Consequently, the Vivado SDK tool chain is no longer used.
• To simplify the installation of host-side tools, a Managed Virtual Machine (MVM) is provided, containing all the required tools.

The typical Linux-based Zynq design is composed of the following parts:

• U-boot SPL (first-stage bootloader)
• U-Boot (second-stage bootloader)
• device tree file
• Linux kernel
• Root file system
• Executable image of core #1 (in case of AMP systems)
• FPGA bitstream.

Generally speaking, these parts (in the binary/synthesized form) are combined together in one monolithic file that is stored in a non-volatile memory such as SPI NOR flash. Generating this file is quite easy as described by Vivado documentation. However, in real world products, this may be too rigid because developers may want to handle these parts separately and independently. Thanks to the use of U-Boot dual stage bootloader, these binary files can be handled separately and independently instead of a unique monolithic file. U-boot SPL bootloader is responsible to correctly initialize the PS (Processing System) based on configurations from the Vivado project.

The role of Vivado

U-Boot SPL is based on one file (ps7_init.c) that is generated by Vivado. In turn, this file contains some initialization parameters that are set according to Zynq configuration.

The U-Boot sources provided by the BELK/BXELK include such file. Unless you need to modify the initial Zynq configuration, you don't need to generate a new ps7_init.c file. Therefore, from the standpoint of the software running on PS, the role of Vivado is limited to the generation of such file.

The role of Yocto

From the point of view of PS software, the role of Yocto build system is crucial. As shown in the following image, in fact, it is used to build:

• U-Boot SPL (first-stage bootloader)
• U-Boot (second-stage bootloader)
• Linux kernel
• Device tree
• root file system
• user applications.

Simplified flow of Yocto-based building process

The image shows the simplified flow of the Yocto-based building process. The modules within the dashed line are included in the Managed Virtual Machine (MVM) delivered along with the kit.

The binary images distributed with the kit are generated by this process.

Please note that the whole build process requires a lot of hardware resources in terms of disk storage, RAM, and processing power. For this reason, it is discouraged to use the MVM to perform such build.

BELK from version 2.1.0 to version 3.0.2 / BXELK from version 1.0.0 to version 1.0.1

The structure of these kits is the same of the previous releases of BELK. In addition to those, a pre-built root file system image is provided. This image is generated by Yocto.

BELK up to version 2.0.0

These kits are characterized by the following items:

• All the software running on the PS is built with the tool chain of the Vivado SDK
• FSBL is used as the first-stage bootloader
• no pre-built root file system images are provided.

To understand the structure of BELK, it is necessary to describe the basic organization of Xilinx Vivado Design Suite/Xilinx SDK and to recall briefly the recent history of development tools provided by Xilinx.

A little bit of history

At the time of this writing (October 2013) Xilinx is migrating from mature ISE 14.x Design Suite - that should be the last series of this suite - to the new Vivado environment. Both are composed by several programs and some of these are in common. From the general standpoint, the main difference between ISE and Vivado - even if ISE does support Zynq - is that the latter has been expressively conceived to support newer SoC architectures such as Zynq, besides traditional FPGAs. Thus, adopting Vivado as the default environment for BELK/BXELK would seem the natural choice. However, the migration process mentioned above has just begun and the majority of application notes and reference designs released by Xilinx still refers to ISE suite. Plus Vivado is still a little bit "green" and several bug fixes and improvements are introduced by every new release.

Since Bora was presented in 2013 and because this product addresses long longevity markets such as industrial and biomedical, DAVE Embedded Systems chose to build BELK/BXELK upon Vivado that undoubtedly represents today the future of Xilinx development environments.

Structure of BELK/BXELK reference designs

The typical Linux-based Zynq design is composed of the following parts:

• FSBL
• U-Boot
• device tree file
• Linux kernel
• Root file system
• Executable image of core #1 (in case of AMP systems)
• FPGA bitstream.

Generally speaking, these parts - in the binary/synthesized form - are combined together in one monolithic file that is stored in a non-volatile memory such as SPI NOR flash. Generating this file is quite easy as described by Vivado documentation. However, in real world products, this may be too rigid because developers may want to handle these parts separately and independently.

Basic structure of Vivado Design Suite and integration into BELK

Vivado/SDK [1] can be viewed as a collection of programs required to deal with all of the development aspects related to Xilinx components (software running on ARM cores, FPGA fabric verification and programming, power estimation etc.). These include strictly FPGA-related tools such as Floorplanner and pure-software development tools such as SDK. The ambitious objective is to provide a complete, user-friendly, integrated environment that allows software developers to deal with FPGA development even if they are not familiar with this technology, by hiding a lot of its complexities [2]. As usual this ease of use comes at the expense of control and flexibility. This could not be acceptable in many cases where engineers need to control and customize many aspects of the project to implement what is required by system specifications. For this reason, BELK and BXELK have been built around Vivado but some deviations from the default development approach suggested by Xilinx have been introduced, in order to push the modularization and the maintainability of the projects to the maximum possible extent.

The following pictures show respectively the Vivado/SDK default development flow and how this has been integrated into the BELK infrastructure.

Vivado/SDK development flow (BELK <= 3.0.2 and BXELK <= 1.0.1)

Vivado/SDK integration into BELK/BXELK

[1] The Software Development Kit (SDK) is the Xilinx Integrated Design Environment for creating embedded applications on Zynq™-7000 All Programmable SoCs. SDK is the first application IDE to deliver true homogenous and heterogenous multi-processor design and debug, it is optionally included with the Vivado Design Suite or ISE Design Suite, or available as a separate free download for application developers.

[2] Nevertheless FPGA developers will find all the traditional tools that allow complete control of FPGA fabric.