FONT SIZE : AAA
While processor architectures are a key factor for designs, it is equally important to have appropriate tools in order to build systems which can integrate the programma- bility of FPGAs and processors. These tools include hardware designs tools at a higher level of abstraction as well as traditional software design and debug tools.
A completely functional SoC consists of a processor, soft peripherals, as well as memories. The fi rst step toward building an SoC + FPGA system is to identify the processor of your choice (primarily MicroBlaze or a Zynq class of SoC). The next step is to determine the correct memory architecture suitable for your application. This includes memories internal to the FPGAs (such as block RAMs ) and external memories (Chap. 5 ) which range from nonvolatile fl ash memories to volatile SRAM and SDRAM memories.
System building tools like Vivado IP Integrator (Chap. 7 ) can aid in creating such designs with relative ease. The fi rst step toward building the SoC design would be to instantiate the necessary processor and then continue to add memories and peripherals. It is also important to partition your system into a register-style slow access (i.e., access to peripherals) and a faster memory access. It is important to ensure that all peripherals and memories are appropriately connected and address- able by the processor. This is done through use of an interconnect .
Once the hardware system is built, you need to export the hardware defi nition to the software development kit ( SDK ) for the software user to build their kernels and applications. Each hardware system is unique, and hence having a mechanism to communicate the information about the hardware built to the SW BSP is important for the correct functioning of the overall system. The hardware defi nition contains the following information which is critical for conveying the details of the system built for the purpose of software development:
1. Address map of peripherals as seen by all processors.
2. Parameters of the IPs used in the design. These parameters are used by the drivers during BSP generation.
3. A BMM fi le, which provides the information of the block memories used in the hardware and their corresponding address map for the peripheral. This is only used in case of MicroBlaze.
4. The bitstream which is built in Vivado and can be directly downloaded by the SDK during software development.
All this information is critical for the software BSP to be created. Any changes in the hard- ware require a reexport of the HW information and a regeneration/recompile of the SW BSP .
Embedded application developers typically write their software programs in a higher-level language like C and C++. These high-level programs are translated into assembly-level object code and eventually into an executable and linking for- mat ( ELF ) fi le which contains machine-level code. Compilers play an active role in optimizing the generated code using the context of the processor being used. For example, in case of MicroBlaze, if the multiplier is implemented as part of the SoC, the code generated would use the mul instruction. If it is not, it would make a call to the multiply function from the pre-built libraries.
Some SoCs such as the MPSoC have more than one processor. These processors can be made to work as SMP (symmetric multiprocessing ) or AMP (asymmetric multiprocessing ). In case of an SMP system, the software kernel such as Linux will take care of scheduling processes on appropriate processor based on system load. With industry standard processors (ARM A9, Cortex A-53, and R5s) on the SoC, you can fi nd the right software kernels for their systems which can be used as a base. With AMP system, you need to take care of not just execution on the individual
.png "Cross trigger (conceptual diagram).png")
Fig 6.4 Cross trigger (conceptual diagram)
processors but also have the appropriate communication mechanism between the various processors.
Often, programs need to be debugged in order to get to the correct functionality. Software tool chains such as SDK would be incomplete without a debugger which can connect to the board and provide helpful information about the program execution.
There are certain situations where it is important to debug the software processes running on the processor ( PS ) in conjunction with the hardware transactions in the fabric ( PL ). Xilinx supports cross trigger solution for both soft processors (MicroBlaze) and hard processors ( Zynq-7000 and Zynq UltraScale+ MPSoC ). A conceptual diagram is represented in Fig. 6.4 .
When a breakpoint is hit in the software debugger, it raises a PS to PL trigger. This trigger can be connected to a logic debug IP (such as “Integrated Logic Analyzer” [ ILA ] IP). The logic analyzer tool which is part of Vivado will then be used to display the current transactions on the signals being tapped in the hardware. In a similar fashion, you can generate a trigger from the ILA (i.e., PL ) to the PS . This will stop the processor from executing instructions leading to a breakpoint. Chapter 17 explains the triggers in hardware.
The cross trigger capability can be extended to multiple processors and multiple hard- ware triggers in the PL . It can be an extremely useful way of debugging HW/SW designs.
For using peripherals in software, it is important to know the exact function and the register map of the peripheral. Peripheral developers would typically provide a device driver which provides the APIs for accessing information at a high level.
Software applications are not all written from scratch. Many applications are built using pre-built libraries or libraries obtained from third parties. One good example of this would be the Light weight IP (LwIP) stack. This provides the basic Ethernet packet header processing capabilities. Applications can use the high-level APIs provided by the library in order to get their job done.
Most applications are written on top of an operating system (also known as kernels). Linux is the choice for several embedded applications. A device tree is used to communicate the details of the hardware with the Linux kernel. This includes the type and width of the devices, interrupt ids, and their addresses.
All the software components above are put together in a bundle which is called as a board support package ( BSP ). BSPs are typically tied to a specifi c board/SoC and the hardware for which the application is expected to be written. Once the hardware is fi nalized, the BSP would rarely change. The BSPs would also have standard APIs, and hence the software developers are free to write their code according to their requirements and not worry about the basic device accesses.
FPGA and SoC combination is now helping go beyond the traditional SoC market and providing useful acceleration techniques. Xilinx is now adding support toward software-defi ned fl ows. These fl ows enable offl oading of software applications on hardware through underlying usage of high-level synthesis ( HLS ) tools. This enables embedded software application developers to off-load a compute- intensive complex algorithm to the fabric.
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: FPGAs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: Varistors
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories:
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS:
Support
