Introduction

Managed Resources

DSPs, DPMs, and DPFs

DSP Resources

Worst-Case Resource Management Calculation

Example

Resource Calculations Overall Resource Requirements 262

Resource Management Keywords

Resource Definition String Syntax

DSP Files and Resource Definitions Example: Configuring Available DSP Resources 264

Resource Definitions

Input and Output Slots

Resource Definition Examples Example: All DPFs Running Exclusively 266

Example: All DPFs Running Simultaneously 267

Example: Some DPFs Running Simultaneously 268

Specifying Conditional Relationships Between DPFs Example 1 269

Example 2 270

Natural Access Media Masks and Call Progress Masks

Echo Cancellation Restriction

Trunk Control Program Resource Usage

Debugging Resource Management

Using CG 6000C Debug Masks

Resource Management Board Errors

Debugging Resource Management with cgtrace

CG 6000C Board DSP Resource Usage

Default Functions Available for CG 6000C Boards

Custom Functions Available for CG 6000C Boards

DSP Files and MIPS Requirements

Introduction

This appendix provides information about:

• CG 6000C DSP resources categories

• Calculating CG 6000C DSP resource usage

• Configuring DSP resources with OAM service board keywords

• Natural Access media and call progress masks, and trunk control programs (TCPs)

• Debugging CG 6000C DSP resource management by setting debug masks and using cgtrace

• DSP Files and MIPS Requirements

Managed Resources

The CG 6000C board is based on a flexible software and hardware architecture. The architecture uses an array of Digital Signal Processors (DSPs) under the control of a specially designed operating system to execute algorithms to detect, encode, decode, and generate voice and call status signals. These DSP resources are managed by the DSP resource manager executing on the board.

CG 6000C DSP resource management is configured to operate on a per-port basis. A port is associated with a circuit-switched call (for PSTN-based applications) or another type of media stream. DSP resource management determines the DSPs on which particular DSP functions run. Resource management can ensure that the DSP resources required to support a call are available when needed.

CG 6000C DSP resource management reserves all of the resources required for a port before the port is used. The DSP resources that are reserved for a port are specified in the Resource[x].Definitions keyword and the Resource[x].TCPs keyword in the board keyword file.

When you do not specify resource strings in the board keyword file, the board checks whether the appropriate resource is available only when an application tries to use the resource.

Note: The standard set of board keyword files provided with CG 6000C software (and Fusion software) contains DSP resource management settings suitable for most applications. Therefore, in most cases you do not need to modify these resource definitions and can skip this chapter. However, if your application requires resources not specified in the sample board keyword files, you may need to customize the CG 6000C DSP resource management settings. You should understand how the CG 6000C DSP resource manager allocates resources before modifying the standard DSP resource definitions.

DSPs, DPMs, and DPFs

CG 6000C DSP programs are distributed in files known as Data Processing Modules (DPMs). These files use the extension .f54, and contain executable code for a family of algorithms. Each algorithm in that family is known as a Data Processing function (DPF), and can be referenced by a unique string generated by combining the family string ID (that corresponds to the DPM) with the function ID string (that corresponds to the DPF). Both the DPM and DPF have associated hexadecimal IDs that can be used to uniquely identify the DSP function.

For example, the file echo.f54 is the DPM for echo cancellation. All of the DPFs in echo.f54 provide a type of echo cancellation functionality. The echo canceller DPM ID is echo and the associated hexadecimal ID is 0x16. For an echo canceller that has a filter length of 20 ms and an adaptation rate of 100%, the DPF ID is ln20_apt100 and the associated hexadecimal ID is 0x0A00). Therefore this echo DPF is identified by the string ID echo.ln20_apt100 (or the hexadecimal ID 0x160A00).

To list all function IDs in a particular family (and their associated hexadecimal IDs), run the f54info program and specify the family string ID. For example, for the echo cancellation family of functions, you would type the following at the command prompt:

f54info -t echo

Note: For more information about f54info (and about DPM and DPF hexadecimal IDs), refer to Appendix D.

DSP Resources

CG 6000C DSP resource usage is calculated based on the following categories:

• MIPS

• Memory

• Timeslots

• Packet queues

• Buffer size

Each DPF that executes on a DSP core consumes resources from each of these categories. The overall resource usage dictates how many DPFs can run on a DSP core, and consequently how many ports can run per board. The following table describes these resource categories:

