Quick Start to TI's codec Engine

Quick Start to TI's codec Engine Favorites

Http://focus.ti.com.cn/cn/general/docs/gencontent.tsp? Contentid = 61575

Cui Jing, General DSP Technology Application Engineer, Texas Instruments semiconductor technology (Shanghai) Co., Ltd.

Texas Instruments (TI)'s first da Vinci (DaVinci) chip (processor) dm6446 has been around for nearly three years. Following dm644x, TI has successively launched a series of multimedia processing platforms, such as dm643x, dm35x, dm6467, and omap353x. Many engineers with strong DSP development experience or arm development experience have switched to the Da Vinci or general OMAP (omap353x) platform to develop products such as video surveillance, video conferencing, and portable multimedia terminals. Everyone is facing the same problem: how to implement communication and collaboration between ARM and DSP or coprocessor? TI's digital video software development kit (dvsdk) provides a software module such as codec engine to implement collaboration between ARM and DSP or coprocessor. Many engineers reported that this software module was very useful and saved a lot of development time. Some engineers thought Ti provided too much information and did not know how to get started quickly. This article will summarize the resources (documents, routines and network resources) provided by TI from the perspective of an engineer who first came into contact with codec engine and introduce the development and debugging methods to help you get started with codec engine.

1. codec engine Overview

As shown in figure 1, codec engine is a bridge between ARM and DSP or co-processor. It is between the application layer (ARM-side applications) and the signal processing layer (DSP-side algorithms) between software modules. The arm application calls the visa (video, image, speech, audio) API of codec engine, videnc_process (A, B, C) in 1 ). Codec engine's Stub (arm side) will package the parameters A, B, C and the information about the DSP-side process to be called, and pass the message queue to the DSP. The skeleton (DSP side) of codec engine unlocks this parameter package and converts the parameters A, B, and C to the corresponding parameters X, Y on the DSP side, Z (for example, the virtual address is transmitted on the arm side, while the DSP can only recognize the physical address) and the server on the DSP side (with a low priority, responsible for communicating with the arm) A process (X, Y, x) task on the DSP side is created based on the process information to implement operations on videnc_process (A, B, C.

2. The first step of getting started with codec engine is to start with the codec engine release instructions (release notes ).

3. Get started with codec engine Step 2. Learn about the running environment of codec engine and the dependent software modules and tools.

Click the validation info in codec engine release instructions (2). We can see that codec engine 1.20 needs to be used with the following software modules and tools:

• Framework components 1.000002
• Xdais 5.21
• Xdc tools 2.93.01
• DSP/BIOS link 1.40.05, configured for the dm6446 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 version is correct under the dvsdk package installed in the codec engine. Otherwise, codec engine examples may not be compiled. So what is framework components, xdais, and xdc tools? You can go to their root directories to view their respective release instructions for a general understanding.

Here, we will give a brief introduction to help you find your own priorities and resources as soon as possible.

1) framework components is a software module provided by TI, responsible for 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 interfaces. This greatly improves the versatility of DSP algorithm software. To write algorithms that can be called by arm through codec engine, DSP algorithm engineers must ensure that their algorithm interfaces comply with this standard. Therefore, DSP algorithm engineers must also understand this software module.

Http://tiexpressdsp.com/wiki/index.php? Title = Category: xdais

3) xdc tools is similar to gmake and is a tool. Based on a set of build commands defined by the user, xdc calls the specified arm tool chain and DSP Compiler (c6x code generation tools) build executable files on the arm side and DSP side. You don't have to go into this tool. You just need to compile the codec engine example to know how to set the build command.

4) DSP/BIOS link is the underlying software for communication between ARM and DSP. codec engine is built on the underlying software. When modifying the system memory allocation (DDR2 of 1.38 MB by default), DSP/BIOS link users need to modify the configuration file of DSP/BIOS link and re-build DSP/BIOS link. This operation is not required for users after DSP/BIOS link 1.40.

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 the C6000 series DSP compiler in Linux. We use the DSP compiler in Windows when developing DSPs with CCS.

6) DSP/BIOS is a DSP real-time operating system provided by TI free of charge. Like c6x code generation tools above, DSP/BIOS is also a version in Linux. DSP System Engineers need to understand this operating system.

Http://tiexpressdsp.com/wiki/index.php? Title = Category: dspbios

