[ieee milcom 2005 - 2005 ieee military communications conference - atlantic city, nj, usa (17-20...

6
INTEGRATING SPECIALIZED HARDWARE TO JTRS/SCA SOFTWARE DEFINED RADIOS James Kulp, Murat Bicer Mercury Computer Systems, Inc Chelmsford, MA ABSTRACT The Joint Tactical Radio System (JTRS) is a family of modular, multi-band, networked software defined radios that are compliant with an international open standard called the Software Communications Architecture (SCA) [1]. In 2004, the JTRS Joint Program Office (JPO) organ- ized an effort to develop a Specialized Hardware Supple- ment (SHS) to the SCA to enable JTRS tactical radios to support high-speed data links and satellite communica- tions (SATCOM). The waveforms for these systems typi- cally operate over 2 GHz. The SHS defines portability re- quirements for the components of these waveforms that target more specialized and resource-constrained envi- ronments commonly represented by digital signal proces- sor (DSP), field programmable gate array (FPGA) and ASIC environments. At the time of the writing of this pa- per, change proposals are under review by JPO to replace the SHS. This paper presents one of these proposals. The Compo- nent Portability Specification [2]. The paper analyzes the principles that this specification is built on to extend the SCA waveform component portability. It examines the three goals the specification intended to achieve. portabil- ity, interoperability and replaceability. The paper con- cludes by articulating the impact of the SHS on existing waveforms and JTR sets. INTRODUCTION The goal of the JTRS program is to replace the existing hardware-intensive radios of the United States military with software-centric communications systems that can be updated with low cost through reprogramming. The JTRS JPO is planning to achieve this objective by building the new software radios compliant to the SCA. The purpose of the SCA is to provide a common standard for waveform development such that waveforms can easily be ported from one radio platform to another. SCA- compliant waveform applications consist of source code and metadata. The waveform metadata is used to describe the properties of each waveform component as well as how these components are assembled to constitute the waveform. The metadata is represented by a set of XML files called the SCA Domain Profile [3]. SCA was designed primarily for radios with CORBA- enabled [4] general purpose processors (GPPs). Unfortu- nately, today's high-bandwidth waveforms have demand- ing processing and power requirements that cannot be met with the state-of-the-art GPPs. Such waveforms can only be executed on radio platforms that employ more special- ized hardware such as FPGAs or DSPs. Acknowledging this problem, JTRS JPO organized a workshop in 2004 to develop the SHS followed by a second workshop in Janu- ary 2005. Proposals have emerged as a result of these workshops, offering solutions to the SHS problem that differ in scope. This paper presents Change Proposal (CP) 289: The Com- ponent Portability Specification (CPS). CPS defines source code portability requirements for waveform components targeting specialized and resource- constrained environments. Through a careful separation of concerns, each SCA waveform component's functionality is isolated from the class of processor used for its imple- mentation. With the help of containers that provide the immediate runtime environment to the component in- stances, waveform components that execute on non-GPP processors can be ported to other processors of the same class. This paper assumes the reader has a basic understanding of the SCA specification and its domain profile. KEY TERMS AND CONCEPTS This section defines the key terms and concepts used throughout the paper to facilitate the discussion. Component: The SCA uses the term "component" in the general sense of any part of the application, infrastructure, environment, or hardware system. The term "resource" is used as the general term for infrastructure or application software modules (i.e. a source of functionality rather than a source of supply or capacity). The CPS uses the term "component" more narrowly, as an independently defined unit offunctionality of an application or waveform, sepa- 1 of 6

Upload: m

Post on 27-Mar-2017

212 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

INTEGRATING SPECIALIZED HARDWARE TOJTRS/SCA SOFTWARE DEFINED RADIOS

James Kulp, Murat BicerMercury Computer Systems, Inc

Chelmsford, MA

ABSTRACT

The Joint Tactical Radio System (JTRS) is a family ofmodular, multi-band, networked software defined radiosthat are compliant with an international open standardcalled the Software Communications Architecture (SCA)[1]. In 2004, the JTRS Joint Program Office (JPO) organ-ized an effort to develop a Specialized Hardware Supple-ment (SHS) to the SCA to enable JTRS tactical radios tosupport high-speed data links and satellite communica-tions (SATCOM). The waveforms for these systems typi-cally operate over 2 GHz. The SHS defines portability re-quirements for the components of these waveforms thattarget more specialized and resource-constrained envi-ronments commonly represented by digital signal proces-sor (DSP), field programmable gate array (FPGA) andASIC environments. At the time of the writing of this pa-per, change proposals are under review by JPO to replacethe SHS.

This paper presents one of these proposals. The Compo-nent Portability Specification [2]. The paper analyzes theprinciples that this specification is built on to extend theSCA waveform component portability. It examines thethree goals the specification intended to achieve. portabil-ity, interoperability and replaceability. The paper con-cludes by articulating the impact of the SHS on existingwaveforms and JTR sets.

INTRODUCTION

The goal of the JTRS program is to replace the existinghardware-intensive radios of the United States militarywith software-centric communications systems that can beupdated with low cost through reprogramming. The JTRSJPO is planning to achieve this objective by building thenew software radios compliant to the SCA.

The purpose of the SCA is to provide a common standardfor waveform development such that waveforms can easilybe ported from one radio platform to another. SCA-compliant waveform applications consist of source codeand metadata. The waveform metadata is used to describethe properties of each waveform component as well ashow these components are assembled to constitute the

waveform. The metadata is represented by a set of XMLfiles called the SCA Domain Profile [3].SCA was designed primarily for radios with CORBA-enabled [4] general purpose processors (GPPs). Unfortu-nately, today's high-bandwidth waveforms have demand-ing processing and power requirements that cannot be metwith the state-of-the-art GPPs. Such waveforms can onlybe executed on radio platforms that employ more special-ized hardware such as FPGAs or DSPs. Acknowledgingthis problem, JTRS JPO organized a workshop in 2004 todevelop the SHS followed by a second workshop in Janu-ary 2005.

Proposals have emerged as a result of these workshops,offering solutions to the SHS problem that differ in scope.This paper presents Change Proposal (CP) 289: The Com-ponent Portability Specification (CPS).

CPS defines source code portability requirements forwaveform components targeting specialized and resource-constrained environments. Through a careful separation ofconcerns, each SCA waveform component's functionalityis isolated from the class of processor used for its imple-mentation. With the help of containers that provide theimmediate runtime environment to the component in-stances, waveform components that execute on non-GPPprocessors can be ported to other processors of the sameclass.

This paper assumes the reader has a basic understanding ofthe SCA specification and its domain profile.

KEY TERMS AND CONCEPTS

This section defines the key terms and concepts usedthroughout the paper to facilitate the discussion.

Component: The SCA uses the term "component" in thegeneral sense of any part of the application, infrastructure,environment, or hardware system. The term "resource" isused as the general term for infrastructure or applicationsoftware modules (i.e. a source of functionality rather thana source of supply or capacity). The CPS uses the term"component" more narrowly, as an independently definedunit offunctionality of an application or waveform, sepa-

1 of 6

Page 2: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

rate from the operating environment or any other infra-structure elements. "Component" applies here equally tounits of functionality implemented for ASICs, FPGAs,DSPs, or GPPs.

Application: CPS uses the term narrowly to designate aconfigured and interconnected set of components as indi-cated by the SCA Assembly (i.e. SAD), but not includingany infrastructure (Core Framework, devices or services).

Class: This term is used to indicate the general category ofthe processing device, container, or component: GPP, Re-source-constrained C-programmable Component (RCC),or RTL-programmable Logic (RPL). A simple DSP canserve as a good example for a RCC. FPGAs and ASICs areexamples for RPLs. The RCC and RPL classes are collec-tively termed the Specialized Hardware Processing (SHP)class.

Container: A container is the immediate runtime envi-ronment in which a component instance executes. Con-tainers provide to component instances the execution envi-ronment, and a standardized set of local ApplicationProgramming Interface (API)-based services. This defini-tion is as used in literature for most component softwaresystems, including the CORBA component model onwhich the SCA was partially and loosely based. In sum-mary, applications consisting of components are executedby instantiating the components for execution in appropri-ate containers executing on processing devices (GPP orSHP). Component source code is authored for a givenclass of container and processing device. Componentsource code is compiled and linked for a specific containerimplementation (e.g. for a specific operating system, com-piler, ORB).

Platform: A platform is a collection of (GPP and SHP)processing devices and associated containers that togethersupport the execution of component-based applications. Inparticular, a set of containers is enabled to communicatewith each other such that components running in differentcontainers can communicate with each other withoutknowledge of the type or class of container housing the"other component". An SCA Core Framework (CF) Do-main Manager manages the platform. The supplier andintegrator of a platform must assemble, install and config-ure the collection of processors, Logical Devices and asso-ciated containers such that they support interoperation ofcomponents. The components (source code, compiledcode, or metadata) have no knowledge of the class of thecontainer or component at the "other end" of inter-component communication.

Figure 1 depicts the simple hierarchy of execution envi-ronment relationships without showing the control infra-structure (core framework elements) or non-programmable

devices. The components shown are, strictly speaking, in-stances of component implementations for componentsindicated in the application's assembly descriptor (SAD).

Platform

Processing Device X

ContainerAComponentinstance 1

Componentinstance2

ContainerBComponentinstance3

Processing Device Y

ContainerCComponentinstance4

Componentinstance5

Componentinstance6

Figure 1. General architecture of platform.

GOALS

The Component Portability Specification is written toachieve the goals listed below. Therefore, the specificnormative sections in the specification should be seen andevaluated against these goals.

Portability: This goal is to make the source code of wave-form components targeting SHP environments to be simi-lar to the level of portability achieved in the core specifica-tion for GPP components. Portability is within the sameclass "like-for-like".

Consistency: SHP components should be treated as con-sistently as possible with GPP components to simplifylearning curves, CF implementations, tools, documenta-tion, metadata, and technology migration.

Replace-ability: Different component implementations,for diferent classes, for the same component interface andfunctionality, should be possible as alternative implemen-tations under the implementation element of the SoftwarePackage Descriptor (SPD), so that the application may bedeployed using any class of processor supported by com-ponent implementations. This enables one deployablewaveform, as defined by one SAD, to target different sce-narios of hardware presence and availability, or to be usedin radios with different hardware configurations, furtherincreasing reusability. Replaceability implies transparencywith respect to other components of the waveform to en-able rapid technology insertion or upgrade.

2 of 6

Page 3: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

Separation of Concerns: Component functionality, andthe role a component plays in an application, should be aseparate concern from how the component is implemented;including for which class of processor the component im-plementation is created. Component implementation au-thorship should be concerned with the class of containerbeing targeted and not the class of other containers thathouse other components that may communicate with it.Writing the container and associated logical device soft-ware to prepare a processor to house components shouldbe separated from waveform component authorship.

Resource Efriciency and Performance: Since SHP exe-cution environments are generally small, lean, and re-source-constrained, the other goals should not compromisethe typical resource efficiency of SHPs. The "portabilitytax" should not be more than necessary. When componentscommunicate within or between SHP containers, the la-tency and throughput characteristics should not be signifi-cantly different than using non-portable approaches.

Minimal Impact to SCA: The above goals are achievedwith design choices that minimize the necessity to changethe SCA Core Specification.

ARCHITECTURAL FOUNDATION

In CPS terminology, the concept of a worker represents theinstantiated code that implements the business logic of acomponent running on a SHP. Each worker is instantiatedwithin a container that provides its execution context.Workers are represented to the SCA CF by generic proxiesthat realize the SCA CF::Resource CORBA interface onbehalf of the worker. Each generic proxy is instantiated bya logical device that represents the SHP hardware device.The generic proxy and the container are provided as a partof the platform and have no knowledge of the worker'sdetails.

Container Behavior: SCA covers the container conceptby referring to "Executable Devices" and "Resource Fac-tories" as places in which software components may beinstantiated and run. The CPS container concept is nar-rower and more precise: it refers to the immediately sur-rounding execution environment that 1) invokes and con-trols the component and 2) provides the local services andAPIs the component invokes during execution. "Contain-ment" means that the component interacts only directlywith the container, and interacts with external entities onlyindirectly, via its container. Containers are sometimesprocesses, sometimes threads, and sometimes use a pool orgroup of threads. These are all implementation variationsthat support the container concept. Containment is logical,not physical, meaning that it may be "optimized away" incases when multiple component implementations are lo-

