SSCR模块管理着XDAIS算法需要的片上暂存区的覆盖图。暂存是算法在运行函数的时候需要的内存。一个算法可以自由的使用暂存而不用考虑内容的优先级。永久存储区是可以安全写的内存区，它的特点是，内容不会在任务完成前改变。这个区别可以通过几个算法覆盖暂存来最优化。如下：
因为一个XDAIS算法在执行一个函数的时候不能阻塞，暂存可以在其他的算法间共享。但是一个高优先级的线程可以中断一个低优先级的线程，所以必须为共享内存提供特别的保护。在上图中，算法A有两个实例，B和C各有一个，它们运行在同一个优先级上。算法的永久内存块必须在任何时候都要保护，但是暂存就不需要。因此，算法就被设置成分享它们的暂存块，这个大小被设置成最大的那块的大小。
SSCR模块允许提供两种方式的保护：
- 优先级。一个单独的暂存区提供给每一个使用暂存区的线程优先级。这个方法是安全的。
- 锁机制。一个暂存区被所有的算法共享。锁机制必须用来保护先占有的线程。
The priority level method provides lower latency but uses a larger total scratch buffer allocation.The application designer should decide whether to minimize latency or memory use.The SSCR module manages one or more "bucket" objects. Each bucket maintains one scratch buffer. In the priority level method, each bucket corresponds to a priority level. In the locking mechanism method, there is only one bucket. A bucket object has the following structure:
typedef struct SSCR_Bucket {
Ptr buffer; /* pointer to the scratch buffer */
Uns size; /* size of the scratch buffer */
Uns count; /* number of users of this bucket */
} SSCR_Bucket;
The SSCR module analyzes and allocates scratch buffers using a three-step process:
1. The application designer decided whether to use the priority or locking mechanisms for scratch overlay protection. Based on this choice, the designer specifies a bucket index in the ICELL_Obj structure for each cell. For example, the default RF5 application uses the THRPROCESSSCRBUCKET bucket for all cells because there is only one task priority level for XDAIS algorithm execution.
2. The application registers a cell with CHAN_regCell(), which in turn calls SSCR_prime() to determine the worst-case scratch memory requirements.
3. The application calls CHAN_open(), which in turn calls SSCR_createBuf() for each cell in a channel to allocate the memory. If the scratch buffer for a bucket index has already
The SSCR module provides the following functions:
• SSCR_init(). Initializes the SSCR module.
• SSCR_setup(). Sets up the SSCR module.
• SSCR_createBuf(). Creates the scratch buffer or returns it if it is already allocated.
• SSCR_getBuf(). Gets the size of and a pointer to the scratch buffer.
• SSCR_prime(). Determines the worst-case scratch usage for an algorithm instance.
• SSCR_deleteBuf(). Deletes the scratch buffer.
• SSCR_exit(). Exits the SSCR module.
Figure 26 summarizes the sequence in which SSCR module functions may be called.
Details about the SSCR module are provided in the Reference Frameworks for eXpressDSP Software: API Reference (SPRA147) application note.
一：优先级方法的应用。
The following example shows a priority-based scratch sharing application. In this example, three threads (thrX, thrY and thrZ) run at three different priorities.
In appThreads.h, the number of scratch buckets is set as follows:
enum SSCRBUCKETS { THRXSCRBUCKET = 0,
THRYSCRBUCKET,
THRZSCRBUCKET,
SCRBUCKETS }; // total # of scratch buckets
The number of scratch buffers must be specified in the CHAN_setup() call. For example, in appThreads.c:
CHAN_setup( INTERNALHEAP, EXTERNALHEAP, INTERNALHEAP, SCRBUCKETS, NULL, NULL );
When a cell is set up, its scrBucketIndex field must be set to accordingly. For example in thrX.c:
cell = &thrX.cellList[ (chanNum * NUMCELLS) + CELLFIR ];
*cell = defaultCell;
cell->name = "FIR";
...
cell->scrBucketIndex = THRXSCRBUCKET;
二。锁方法的应用
The following example shows how an application could use only one scratch buffer through use of a locking mechanism. Again, three threads (thrX, thrY and thrZ) run at three different priorities. Note: If all the processing threads run at the same priority, no locking mechanisms are needed.
In appThreads.h, the number of scratch buckets is set as follows:
enum SSCRBUCKETS { ONESCRBUCKET = 0,
SCRBUCKETS }; // total # of scratch buckets
A single scratch buffer is specified in the CHAN_setup() call in appThreads.c as follows:
CHAN_setup( INTERNALHEAP, EXTERNALHEAP, INTERNALHEAP, SCRBUCKETS, NULL, NULL );
When a cell is set up, its scrBucketIndex field must be set to ONESCRBUCKET. For example in thrX.c:
cell = &thrX.cellList[ (chanNum * NUMCELLS) + CELLFIR ];
*cell = defaultCell;
cell->name = "FIR";
...
env.protectScratch = TRUE; //user defined structure
cell->cellEnv = &env;
cell->scrBucketIndex = ONESCRBUCKET;
The previous code snippet also shows a use of the cellEnv pointer. By checking a field in the user-defined structure, the implementation of the cell can be more robust. In the cell, a locking mechanism must be used. For example, if latency is not a key care-about, one can use HWI_disable and HWI_restore to block other threads from running and accessing the scratch buffer. It is up to the integrator to chose the best locking mechanism for the particular application.
Bool FIR_cellExecute( ICELL_Handle handle, Arg arg )
{
IFIR_Fxns *firFxns = (IFIR_Fxns *)handle->algFxns;
IFIR_Handle firHandle = (IFIR_Handle)handle->algHandle;
Uns interruptState;
if (handle->cellEnv->protectScratch == TRUE) {
interruptState = HWI_disable();
}
// activate instance object
ALGRF_activate( handle->algHandle );
firFxns->filter( firHandle,
(Short *)handle->inputIcc[0]->buffer,
(Short *)handle->outputIcc[0]->buffer );
// deactivate instance object
ALGRF_deactivate( handle->algHandle );
if (handle->cellEnv->protectScratch == TRUE) {
H WI_restore( interruptState );
}
return ( TRUE );
}
链接：http://blog.gkong.com/more.asp?name=barongeng&id=5474