Resource Category	Description
MIPS	Measures the computational capacity of a DSP core and the fraction of a DSP core's processing power consumed by a given DPF. The CG 6000C board uses 32 DSP cores, each running at 100 MIPS. The DSP Operating System (DSPOS) consumes approximately 5 MIPS, leaving approximately 95 MIPS per DSP core available for the loadable DPFs.
Memory	Each DSP core has 100K words of memory, of which approximately 90K words are available for DPFs.
Timeslots (input and output)	Each DSP core is connected to an H.110 interface chip through shared local streams consisting of 128 input and 128 output timeslots. Groups of four or eight DSP cores are connected to a single local stream. Therefore, each DSP core in the group is physically connected to 128 input and output timeslots. However, each DSP uses only a subset of the available timeslots. The DSP operating system used for universal ports supports up to 16 full duplex timeslots per DSP core. Input timeslots on the CG 6000C board can be shared between DPFs. In addition, there are 32 input and 16 output timeslots internal to each DSP core. These internal timeslots are used for DPF-to-DPF communication.
Packet queues (input and output)	Carry data between the DSP cores and the CG 6000C board StrongARM processor. The number of queues is limited in the DSPOS in order to conserve system memory and optimize performance.
Buffer size	Packets/buffers take up resources in the DSP-to-StrongARM buffer or StrongARM-to-DSP buffer.

A universal port is a set of DSP resources required for a single call. These resources are specified with keywords in the board keyword file. The DSP resource manager allocates all the resources required for a call on one DSP according to the universal port definition.

The following table summarizes resources available on each CG 6000C board DSP core:

Resource Category	Available Resource
MIPS	approximately 95 MIPS per DSP
External time slots (input and output)	16 full duplex
Internal time slots (input and output)	32 in, 16 out
Memory	approximately 90K Words
Input packet queues	64
Output packet queues	64
Buffer size (StrongARM-to-DSP and DSP-to-StrongARM)	768 Words each

Note: If no other limitations apply (for example MIPS or memory) the maximum number of DPFs that can be loaded to a DSP is 63.

Worst-Case Resource Management Calculation

One way to find out if the available board resources can support all the processes is to calculate the resources required by the application in its most demanding scenario. This is called a worst-case scenario calculation.

Note: This is a complex calculation and is not always practical to apply. The CG 6000C board calculates the requested resources at boot time and determines if the requested DSP resources are available.

This section describes a worst-case resource usage example (a telephony application using an on-board CAS or ISDN protocol) in order to illustrate the methods used to calculate resources under particular conditions.

Example

For calls in the connected state (also called the conversation state), media processing functions (that is, vocoders or fax functions) consume the greatest amount of DSP processing power. TCPs used during the call also require DSP resources, but they use the greatest amount of resources during the set up phase of the call. In general, the resources required during call set up are less than the resources required in the connected state. For this reason, the examples that follow calculate resources used during calls in the connected state.

The following example shows resource requirements for a call that use the following functions in the connected state:

• Echo cancellation (echo.ln20_apt100 DPF)

• DTMF detection with energy detector and two tone detectors (dtmf.det_all DPF)

• Precise tone detection (ptf.det_2f DPF)

• NMS ADPCM record vocoder (voice.rec_32 DPF)

This example assumes that the worst-case usage (that is, the point where DSP resources experience their highest MIPS usage, heaviest time slot usage, etc.) occurs during the connected state of the call.

Note: ISDN signaling and out-of-band signaling for CAS use dedicated signaling resources (running on DSP 0) that are not managed by the DSP resource manager.

The following table shows the resources consumed by the DSP functions in this scenario:

DPF	MIPS	Input Slots	Output Slots	Data Memory	InputPkt Queue	Output Pkt Queue	DSP-to-StrongARM Buffer Size	Comments
echo	4.0	2	1	800	0	0	-	20 ms length, 100% adapt rate
dtmf	2.5	1	0	200	0	0	-
ptf	1.3	1	0	100	0	0	-
voice	3.3	1	0	300	0	1	40	NMS Record 32 kbit/s
Total	11.1	5	1	1400	0	1	35

Note: The displayed resource numbers are approximate. To find the most up-to-date resource requirements for specific DPFs, run f54info as described in section Appendix D.

Resource Calculations

Based on the previous example, you can calculate the following resource limitations for the sample application:

Resource Category	Worst Case Usage
MIPS	MIPS used by this worst case example are the sum of all the functions' MIPS requirements, or 11.1 MIPS. Divide the 95 MIPS (approximately) available per DSP core by the sum and truncate the result (95 / 11). This yields 8 ports of conversation state per DSP core.
Memory	Each DSP core has 100K words of memory. Approximately 90K words of the memory are available for both code and data. This example assumes 60K words are used for the DSP operating system and DPF code leaving 40K words for DPF data. Therefore yields 1400/40 = 35.
Timeslots (input and output)	Each connected port consumes one full duplex timeslot because input slots are shared. Furthermore, two of the echo canceller slots, one input slot and one output slot, are internal. The port limit per DSP core due to timeslots is 16 ports (16 / 1), for both external and internal slots. If the total input or output time slots calculation is greater than 1, the resource manager sets it to 1.
Packet queues	The number of packet queues required in the example is 1. The packet queue limit is therefore 64 (64 / 1).
Buffer size	The StrongARM packet size limit is applicable only for DSP functions sending or receiving data from the StrongARM processor. Typically, this limit will be imposed by a vocoder in the conversation/connected state. Since this example uses a voice recording DPF, the packets take up resources in the DSP-to-StrongARM buffer. An NMS 32 kbit/s vocoder uses 42 words (40 words of data, 2 header words) per StrongARM packet, resulting in an 18 port per DSP core limit (obtained by dividing DSP-to-StrongARM buffer size by packet size or 768 / 42). An NMS 64 KB vocoder uses 82 word buffers in a connected state, and therefore limits each DSP core to nine ports. Note: In the case of play functions, the packets consume resources in the StrongARM-to-DSP buffer plus an additional four words in the DSP-to-StrongARM buffer. This is because the DSP operating system sends data acknowledgment events through DSP-to-StrongARM buffers.