4. Step 3 of getting started with codec engine. Develop the SDK based on relevant documents and examples of your role.

Three types of engineers are required to develop the ARM + DSP Platform: ARM application engineers, DSP algorithm engineers, and DSP System Engineers. The development of the ARM + coprocessor platform only requires ARM application engineers. Next let's introduce these three types of engineers separately. If you are using a third-party CODEC algorithm of Ti or Ti, you do not need to pay attention to the part of the DSP algorithm engineer. If you use the ARM + coprocessor platform, you only need to care about the ARM application engineers.

4.1 how should DSP algorithm Engineers start?
Here we will not discuss how to develop DSP algorithms, But how DSP algorithm engineers can make their own algorithms available to be called by arm through codec engine. (For details about the release package and related. Xs and. xdc files, users of codec engine1.20 and later can skip this Section and will introduce the tools to automatically generate these files .)

1) familiar with xdais and xdm standards.
Xdm is only an extension of xdais. Therefore, you must first understand xdais. In the release instruction document under the xdais Software Package root directory, you can quickly find a link to the document about xdais and xdm.
Http://focus.ti.com/lit/ug/spruec8b/spruec8b.pdf
There is a g711_sun_internal.c in examples/Ti/xdais/dm/examples/g711 under the xdais installation path. This algorithm does not comply with the xdais standard. G711dec_sun_ialg.c (decoder) and g711enc_sun_ialg.c (encoder) in the same path are encapsulated into an encoding/decoding algorithm that complies with the xdm standard. You can use this example to learn how to encapsulate your own algorithms into xdm-compliant algorithms.
Xdais 6.10 and later versions, including a tool qualiti, can check whether your DSP algorithm meets the xdais standard (but does not check whether it meets the xdm ). For details, see:

Http://tiexpressdsp.com/wiki/index.php? Title = qualiti_xdais_compliance_tool

2) familiar 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 first and allocated by dskt2. Similarly, the edma channel used by the DSP algorithm is applied to dman3 and allocated by dman3. Qdma operations are implemented through the acpy3 module. The advantage is that it is easy to integrate different algorithms on the DSP side. Different algorithms do not have to worry about conflicts between resources (memory and edma.
You can quickly find links to related documents in the release instruction document under the framework components Software Package root directory. In the framework components installation path, packages/Ti/SDO/FC/dman3/examples provides a fast copy example to help you understand how to implement qdma operations based on the acpy3 module of framework components.
In addition, some users' DSP-side algorithms are relatively simple. It is also possible to directly operate edma in the algorithm without using dman3 without conflict with arm-side edma resources. The disadvantage of doing so is that resource usage conflicts may occur when integrating with other algorithms.

4.2 How should DSP System Engineers start?
Generally, DSP algorithm engineers compile their own xdm-compliant algorithms into A. Lib file (or. a64p) for DSP System Engineers to call. The DSP system engineer finally builds a DSP server (that is, the executable program. x64p of the DSP, which is similar to the. out program compiled under CCS ). (For details, refer to engine1.20 and later versions. The tool will automatically generate these files .)

1) if there is a. Lib file (or. a64p) (the algorithm must comply with the xdm standard), how can I generate my DSP server? The following url provides a detailed description of the rtsc codec and server package wizard tool. the LIB file is encapsulated into the rtsc codec package and rtsc DSP server package, and the executable program of the DSP is finally built. x64p.

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 earlier than codec engine 1.20, see examples/servers/video_copy In the codec engine installation path. In this case, the file functions such as. xdc and. Xs mentioned in sprued6c.pdf and sprued5b.pdf can also be modified to manually create your rtsc codec package and rtsc DSP server package based on the relevant files in video_copy.

3) after the rtsc codec and rtsc DSP server packages are created, the problem is how to build. x64p. Click examples in Figure 2 to find the link to the instructions in the build codec engine example. After reading this document, you can 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 on which codec engine depends.

4) if the size of your hardware DDR2 is different from the 256mbytes In the example, You need to modify the. TCF file of the DSP and other configurations. Some engineers still do not know how to allocate memory and how to determine specific segments, such as ddralgheap and DDR, and how to configure parameters in./loadmodules, please refer to: http://wiki.davincidsp.com/index.php? Title = changing_the_dvevm_memory_map.

