Agenda

Support for Support for Specialized Specialized Hardware Devices Hardware Devices within the SCA within the SCA CoreFrameworkCoreFramework

SBC WorkshopSBC Workshop15 September 200415 September 2004

AgendaAgenda

• Context.

• Modem architecture models.

• Waveform – modem portability.

• Dedicated modem resource model.

• Extending the CoreFramework into the modem.

• Dealing with non-CORBA enabled devices.

• Need for a hardware abstraction layer.

• Pooled modem resource model.

• Shared modem resource model.

• Supporting advanced waveforms.

• Summary.

• Context.










• Summary.

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

ContextContext

• Techniques developed during the building of an SCA2.2 platform on top of a high-performance SDR modem engine.

• Goals of this activity:• Build an SDR platform that encourages and supports

the design of portable waveforms.

• Minimize effort of porting existing waveforms to the platform.

• Produce re-usable modem platform components (by designing for a wide range of modem architectures).

• Lessons learned – limitations of SCA2.2 leading to change proposals for future specifications.

• Techniques developed during the building of an SCA2.2 platform on top of a high-performance SDR modem engine.

• Goals of this activity:• Build an SDR platform that encourages and supports

the design of portable waveforms.

• Minimize effort of porting existing waveforms to the platform.

• Produce re-usable modem platform components (by designing for a wide range of modem architectures).

• Lessons learned – limitations of SCA2.2 leading to change proposals for future specifications.

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Modem Architectures: Device SelectionModem Architectures: Device Selection

Goal: Maximize Waveform Portability.

• General Purpose Processors (GPPs) are used wherever possible.

• Maximize reconfigureability of application.

• Maximize portability of software components.

• Digital Signal Processors (DSPs) are used where size and power constraints limit the use of GPPs.

• Floating-point preferred to fixed.

• FPGAs are used wherever DSPs do not meet performance requirements .

• ASICs are used as little as possible.• i.e. Never

Goal: Maximize Waveform Portability.

• General Purpose Processors (GPPs) are used wherever possible.

• Maximize reconfigureability of application.

• Maximize portability of software components.

• Digital Signal Processors (DSPs) are used where size and power constraints limit the use of GPPs.

• Floating-point preferred to fixed.

• FPGAs are used wherever DSPs do not meet performance requirements .

• ASICs are used as little as possible.• i.e. Never

Modem Architectures: InterconnectionModem Architectures: Interconnection

• The topology in which the selected processing devices are interconnected determines redundancy and reconfigurability properties of the modem platform.

• SCA makes possible several different architectures, but they generally break into 3 models:

• Dedicated Modem Resources.

• Pooled Modem Resources.

• Shared Modem Resources.

• In addition, a number of advanced waveform applications (i.e. beyond 2 GHz) require non-traditional architectures for waveform support.

• Array Processing.

• Shared Resource Applications.

We will consider each of these in detail as we proceed.

• The topology in which the selected processing devices are interconnected determines redundancy and reconfigurability properties of the modem platform.

• SCA makes possible several different architectures, but they generally break into 3 models:

• Dedicated Modem Resources.

• Pooled Modem Resources.

• Shared Modem Resources.

• In addition, a number of advanced waveform applications (i.e. beyond 2 GHz) require non-traditional architectures for waveform support.

• Array Processing.

• Shared Resource Applications.

We will consider each of these in detail as we proceed.

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Waveform – Modem Portability:SCA view of the ModemWaveform – Modem Portability:SCA view of the Modem

• SCA treats the modem as just one of many entities within a waveform.

• SCA treats the modem as just one of many entities within a waveform.

• Much of the literature tends to regard the modem as a single component within a radio.

• Much of the literature tends to regard the modem as a single component within a radio.

Waveform – Modem PortabilityWaveform – Modem Portability

• But, SCA does not constrain modem architecture:• Designers are free to use any combination of GPPs, DSPs,

FPGAs and interconnects that meets system requirements and constraints.

• Different architectures are likely to be fundamentally incompatible.

• One way of dealing with this is to abstract away the architecture of the modem (i.e. define a ModemDevice) .

• But with this approach, waveform portability is limited to the modem boundary.

• The waveform ModemDevice that must run on the ModemDevice will have to be re-written for each modem architecture.

• Yes, the rest of the waveform will be portable but only to whatever interface ModemDevice exports.