Overall Resource Requirements

In this example, the number of ports per DSP core is limited to a total of 8 by the MIPS requirements.

Resource Management Keywords

The following keywords configure CG 6000C board DSP resource management:

Keyword	Description
DSP.C5x[x].Files	Specifies the data processing function modules (DPMs) to load to a specified CG 6000C board DSP.
TCPFiles[x]	Specifies the trunk control programs (TCP) loaded to the board.
Resource[x].TCPs	Specifies the TCPs the resource manager uses with the resource definition.
Resource[x].Name	Associates a name (character string) with a particular resource definition.
Resource[x].Definitions	Specifies a relational string of Data Processing Functions (DPFs), describes the functionality that can occur on a single port, and describes how and when functions execute in relation to each other.
Resource[x].Size	Specifies the number of channels or ports managed by the on-board resource manager.

The following sections describe in detail how to use the DSP.C5x[x].Files and Resource[x].Definitions keywords. For more information about these and other CG 6000C DSP resource management keywords, refer to Chapter 6.

Resource Definition String Syntax

When specifying resource definitions, you can use a set of logical operators in board keyword files to combine DPFs and define the relationships between them.

The following logical operators are supported in board keyword files:

Operator	Description
&	And
|	Or
()	Open and close parenthesis
\	Line break

Note: Resource[x].Definitions strings always start with an open parenthesis, and end with a close parenthesis.

DSP Files and Resource Definitions

The DSP.C5x[x].Files keyword specifies the DPMs that are loaded to particular DSPs.

Note: In general, most configuration files load DSPs 1-31 with the same DSP files.

The CG 6000C DSP resource manager recognizes and manages only DPFs that are specified with the Resource[x].Definitions keyword. The DSP resource manager only recognizes DPFs if the DPMs in which they reside have been loaded to board DSPs. Load DPMs to the CG 6000C board by specifying the DPM name in a DSP.C5x[x].Files keyword string, where x represents a DSP or range of DSPs.

If the DSP resource manager is allocating resources, but finds that a DPF is not loaded to any DSP, it returns the error:
Board Error 0xa0e: Function 0xxxxx not found on any engine.

Where xxxx is the value of the DFF not found.

Example: Configuring Available DSP Resources

Use the DSP.C5x[x].Files keyword to load a particular DPMs functionality to specific DSPs on the CG 6000C board. Specify DPM files to load by using the following format:

DSP.C5x[x].Files = dpmfilename dpmfilename dpmfilename...

Where x refers to the DSP core, or a range of DSP cores, to load (there are 32 DSP cores on the CG 6000C board, so the value of x ranges from 0 - 31), and dpmfilename refers to a DPM to load to the corresponding DSP cores.

For example, the string:

DSP.C5x[1,5,11].Files = echo dtmf

indicates to load cores DSP[1], DSP[5], and DSP[11] with the DPMs echo and dtmf.

You can also specify to load the DPM files to a range of DSPs, as in the following:

DSP.C5x[1..31].Files = echo dtmf ptf

In this case, the string indicates to load cores DSP[1] through DSP[31] with the DPMs echo, dtmf, and ptf.

Resource Definitions

The following sections provide several examples of Resource[x].Definitions strings that use the DPFs echo.ln20_apt100, dtmf.det_all, ptf.det_2f, and voice.rec_32. These examples specify which DPFs run on a specific DSP as well as the relationship between these DPFs (that is, which DPFs can run simultaneously and which cannot).

Note: The resource requirements for the DPFs specified in this chapter are subject to change. To verify resource usage for specific DPFs, run f54info as described in Appendix D.

In this example and the other DSP resource management examples that follow, the input slots requirements are calculated differently from other resource categories in a worst-case scenario.

Input and Output Slots

The input slots column shows the number of timeslots required to move data to and from DSPs. If all of the DPFs for a call have been allocated on one DSP, the resource manager needs to allocate enough timeslots only to move the data to and from the DSP. Therefore, if the results of the inputs slots calculation is greater than one, but all DPFs reside on a single DSP, the DSP resource manager allocates only one input timeslot and one output timeslot for the resource.

For example, the resource manager determines if all of the resources specified in the Resource[x].Definitions string can be allocated on a single DSP. It also determines if the DPFs specified in the Resource[x].Definitions string use DPF-to-DPF communication. If all the DPFs specified for each port can run on a single DSP, the DPFs can use internal timeslots to move data between the DPFs. In this case, the on-board resource manager can efficiently allocate sufficient resources by assigning only one input timeslot per port.

