Rapidly realize communication and cooperation between ARM and DSP in video surveillance system

Figure 1 DaVinci software structure diagram

Through the introduction in the first part, we know that the Codec Engine software module in TI Digital Video Software Development Kit (DVSDK) can help us easily realize the collaborative work of ARM and DSP or coprocessor, as well as the overview of the Codec Engine software module. Now we will tell you how to complete the first and second steps of Codec Engine. Welcome to reprint, this article comes from Electronics Fans Network (http://www.elecfans.com)

2. The first step to getting started with Codec Engine

Some beginners think that the structure of the Codec Engine file package is complex and it is difficult to find the documents or examples they want. In fact, there is a release notes document in the root directory of the Codec Engine file package, such as release_notes_codec_engine_1_20.html in the root directory of Codec Engine 1.20. This document is the beginning of your understanding of Codec Engine. It contains detailed descriptions about this version of Codec Engine, links to related documents, new features, supported chips, known bugs, fixed bugs, examples, etc. The details are shown in blue font in Figure 2. After browsing this document, beginners can at least know where to find the documents or examples they want. For example, if you want to find related documents, click Documentation to see the links to the documents in this Codec Engine file package.

Figure 2 Screenshot of Codec Engine 1.20 Release Notes

3. Codec Engine Getting Started Step 2

Click Validation Info in the Codec Engine release notes (Figure 2), and you will see that Codec Engine 1.20 needs to be used with the following software modules and tools:

?Framework Components 1.20.02

?xDAIS 5.21

?XDC Tools 2.93.01

?DSP/BIOS Link 1.40.05, configured for the DM6?46 EVM

?C6x Code Generation Tools version 6.0.8

?DSP/BIOS 5.31.05

?MontaVista Linux v4.0

?Red Hat Enterprise Linux 3 (SMP)

Therefore, we need to check whether the software modules and tools mentioned above are installed and the versions are correct under the DVSDK file package installed in the Codec Engine. Otherwise, the Codec Engine examples may not compile. So, what are Framework Components, what is xDAIS, and what is XDC Tools? You can browse their respective release notes in their root directories to get a general understanding.

We will give a brief introduction here to help you find the key points and resources relevant to you as quickly as possible.

1) Framework Components is a software module provided by TI, which is responsible for the memory and DMA resource management on the DSP side. Therefore, DSP algorithm engineers need to understand this software module. http://tiexpressdsp.com/wiki/index.php?title=Framework_Components_FAQ

2) xDAIS is a standard that defines the standard of TI DSP algorithm interface. This greatly improves the versatility of DSP algorithm software. DSP algorithm engineers must ensure that their algorithm interface complies with this standard if they want to write algorithms that can be called by ARM through Codec Engine. Therefore, DSP algorithm engineers must also understand this software module. http://tiexpressdsp.com/wiki/index.php?title=Category:XDAIS

3) XDC Tools is a tool similar to gmake. XDC builds executable files on the ARM side and the DSP side by calling the ARM tool chain (Tool Chain) and DSP compiler (C6x Code Generation Tools) specified by the user according to a set of build instructions defined by the user. You don't need to study this tool in detail. You only need to learn how to set the build instructions through the example of compiling the Codec Engine.

4) DSP/BIOS Link is the underlying software that implements communication between ARM and DSP. Codec Engine is built on this underlying software. When modifying the system memory allocation (the default is 256MB of DDR2), users of DSP/BIOS Link 1.38 version need to modify the DSP/BIOS Link configuration file and rebuild DSP/BIOS Link. Users of DSP/BIOS Link 1.40 and later versions do not need to do this. http://tiexpressdsp.com/wiki/index.php?title=DSPLink_Overview

http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map

5) C6x Code Generation Tools is a compiler for C6000 series DSPs in Linux environment. When we develop DSPs with CCS, we use the DSP compiler in Windows environment.

6) DSP/BIOS is a DSP real-time operating system provided free of charge by TI. Like the C6x Code Generation Tools above, DSP/BIOS here is also a version for Linux environment. DSP system engineers need to understand this operating system.

4. Codec Engine Getting Started Step 3

Developing ARM+DSP platform requires three types of engineers: ARM application engineer, DSP algorithm engineer and DSP system engineer. However, developing ARM+coprocessor platform only requires ARM application engineer. Let's introduce these three types of engineers separately. If you are using TI or TI's third-party codec algorithm, you don't need to pay attention to the DSP algorithm engineer part. If you use ARM+coprocessor platform, you only need to care about the ARM application engineer part.

4.1 How should DSP algorithm engineers proceed?

Here we will not discuss how to develop DSP algorithms, but only how DSP algorithm engineers can make their algorithms available to ARM through Codec Engine. (Refer to http://www.ti.com/litv/pdf/sprued6c, this document will talk about codec package and related .xs and .xdc files. Users of Codec Engine 1.20 and above can skip these details for now. Later we will introduce tools to help you automatically generate these files.)

1) Familiar with xDAIS and xDM standards.

