How to Build da Vinci DSP Server

• How to Build da Vinci DSP Server
• Author: Cui Jing, Ti General DSP Technology Application Engineer

• Texas Instrument's DaVinci digital media technology platform consists of four parts: chips (processors), development tools or Development kits, software and technical support. Software development involves operating systems, audio/video coding/DecodingAlgorithmAnd the division of labor between ARM and DSP makes many engineers feel complicated. To this end, TI has launched a series of software modules and tools to establish the DaVinci software development framework, so that engineers can quickly develop their own products on this basis. These software modules and toolkit are included in TI's Da Vinci technology-based digital video evaluation board software development kit. In a general video application system, DaVinci's arm is responsible for operating system applications, DSP is responsible for running audio and video codec algorithm processing, and arm calls the DSP-side codec through TI's codec engine mechanism. How can we integrate different codec algorithms into a DSP for execution? Program (Called DSP server), and ensure that the resources they occupy do not conflict with each other? This article starts with the DaVinci software structure and introduces how to build a DSP server and how to configure FC (framework component) through the DSP server configuration file to manage DSP resources through FC.Da Vinci dmsoc Software Overview Generally, software systems are divided into three parts: application layer, signal processing layer, and I/O layer. The Da Vinci reference software framework provided by TI is based on this structure, as shown in figure 1. DaVinci's application engineers can add and utilize their own features in the system's user space. The signal processing layer usually runs on the DSP side for signal processing, including audio/video coding and decoding algorithms, codec engine, DSP real-time operating system DSP/bios, and arm communication modules. The I/O layer is what we usually call a driver. It is a driver for the DaVinci peripheral module.
  The application layer uses the codec engine's visa (video, image, speech, audio) API to call the DSP-side algorithm, and the epsi (easy peripheral software interface) API to access and operate the peripherals of DaVinci. These three parts usually correspond to three DaVinci software development teams. Of course, a system integration engineer is required to integrate these three parts. However, the existence of visa API and epsi API has greatly simplified the complexity of integration. As shown in 2, software development of DaVinci usually requires four steps (this article takes codec running on DSP as an example ):
  Figure 2: software systems are divided into three parts: application layer, signal processing layer, and I/O layer. Da Vinci software development usually requires the above four steps. Step 1: engineers must develop their own audio/video coding/Decoding Algorithms Based on DSP and compile a library file for encoding/Decoding Algorithms *. lib (equivalent *. a64p. You can directly modify the file Suffix in Linux ). If you want to call the Algorithm functions in this library file through codec engine, these algorithm implementations must comply with xdm (xdais (express DSP algorithm interface standard) for digital media) standards; codec functions ). Step 2: generate an executable program *. x64p (that is, the. Out file) running on the DSP, that is, the DSP server. This step is described in detail. Step 3: Create the configuration file *. cfg of codec engine based on the name of the DSP server and the audio/video codec algorithm. This file defines the different configurations of the engine, including the engine name, codecs contained in each engine, and each codec running on the armor is also the dspside (for specific instructions, see Chapter 5th integrating an engine in sprue67.pdf ). Finally, application engineers receive different codec packages, DSP server and engine configuration files *. cfg, compile and link their applications, and finally generate arm-side executable files. Codec engine Overview As mentioned above, application engineers call the apiof codec engineers to call and run the xdais ((( (for specific information about api, see Chapter 4th of sprue67.pdf ). In DaVinci software, the call of audio/video codec algorithm (xdm algorithm) that complies with xdais is completed through the visa API of codec engine. Codec engine provides a standard software architecture and interface for Algorithm Execution through this API, which is reflected in the following aspects: 1. algorithms called through codec engine APIs can run locally (on the arm side) or remotely (on the DSP side); 2. codec engine can be run on ARM + DSP, DSP or arm. 3. no matter whether codec engine runs on arm or DSP, the corresponding codec engine APIs are completely consistent; 4. the API of codec engine has nothing to do with the operating system. For example, codec engine APIs in Linux, VxWorks, and wince environments are completely consistent.
  Codec engine is a software module between an application and a specific algorithm. The visa API accesses the engine SPI through stub and skeleton and finally calls a specific algorithm. Therefore, codec engine works by completing Visa API tasks. Visa API is divided into four parts: visa create/control/process/Delete. We take the CODEC algorithm running on DSP as an example to understand the working principle of codec engine through the execution process of visa API. Before calling the visa API, you need to use the engine API engine_open () in the application to load the DSP executable program to the memory of the DSP, and release the DSP from the reset status, at this time, the DSP starts to run the DSP server initialization program to create a Remote Management Server (RMS) with the lowest priority on the DSP side. RMS is responsible for managing and maintaining the instances corresponding to the specific CODEC algorithm. 3. The application calls the visa create API, and the corresponding visa create function goes to the codec table in the engine SPI to find that the codec runs on the remote DSP side. Then the engine SPI transmits the visa CREATE command to the RMS on the DSP side through osal (operating system prepare action layer) and DSP link. After RMS finds the CODEC algorithm to be called through the codec table of the DSP-side engine SPI, a corresponding instance (a task in the DSP/BIOS system) is created in RMS ). Visa create returns the handle of an instance to facilitate subsequent visa control/process/delete information for this instance. The principle of visa Delete is similar to that of visa create, except that RMS deletes the instance of the corresponding CODEC algorithm and the task of executing the CODEC algorithm.
  Figure 3: process description of visa create/Delete. In summary, visa control is used to dynamically modify the attributes of codec instance. visa process is used to process the input data stream of the algorithm and return an output data stream. 4. When the application calls visa process/control, it collects the parameters passed to the CODEC algorithm through xdm stub and converts them to physical addresses that can be recognized by the DSP. Stub transmits these parameters and related commands to the DSP-side instance through engine SPI, osal, and DSP link. Then, the instance parses the passed parameters and commands through skeleton and executes control/process on the CODEC algorithm through the DSP-side visa control/process. After learning about the basic working principles of codec engine, we will have a clearer understanding of how DSP software works with applications and what should be included in the DSP server in addition to algorithms. Create DSP Server For Da Vinci's software, DSP server is also called codec server. "Codec" is a set of algorithms. As shown in Figures 3 and 4, in addition to algorithms, the DSP server also integrates other software modules (such as DSP/bios, DSP link, and CODEC engine ). 1. xdc introduction to Da Vinci's software development environment, there is a DSP engineer unfamiliar tool xdc (express DSP component ). Similar to gmake, xdc generates executable files based on a set of build commands. Xdc also builds dependent files, and can build executable files of multiple target objects at a time (hello. x64p is the executable file of DSP, hello. x470mv is an executable file of arm ). Xdc source files can be C Programs, C ++ programs, assembler programs, and library files.
  As shown in figure 5, xdc builds the DSP Server Source file (similar to make) according to the build command to generate the DSP server. x64p file. This process can be divided into three parts: creating the source file of the DSP server, setting the xdc configuration file, and executing "make" to generate the executable file.

  Figure 5: xdc builds the DSP Server Source file according to the build command to generate the DSP server. x64p file.

  Figure 5: xdc builds the DSP Server Source file according to the build command to generate the DSP server. x64p file. 2. The source file of the DSP server uses video_copy in codec engine_000002 as an example. 6 we can see that the DSP server of video_copy includes the source files main. C, video_copy.tcf, and link. CMD corresponding to figure 5. Packages in Figure 5 refer 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 must first create the dsp bios configuration file. TCF and link. CMD of Main. C and server. We mentioned that engine_open will release the DSP from the reset state, and the DSP server program will start to run initialization and so on. This Initialization is ceruntime_init () in DSP server main. C (see figure 7 (). In addition, you can enable the trace function of the codec engine in Main. C to read or change the parameters of the main function.

  The dsp bios configuration file. TCF defines the memory map of the DSP, sets the reset/interrupt vector table of the DSP, and creates and initializes various Data Objects (8. TCF) required by the BIOS program ). In. TCF, we can only define the default sections (such as. Text and. BSS) of the compiler ). However, we can define our own sections in link. CMD (for example,. Tables and. csl_vect in 8 link. cmd ).
  3. xdc File In Linux, we use the make command to generate executable files based on makefile. xdc also has similar script files (collectively referred to as xdc files ). The package. bld, package. xdc, and video_copy.cfg files are the xdc files provided to xdc build DSP server. In package. xdc, declare the DSP server name, its path, and the server dependency file. The package. BLD file function is similar to makefile in Linux. It tells xdc how to build the source file of DSP server. 9. in bld, the target is defined as a c64p DSP and an executable program for the target is to be generated. The configuration script file is video_copy.tcf (as shown in Figure 8. similar to TCF). The link option is Link. CMD (link to figure 8. similar to cmd) file, and also generate main. objective of C Code .

  Xdc is also powerful in that it provides a powerful tool for system integration engineers, which can be used to combine various code modules into their final products. The xdc configuration file is. cfg in DSP server (video_copy.cfg in Example 5) responsible for system level management. Note the following. the cfg file is different from the codec engine. cfg file (for example, ce_install_dir/examples/apps/video_copy/dualcpu/ceapp. CFG. CFG refers to the DSP server. cfg file.

  Xdc generates package. Mak (similar to makefile) based on the configuration file mentioned above, and finally runs it to generate the package that includes the executable file, as shown in Figure 5. We can open and View package. Mak, but it cannot be modified. Because after xdc is re-run, a new package. Mak is generated. 4. Set the xdc configuration file Since the. cfg file is responsible for system-level management, what needs to be managed first? Of course, it is a DSP resource, nothing more than CPU cycles, memory and DMA. For DSP software development on DaVinci, Ti provides framework components to facilitate DSP software engineers to use DSP's memory and DMA resources. Instances of the xdm and xdais algorithms both send resource requests to FC, for example, requests for 1 Kbyte memory or a DMA channel. Dskt2 and dman3 in FC allocate resources (including resources that can be shared between instances) to the algorithm through standard and configurable methods ). For example, with dskt2, engineers responsible for developing different algorithms do not have to worry about whether a piece of memory they are using has been occupied by other algorithms or not, because the memory of each algorithm is allocated by dskt2. A. dskt2 framework dskt2 is responsible for managing the memory requirements of all xdais algorithms in the system. It is very simple with the interface at the application layer: "Create, execute, delete ". System integration engineers need to initialize the dskt2 module with all available memory. The dskt2 module includes two types of memory: permanent memory (memory occupied by this algorithm as long as it exists) and scratch memory (memory that can be shared between algorithms ). When an algorithm is created, permanent memory is assigned to this algorithm by dskt2. When the algorithm is deleted, this memory is returned to heap. When an algorithm applies for Scratch memory, it is allocated a memory 'pool ', which is shared by other algorithms with the Same Scratch pool ID. That is to say, the algorithms that share scratch memory belong to the same priority and cannot interrupt each other. B. Configure the. cfg file of the DSP server. You can configure the following three parts in the. cfg file. (1) CODEC configuration: Each codec is included in its own thread, and the attributes of each codec thread (thread priority, stack size, and stack memory resources) are configured ). For more information, see ce_install_dir/xdoc/index.html. (2) dskt2 configuration: combines all ialg memory types with available DSP Memory, and defines the memory size of the default scratch group. (3) dman3 configuration: defines the DMA channel numbers that dman3 can manage and the TCC numbers that dman3 can provide to algorithms. Take video_copy.cfg as an example. It corresponds to the DSP server section shown in Figure 4. The osal and codecs modules are declared and defined in the. cfg file. We can see that the video_copy Server includes viddec_copy and videnc_copy codec.
  Configure the server, including the attribute configuration of each thread. Codec engine automatically matches the scratch memory ID of the algorithm and the priority of the algorithm thread to ensure safe operation.
  For more information about dskt2 configuration, see the following example. Note that the size of each scratch memory pool is defined in an array. The first element of the array corresponds to scratch pool id0, the second element corresponds to scratch pool Id2, and so on.
  The following is an example of dman3 configuration. Because DMA requires memory to store PARAM and other channel configurations, heap (divided into internal heap and external heap) is allocated in dman3 ). Dman3 Param is allocated by its own base index and quantity. In this example, it is allocated to dman3 48 Param. In this example, we can also see that dman3 has eight available qdma channels and TCC is allocated through bit mask. 5. xdc build process xdc is called by executing the xdc command. Before that, we need to take the following steps:. in config. the Platform (arm or DSP), config. the path of BLD is defined by xdcbuildcfg; B. in package. define package and package in xdc. the xdc is in the current path (the video_copy example of 6); C. in package. BLD defines the executable files and library files to be built, package. BLD is in the current path (video_copy example in 6); D. modify the server according to your application according to the previous introduction. cfg file. Run xdc to generate package. Mak, and then run package. Mak to generate a package containing executable files. The summary of this article is based on some problems encountered by engineers in the actual development process. We hope to pass this article Article You can clarify your ideas first, and then engineers can conduct further research and study. For more details about how to build DSP server, see sprued5.pdf and the user manual and application documents mentioned in this article.

Source: Electronic System Design
Author: Cui Jing, Ti General DSP Technology Application Engineer