How to construct Da Vinci's DSP Server_davinc da Vinci

Texas Instruments (TI) 's Leonardo da Vinci (DaVinci) Digital media technology platform includes four major parts: chips (processors), development tools or development kits, software and technical support.         Software development involves the operating system, audio and video codec algorithm and arm and DSP between the division of cooperation, so that many engineers feel more complex. TI introduced a series of software modules and tools to establish the framework of DaVinci Software development, so that engineers can quickly develop their own products on this basis.        These software modules and tools are included in the software development package of the TI's digital video evaluation board based on the Da Vinci technology. General video Application system, DaVinci Arm is responsible for operating system applications, DSP is responsible for running audio and video codec algorithm processing, arm through TI's codec engine mechanism to call the DSP side of the codec. Then how to integrate different codec algorithms into a DSP executable (called DSP Server), and ensure that the resources they occupy are not conflict. Starting with DaVinci Software structure, this paper introduces how to build DSP server and how to configure FC (Framework Component) through the configuration file of DSP server to manage the resources of DSP through FC.
Leonardo da Vinci Dmsoc Software overview
Generally speaking, the software system is divided into application layer, signal processing layer and I/O layer three parts, TI provided by the Da Vinci Reference software framework is based on such a structure, as shown in Figure 1. DaVinci's application engineers can add and perform their own features in the system's user space. Signal processing layer is usually run on the DSP side responsible for signal processing, including audio and video codec algorithm, Codec Engine, DSP real-time operating system Dsp/bios and ARM communication module. The I/O layer is what we typically call a driver, a driver for a DaVinci peripheral module.

The application layer uses the codec engine's visa (video, Image, Speech, Audio) API to invoke the DSP-side algorithm through EPSI (easy peripheral Software) API to access and manipulate DaVinci peripherals. These three parts usually correspond to three DaVinci software development groups. Of course, a system integration engineer is needed to integrate these three parts, but the presence of the visa API and the EPSI API has greatly simplified the complexity of the integration effort.
As shown in Figure 2, DaVinci Software development typically requires four steps (this article takes the example of codec running on DSP):

Figure 2: Software system is divided into application layer, signal processing layer and I/O layer three parts, da Vinci software development usually need above four steps. The first step, engineers need to use CCS based on DSP to develop their own audio and video codec algorithm, compiled to generate a codec algorithm of the library file *.lib (equivalent to the Linux environment under the *.a64p, directly in the Linux environment to modify the file suffix name). If you want to invoke the algorithm functions in this library file via codec engine, then these algorithm implementations need to conform to the XDm (Xdais (eXpress DSP algorithm Interface) for Standard Media) standard CODEC engine mechanism does not conform to the XDM standard algorithm implementation needs to create algorithms own stub and skeleton (please refer to spraae7.pdf).
The second step is to generate an executable program *.x64p (that is, an. out file) running on the DSP, which is the DSP Server. This step-by-step article will be covered in detail.
The third step, based on the name of the DSP server and the specific audio and video codec algorithm contained in the codec engine, create the configuration file *.cfg. This file defines the different configurations of the engine, including the name of the engine, the codecs included in each engine, and each codec run at arm or DSP side, etc. (for details, please refer to Sprue67.pdf's 5th chapter integrating an Engine).
Finally, the application engineer receives the different codec package, the DSP server and the engine configuration file *.cfg, the own application compiles, the link, finally produces the arm side executable file.
CODEC Engine Overview
As we mentioned earlier, the application engineer invokes and runs the Xdais algorithm by calling the codec engine API (for specific information about the API, refer to Sprue67.pdf 4th). In the DaVinci Software, the Xdais audio-video codec algorithm (XDM algorithm) is called through the Visa API codec engine. Codec engine through this set of APIs for the implementation of the algorithm provides a standard software architecture and interface, reflected in the following aspects: 1. The codec Engine API call algorithm can be run either locally (arm side) or distal (DSP side); 2. Codec engine can be run on ARM+DSP, DSP or arm; 3. Whether the codec Engine is running on arm or DSP, the corresponding codec Engine API is exactly the same; 4. The API for CODEC engine is independent of the operating system. For example, the codec Engine APIs in Linux, VxWorks, and wince environments are identical.
Codec engine is a software module between an application and a specific algorithm, where the Visa API accesses engine SPI via stub and skeleton to finally invoke the specific algorithm. Therefore, Codec engine's work is demonstrated by completing the Visa API task. Visa API is divided into four parts of the visa create/control/process/delete, we use the codec algorithm in DSP as an example, through the implementation of the visa API to understand the codec engine work principle.
Before calling the Visa API, you need to load the DSP executable program into the memory of the DSP in the application through the Engine_open () engine API, and then release the DSP from the reset state, when DSP starts to run DSP The Server's initialization program creates a minimal priority task RMS (Remote Management Server) on the DSP side, and RMS is responsible for managing and maintaining the instances corresponding to the specific codec algorithm.        As shown in Figure 3, the application calls the visa create API, the corresponding visa create function to the codec table in engine SPI to find this codec running on the remote DSP side. Then engine SPI through Osal (operating System abstraction Layer), DSP link to the "Visa create" command to the DSP side of the RMS. When RMS finds the codec algorithm to invoke via the DSP side engine SPI codec table, it creates a corresponding instance in RMS (that is, a task in a Dsp/bios system). Visa Create returns a instance handle to provide information to the instance for subsequent visa control/process/delete. The visa delete and visa create principles are similar, except that RMS removes the instance of the corresponding codec algorithm and the task of executing the codec algorithm.

Figure 3:visa Create/delete Process description diagram. In general, visa control is used to dynamically modify the properties of the codec instance, and visa process is used to process the input data stream of the algorithm and return an output data stream. As shown in Figure 4, the application collects the parameters passed to the codec algorithm via the XDm stub when calling Visa Process/control and converts to the physical address that the DSP can recognize. Stubs pass these parameters and related commands to the DSP-side instance via engine SPI, osal, and DSP link. Instance again through the skeleton pass over the parameters and the command to parse out, through the DSP side visa control/process to codec algorithm implementation control/process.
After understanding the basic working principle of codec engine, we will have a clearer understanding of how the DSP software works with the application and what should be included in the DSP server in addition to the algorithm.
Creating a DSP Server
For Leonardo da Vinci's software, the DSP server is also called codec server. Where "Codec" is a set of algorithms. From figures 3 and 4, you can see that, in addition to the algorithm, DSP server also integrates other software modules (such as Dsp/bios, DSP Link, Codec engine, etc.).
1. Xdc Introduction
Leonardo da Vinci's software development environment, there is a DSP engineer relatively unfamiliar tool XDC (Express DSP Component). Like Gmake, Xdc generates an executable file based on a set of build instruction builds. XDC also builds dependent files, and can build multiple object executables at a time (as shown in Figure 5, hello.x64p is the DSP executable, HELLO.X470MV is arm's executable file). Xdc source files can be C programs, C + + programs, assembler and library files.