xDM is just an extension of xDAIS, so you need to understand xDAIS first. You can quickly find the document links about xDAIS and xDM in the release notes document in the root directory of the xDAIS software package. http://focus.ti.com/lit/ug/spruec8b/spruec8b.pdf

There is a g711_sun_internal.c in the examples/ti/xdais/dm/examples/g711 under the xDAIS installation path. This algorithm does not comply with the xDAIS standard. The g711dec_sun_ialg.c (decoder) and g711enc_sun_ialg.c (encoder) in the same path are the encoding and decoding algorithms that are packaged to comply with the xDM standard. You can learn and understand how to package your own algorithm into an algorithm that complies with the xDM standard through this example.

xDAIS 6.10 and later versions include a tool called QualiTI, which can check whether your DSP algorithm meets the xDAIS standard (but not whether it meets xDM). For details, please refer to: http://tiexpressdsp.com/wiki/index.php?title=QualiTI_XDAIS_Compliance_Tool

2) Familiarity with Framework Components.

Framework Components mainly includes two modules, DSKT2 and DMAN3, which are responsible for memory and EDMA resource management on the DSP side respectively. The memory used by the DSP algorithm must be applied to DSKT2 and allocated by DSKT2. Similarly, the EDMA channel used by the DSP algorithm is also applied to DMAN3 and allocated by DMAN3. The operation of QDMA is implemented through the ACPY3 module. The advantage of this is that it is easy to integrate different algorithms on the DSP side, and there is no need to worry about resource (Memory and EDMA) conflicts between different algorithms.

You can quickly find links to related documents in the release notes document in the root directory of the Framework Components package. There is a Fast Copy example in packagestisdofcdman3examples under the Framework Components installation path, which can help you understand how to implement QDMA operations based on the ACPY3 module of Framework Components.

In addition, some users have relatively simple algorithms on the DSP side. Under the premise of ensuring that there is no conflict with the EDMA resources on the ARM side, it is also possible to directly operate EDMA in the algorithm without using DMAN3. The disadvantage of doing so is that there will be resource usage conflicts when integrating with other algorithms. [page]

4.2 How should a DSP system engineer proceed?

Usually DSP algorithm engineers will compile their own xDM-compliant algorithms into a .lib file (or .a6?P) for DSP system engineers to call. DSP system engineers will eventually build a DSP Server (that is, the DSP executable program .x6?P, similar to the .out generated by CCS). (Refer to http://focus.ti.com/lit/ug/sprued5b/sprued5b.pdf, this document will talk about .xdc and .bld files, users of Codec Engine 1.20 and above can ignore the details for now, and the tool will help you automatically generate these files later.)

1) If you have a .lib file (or .a6?P) (the algorithm must comply with the xDM standard), how do you generate your own DSP Server? The following URL has a detailed introduction to the RTSC Codec and Server Package Wizard tool, which teaches you how to package a .lib file into an RTSC Codec package and an RTSC DSP Server package, and finally build the DSP executable program .x6?P. http://wiki.davincidsp.com/index.php?title=RTSC_Codec_And_Server_Package_Wizards http://wiki.davincidsp.com/index.php?title=I_just_want_my_video_codec_to_work_with_the_DVSDK

2) If you are using a version prior to Codec Engine 1.20, please refer to the example in examples/servers/video_copy under the Codec Engine installation path. You need to understand the functions of the .xdc and .xs files mentioned in sprued6c.pdf and sprued5b.pdf. You can also modify the relevant files in video_copy to manually create your own RTSC Codec package and RTSC DSP server package.

3) After creating the RTSC Codec and RTSC DSP Server packages, the next question is how to build the .x64P. Click on Examples as shown in Figure 2 to find a link to the documentation for building the Codec Engine example. After following this documentation, you will have a clear understanding of how to build the Codec Server. The key is to modify the user.bld and xdcpaths.mak files and set the correct paths for other software modules and tools that the Codec Engine depends on.

4) If your hardware DDR2 size is inconsistent with the 256Mbytes in the example, you need to modify the DSP's .tcf file and other configurations. Some engineers are not clear about how to allocate memory and how to determine specific segments, such as the size of DDRALGHEAP and DDR, and how to configure the parameters in ./loadmodules. Please refer to: http://wiki.davincidsp.com/index.php?title=Changing_the_DVEVM_memory_map.

4.3 How should an ARM application engineer get started?

