VICPLIB DM644x DM64x FAQ
From Texas Instruments Embedded Processors Wiki
This FAQ pertains to questions related to the VICP Signal processing library on DM644x and DM64x devices.
Q.1 How does DM644x/DM64x VICP Library handle EDMA resource?
This section provides more information and background on VICP Signal Processing Library usage of EDMA. The EDMA is a shared resource between the VICP and the other system masters. This information is provided so that users can make the most optimal usage of the EDMA resource. Below is how the EDMA configuration for VICP library is handled. Also listed is the VICP librarie's minimum requirement towards EDMA resource and how users can modify the resource allocations to make it work best for their system. For below description, some information has been borrowed from the VICP Lib Users Guide as well. The below description assumes DM64x device specifics. It is assumed that the user can easily extend these details for DM644x
Basic Concept
The VICP library uses EDMA LLD to request the EDMA resource. To ensure conflict-free usage of EDMA channels from both VICP and DSP, the VICP configuration of the EDMA resources must not interfere with the DSP’s. The VICP library’s EDMA configuration is provided in the file vicp_edma3_dm648_cfg.c located at [VICP_LIBRARY_INSTALLATION_DIR]\test\src. Note this file is available in the dmcsl648_bios.lib library so you do not have to include it in yuor project. But if you need to change the configuration file, you will need to add the modified file to your DSP project so that the modified configuration is picked up instead on the one provided with the dmcsl648_bios.lib.
Now, the VICP lib also includes an example of the EDMA configuration that the DSP can use to ensure conflict-free partition of the EDMA channels between DSP and VICP. The file bios_edma3_drv_sample_dm648_cfg.c is also located at [VICP_LIBRARY_INSTALLATION_DIR]\test\src. These examples provide a conflict-free partition of the EDMA channels between DSP and VICP. Be aware that bios_edma3_drv_sample_dm648_cfg.c’s content is different than the default configuration file which is provided with the EDMA3 LLD. The default configuration file provided by the EDMA LLD is included in the edma3_drv_bios.lib. Unless you rebuild the edma3_drv_bios.lib with the updated bios_edma3_drv_sample_dm648_cfg.c file, your application will not take the new configuration. To avoid rebuilding the library, you can add the configuration file bios_edma3_drv_sample_dm648_cfg.c to your project. Adding the modified file to the project will override the default configuration provided by the EDMA LLD.
EDMA Resource Requirement for the VICP Lib
The VICP library requires the below mentioned EDMA resource:
| Resources Reserved | DM644x | DM64x |
|---|---|---|
| Number of EDMA Channels | 9 | 11 |
| Number of EDMA param entries | 29 | 31 |
EDMA Resource Allocation by the VICP Lib and how to tune it
Following are the key settings that are used in the file vicp_edma3_dm648_cfg.c. These settings can be adjusted to ensure most optimal EDMA resource allocation in the system. Note, if the settings in the file vicp_edma3_dm648_cfg.c are adjusted, the corresponding settings in the file bios_edma3_drv_sample_dm648_cfg.c should be adjusted as well to maintain consistent EDMA configuration.
DMA Channel mapping:
- define EDMA3_DMA_CHANNEL_TO_EVENT_MAPPING_0 0xFFFCFFBFu
- define EDMA3_DMA_CHANNEL_TO_EVENT_MAPPING_1 0x0Fu
The above macros control mapping of DMA channels to Hardware Events from various peripherals, which use EDMA for data transfer. Thus, if the bit corresponding to a particular channel is set (1), the EDMA channel can be triggered using the event associated with that channel. For the event mapping, please refer the EDMA UG (Table 2-6. EDMA3 Channel Synchronization Events).
EDMA3_DRV_GblConfigParams:
This configuration structure is used to specify the EDMA3 Resource Manager global settings, specific to the SoC. The structure is described in the EDMA3_Driver_User_Guide.pdf. The vicp_edma3_dm648_cfg.c includes the structure vicpEdma3GblCfgParams. The key fields that may be of interest are:
dmaChannelPaRAMMap: Mapping from each DMA channel to a Parameter RAM set. This array stores the respective PaRAM Set for each DMA channel
dmaChannelTccMap: Mapping from each DMA channel to a TCC. This array stores the respective TCC (interrupt channel)for each DMA channel
dmaChannelHwEvtMap: Mapping of DMA channels to Hardware Events from various peripherals. This setting uses the DMA channel mapping macros described earlier
EDMA3_DRV_InstanceInitConfig:
This configuration structure is used to specify which EDMA3 resources are owned and reserved by the EDMA3 driver instance. This configuration structure is shadow region specific. Note VICP uses shadow region 2 and the structure vicpInstInitConfig defined in the file vicp_edma3_dm648_cfg.c is used to describe the EDMA resource that should be allocated for the region 2, that is VICP. This structure is described well in the EDMA3_Driver_User_Guide.pdf. The key fields that will be of interest are:
ownPaRAMSets: PaRAM Sets owned by this EDMA instance. Update this field to allocate appropriate number of PARAM. The current setting is:
{0x0u, 0xFFFFFFF0u, 0x00000000u, 0xFFFFFFFEu,
0x0u, 0x0u, 0x0u, 0x0u,
0x0u, 0x0u, 0x0u, 0x0u,
0x0u, 0x0u, 0x0u, 0x0u},
The above is nonoptimal and can be modified to:
{0x380u, 0xFFC03000u, 0x00000000u, 0xFFFFFFFFu,
0x0u, 0x0u, 0x0u, 0x0u,
0x0u, 0x0u, 0x0u, 0x0u,
0x0u, 0x0u, 0x0u, 0x0u},
ownDmaChannels: EDMA channels owned by this EDMA instance. Update this field to allocate appropriate number of DMA channels. The current setting is:
{0x00000780u, 0xFFFFFFF0u},
The above is nonoptimal and can be modified to:
{0x00000380u, 0xFFC03000u},
ownTccs: TCCs owned by this EDMA instance. Update this field to allocate appropriate number of TCCs. The current setting is:
{0x00000780u, 0xFFFFFFF0u},
The above is nonoptimal and can be modified to:
{0x00000380u, 0xFFC03000u},
Q.2 What operating system dependencies are there in the VICP lib?
There is one internal dependency, related to EDMA3 LLD. To port to any OS you need to port the file test\src\vicp_edma3_support.c and include it in your application project. This file is also present in the dmcsl648_bios.lib library so once you include it in your project, your implementation will override the one in dmcsl648_bios.lib . In this file, a handful of functions need to be ported: edma3OsProtectEntry(), edma3OsProtectExit(), edma3OsSemCreate(), edma3OsSemDelete(), edma3OsSemTake(), edma3OsSemGive(). This procedure is very similar to what would be required if one wanted to use the EDMA3LLD on the DSP side in an environment that didn't use DSP-BIOS: the file %TI_EDMA3LLD%\packages\ti\sdo\edma3\drv\sample\src\bios_edma3_drv_sample_cs.c would have to be ported to the target OS and the library edma3_drv_<..>_sample.lib be rebuilt.
Note that the test benches in test directory have dependencies with an OS, through the file platform_support64xbios.c but these dependencies are external. The VICP interrupt service routine is set up externally by the test bench through the call intSetup(), which uses DSP Bios’s ECM module.
Q.3 Are there any dynamic memory allocations in the VICP lib?
There is no dynamic allocation inside the VICP library. User must call CPIS_getMemSize() to enquire about the library’s memory requirement, allocate and then pass the memory to CPIS_init().
Q.4 Are there any constraints with respect to the EDMA priority for the channels the VICP uses? Does the VICP lib configure their priority ? If not, how to set it ?
Please see p.9,p.10 of sprugj3e.pdf in release v3.3.
The user of the library can set the transfer queues of the VICP EDMA channels by setting the global variables VICP_EDMA3_FROM_DDR_queue and VICP_EDMA3_TO_DDR in bios_edma3_drv_sample_dm648_cfg.c . In addition each EDMA queue can have different priorities by setting the register QUEPRI at 0x02A0 0284 (see DM648 data manual, p.71).
Q.5 Which interrupt event is used by the VICP lib, and how should it be set up by the application (e.g. ECM - but that belongs to BIOS), what has to be done in case of no DSP/BIOS ?
On DM648, the VICP’s device event is #27 (see p.96 of DM648 data manual) and on DM6446, it is event #20. In DSP/BIOS environment, the ECM routes the device's event #27 or #20 to CPU interrupt #8 of the DSP but of course it can be routed to any of the 12 interrupts. In case of no DSP/BIOS, you probably need to set the c64x+ interrupt controller registers described in chapt 7 of the C64X+ user guide.
Q.6 Does the polling mode internally uses interrupts?
No, the polling mode just polls for a busy flag in a register, when you call CPIS_wait(). If you register a wait callback function through CPIS_setWaitCB(), then calling CPIS_wait() will first go to your custom wait callback function and then do the register polling. If your custom wait callback function contains a semaphore pend upon a flag set by the VICP isr, then minimum CPU cycles will be spent waiting for the VICP to complete. The busy polling will still be done but after your wait callback function exits but will see that VICP has completed and just exits its while loop.
Q.7 Are there any restrictions with respect to image location, for the VICP-owned EDMA transfers to receive/send frames from/to?
On DM648, the same restrictions that apply to DSP also apply to VICP. See p. 50 of the DM648 data manual. The TC#3 cannot reach PCI, VLYNQ, configuration SCR.
Q.8 Can the VICP Lib be used if the DSP is also being used to run Codecs?
Some of the Codecs implemented for the DM644x and DM64x devices utilize VICP resource to achieve higher performance. If the VICP library is also used along with the codecs that use the VICP resource, there is a potential for conflict. This section describes the usage of VICP resource by codecs and provides recommendations on how the VICP library can be used along with the codecs such that there is no conflict. There are two ways by which Codec implementation can leverage the VICP resource. They are:
- Use the internal memory of the VICP resource to place critical code/data sections
- Use the VICP computation unit to offload processing
The table below describes the VICP resource usage by the various codecs
| Device | Decode | Encoder | VICP Mem Usage | VICP Comp Unit Usage | Comments |
|---|---|---|---|---|---|
| DM6446 | H.264 | YES | NO | ||
| DM6446 | MPEG4 | NO | NO | ||
| DM6446 | MPEG2 | NO | NO | ||
| DM6446 | WMV9 | NO | NO | ||
| DM6446 | JPEG | NO | NO | ||
| DM6446 | H.264 | YES | YES | Code is placed in VICP Memory | |
| DM6446 | MPEG4 | NO | YES | ||
| DM6446 | JPEG | NO | NO | ||
| DM648 | H.264 | NO | NO | ||
| DM648 | MPEG4 | NO | NO | ||
| DM648 | MPEG2 | NO | NO | ||
| DM648 | WMV9 | NO | NO | ||
| DM648 | JPEG | NO | NO | ||
| DM648 | H.264 | YES | YES | Code is placed in VICP Memory | |
| DM6446 | MPEG4 | NO | YES | ||
| DM6446 | JPEG | NO | NO |
For the Codecs that don’t use VICP resource at all, there will be no conflict if VICP lib is used at the same time as the codecs. For the codecs that use the VICP resource, follow the below guidelines to avoid conflict between the VICP lib usage and the Codec
- If the Codec uses VICP computation unit for acceleration, the VICP library can’t be used when the codec is using the VICP computation unit during the frame processing. But, the Codecs don’t use the VICP Computation unit as a persistent resource. That is, the Codecs reinitializes the VICP computation unit for every frame. Thus, the VICP lib can be used inbetween the frame processing when the codec is not active. Just like codecs, the VICP lib usage shouldn’t assume persistent ownership of the VICP resource. That is, after completing the usage of VICP Lib, the application should call CPIS_delete(). This should be done before the codec is invoked to process the next frame. Therefore the flow should be as described below:
- CPIS_init: Initialize the VICP Library
- CODEC Initialization
- Start Codec frame processing
- End codec frame processing
- Call VICP Lib API (See Ex Below)
- CPIS_arrayOp();
- CPIS_start ();CPIS_wait ();CPIS_reset ();
- CPIS_start ();CPIS_wait ();CPIS_reset ();
- CPIS_end();
- CPIS_filter ();
- CPIS_start ();CPIS_wait ();CPIS_reset ();
- CPIS_end();
- Jump back to start the processing for next Codec frame
- For the Codecs that use the VICP internal memory to place code sections, VICP Lib can only be used if the code sections are moved out of VICP memory. Note, the placement of code sections in the VICP memory is equivalent to persistent blocking of the resource. Moving the code sections to DSP IRAM will not result in any performance degradation. But if the DSP IRAM is not available, the code sections can be moved to device external memory. The performance impact will be small ( ~<5%) but it is system and codec usage dependent. Thus, the user should measure the impact in the actual system. In most cases, moving these code sections to external memory should not be a concern. To move these code sections to external memory or DSP IRAM, please modify the DSP command file included with the CCS project. Note the codecs place the sections in the VICP_iVLD memory. Such sections should be redirected to external memory or DSP IRAM. For ex, the H.264 encoder places the .text:H264VENC_TI_cSect2 section in the VICP internal memory. Once all the code sections are moved outside the VICP IRAM, the VICP resource is free to be used with the VICP library
| For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article VICPLIB DM644x DM64x FAQ here. |