• But, SCA does not constrain modem architecture:• Designers are free to use any combination of GPPs, DSPs,

FPGAs and interconnects that meets system requirements and constraints.

• Different architectures are likely to be fundamentally incompatible.

• One way of dealing with this is to abstract away the architecture of the modem (i.e. define a ModemDevice) .

• But with this approach, waveform portability is limited to the modem boundary.

• The waveform ModemDevice that must run on the ModemDevice will have to be re-written for each modem architecture.

• Yes, the rest of the waveform will be portable but only to whatever interface ModemDevice exports.

AgendaAgenda

• Context.









• Array processing.

• Summary.

• Context.









• Array processing.

• Summary.

Dedicate Resource Model Example:A single channel modem

Dedicate Resource Model Example:A single channel modem

RF XCVR

Modem Channel 1

A/Ds

and

D/As

FPGA

DSP(Optional)

ModemChannel

GPP(Optional)

SCA LogicalDevices/Adaptors

Front-End Control

Waveform Setup and Control

ModemChannel

GPP

Scalability Achieved in a Dedicated Resource Model by Adding Additional "Modem Channels"

Scalability Achieved in a Dedicated Resource Model by Adding Additional "Modem Channels"

RF XCVR

Modem Channel M

A/Ds

and

D/As

FPGAEqualization

DDC/DUC

Hop Sync./RFControl

TDMA FrameSync

TDMA Burst Format

DSPMod/Demod

RS Encode/ Decode

ModemChannel

GPP


Front-End Control


RF XCVR

Modem Channel 3

A/Ds

and

D/As

FPGAEqualization

DDC/DUC

Hop Sync./RFControl

TDMA FrameSync

TDMA Burst Format

DSPMod/Demod

RS Encode/ Decode

ModemChannel

GPP


Front-End Control


RF XCVR

Modem Channel 2

A/Ds

and

D/As

FPGAEqualization

DDC/DUC

Hop Sync./RFControl

TDMA FrameSync

TDMA Burst Format

DSPMod/Demod

RS Encode/ Decode

ModemChannel

GPP


Front-End Control


