G.PAK™ Framework

Throughout the document, reference is made to G.PAK DSPs, a G.PAK DSP is considered to be an individual core on a DSP chip.

G.PAK – G.PAK BASED TURNKEY SOLUTIONS

G.PAK™ integrates the building blocks that are required in voice-over-packet and voice-over-IP systems into a turnkey solution. G.PAK is a scalable, build time configurable voice-over-packet DSP software application that runs on the TI’s TMS320C5000 and TMS320C6000 families of DSPs.

G.PAK provides all of the DSP components necessary in a voice-over-packet system and provides an application interface to allow easy integration into a user’s application. It includes one or more algorithms like conferencing, vocoders, echo cancellation, tone detection, etc. G.PAK runs the entire DSP and interfaces with peripherals such as the serial port.

G.PAK is run time configurable allowing channels to be setup for individualized processing. Channel setup (identification of input and output ports, vocoders, and voice algorithms), conference setup, and teardown operations are performed at run time. G.PAK DSPs interface to a host control processor.

Adaptive Digital’s G.PAK DSP software solutions address the need for high-density, VoIP, and traditional telecommunications applications. Adaptive Digital provides pre-built G.PAK software images for telephony applications such as VoIP gateway, conferencing, and transcoding. These solutions include host API software to simplify the process of integrating a host processor with the DSP applications. G.PAK can easily be customized to include only the necessary algorithms, channel configurations, and interfaces of a particular application’s requirements. If G.PAK’s built-in flexibility is not enough, source code can be licensed.

BUILD TIME CONFIGURABILITY

In order to maximize channel density, G.PAK is configured specifically for the user’s application. No extra resources (MIPS and Memory) are wasted on algorithms or port configurations that are not required in the users application. Similarly, this approach allows the designer to select a more cost effective DSP solution.

RUNTIME CONFIGURABILITY

Each channel is configured at runtime to interface between the appropriate port types. Port types include PCM, Packet, and Circuit Data. The most common channel configuration is PCM on one side of the channel and packet data on the other side of the channel (a PCM to Packet channel.) Other configurations include PCM to PCM, Packet to Packet, and Circuit Data. The result is true universal port operation.

ECHO CANCELLATION

There are two types of echo cancellers used in a G.PAK system; PCM and Packet. The PCM echo canceller is used when the near end data is from a serial port within the DSP and the far end data is from another serial port or from a packet provided by the host processor. The packet echo canceller is used when the near end data is from a packet provided by the host processor and the far end data is from a serial port within the DSP or another packet provided by the host processor. Each type can be uniquely configured and typically require different settings. The tail length and number of tails is often greater on a packet network than for local PCM data due to network delays and less predictable communication paths. Characteristics of the voice enhancement algorithms are selected at build time and can be modified at run time.

FRAME SIZES/ PACKET TYPES

G.PAK can be configured at build time to support processing frame sizes of 8, 20, 40, 80, 160, and 240 samples. Each channel can be configured at run time to use any of the frame sizes selected at build time. G.PAK can be configured at build time to format Voice, Silence, and Tone packets for either RTP or AAL2 type payloads.

INPUT/OUTPUT

The DSP’s multi channel serial ports are used to read and write 8 KHz sampled speech data. From 1 to 3 serial streams can be supported depending on the DSP type and from 1 to 128 time slots per stream can be used. The format of the data can be configured as u-Law, A-Law, or linear. Port characteristics such as transmit and receive sync and clock polarities are configured at build time.Channel (slot) selections are configured at run time for flexibility in assigning resources in multiple DSP applications. Dynamic transmit enabling is used to allow multiple DSPs to share the same stream

In a PCM to Packet system with multiple G.PAK DSPs, the control processor controls the G.PAK DSPs via a local bus and the DSPs’ host port interfaces (HPI). The control processor also exchanges packet information with the DSPs via the same interface. The control processor uses the G.PAK ANSI “C” API software, which runs on the control processor, to control the G.PAK DSPs and also to exchange packet information. By providing this level of abstraction, the designer does not need to be bothered with the details of inter-processor messaging.

Channel Type

Each G.PAK DSP supports a fixed number of channels. The number of channels available in a DSP is dependent on the DSP type and the capabilities selected at build time.

There are several types of channels; TDM to Packet, PCM to TDM, Packet to Packet, AAL2, Circuit Data, TDM to Conference, Packet to Conference, and Conference Composite. Each channel in a DSP can be dynamically setup as any type at run time. Frame sizes, audio codec types, and tone detection types are selected when a channel is setup from capabilities configured at build time

TDM to packet channel types provide a linkage between analog telephones (TDM data) and digital telephones (packet data). They are full duplex channels used to convert TDM data to/from packet data. This type of channel is typically used in a voice-over-packet application.

TDM to Packet TDM to packet channel types provide a linkage between analog telephones (TDM data) and digital telephones (packet data). They are full duplex channels used to convert TDM data to/from packet data. This type of channel is typically used in a voice-over-packet application.

TDM to packet processing. The TDM to packet processing thread inputs 8 kHz PCM samples from a TDM time slot and buffers as many samples as needed to build an output frame. When enough samples are buffered, the PCM input data is optionally passed through the PCM echo canceller, automatic gain control (AGC), the tone detector (TD) and the voice activity detector. The channel’s encoder type identifies which vocoder will be used. The vocoder output is formatted and packed into the vocoder’s packet payload and sent to the host for transmission. Packet to TDM processing. The packet to TDM processing thread reads a packet from the host control processor and generates PCM samples according to the received packet type.