4.3 how should arm application engineers start?
ARM application engineers need to call the visa API of codec engine to compile executable programs on the arm side. Therefore, you must learn the relevant visa API and how to create the package and configuration file of the application-side codec engine based on your own applications. (Refer to volume engine content ).

1) Understand how arm applications call codec engine, visa API, and other codec engine APIs. You can refer to the example of examples/apps/video_copy In the codec engine installation path (relatively simple) or the example of encode/decode/encodedecode in demos in the dvsdk installation path (complicated ).
Http://wiki.davincidsp.com/index.php? Title = configuring_codec_engine_in_arm_assist_with_createfromserver

2) understand the ceapp. cfg file. Sprue67d.pdf
Examples/apps/video_copy/ceapp. cfg.

3) use the methods mentioned in 4.2 3) to learn how to build executable programs on the arm side.

4) how to call codec engine in multiple threads, refer:
Http://wiki.davincidsp.com/index.php? Title = multiple_threads_using_codec_engine_handle

5) You can refer to the following three documents to learn more about the structure and thread scheduling of the ARM application of Ti demo.

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. problems frequently encountered during use

1) if there is a problem you can first access the http://wiki.davincidsp.com/index.php? Title = codec_engine_faq.

2) some engineers do not have DSP development experience, or do not have a simulator to debug DSP through JTAG. You can refer to the content on the following web page to make a "hello World" routine to learn 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 to add their own algorithms. This is easier because of the source code. However, you must modify the buffer and parameters transmitted between the arm and DSP according to the needs of your own algorithms. It is important to ensure that the application on the arm side can correctly transmit the buffer and parameters to the DSP, the DSP can pass the processed buffer to the arm-side application correctly. After this path is connected, it is easier to identify whether the problem lies in an arm application or a DSP-side algorithm. In addition, pay attention to the comments of the code when referring to the video_copy example to know which code can be deleted and which must be modified or retained.

To expand the xdm data structure, see:

Http://wiki.davincidsp.com/index.php? Title = extending_data_structures_in_xdm.

4) The DSP side of codec engine will involve the cache consistency problem. See:
Http://wiki.davincidsp.com/index.php? Title = cache_management

5) There are several methods for Codec engine system debugging:

• 1. A) CODEC engine 2.0 and later versions, see: http://wiki.davincidsp.com/index.php? Title = easy_ce_debugging_feature_in_ce_2.0

     B) CODEC engine 1.x version, see: http://wiki.davincidsp.com/index.php? Title = traceutil

     A. Open the codec engine trace and print the information to see what the problem is. For example, engine_open fails, and CODEC cannot be created on the DSP side.

     B. After the ARM application runs, use the simulator to connect to CCS to debug the DSP side program. For more information, see: 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 calculate the operating time (benchmark) of specific functions (arm and DSP side ). See: http://tiexpressdsp.com/wiki/index.php? Title = soc_analyzer

6) Because codec engine is a software module between ARM applications and CODEC algorithms, many engineers want to know its overhead. For details, refer:
Http://wiki.davincidsp.com/index.php? Title = codec_engine_overhead

7) how to compile DSP assembly or linear assembly programs in Linux?
In the codec engine installation path/packages/config. BLD File
VaR c64p = xdc.usemodule('ti.tar gets. c64p ');
Then add:
C64p. Extensions [". Sa"] = {
SUF: ". SA", Typ: "ASM:-fl"
}
Or
C64p. Extensions [". ASM"] = {
SUF: ". ASM", Typ: "ASM:-FA"

8) How does one count the running time of a specific function on the DSP side?
Ti dspc64x + kernel has a 64-bit hardware timer (time stamp counter), which is the same as the CPU frequency.
The simplest method is to use TSC's low 32-bit tscl. Note that in dm644x, Tsch is used for arm.
# Include void main (){
...
Tscl = 0;
...
T1 = tscl;
My_code_to_benchmark ();
T2 = tscl;
Printf ("# cycles = % d/N", (t2-t1 ));
}

6. Conclusion

The above is a simple summary of how to get started with TI's codec engine. There are still many details that are not involved. Engineers are also invited to find and study the relevant documents from the release notes of the software modules they are going to use. Visit TI's web pages, http://wiki.davincidsp.com and http://tiexpressdsp.com/wikifind the latest information and information. You are also welcome to ask questions on the Wiki.