ARM application engineers need to call the VISA API of Codec Engine and finally compile the executable program on the ARM side. Therefore, they must learn the relevant VISA API and how to create the package and configuration file of the application-side Codec Engine according to their own applications. (Refer to http://focus.ti.com/lit/ug/sprue67d/sprue67d.pdf, which also covers how to debug the Codec Engine).

1) Understand the process of ARM application calling Codec Engine, VISA API and other Codec Engine API. You can refer to the examples in examples/apps/video_copy under the Codec Engine installation path (simpler) or the encode/decode/encodedecode examples in demos under the DVSDK installation path (more complex). http://wiki.davincidsp.com/index.php?title=Configuring_Codec_Engine_in_Arm_apps_with_createFromServer

2) Understand the ceapp.cfg file. sprue67d.pdf has a related introduction. You can read examples/apps/video_copy/ceapp.cfg first.

3) Use the method mentioned in 4.2 3) to learn how to build an executable program on the ARM side.

4) How to call the codec engine in multiple threads, refer to: http://wiki.davincidsp.com/index.php?title=Multiple_Threads_using_Codec_Engine_Handle

5) You can also refer to the following three documents to learn more about the structure of TI demo's ARM application, thread scheduling and other specific issues.

EncodeDecode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraah0a.htm, 8 KB) 27 Jun 2007 Abstract

Encode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraa96a.htm, 8 KB) 27 Jun 2007 Abstract

Decode Demo for the DaVinci DVEVM/DVSDK 1.2 (Rev. A) (spraag9a.htm, 8 KB) 27 Jun 2007 Abstract

5. Common problems encountered during use

1) If you encounter any problems, please visit http://wiki.davincidsp.com/index.php?title=Codec_Engine_FAQ first.

2) Some engineers have no experience in DSP development, or do not have an emulator to debug DSP via JTAG. You can refer to the following webpage and make a "Hello World" program to get a sense of how ARM and DSP work together. http://wiki.davincidsp.com/index.php?title=How_to_build_an_ARM/DSP_Hello_World_program_on_the_DaVinci_EVM

3) Many engineers refer to the video_copy example and add their own algorithms based on it. This is easier because there is source code. However, the buffer and parameters transmitted between ARM and DSP must be modified according to the needs of their own algorithms. The important thing is to ensure that the application on the ARM side can correctly pass the buffer and parameters to the DSP, and the DSP can correctly pass the processed buffer to the application on the ARM side. After this channel is opened, it is easier to locate whether the problem lies in the ARM application or the algorithm on the DSP side. In addition, when referring to the video_copy example, pay attention to the comments in the code to make it clear which code can be deleted and which must be modified or retained. If you want to expand the data structure of xDM, please refer to: http://wiki.davincidsp.com/index.php?title=Extending_data_structures_in_xDM.

4) The Codec Engine DSP side will involve cache consistency issues. Please refer to: http://wiki.davincidsp.com/index.php?title=Cache_Management

5) Regarding Codec Engine system debugging, there are several methods:

A. Open Codec Engine trace and check the printed information to see where the problem is, such as engine_open failure, codec cannot be created on the DSP side, etc.

a) Codec Engine 2.0 and above, please refer to: http://wiki.davincidsp.com/index.php?title=Easy_CE_Debugging_Feature_in_CE_2.0

b) Codec Engine 1.x version, please refer to: http://wiki.davincidsp.com/index.php?title=TraceUtil

B. After the ARM application is running, use the emulator to connect to CCS to debug the DSP side program. For reference: http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS

C. In addition to system debugging, Soc Analyzer can also be used to count the execution time of specific functions (ARM and DSP side) (benchmark). Please refer to: http://tiexpressdsp.com/wiki/index.php?title=SoC_Analyzer

6) Because Codec Engine is a software module between ARM application and codec algorithm, many engineers are eager to know its overhead. Please refer to: http://wiki.davincidsp.com/index.php?title=Codec_Engine_Overhead

7) How to compile DSP assembly or linear assembly program in Linux environment?

In the /packages/config.bld file under the Codec Engine installation path

var C6?P = xdc.useModule(‘ti.targets.C6?P’);

Then add:

C6?P.extensions[“.sa”] = {

suf: ".sa", typ: "asm:-fl"

}

or

C6?P.extensions[“.asm”] = {

suf: “.asm”, typ: “asm:-fa”

}

8) How to count the running time of specific functions on the DSP side?

The TI DSPC6-x+ core has a 6-bit hardware timer (Time Stamp Counter) whose frequency is the same as the CPU frequency. The simplest way is to use the lower 32 bits of TSC, TSCL. Note that in DM6-4x, TSCH is used for ARM.

#include

void main (){

…

TSCL=0;

…

t1=TSCL;

my_code_to_benchmark();

t2=TSCL;

printf(“# cycles == %dn”, (t2-t1));

}

6. Conclusion

The above is a brief summary of how to get started with TI's Codec Engine. There are still many specific details that have not been covered. Please start by finding and studying the relevant documents from the release notes of the software module you want to use.