cated in the same container. Thus containment does notalways imply any overhead. There is no particular rela-tionship between thread, process and container.

The SCA concept of a device is hardware, and the SCAconcept of a Logical Device is a software proxy for hard-ware. Containers exist (execute) on the hardware process-ing device, and thus have a "runs on" relationship withhardware devices, and an "is controlled by" relationshipwith Logical Devices. There can be multiple containers perSCA device, since components deployed on devices mightrequire different execution environment attributes (e.g.security or priority), which would require them to run indifferent containers on the same processing device. TheLogical Device for a processing device must be a GPPsoftware infrastructure module that executes on a GPP. AGPP processing device may host its own Logical Deviceproxy. Since functionality can be flexibly divided betweenthe Logical Device and the container, there is no standardinterface between them for any class. Logically, the SHPcontainer performs functions analogous to GPP containers.The main difference is in the local (inside the container)interfaces between components and containers. These in-terfaces do not use CORBA, and they are more constrainedand simplified than those for GPP components. They arespecialized differently for both RCC and RPL classes.

Component Behavior: SCA components are defined tohave a specific control interface (e.g. CF::Resource) and anumber of port interfaces, and to use local ApplicationEnvironment Profile (AEP) [5] services.

The term "worker" is used for the instantiated SHP com-ponent implementation that runs directly on the SHP de-vices. Since workers do not use CORBA, and SCA appli-cation components for GPPs are required to use CORBA,SHP components are implemented in two parts: the workerand the generic proxy. Generic proxy acts as the bridgebetween the worker and the SCA CF.