Note: If the resource manager is not able to allocate all DPFs for a port on one DSP, the Input slots are calculated cumulatively by adding the slots required for each DPFs.

Resource Definition Examples

The following sections describe the resource strings used to set up DPFs to run under following DPF conditions:

• All DPFs running simultaneously

• All DPFs running exclusively

• Different subsets of DPFs running simultaneously

Example: All DPFs Running Exclusively

In the following example, all the DPFs specified in the resource definition string run exclusively (in other words, only one DPF can run at a time). In this case, you would set the Resource[x].Definitions keyword string to:

Resource[1].Definitions = ( dtmf.det_all | ptf.det_2f | voice.rec_32)

The resources consumed by the DPFs in this resource string are shown in the following table that lists the resources consumed by each function:

DPF	MIPS	Input Slots	Output Slots	Data Memory (words)	InputPkt Queue	Output Pkt Queue	DSP-to-StrongARM Buffer Size	Comments
dtmf	2.5	1	0	200	0	0	-
ptf	1.3	1	0	100	0	0	-
voice	3.3	1	1	300	0	1	40	NMS Record 32 kbit/s
Total	3.3	1	1	300	0	1	40

Since the example specifies that only one DPF function can execute at a time, the worst case MIPS requirement is 3.3 MIPS, the worst case data memory requirement is 300 words, and the worst case output slots requirement is 1 (the highest resource usage in each category).

Example: All DPFs Running Simultaneously

In the following example, all of the DPFs specified in the resource definition string can run at the same time. In this case, you set the Resource[x].Definitions keyword string to:

Resource[1].Definitions = ( echo.ln20_apt100 & dtmf.det_all & \

ptf.det_2f & voice.rec_32 )

DPF	MIPS	Input Slots	Output Slots	Data Memory (words)	InputPkt Queue	Output Pkt Queue	DSP-to-StrongARM Buffer Size	Comments
echo	4.0	2	1	800	0	0	-	20 ms length, 100% adapt rate
dtmf	2.5	1	0	200	0	0	-
ptf	1.3	1	0	100	0	0	-
voice	3.3	1	0	300	0	1	40	NMS Record 32 kbit/s
Total	11.1	1	1	1400	0	1	40

Since all of the MIPS are added together, the MIPS calculation for this string is 11.1 MIPS, while the data memory requirement is 1400 words (the cumulative total of adding up the requirements for each DPF).

However, when all of the DPFs reside on the same DSP core, the slots internal to the DSP core are used for DPF to DPF communication. Since they use internal timeslots, the input slot requirements are equal to 1.

Example: Some DPFs Running Simultaneously

In the following example, only the echo and voice DPFs can execute at the same time. In this case, you can specify the following Resource[x].Definitions keyword string:

Resource[1].Definitions = ( ptf.det_2f | dtmf.det_all | \

( echo.ln20_apt100 & voice.rec_32 ) )

DPF	MIPS	Input Slots	Output Slots	Data Memory (words)	InputPkt Queue	Output Pkt Queue	DSP-to-StrongARM Buffer Size	Comments
echo	4.0	2	1	800	0	0	-	20 ms length, 100% adapt rate
dtmf	2.5	1	0	200	0	0	-
ptf	1.3	1	0	100	0	0	-
voice	3.3	1	0	300	0	1	40	NMS Record 32 kbit/s
Total	7.3	1	1	1100	0	1	40

The MIPS calculation for this example adds the MIPS requirements for the echo and voice DPFs and compares the result to dtmf and then to ptf. The largest of the three is allocated to the MIPS resource.

In this case echo + voice is 7.3 MIPS, which is greater than the MIPS requirement for either the dtmf or ptf DPMs (2.5 and 1.3 MIPS respectively). Therefore, the maximum MIPS requirement is 7.3 MIPS. The sum of voice and echo requirements for data memory is also larger than the dtmf and ptf requirements, so the maximum data memory requirement is 1100 words.

The output slots requirement is 1 and the input slots requirement is 1 because all DPFs are executing on one DSP. The resource manager uses these calculations to determine how many ports the board supports.

Note: Parentheses are used to indicate groupings and order of operation. In this example, echo and voice resources are added together with the AND operator before the OR comparisons occur.

Specifying Conditional Relationships Between DPFs

The following examples define complex conditional relationships between DPFs using the AND operator, the OR operator, and parentheses to combine DPF string IDs.

Example 1

In the following example, OKI play and OKI record DPFs run simultaneously with:

• DTMF detection

• Echo cancellation

• Precise tone detection with two single frequencies

You can run simultaneous 24 kbit/s OKI ADPCM play and record functions by specifying the following Resource[x].Definitions string:

Resource[1].Definitions = ( dtmf.det_all & echo.ln20_apt25 &   \ 
ptf.det_2f & ( oki.rec_24 & (oki.play_24_100 | oki.play_24_150 | \  oki.play_24_200 ) ) )