TDM to TDM channel types provide a linkage between two analog phones. They are full duplex channels used to transfer PCM data between TDM slots. These channels are typically used for PCM echo cancellation or time slot interchanging. They are implemented as two functions (forward and reverse channels) within a single thread of processing. Each function inputs 8 kHz PCM samples from a serial port time slot and buffers as many samples as needed to perform echo cancellation. When enough samples

are buffered, the PCM input data is passed through the echo canceller and again buffered for output. The buffered output samples are then delivered to a TDM slot.

Both echo canceller algorithms are independent options selectable at channel setup.

Packet to Packet type channels provide conversion of packet payload data from one type or frame size to another for a full duplex communication path. Packet payload data is read from the control processor and decoded to 8 KHz samples. The samples are then processed, encoded, and the modified packet is written to the control processor. This same process occurs for two packet paths (A to A’ and B to B’). Each packet can use any configured frame size and codec type. VAD and Tone processing can optionally be performed on the decoded data. G.168 can optionally be used for the A to A’ path and/or B to B’ path. This type of channel is typically used in a gateway application to perform rate conversion, codec type conversion, or echo cancellation.

Circuit Data type channels have 2 threads of processing. The first thread inputs a number of contiguous slots (8 KHz samples) from a serial port, multiplexes the samples into a single packet payload, and writes the packet payload to the control processor. The second thread reads a packet payload from the control processor, demultiplexes the samples from the payload, and outputs the samples to a number of contiguous slots on a serial port. Both threads multiplex or demultiplex the same number of samples (Mux Factor). The frame size used by both channels is dependent upon the Mux Factor. This type of channel is typically used for AAL2 Circuit Data packets.

TDM Conference Channel types are used to allow analog telephones to join a conferencing call. These channels invoke two functions within a single processing thread. The conference input function inputs 8 kHz PCM samples from a TDM slot and buffers as many samples as needed for a frame used by the conference. When enough samples are buffered, the PCM data is optionally passed through PCM echo cancellation and automatic gain control (AGC) algorithms before being passed to the Conferencing algorithm for use as one of the conference inputs. The conference output function buffers the conference’s output data for the channel. Each channel has its own conference output data that removes a speaker’s voice from his own output. The buffered samples are then output to a TDM slot. The pcm canceller and automatic gain control algorithms are independent options selectable at channel setup.

Packet Conference Channel types allow digital telephones to join a conferencing call. These channels invoke two functions within a single thread of processing. The conference input function reads a packet from the host control processor and generates PCM samples according to the received packet type. If a silence packet is received, comfort noise is generated. If a tone packet is received, the specified tone is generated.

If an audio packet is received, it is decoded according to the input packet codec type. The generated PCM samples are then optionally passed through the packet echo canceller and automatic gain control algorithms before being passed to the Conferencing algorithm for use as one of the conference inputs.

Conference Output

The conference output function buffers the normalized sum of all conference member’s input data minus the channel’s own input data. The samples are buffered until there are enough samples to build an output frame. When enough samples are buffered, the samples are optionally passed through the tone detector (TD) and the voice activity detector (VAD).

G.PAK notifies the host at the start and end of each tone. If tone relay is enabled, tone packets are generated for each frame until the tone ends; an end of tone packet is generated when the tone stops. Voice activity detection is optionally performed when no tone is detected. A silence packet is generated when VAD does not detect voice activity; Voice encoding is performed whenever tone or silence packets are NOT generated. The channel’s encoder type identifies which vocoder will be used. The vocoder output is formatted and packed into the vocoder’s packet payload and sent to the host for transmission. The packet echo canceller, tone detection, tone relay, voice activity detection, and automatic gain control algorithms are independent options selectable at channel setup. Input packets are read and output packets are generated with the same frequency as the conference’s frame size.

Channel Density

The maximum number of channels available with G.PAK is a function of the target DSP type and the features selected at build time. Each G.PAK DSP is configured at build time to ensure that sufficient DSP memory and MIPS exist to support all channels concurrently regardless of the features selected at channel setup.

Control/DSP Interface

G.PAK API functions are provided to allow applications executing on the control processor to control and monitor the G.PAK DSPs. There are APIs to read the system configuration, read and write system parameters, configure the serial ports, setup and tear down channels, read channel status, and read and write packet payloads. All APIs are provided as operating system independent ANSI “C” source code for easy integration into the control processor’s software environment. The physical interface between a G.PAK DSP and a control processor is through the DSP’s Host Port Interface. The G.PAK APIs use the HPI to access DSP memory. Several control processor dependent support functions must be completed by the user. Template functions are provided with the G.PAK APIs. The support functions are used to read and write DSP memory via the HPI, time delay, and optionally provide DSP access mutual exclusion.

Build options

The capabilities of a G.PAK DSP are selected at build time. A DSP software image in the form of an object file is created based on the user’s selections. The software image is loaded into a DSP core’s memory whenever the DSP is powered on. This usually occurs at system startup by a host control processor. The software image can be loaded into multiple DSP cores of the same type DSP having the same serial port I/O characteristics. The software image is not tied to a particular core. Multiple software images can be created, each with its own unique capabilities. Any software image built for a particular type DSP can be loaded into any DSP core of that type having then same serial port I/O characteristics. This can be useful for changing the set of DSP capabilities in a system as the need arises simply by reloading the DSP core with a different software image. The G.PAK APIs executing on the host control processor are independent of a particular software image or DSP core. Every software image presents a common interface to the APIs. The number of channels that can be supported by a DSP core is dependent on the capabilities (options) selected at build time and the amount of memory available on the DSP core. In order to maximize channel density, only necessary options should be selected at build tim