As shown in Figure 5, XDC generates a DSP server. x64p file with a build (similar to make) of the source files of the DSP server according to the builds directive. This process can be divided into three parts: creating the source file of the DSP server, setting up the XDC configuration file, and executing "make" to build the executable file.

Figure 5:XDC Build the DSP server. x64p file by constructing the source files of the DSPs in accordance with the construction instructions.
Figure 5:XDC Build the DSP server. x64p file by constructing the source files of the DSPs in accordance with the construction instructions.
2. DSP server's source files
In the case of video_copy in codec engine_1_02, as shown in Figure 6, we can see that the Video_copy DSP server includes the source files Main.c, video_copy.tcf, and link.cmd corresponding to Figure 5. The packages in Figure 5 refers to codecs, RMS, Engine SPI, and osal in Figure 3 and Figure 4. Next, we can see how to add packages to the server through the XDC configuration file.
To build a DSP server, you first need to create a DSP BIOS configuration file for MAIN.C and servers. TCF and Link.cmd. We mentioned that Engine_open will release the DSP from the reset state, the DSP server program starts to run initialization and so on. This initialization is the Ceruntime_init () in the DSP Server MAIN.C (see Figure 7). In addition, the trace function of codec engine can be turned on in main.c to read or change the parameters of main function.

The configuration file for the DSP BIOS. TCF defines the DSP's memory map, sets the DSP reset/interrupt vector table, and creates and initializes various data objects required by the BIOS program (as shown in Figure 8. TCF). In. TCF we can only define compiler default sections (such as. Text and. BSS, etc.). However, we can define our own sections in Link.cmd (as in Figure 8 link.cmd. Tables and. Csl_vect, etc.).

3. XDC Documents
In Linux we use the make command to generate executable files based on makefile, and Xdc has a similar build script file (collectively, xdc file). As shown in Figure 6, the three files in Package.bld, PACKAGE.XDC, and video_copy.cfg are xdc files that are provided to the XDC build DSP server.
In Package.xdc, declare the name of the DSP server, its path, and the server's dependent files. The Package.bld file functions like the makefile in Linux, and it tells Xdc how to build a DSP server's source file. As shown in Figure 9, the target is defined in Package.bld as c64p DSP, to generate an executable program for target, where the configuration script file is video_copy.tcf (similar to the. TCF in Figure 8), and the link option is a link link.cmd ( Similar to the link.cmd in Figure 8), but also to generate the target code for the MAIN.C.