This resource definition string reserves DSP resources so that the worst-case resource usage of the play functions (oki.play_24_100, oki.play_24_150, oki.play_24_200) run simultaneously with the record function (oki.rec_24).

Example 2

In this example, OKI play, OKI record, or tone generator functions run in the connected state, but not at the same time. Functions that execute simultaneously with OKI play or OKI record functions include:

• DTMF detection

• Echo cancellation

• Precise tone detection with two single frequencies
  Note: In this example, the tone generator will not run if an OKI ADPCM play or OKI ADPCM record function is running.

You can run a 24 kbit/s ADPCM OKI play function or a 24 kbit/s ADPCM OKI record function (a 24 kbit/s ADPCM OKI play function never runs at the same time as 24 kbit/s ADPCM OKI record function) by specifying the following Resource[x].Definitions string:

Resource[1].Definitions = ( dtmf.det_all & echo.ln20_apt25 & \ ptf.det_2f & ( oki.rec_24 | oki.play_24_100 | oki.play_24_150 \ |oki.play_24_200 | tone.gen ))

This resource definition string allows either the record functions, one of the play functions, or the tone generator to run at the same time as the DTMF detection, echo cancellation, and PTF functions.

Natural Access Media Masks and Call Progress Masks

Natural Access uses two masks that effect DSP resource management. The following table presents the names of the masks (media mask and call progress mask):

If you are using this service...	The masks are...
NCC service	NCC.X.ADI_START.mediamask NCC.X.ADI_PLACECALL.CALLPROG.precmask
ADI service	ADI.START.callctl.mediamask ADI.PLACECALL.callprog.precmask

These masks indicate DPFs that will execute on the board. If any of the bits in either of these two masks are set, the DPFs relating to the set bits must be specified in the Resource[x].Definitions keyword. Since the bits in the media mask are set by default, the DPFs that correspond to these set bits are in the default Resource[x].Definitions keyword in the templates. For more information about these masks, refer to the Natural Access Developer's Reference Manual.

Echo Cancellation Restriction

Only one echo canceller runs per call. Therefore, specify only one occurrence of echo cancellation in the Resource[x].Definitions string.

Trunk Control Program Resource Usage

The Resource[x].TCPs keyword specifies which TCPs are used to perform call control for a resource definition. A number of TCPs are supplied with the CG 6000C board. The following table shows the digital TCPs provided with CG 6000C software and their MIPS and memory requirements.

This information is useful for predicting the number ports per DSP core. One input timeslot and one output timeslot are allocated as part of the resources (assuming that all of the resources for a TCP are allocated on one DSP core).

Protocol	MIPS	Memory
MFC-R2, E&M	2.7	475
EUC, AP2	2.7	360
SS5	4.405	257
R15	2.7	475
MFS	4.222	575
WNK, FGD	2.7	360
OPS, GDS	3.793	360

Note: TCP MIPS usage numbers are subject to change.

The resource calculations displayed when the board is booted include only resources for TCPs specified with the Resource[x].TCPs.

Note: All TCPs included in the Resource[x].TCPs statement must also be specified in the TCPFiles[x] keyword string.

Debugging Resource Management

There are several ways to debug the resource management strings defined in the CG 6000C board:

• Using the DebugMask keyword

• Monitoring CG 6000C board errors

• Using cgtrace

The following sections describe these debugging methods in more detail.

Using CG 6000C Debug Masks

Each CG 6000C board keyword file includes a DebugMask keyword. When this keyword value is set, it turns on global flags in the system. These flags display status information about different board components whenever the board is booted. After the board has been booted, you can run cgtrace to obtain a list of global and local debug masks and a brief description of the types of information they provide (for more information about using cgtrace, refer to Appendix D).

Note: To view debug information, you must be running the OAM service utility oammon. For more information about using oammon, refer to the NMS OAM System User's Manual.

If you encounter DSP resource management problems when booting the
CG 6000C board, set the DebugMask keyword value to 0x08. This setting configures the board so that it displays all the resources available for each DSP. In some circumstances, it also displays the calculated resource usage based on the resource management keywords specified in the board keyword file.

Resource Management Board Errors

If an application tries to use the allocated DSP resources in a way not specified in the board's DSP resource management configuration, the board returns an error. Use the NMS OAM utility oammon to monitor these errors. For more information about DSP resource management board errors, refer to Section 4.10.

Some possible debug errors include the following error messages:

Error message	Problem	Solution
Board Error 0xe40: Resource Manager: Insufficient resources. Note: In this case, the total resource usage for the board is displayed.	The board can allocate resources for only a portion of the ports you require, because the resource consumption exceeds the available MIPS or memory.	Adjust the number (or type) of DPFs that can execute simultaneously on each port so that the board will support the required number of ports. or Decrease the number of ports used.
Board Error 0xa0e: Function 0x001A0000 not found on any engine. Note: In this case, the calculated resource is not displayed.	A DSP has not been loaded with all the DPMs specified in the Resource[x].Definitions or Resource[x].TCPs keyword strings.	The error provides the DPF's family and function ID in hexadecimal form (in the example error, this is 0x001A0000). Make sure a DPM has been loaded (with the DSP.C5x[x].Files or TCPFiles[x] keyword) for each DPF specified in the resource definition string.