`

Black SideHost GPP(Optional)

Link Processing

Network Processing

INFOSECProcessing(TRANSEC

andCOMSEC)

Red Side Payload Data Processing

(GPP + Audio)

RF XCVR

Modem Channel 1

A/Ds

and

D/As

FPGA

DSP(Optional)

ModemChannel

GPP(Optional)


Front-End Control


ModemChannel

GPP

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Extending the CF Inside the ModemExtending the CF Inside the Modem

• We are better off exposing all the processing elements inside the modem to the CF as Logical Devices.

• Allows for a common application interface for functions such as set-up, tear-down, connection and control of waveform resources inside the modem at a component level.

• Promotes the ability to drop standard COTS building blocks directly onto devices within the modem, which provides portability and re-use benefits.

• We are better off exposing all the processing elements inside the modem to the CF as Logical Devices.

• Allows for a common application interface for functions such as set-up, tear-down, connection and control of waveform resources inside the modem at a component level.

• Promotes the ability to drop standard COTS building blocks directly onto devices within the modem, which provides portability and re-use benefits.

Components Required in the Example Dedicated Resource Model

Components Required in the Example Dedicated Resource Model

GPP Logical device

DSP Logical Device

FPGA Logical Device

Device Manager

GPP Logical device

DSP Logical Device

FPGA Logical Device

Device Manager

Per Modem ChannelPer Modem Channel

RF XCVR

Modem Channel 1

A/Ds

and

D/As

FPGA

DSP(Optional)

ModemChannel

GPP(Optional)


Front-End Control


ModemChannel

GPP

Limits of PortabilityLimits of Portability

• While the modem building blocks are in theory re-usable, they still have to be hooked together in a way which is ultimately architecture specific.

Contention: There is no such thing as a completely portable (useful, real-world) SCA (2.2)

Waveform Application.

• However porting effort can be minimized.

• While the modem building blocks are in theory re-usable, they still have to be hooked together in a way which is ultimately architecture specific.

Contention: There is no such thing as a completely portable (useful, real-world) SCA (2.2)

Waveform Application.

• However porting effort can be minimized.

Minimizing the Porting EffortMinimizing the Porting Effort

• In the best case we will avoid the need to write/modify anything that needs compilation.

• In order to achieve this we need to do two things:

• Define a standard method for interfacing CORBA waveform components to waveform components running on non-CORBA enabled devices. (Typically control flows).

• Define a standard way of interconnecting components running on non-CORBA enabled devices (Data flows).

• In the best case we will avoid the need to write/modify anything that needs compilation.

• In order to achieve this we need to do two things:

• Define a standard method for interfacing CORBA waveform components to waveform components running on non-CORBA enabled devices. (Typically control flows).

• Define a standard way of interconnecting components running on non-CORBA enabled devices (Data flows).

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Non-CORBA Enabled Devices (NCEDs)Non-CORBA Enabled Devices (NCEDs)

• FPGAs and DSPs (for now).

• Need to provide a CF::LoadableDevice running on a CORBA enabled GPP which has access to the physical device.

• FPGAs and DSPs (for now).

• Need to provide a CF::LoadableDevice running on a CORBA enabled GPP which has access to the physical device.

CORBA Enabled GPP

Physical FPGA/DSP

LoadableDevice

DevDrv

BinaryImage

• However, having done so, how is this Image configured and controlled by the waveform application, and how is data flow to and from it set up?

• However, having done so, how is this Image configured and controlled by the waveform application, and how is data flow to and from it set up?

• This enables a waveform application to drop a Binary Image (FPGA Core or DSP Code) onto the device.

• This enables a waveform application to drop a Binary Image (FPGA Core or DSP Code) onto the device.

CORBA Enabled GPP

Physical FPGA/DSP

BinaryImage

LoadableDevice

DevDrv

Binary Image ProxiesBinary Image Proxies

• But, to control the Image, the proxy needs hardware level access the FPGA. How can we ensure this?

• But, to control the Image, the proxy needs hardware level access the FPGA. How can we ensure this?

Proxy

Image API

Rest of waveform

ExecutableDevice

DevDrv

• We need to provide a CORBA interface via which we can setup and control the Binary Image.

• Create a proxy, with a suitable (component specific) provides port interface, to manage the Binary Image.

• We need to provide a CORBA interface via which we can setup and control the Binary Image.

• Create a proxy, with a suitable (component specific) provides port interface, to manage the Binary Image.

• Extend the LD to be an ExecutableDevice.

• Specify a collocation requirement between proxy and Image.

• Binary loads go to the physical device.

• Executable loads go to the collocated GPP.

• Extend the LD to be an ExecutableDevice.

• Specify a collocation requirement between proxy and Image.

• Binary loads go to the physical device.

• Executable loads go to the collocated GPP.

ExecutableDevice DelegationExecutableDevice Delegation

We may have several such “virtual” ExecutableDevices but only one physical GPP.

How do we manage its capacities?

We may have several such “virtual” ExecutableDevices but only one physical GPP.

How do we manage its capacities?

FPGA

CORBA Enabled GPP

DSP

FPGAExecutable

Device

FPGA API

DSPExecutable

Device

DSP API

Binary Loads

Binary Loads

GPPExecutable

Device

Delegated Executes& Capacities

We Delegate!

Sample Waveform Instantiation on the example Dedicated Resource Architecture

Sample Waveform Instantiation on the example Dedicated Resource Architecture

Payload Data

Out

XYZDemodulator

(Demod)

AssemblyController

DigitalDownconverter

(DDC)

Control

Control

Intermediate Data

(High Bandwidth requirement)

Digitized RF In

Capacity Allocation and Component DeploymentCapacity Allocation and Component Deployment

Question: How do you guarantee that the AppFactory selects an FPGA and DSP that have the correct type of direct connection?

FPGA

CORBA Enabled Processor(s)

DSP

FPGALogicalDevice

FPGA API

DSPLogicalDevice

DSP API

Direct Connection

AssemblyController

Payload Data

Out

DemodulatorProxy

Demod API

COTSDemodImage

Intermediate DataDigitize

d

RF In

DDCProxy

DDC API

COTSDDC Core

The Problem with Allocating Capacity to Support Direct Connections in a Dedicated Resource Architecture

The Problem with Allocating Capacity to Support Direct Connections in a Dedicated Resource Architecture

How do you guarantee that the AppFactory selects two devices with the correct type of direct connection?

• Force the selection of specific processing devices using deviceAssignments on ApplicationFactory::Create().

• Try all valid assignments (higher level management layer required) .

• Offline (during porting) pre-determination and testing of valid assignments.

• Require that both devices have the same value for a particular property.

• For example Slot_ID.

• Not supported in SCA 2.2!

• Provide a Logical Device that associates each of the valid FPGA and DSP pairs into a new Logical Device.

How do you guarantee that the AppFactory selects two devices with the correct type of direct connection?

• Force the selection of specific processing devices using deviceAssignments on ApplicationFactory::Create().

• Try all valid assignments (higher level management layer required) .

• Offline (during porting) pre-determination and testing of valid assignments.

• Require that both devices have the same value for a particular property.

• For example Slot_ID.

• Not supported in SCA 2.2!

• Provide a Logical Device that associates each of the valid FPGA and DSP pairs into a new Logical Device.

“Cumulative” Logical Device“Cumulative” Logical Device

FPGALogicalDevice

DSPLogicalDevice

CumulativeLogicalDevice

Direct ConnectionFPGA DSP

FPGA API DSP API

Deployed Waveform Components Using the "Cumulative" Logical Device

Deployed Waveform Components Using the "Cumulative" Logical Device

ModemWaveform Setup and Control

FPGA DSP

GPP

CORBA Bus

RFTransceiver

and

Converters

Front-End Control

DDCImage

DemodImage

ModemDevice

ManagerFPGALogicalDeviceFPGAAPI

DSPLogicalDeviceDSPAPI GPP

LogicalDevice

DDCProxy

FPGAAPI

DemodProxy

DSPAPI


To Assembl

y Controll

er

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

The Need for Hardware AbstractionThe Need for Hardware Abstraction

Have we achieved portability of the waveform components for NCEDs?

Have we achieved portability of the waveform components for NCEDs?

No:

• The mechanism via which a proxy communicates with its Binary Images is platform specific.

• The interface between a Binary Image and a physical communication link is platform specific.

No:

• The mechanism via which a proxy communicates with its Binary Images is platform specific.

• The interface between a Binary Image and a physical communication link is platform specific.

We need to abstract and standardize these interactions.

We need to abstract and standardize these interactions.

Use of Hardware Abstraction Layer (HAL) in Sample DeploymentUse of Hardware Abstraction Layer (HAL) in Sample Deployment

FPGA


DSP

FPGALogicalDevice

FPGA API

DSPLogicalDevice

DSP API

Payload Data

Out

Digitized

RF In

DemodulatorProxy

Demod API

AssemblyController

DDCProxy

DDC API

Direct Connection

Intermediate DataCOTS

DDC CoreCOTS

Demod Image

HALHAL

HAL HAL

HA

L

HA

L

HAL+ HAL+

Hardware Abstraction Layer (HAL) RequirementsHardware Abstraction Layer (HAL) Requirements

• Define a model for NCE data communications.

• HAL for GPPs and DSPs:• Define a standard API.

• Abstracts hardware register/memory access.

• Abstracts loading and unloading of NCEDs.

• HAL for FPGAs:• Define standard set of signals for interfacing to

communication transport mediums.

• Define standard registers for managing FPGA Images.

• Define a model for NCE data communications.

• HAL for GPPs and DSPs:• Define a standard API.

• Abstracts hardware register/memory access.

• Abstracts loading and unloading of NCEDs.

• HAL for FPGAs:• Define standard set of signals for interfacing to

communication transport mediums.

• Define standard registers for managing FPGA Images.

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Pooled Resource Modem ArchitecturePooled Resource Modem Architecture

RapidIOSwitched

CommunicationsFabric

FPGA

FPGA

FPGALogicalDevice

FPGALogicalDevice

DSP

GPPw/o

FabricPort

GPPwith

FabricPort

SCA "LogicalSoftware Bus"

RF Front End (M of M)

RF Front End (1 of M)

RFLogicalDevice

DSP

RFLogicalDevice

DSPLogicalDevice

DSPLogicalDevice

Non-CORBAEnabledDevices

Sample Waveform Instantiation on a Pooled Resource ArchitectureSample Waveform Instantiation on a Pooled Resource Architecture

Payload Data

Out

XYZDemodulator

(Demod)

AssemblyController


(DDC)

Control Control

Digitized RF In

Intermediate Data


Sample Waveform Instantiation on a Pooled Resource ArchitectureSample Waveform Instantiation on a Pooled Resource Architecture

Payload Data

Out

XYZDemodulator

(Demod)

AssemblyController


(DDC)

Control Control

Digitized RF In

Device that loadsthe Demod

Device that loadsthe DDC

Intermediate Data


CollocationOptimization

Converter Converter

Logical Channel Support Through Switched FabricLogical Channel Support Through Switched Fabric

A logical channel is a software representation of a physical channel

• Multiple logical channels occupy a single physical channel.

• Composite data rate of the supported logical channels must be sufficient to support.

• The latency and determinism requirements of the application.

• Any overhead required for the channels.

A logical channel is a software representation of a physical channel

• Multiple logical channels occupy a single physical channel.

• Composite data rate of the supported logical channels must be sufficient to support.

• The latency and determinism requirements of the application.

• Any overhead required for the channels.

Processing Element 1 (e.g. FPGA) Processing Element 1 (e.g. GPP+)

SoftwareComponent 1

SoftwareComponent 2

SoftwareComponent 3

SoftwareComponent 4

Physical Channel (e.g. Serial RapidIO)

Logical Channel 1

Logical Channel 2

Device Support for Logical ChannelsDevice Support for Logical Channels

• Each Device that has access to the Switched Fabric needs to support multiple Logical Channel EndPoints or “FabricPorts”.

• Device delegates each Switched Fabric connection to a free FabricPort.

• Each Device that has access to the Switched Fabric needs to support multiple Logical Channel EndPoints or “FabricPorts”.

• Device delegates each Switched Fabric connection to a free FabricPort.

Device FabricPort

1 *

+Owner

<<Interface>>PortProvider

<<Interface>>Port

<<Interface>>SimplePacket

Sample Waveform Deployment in Pooled Resource ModelSample Waveform Deployment in Pooled Resource Model

FPGA


DSP

FPGAFabricPort

DSPFabricPort

Payload Data

Out

Digitized

RF In

DemodulatorProxy

Demod API

AssemblyController

DDCProxy

DDC API

COTSDDC Core

COTSDemod Image

HALHAL

HAL HAL

HA

LSwitchedFabri

c

SwitchedFabric

Intermediate Data

HA

L

Address Discovery

HAL+ HAL+Fabric

EndPoint Setup

Other Pooled Resource Model Considerations: RedundancyOther Pooled Resource Model Considerations: Redundancy

Support for redundant fabric may be required to eliminate fabric as single point of failure.

• May require FabricPort is mirrored on both fabrics.

Support for redundant fabric may be required to eliminate fabric as single point of failure.

• May require FabricPort is mirrored on both fabrics.

Device Device Device

Redundant Fabric

Redundant Fabric

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Shared Resource Model Shared Resource Model

• We may wish to optimize hardware resource utilization by sharing processing devices between waveform applications.

• Operating Environment supporting resource partitioning:

• GPP: • Use a secure O/S (e.g. DO-178B Certified).

• FPGA:• Requires 3 key technologies:

• Partial Reconfiguration.

• Re-locatable bitstreams.

• Support for channelized I/O.

• These technologies are often device dependent.

• Tools are maturing.

• We may wish to optimize hardware resource utilization by sharing processing devices between waveform applications.

• Operating Environment supporting resource partitioning:

• GPP: • Use a secure O/S (e.g. DO-178B Certified).

• FPGA:• Requires 3 key technologies:

• Partial Reconfiguration.

• Re-locatable bitstreams.

• Support for channelized I/O.

• These technologies are often device dependent.

• Tools are maturing.

Other Considerations for the Shared Resource Model: Redundancy

Other Considerations for the Shared Resource Model: Redundancy• With application resources from multiple

waveforms operating on a single processor, if that processor goes down, it takes all of the supported waveforms with it.

• May require a redundant copy of each waveform operating on the platform.

• Typical paradigm employed in commercial telco for 5 nines performance.

• Domain profile must be tailored to accommodate.

• With application resources from multiple waveforms operating on a single processor, if that processor goes down, it takes all of the supported waveforms with it.

• May require a redundant copy of each waveform operating on the platform.

• Typical paradigm employed in commercial telco for 5 nines performance.

• Domain profile must be tailored to accommodate.

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

Supporting Advanced WaveformsSupporting Advanced Waveforms

Applications such Advanced SATCOM may require special techniques such as:

• Array Processing.• Required when the processing requirements

of an application resource exceed the capacity of a single processing device.

• Shared Application Resource.• Required when a front end application

resource is shared across multiple back end waveform applications.

• Especially troublesome when backend resources must be dynamically loaded.

Applications such Advanced SATCOM may require special techniques such as:

• Array Processing.• Required when the processing requirements

of an application resource exceed the capacity of a single processing device.

• Shared Application Resource.• Required when a front end application

resource is shared across multiple back end waveform applications.

• Especially troublesome when backend resources must be dynamically loaded.

Cumulative Logical Device Supporting Array ProcessingCumulative Logical Device Supporting Array Processing

FPGALogical

Device 1

FPGALogical

Device N


Direct ConnectionFPGA 1 FPGA N

FPGA API FPGA API

Shared Application ResourceShared Application Resource

Digital Transceiver Subsystem

Channel Processing: Channel 1

Uplink ModemProcessing

ModulationSpectral Shaping

ChannelizationProcessing

andModem

Preprocessing

A/D and D/AConverters(May be in RFTransceiver)

Digital AGC

Resampling

Channel Equalization/Pre-emphsais

TDM CarrierRecoveryTDM Symbol RateRecoveryTDM DemodulationTDM Demultiplex

TDMA BurstProcessing

RF XCVR

DigitalBaseband

ChannelControl

Link, Network,and SecurityApplicationProcessing

Transceiver ControlProcessing

Transceiver Control

Codec ProcessingFEC Coding/ DecodingPacket FramingInterleavingDeinterleaving

IF Signal

Channel Processing: Channel M

Uplink ModemProcessing

ModulationSpectral Shaping

DigitalBaseband

ChannelControl

Codec ProcessingFEC Coding/ DecodingPacket FramingInterleavingDeinterleaving

Payload Data

Payload Data

RF Control

Control Data

Supporting a Shared Application Resource with the SCASupporting a Shared Application Resource with the SCA

• A shared application resource, such as a channelizer, is instantiated as a separate application.

• This application encapsulates all common front end functions.

• This resource registers with the naming service.

• It provides “channels” to which external application components may attach.

• Each channel acts as a front end resource for a backend waveform application.

• Waveform channels that need this shared resource attach to it upon instantiation.

• The shared resource application manages channel availability.

• The shared application resource will only allow itself to be torn down if no waveform application is using it.

• Behaves a bit like a dynamically created “device”.

• A shared application resource, such as a channelizer, is instantiated as a separate application.

• This application encapsulates all common front end functions.

• This resource registers with the naming service.

• It provides “channels” to which external application components may attach.

• Each channel acts as a front end resource for a backend waveform application.

• Waveform channels that need this shared resource attach to it upon instantiation.

• The shared resource application manages channel availability.

• The shared application resource will only allow itself to be torn down if no waveform application is using it.

• Behaves a bit like a dynamically created “device”.

Example: 4 Port Satellite TerminalExample: 4 Port Satellite Terminal

TDM Processing as aShared Application withCumulative FPGA DeviceSupporting 2 or More FPGAs

RFXCVR

QPSKDemod

FEC(Rate 1/2)

Demux

Channel 1Processing

Channel 2Processing

Channel 3Processing

Channel 4Processing

LinkNetwork

Processing

TDMABurst

Processor

UplinkTimeslot

Mod 1

UplinkTimeslot

Mod 2

UplinkTimeslot

Mod 3

UplinkTimeslot

Mod 4

UplinkTimeslot

FEC 1

UplinkTimeslot

FEC 2

UplinkTimeslot

FEC 3

UplinkTimeslot

FEC 4

Shared Application

DSP Processing(1 per Channel)

AgendaAgenda

• Context.










• Summary.

• Context.










• Summary.

SummarySummary

• With careful design, the SCA Core Framework can support a wide variety of modem platform architectures.

• Dedicated Resources.

• Pooled Resources.

• Shared Resources.

• Combinations of the above.

• Such support can be provided in a way that minimizes waveform porting effort while leveraging high-performance features of the platform.

• Support for advanced waveforms may require both array processing and shared resource processing, both of which can be accommodated by the SCA.

• With careful design, the SCA Core Framework can support a wide variety of modem platform architectures.

• Dedicated Resources.

• Pooled Resources.

• Shared Resources.

• Combinations of the above.

• Such support can be provided in a way that minimizes waveform porting effort while leveraging high-performance features of the platform.

• Support for advanced waveforms may require both array processing and shared resource processing, both of which can be accommodated by the SCA.

Documents

Agenda