SHP component implementations are the functional codeswritten in the source language of the SHP class. The com-piled binary code executes directly on the SHP device in-side the SHP container. Its control interface (controlled viathe generic proxy's implementation of the CF..Resourceinterface) uses a fixed API which is a rough functionalsubset of the Resource interface. CP 289 defines specificAPIs per SHP class.

Worker ports operate according to interfaces defined by apure IDL [6] subset as indicated in the Software Compo-nent Descriptor (SCD), and use a fixed container API tosend and receive interoperable messages whose structure isderived from the IDL. The worker does not know anythingabout any communication mechanisms used on the plat-form or between any containers, or even inside a container.

3 of 6

Page 4: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

It knows only how to interact locally and directly with itscontainer. It does not need or use CORBA.

When multiple workers are collocated in the same con-tainer, the container may arrange for them to communicatedirectly with each other, as an optimization.

The generic proxy is a specialization of the SCA adapterconcept. When the SHP Logical Device is asked to instan-tiate an SHP component, using the load and execute opera-tions, it creates the generic proxy as a local CORBA objectto represent that instantiation in the SHP container on theSHP device.

The generic proxy is responsible for establishing connec-tions with its worker. Since each worker running on theSHP device has its own ports, the per-worker genericproxy implements the CF. .PortSupplier interface, createsCF::Port objects, and implements the connectPort opera-tions for its worker. Since there may be multiple workersbased on a single implementation, or multiple workerswith common port names running on an SHP device, thegeneric proxy also provides the appropriate scope for eachworker's port connectivity.

The generic proxy object has special knowledge and capa-bility to communicate with the SHP container for the pur-pose of loading, creating, controlling and configuring theworkers. Generic proxies hide the mechanisms used tocontrol containers and workers.

Additionally, an optional custom proxy that executes in aGPP container can be used to implement an SHP compo-nent's specific interface, when the generic CF::Resourcebehavior of the generic proxy is insufficient.

Connectivity: CPS states that the contract between theworker and the container combines a data transfer interfaceand a message format. The message format is derivedfrom IDL and is the same for FPGAs and DSPs. CPSmandates some restraints on the IDL and message formatto enhance performance. These restrictions are compatiblewith the "High Performance Enablers for CORBA" [7]specification. The data transfer interface differs betweenFPGAs and DSPs.

For DSPs, the data transfer interface is a pure zero-copy,container-managed-buffers interface using the simplestpossible technique: container supplies pointers to buffers,worker returns a value that indicates which buffers havebeen filled or consumed.

For FPGAs, the interface is Open Core Protocol (OCP)-based [8], since that is the way blocks of reusable IP inFPGAs and ASICs like to be connected to each other. Theworker blocks connect to each other, or to the containersthat manage buffers and deal with transport. Whether the

PCI bus, or a custom serial link, or multiplexed or not, isthe container's business.

CPS puts the burden of creating the message in a standardformat on the worker, to avoid the code bloat of generatingthe equivalent of CORBA stubs and skeletons. CORBAcomponent environments essentially have three parts: theinner code (like the worker), the type-specific generatedcode (stubs and skeletons), and the container code (likeORB and transport). CPS chose to eliminate the middlepiece, the generated code, for reasons of footprint and effi-ciency, since such a simplification did not compromiseportability, but did give freedom to worker authors to op-timize and flatten the message creation code.

Platform Requirements: The SCA defines the interac-tions between components to be IDL-based, but in the caseof non-GPP containers, the interactions should not neces-sarily be CORBA-based. In the GPP environment, aCORBA IDL compiler is used to read IDL and generateCORBA interface artifacts (called "stubs" for the cli-ent/user and "skeletons" for the server/provider). The plat-form must allow IDL-defined messages (i.e. re-quests/replies, invocations, etc.) to flow betweencomponents in different containers. While this requires thecontainer implementations in the platform know how totalk to each other, it does not imply that these mechanisms(middleware or hardware machinery) need to be standard-ized. The SCA requires that CORBA be used within andbetween GPP containers, but does not specify any com-munication machinery or hardware or ORB or transportAPI.

Similarly, CPS does not mandate any inter-container mes-sage format, but mandates only that the containers in aplatform cooperate to deliver and accept messages accord-ing to the local communication interfaces defined for thatclass of container. Messages created in one container(based on an API between component and container) mustbe delivered properly formatted to a component in anyother container. No further mandatory mechanisms areneeded to achieve portability. This is shown in Figure 2,where the black arrows represent the logical communica-tion between components, the lined arrows show where thecomponents actually communicate with their containersvia specific interfaces, and the dotted arrows show howcontainers in the platform communicate with each other toeffect the inter-component communication. The dottedarrows are not relevant to component portability, but rep-resent the required communication inside the platform.

ports end up multicasting, or being local, or put data on a

4 of 6

Page 5: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

Containers talk to containers.Components talk to their containers. Important interface for interop-important interface for portability of erability/plug & play

-._::~'components. APls used by component = ;t of containers (e.g. boards).authors. Protocols/networks/busses.

Communication between components, conveyed by their containers

Figure 2. Simple FM3TR receiver showing containerinteroperability.

RCC SPECIFIC REQUIREMENTS

CPS defines two profiles for RCC (e.g. DSP) environ-ments. The base profile and the optional multi-threadedprofile which is a superset of the base profile. An RCCcontainer implementation may choose to support either thebase profile or both profiles. An RCC worker implementa-tion may be written to either profile. Naturally, workerswritten for the multi-threaded profile can be executed onlyin containers that support this profile.

RPL SPECIFIC REQUIREMENTS

CPS uses OCP as the basis for RPL (e.g. FPGA, ASIC)interface definitions. OCP is an internationally supportedIP core interconnection standard. It is a standard socketarchitecture that defines a communication protocol and ahardware connection scheme for SoC logic blocks. OCPprovides bus, technology and language independencewhile supporting a richness that is optional and can becompiled out if not used by either side of a communica-tion. In other words, OCP is a tool to define a class of in-terfaces. CPS proposes to use this tool to define part of thecontract between worker and container. The RPL interfacerequirements are designed to support partial reconfigura-tion of FPGAs.

The worker control interface is an OCP interface with thecontainer as master and the worker as slave. Each workerhas this single worker control interface, as well as inter-faces for ports and local memory. The RPL worker re-ceives an operation indication to start processing, performsthe operation, and returns. The interface provides configu-ration operations to read or write the worker's configura-tion address space. Containers can interrupt the controloperations.

RPL environments also provide three local system ser-vices: reset services, clock services and local memory ser-vices.

CONCLUSION

In contrast to the discussion of GPP component require-ments in section 3.2 of the SCA, CPS defines portabilityrequirements for waveform components targeting morespecialized and resource-constrained environments typi-cally represented by DSP, FPGA and ASIC environments.Although some DSP environments are rich enough to betreated as general-purpose environments as addressed inthe SCA specification, CPS addresses more limited andmore typical resource-constrained C-programmable envi-ronments typical of DSPs.

Thus, the purpose of CPS is to enable portability require-ments to be placed on such environments in a way consis-tent with, and analogous to, the portability requirementsthat SCA section 3.2 defines. This increases the portabilityof waveforms in general since it increases the functionalityand source code that can be subjected to portability man-dates in procurements. A related purpose of CPS is to fa-cilitate the replacement or migration of components inwaveforms among the different types of processing envi-ronments without affecting the waveform as a whole, orother components in the waveform. This reduces the effortof technology insertion and migration when deploymentrequirements change or new technology emerges: it en-ables multiple compatible, replaceable implementations ofthe same component functionality, targeting either GPPs orSHPs.

5 of 6

Page 6: [IEEE MILCOM 2005 - 2005 IEEE Military Communications Conference - Atlantic City, NJ, USA (17-20 Oct. 2005)] MILCOM 2005 - 2005 IEEE Military Communications Conference - Integrating

REFERENCES

1. Joint Tactical Radio System Joint Program Office, Soft-ware Communications Architecture Specification JTRS-5000SCA V2.2. ], April 3 0, 2004.

2. SCA Extensions Workshop Task Force, ExtensionforComponent Portability for Specialized Hardware Proces-sors to the JTRS Software Communications ArchitectureSpecification - Change Proposal 289, March 17, 2005.

3. Joint Tactical Radio System Joint Program Office, Soft-ware Communications Architecture Specification Appen-dix D - Domain Profile V2.2. 1, April 30, 2004.

4. Object Management Group, Common Object RequestBroker Architecture V3. 0.3, March 2004.http://www.omg.org/cgi-bin/doc?formal/04-03-0 1

5. Joint Tactical Radio System Joint Program Office, Soft-ware Communications Architecture Specification Appen-dix B - Application Environment Profile V2.2. 1, April 3 0,2004.

6. Object Management Group, Common Object RequestBroker Architecture Specification V3. 0.3 Chapter 3 - In-terface Definition Language, March 2004.http://www.omg.org/cgi-bin/doc?formal/04-03-0 1

7. Object Management Group, High Performance En-ablers, June 2005http://www.omg.org/cgi-bin/doc?ptc/05-06-0 1

8. Open Core Protocol - International Partnership, OCPSpecification V2.1, March, 2005

6 of 6