For more information about CG board errors, refer to the NMS Board and Driver Errors Manual. For more about the hexadecimal IDs associated with DPMs and DPFs refer to the f54info section in Appendix D.

Debugging Resource Management with cgtrace

cgtrace is an interactive debugging tool that enables you to debug CG 6000C board output. Once the CG 6000C board is booted, you can use cgtrace to evaluate CG 6000C board DSP resource management on a per-port and per-DSP basis.

To debug DSP resource management with cgtrace:

1. Enter cgtrace at a command prompt.
   cgtrace displays the following list of active managers on the board:
   Tracing Board 0...
   Commands:
   A About
   M Display Manager Info
   S Send New Mask
   R Refresh Manager List
   G Change Global Trace Mask
   Q Quit

2. Enter the M command to display the following list of active board managers.
   0: Global Tracing
   1: Filter Manager
   2: Executive
   3: Host Interface
   4: Switching Manager
   5: Legacy Manager
   7: Image Manager
   8: Framer Manager
   9: Resource Manager
   A: HDLC Manager
   D: DSP Manager
   10: CLK Manager

3. Enter 9 to specify the resource manager.
   cgtrace displays the following list of resource management trace values available with a brief description of what each value traces:
   Manager 80000009 "Resource Manager" - 2 trace elements
   Bitmask Field:
   .. 00000001: RM CMD Enable Trace Commands
   .. 00000002: RM EVT Enable Trace Events
   .. 00000010: Resource Objects creation and destruction
   .. 00000040: Allocate and Destroy of Resource Objects while running
   .. 00100000: Print Prestart list
   .. 01000000: Prints Host ResDef (string required)
   .. 02000000: Prints all TCP ResDefs (string required)
   .. 04000000: Resource Calculation of Definition in use
   (string requred)
   .. 10000000: Number of pools and their names
   .. 20000000: Single pool: number of objects, number objects in use
   (string required)
   .. 40000000: Single pool details: List of resource objects and their
   engine (string required)
   String Field:
   .. MaxLen 11, Default , Req 0: Res Label or TCP label

4. Enter the S command to send a trace to the on-board resource manager.
   Note: When the menu indicates string required for a particular trace mask, you must enter in quotes the name (set with the Resource[x].Name keyword) associated with the resources you want to trace.
5. Enter the G command to set the global trace mask on the board (only after the board has been booted).
   cgtrace displays information about resources allocated on the CG 6000C board on a per-port and per-DSP basis.

For more information about using cgtrace, refer to Appendix D.

CG 6000C Board DSP Resource Usage

The binary code for running functions is contained in DSP files. One or more functions are contained in each file. NMS boards differ in the total number of DSP cores they contain and the speed of the DSP cores on the board.

DSP speed is measured in millions of instructions per second (MIPS). Each function that runs on a DSP core consumes MIPS. If the total MIPS consumption for all the requested functions on all the ports of a given board exceeds the total MIPS available for that board, then an error event will occur. If MIPS-intensive functions are required, it may be necessary to reduce the total number of ports on a board, which makes more MIPS per port available.

The following table shows the number of DSP cores and total amount of MIPs available per CG 6000C board:

CG Board	Total # DSP Cores	MIPS per DSP Core	OS Overhead per DSP (MIPS)	Available MIPS
CG 6000/400	32	100	approximately 5 (52 on signaling DSP only)	2993

Default Functions Available for CG 6000C Boards

Most of the Natural Access functions implicitly make use of functions that run on the DSP resources. For example, adiStartToneDetector starts the tone detector function running on a DSP. adiStartRecording starts one of many voice compression functions running on a DSP. CG boards are shipped with default configurations that make the most commonly used functions available.

Custom Functions Available for CG 6000C Boards

The following functions can be loaded on CG 6000C boards with NMS OAM utilities:

• Caller ID

• Echo Cancellation

• ADSI

• NMS Speech Normal

• NMS Speech 1.5X

• NMS Speech 2.0X

• OKI Speech Normal

• OKI Speech 1.5X

• OKI Speech 2.0X

• IMA/DVI Speech

• WAVE Speech

• G.726 Speech

• GSM speech

DSP Files and MIPS Requirements

The following table shows the MIPS usage for all the available DPMs shipped with Natural Access:

