Analysis of typical problems in the development of ARM+DSP dual-core architecture

灞波儿奔

Analysis of typical problems in the development of ARM+DSP dual-core architecture [Copy link]

For these DM643x, DM35x/36x, DM6467, OMAP35x, OMAPLx and other series of ARM+DSP or ARM+video coprocessor multimedia processor platforms. Many engineers with strong DSP development experience and application processing development experience have turned to using Da Vinci or OMAP platforms to develop products such as video surveillance, video conferencing and portable multimedia terminals. Based on the ARM+DSP chip architecture, how to develop and implement the desired embedded applications? Traditional chips are basically a processor core, or a general-purpose processor such as ARM, or DSP. For control and user interface, they are generally implemented with general-purpose processors, while algorithm processing or media processing depends on DSP or hardware chips. Many systems are dual-chip architectures. The development model is also relatively simple. For example, ARM chips have ARM simulation tools, which are based on OS for application development; DSPs have DSP development tools, such as TI's CCS and 510, 560 simulators, which can be used for algorithm transplantation, optimization, tracking, debugging, etc. At this time, the experience required is also relatively simple. Based on the dual-core architecture of ARM+DSP, many engineers do not know how to start development and have raised many questions. For example, ARM engineers are confused about how to use DSP resources, how to interact with data, and how to keep the dual cores synchronized. DSP engineers are asked how to debug ARM, how to start DSP, and how to operate peripherals to obtain or send data if media acceleration is performed. Based on different development experience and foundation, ARM engineers and DSP engineers will look at SOC chips from completely different perspectives, so that they do not know how to start with SOC chips. Here I would like to share my experience with you. First of all, the ARM+DSP chip is a dual-core chip, corresponding to different instruction sets and compilers for ARM and DSP respectively. The SOC chip can be regarded as a synthesis of two single chips, which requires two different sets of development tools, CCS3.3. Chip-level debugging and simulation can be performed, but different platforms need to be selected for ARM and DSP. Generally speaking, ARM runs operating systems, such as Linux, Wince, etc. Development on ARM, except for bootloader, is basically based on OS development, such as driver, kernel reduction, and upper-level applications. The debugging and simulation required mainly rely on log or debugger provided by OS, such as KGDB, Platform Builder, etc. Development based on DSP core is the same as traditional single-core DSP, and CCS+ emulator is needed for development and debugging. Secondly, for the peripheral interface of the chip, both ARM core and DSP core can access it. Typically, ARM controls all peripherals and controls and manages them through drivers on OS. This part is similar to traditional ARM chips; DSP mainly accelerates algorithms and only deals with memory. In order to maintain the consistency of chip resource management, try to avoid DSP accessing peripherals. Of course, according to specific application requirements, DSP can also control the peripheral interface to send and receive data. At this time, it is necessary to do a good job of system management to avoid conflicts in dual-core operations. Regarding the use of memory, non-volatile storage space, such as NAND and NOR Flash, is basically accessed by ARM. The algorithm code of DSP exists as a file in the ARM-side OS file system, and the DSP program is downloaded and the DSP chip is controlled through the application. The external RAM space, that is, the DDR storage area, is shared by ARM and DSP. However, when designing the system, it is necessary to strictly separate the physical addresses of the memory used by ARM and DSP, and reserve a part of the memory space for interaction. Generally, ARM uses low-end addresses, and DSP allocates high-end addresses through CMD files, and some space is reserved in the middle for data interaction. For example, in the DVSDK under Linux of OMAP3, the 128MB DDR space is divided into three parts. The 88MB space from the low-end address 0x8000000 to 0x85800000-1 is used by the Linux kernel; the 16MB from 0x85800000 to 0x86800000-1 is used by the CMEM driver for large-block data interaction between ARM and DSP, and the 24MB from 0x86800000 to 0x88000000-1 is the code and data space of DSP. The startup of the chip is also an issue that needs to be considered. Generally, it is ARM startup. Like the traditional single-core ARM, it supports different startup methods, such as NAND, NOR, UART, SPI, USB, PCI and other interface startup. The DSP is in reset state by default. Only after the code is downloaded through the ARM application and the reset is released, can the DSP run. In some application scenarios, the DSP needs to be automatically started directly from the external power-on, and some chips also support this mode. Finally, regarding the communication and synchronization of the chip, this is a problem that troubles many engineers. In order to facilitate customer development and use, TI provides DSPLINK, CODEC ENGINE's DVSDK development kit. Based on DVSDK, ARM+DSP application development can be easily carried out. The following is a brief introduction to the software architecture of DVSDK and the functions of each software module. DVSDK is an integration of multiple software modules, including pure DSP-side software modules, ARM software modules and dual-core interactive software modules. The software packages of DVSDK are all based on the real-time software component (RTSC). You also need to install the RTSC tool XDC, which is an open source tool from TI. It can support cross-platform development and maximize code reuse. If you need to develop pure ARM, you also need ARM's compiler tools and Linux kernel or Wince BSP. If you need to develop DSP algorithms or generate DSP-side executable code, you also need to install DSP compilers cgtools and DSP/BIOS. In order to facilitate the configuration and generation of DSP-side executable code, you can generate Codec's RTSC package and executable code through the wizard, and you can also install ceutils and cg_xml. The core of DVSDK is Codec Engine, and all other software modules are basically centered around Codec Engine. Codec Engine is a bridge between ARM and DSP. It is a software module between the application layer (ARM-side application) and the signal processing layer (DSP-side algorithm). When compiling DSP-side executable code and ARM-side application, the support of Codec Engine is required. Codec Engine mainly consists of two parts: ? ARM-side application adaptation layer, which provides a streamlined API and corresponding libraries for the application layer to use. ? DSP algorithm call layer, which provides the interface encapsulation specification of DSP algorithms, so that all algorithms can be compiled into the DSP executable program through simple configuration. The final application needs to download DSP code through the API interface of Codec Engine, call the encapsulated algorithm on the DSP side, and communicate between ARM and DSP. For an introduction to Codec Engine, please refer to "Helping You Get Started with Codec Engine Quickly". The communication between the underlying ARM and DSP of Codec Engine is based on DSP/BIOS Link, which is the software module that truly realizes the interaction between ARM and DSP. Since DSP/BIOS Link is cross-platform, it is also composed of ARM and DSP parts. On the ARM side, it includes OS-based drivers and library files for application calls. On the DSP side, DSP/BIOS must be used, and the executable code of DSP needs to include the library files of DSP/BIOS Link. DSP/BIOS Link commonly uses the following software modules: PROC-related, mainly used to control DSP chips, such as starting, stopping, downloading DSP executable code, and directly reading and writing DSP memory space, etc. MSGQ-related, the communication between ARM and DSP is based on MSGQ, MSGQ has polling waiting mode or interrupt mode, and MSG is based on shared memory pool mode. Codec Engine exchanges some key data through MSGQ, such as control and address pointers of some large blocks of data. A large amount of data interaction needs to be implemented through cmem. On the ARM side, the software modules used with Codec Engine include LinuxUtils or WinceUtils, including cmem, SDMA, etc. cmem is used to allocate continuous physical memory space outside the OS and perform conversion from physical address to virtual address, and from virtual address to physical address space. In order to avoid multiple copying of data, it is necessary to open up a data space shared by ARM and DSP. Both ARM and DSP can access it directly. This space needs to be managed by CMEM. For ARM, CMEM is a driver on the OS, and IOCTL is needed to implement memory allocation or address space conversion. Since the DSP can access any physical address space, the pointer passed to the DSP through ARM must be a physical address. In order to adapt to the interfaces of some players, DVSDK also provides DMAI (Digital Media Application Interface). DMAI provides a more streamlined media interface and OS-based audio and video capture, playback and other interfaces. The gstreamer under Linux and the dshow filter under Wince are based on DMAI. And DMAI also provides the most basic test application examples, which can be easily modified and tested. If you just call the ready-made or third-party algorithm library, you can only understand the software module on the ARM side. Codec Engine or DMAI has provided a rich application interface. DSP can be considered as a simple media accelerator, and the ARM+DSP chip can be used as an ASIC. If you want to give full play to the performance of DSP, you need to develop DSP. Codec Engine only standardizes the interface of DSP algorithm to facilitate the generation of DSP executable program together with Codec Engine.