The strength of XDC is that it provides system integration engineers with a powerful tool that can be used to assemble a wide variety of code modules into their own final product. The XDC configuration file is the one in the DSP server. CFG (for example, the video_copy.cfg in Figure 5) is responsible for system-level management. Please note that the. cfg file is different from the. cfg file (for example, Ce_install_dir/examples/apps/video_copy/dualcpu/ceapp.cfg) mentioned in chapter codec engine.        The. CFG, referred to below, refers to the. cfg file of the DSP server. XDC generates Package.mak (similar to makefile) based on the configuration file mentioned above and eventually runs it to generate package that includes the executable file as shown in Figure 5. We can open the view Package.mak but cannot modify it. The new Package.mak is generated because the XDC is rerun.
4. Set up the XDC configuration file
Since the. cfg file is responsible for system-level management, we need to understand what needs to be managed first. Of course is the DSP resources, nothing but CPU cycles, memory and DMA. For the software development of DSP on DaVinci, TI provides framework components to facilitate DSP software engineers to use memory and DMA resources of DSP. The instance of XDm and Xdais algorithms make their own resource requests to FC, such as requesting 1KByte memory or a DMA channel. DSKT2 and DMAN3 in FC allocate resources (including those that can be shared between instances) to the instances of the algorithm through standard, configurable methods. For example, a DSKT2 is responsible for the development of different algorithms will not have to worry about the use of a section of the memory has been another algorithm occupied by a series of problems, because each algorithm memory is allocated by the DSKT2.
A. DSKT2 Framework
DSKT2 is responsible for managing the memory requirements of all Xdais algorithms in the system, and it is very simple with the interface of the application layer "Create, Execute, Delete". The system integration engineer needs to initialize the DSKT2 module with all available memory. The DSKT2 module consists of two types of memory, permanent memory (which will occupy memory as long as the algorithm exists) and scratch memory (memory that can be shared between the algorithms). When an algorithm is created, a permanent memory is DSKT2 assigned to the algorithm, and when the algorithm is deleted, the memory is returned to the heap. When an algorithm requests scratch memory, it is assigned a memory ' pool ', which is shared by other algorithms that have the same scratch pool ID. In other words, the shared scratch memory algorithm belongs to the same priority and cannot be interrupted.
B. Configuring the. cfg file for DSP server
The following three sections can be configured in the. cfg file. (1) Codec configuration: Each codec is included in its own thread; Configures the properties of each codec thread (thread priority, stack size, and stack memory resources).       Please refer to ce_install_dir/xdoc/index.html for details.       (2) DSKT2 configuration: Combine all IALG memory types into available DSP memory; Define the scratch size of the default memory group. (3) DMAN3 configuration: Defines the DMA channel number that DMAN3 can manage, and defines the TCC number that DMAN3 can provide to the algorithm.
Take Video_copy.cfg as an example, corresponding to the DSP Server section shown in Figure 4, the. cfg file declares and defines the Osal and codecs modules. We can see that the Video_copy Server includes viddec_copy and videnc_copy two codec.

The server is then configured, including the individual thread's property configuration. Codec engine automatically matches the scratch memory ID of the algorithm and the priority of the algorithm thread to ensure safe operation.

For the DSKT2 configuration, see the example below. Note that the size of each scratch memory pool here is defined by the form of an array, the first element of the array corresponds to the scratch pool ID0, the second element corresponds to scratch pool ID2, and so on.

The

       below is an example of DMAN3 configuration. Because DMA requires memory to store param and other channel configurations, heap is allocated in DMAN3 (divided into internal heap and external heap). The param of DMAN3 is allocated through its own base index and quantity, and this example is allocated to DMAN3 48 param. From this example we can also see that the DMAN3 has 8 available QDMA channels, TCC are allocated by bit mask.  5. The XDC build process
Xdc calls are completed by executing the command xdc. Before this, we need to do the following steps: A. Define the platform (ARM or DSP) in the Config.bld, where the config.bld path is defined by XDCBUILDCFG; Define PACKAGE,PACKAGE.XDC in Package.xdc under the current path (as shown in Figure 6, video_copy example); Define the executable and library files to build in Package.bld, package.bld under the current path (as shown in Figure 6, video_copy example); Modify the server's. cfg file according to your application as described earlier. The
generates PACKAGE.MAK,XDC before running Xdc and then runs Package.mak builds package that contains the executable file.
This article summarizes
the above introduction is based on some of the problems experienced by engineers in the actual development process. We hope that through this article can be a clear idea, and then engineers can be targeted further study and study. To learn more about the details of building DSP server, please refer to sprued5.pdf and the user manual and application documentation mentioned in the article.
This article source: Electronic system design      Author: Dezhou Instrument General DSP Technology application engineer Tri Jing