DSP File	Function	MIPS	Related API Function	Related Arguments
adsir.f54	ADSI receiver	2.67	adiStartReceivingFSK
adsix.f54	ADSI transmitter	.88	adiStartSendingFSK
callp.f54	Call progress	.90	adiStartCallProgress
dtmf.f54	DTMF only	1.81	adiStartToneDetector
dtmf.f54	Post- and pre- tone silence	0.69	adiStartToneDetector
dtmf.f54	DTMF, post- and pre-tone silence, and one tone pair	2.46	adiStartToneDetector
dtmf.f54	1 tone pair	1.28	adiStartToneDetector
dtmf.f54	DTMF, post- and pre-tone silence, and one tone pair, and one frequency	2.72	adiStartToneDetector
dtmf.f54	Post- and pre-tone silence, and one tone pair, and one frequency	1.57	adiStartToneDetector
g723.f54	G723.1 5.33 kbit/s Play	1.85	adiStartPlaying
g723.f54	G723.1 5.33 kbit/s Record	16.20	adiStartRecording
g723.f54	G723.1 6.4 kbit/s Play	1.85	adiStartPlaying
g723.f54	G723.1 6.4 kbit/s Record	16.20	adiStartRecording
g729.f54	G729a Play	3.16	adiStartPlaying
g729.f54	G729a Record	13.10	adiStartRecording
g726.f54	G.726 Play	7.33	adiStartPlaying	encoding = ADI_ENCODE_G726
g726.f54	G.726 Record	6.72	adiStartRecording	encoding = ADI_ENCODE_G726
gsm_ms.f54	MS-GSM Play 8 kHz	2.00	adiStartPlaying	encoding = ADI_ENCODE_GSM
gsm_ms.f54	MS-GSM Record 8 kHz	4.10	adiStartRecording	encoding = ADI_ENCODE_GSM
gsm_mspl.f54	MS-GSM Play 8 kHz	2.01	adiStartPlaying	encoding = ADI_ENCODE_GSM
gsm_mspl.f54	MS-GSM Record 8 kHz	4.10	adiStartRecording	encoding = ADI_ENCODE_GSM
ima.f54	IMA/DVI ADPCM Play 6 kHz	1.91	adiStartPlaying	encoding = ADI_ENCODE_IMA_24 maxspeed = 100
ima.f54	IMA/DVI ADPCM Play 6 kHz	1.91	adiStartPlaying	encoding = ADI_ENCODE_IMA_24 maxspeed = 150
ima.f54	IMA/DVI ADPCM Play 6 kHz	1.91	adiStartPlaying	encoding = ADI_ENCODE_IMA_24 maxspeed = 200
ima.f54	IMA/DVI ADPCM Play 8 kHz	1.62	adiStartPlaying	encoding = ADI_ENCODE_IMA_32 maxspeed = 100
ima.f54	IMA/DVI ADPCM Play 8 kHz	1.62	adiStartPlaying	encoding = ADI_ENCODE_IMA_32 maxspeed = 150
ima.f54	IMA/DVI ADPCM Play 8 kHz	1.62	adiStartPlaying	encoding = ADI_ENCODE_IMA_32 maxspeed = 200
ima.f54	IMA/DVI ADPCM Record 6 kHz	1.91	adiStartRecording	encoding = ADI_ENCODE_IMA_24
ima.f54	IMA/DVI ADPCM Record 8 kHz	2.00	adiStartRecording	encoding = ADI_ENCODE_IMA_32
mf.f54	Forward detect, backward compelling	2.56	adiStartMFDetector
mf.f54	Backward detect, forward compelling	2.56	adiStartMFDetector
mf.f54	MF detection	1.81	adiStartMFDetector
mf.f54	MF forward detection	1.81	adiStartMFDetector
mf.f54	MF backward detection	1.81	adiStartMFDetector
oki.f54	OKI Play 6 kHz	2.10	adiStartPlaying	encoding = ADI_ENCODE_OKI_24, maxspeed = 100
oki.f54	OKI Play 8 kHz	1.80	adiStartPlaying	encoding = ADI_ENCODE_OKI_32, maxspeed = 100
oki.f54	OKI Play 6 kHz 1.5X	4.11	adiStartPlaying	encoding = ADI_ENCODE_OKI_24, maxspeed = 150
oki.f54	OKI Play 8 kHz 1.5X	3.78	adiStartPlaying	encoding = ADI_ENCODE_OKI_32, maxspeed = 150
oki.f54	OKI Play 6 kHz 2.0X	5.43	adiStartPlaying	encoding = ADI_ENCODE_OKI_24, maxspeed = 200
oki.f54	OKI Play 8 kHz 2.0X	5.00	adiStartPlaying	encoding = ADI_ENCODE_OKI_32, maxspeed = 200
oki.f54	OKI Record 6 kHz	2.21	adiStartRecording	encoding = ADI_ENCODE_OKI_24
oki.f54	OKI Record 8 kHz	2.12	adiStartRecording	encoding = ADI_ENCODE_OKI_32
ptf.f54	2 single frequency or 1 tone pair	1.29	adiStartToneDetector
ptf.f54	4 single frequency or 2 tone pair	1.81	adiStartCallProgress	precmask!=0
rvoice.f54	mu-law Play	0.62	adiStartPlaying	encoding = ADI_ENCODE_ MULAW
rvoice.f54	A-law Play	0.62	adiStartPlaying	encoding = ADI_ENCODE_ ALAW
rvoice.f54	WAVE Play, 8 kHz, 16-bit	0.63	adiStartPlaying	encoding = ADI_ENCODE_ PCM8M16
rvoice.f54	mu-law Record	0.62	adiStartRecording	encoding = ADI_ENCODE_MULAW
rvoice.f54	A-law Record	0.62	adiStartRecording	encoding = ADI_ENCODE_ ALAW
rvoice.f54	WAVE Record, 8 kHz, 16-bit	0.62	adiStartRecording	encoding = ADI_ENCODE_ PCM8M16
tone.f54	Tone Generator	0.61	adiStartDial adiStartDTMF adiStartTones
voice.f54	NMS Play 16 Kbit/s	2.95	adiStartPlaying	encoding = ADI_ENCODE_ NMS_16, maxspeed = 100
voice.f54	NMS Play 24 Kbit/s	2.96	adiStartPlaying	encoding = ADI_ENCODE_ NMS_24, maxspeed = 100
voice.f54	NMS Play 32 Kbit/s	2.95	adiStartPlaying	encoding = ADI_ENCODE_ NMS_32, maxspeed = 100
voice.f54	NMS Play 64 Kbit/s	0.51	adiStartPlaying	encoding = ADI_ENCODE_ NMS_64, maxspeed = 100
voice.f54	NMS Play 16 6 kHz 1.5X	5.86	adiStartPlaying	encoding = ADI_ENCODE_ NMS_16, maxspeed = 150
voice.f54	NMS Play 24 6 kHz 1.5X	5.88	adiStartPlaying	encoding = ADI_ENCODE_ NMS_24, maxspeed = 150
voice.f54	NMS Play 32 6 kHz 1.5X	5.95	adiStartPlaying	encoding = ADI_ENCODE_ NMS_32, maxspeed = 150
voice.f54	NMS Play 64 6 kHz 1.5X	2.44	adiStartPlaying	encoding = ADI_ENCODE_ NMS_64, maxspeed = 150
voice.f54	NMS Play 16 6 kHz 2.0X	7.41	adiStartPlaying	encoding = ADI_ENCODE_ NMS_16, maxspeed = 200
voice.f54	NMS Play 24 6 kHz 2.0X	7.47	adiStartPlaying	encoding = ADI_ENCODE_ NMS_24, maxspeed = 200
voice.f54	NMS Play 32 6 kHz 2.0X	7.53	adiStartPlaying	encoding = ADI_ENCODE_ NMS_32, maxspeed = 200
voice.f54	NMS Play 64 6 kHz 2.0X	2.85	adiStartPlaying	encoding = ADI_ENCODE_ NMS_64, maxspeed = 200
voice.f54	NMS Record 16 Kbit/s	3.33	adiStartRecording	encoding = ADI_ENCODE_NMS_16
voice.f54	NMS Record 24 Kbit/s	3.36	adiStartRecording	encoding = ADI_ENCODE_ NMS_24
voice.f54	NMS Record 32 Kbit/s	3.35	adiStartRecording	encoding = ADI_ENCODE_ NMS_32
voice.f54	NMS Record 64 Kbit/s	0.58	adiStartRecording	encoding = ADI_ENCODE_ NMS_64
wave.f54	WAVE Play 11 kHz 8-bit	1.58	adiStartPlaying	encoding = ADI_ENCODE_PCM11M8
wave.f54	WAVE Play 11 kHz 16-bit	1.36	adiStartPlaying	encoding = ADI_ENCODE_PCM11M16
wave.f54	WAVE Record 11 kHz 8-bit	1.59	adiStartRecording	encoding = ADI_ENCODE_PCM11M8
wave.f54	WAVE Record 11 kHz 16bit	1.20	adiStartRecording	encoding = ADI_ENCODE_PCM11M16

The following table provides information (filter length, adaptation times, and MIPS consumption) for echo cancellation DPFs:

DSP File	Filter Length (ms)	Adapt Time (ms)	MIPS
echo.f54	2	100	2.85
echo.f54	2	200	2.78
echo.f54	2	400	2.78
echo.f54	2	800	2.78
echo.f54	4	100	3.13
echo.f54	4	200	2.98
echo.f54	4	400	2.91
echo.f54	4	800	2.91
echo.f54	6	100	3.41
echo.f54	6	200	3.19
echo.f54	6	400	3.04
echo.f54	6	800	3.04
echo.f54	8	100	3.69
echo.f54	8	200	3.39
echo.f54	8	400	3.24
echo.f54	8	800	3.17
echo.f54	10	100	3.97
echo.f54	10	200	3.60
echo.f54	10	400	3.37
echo.f54	10	800	3.30
echo.f54	16	100	4.80
echo.f54	16	200	4.21
echo.f54	16	400	3.91
echo.f54	16	800	3.76
echo.f54	20	100	5.36
echo.f54	20	200	4.62
echo.f54	20	400	4.25
echo.f54	20	800	4.03