migrating legacy waveforms to the software communications architecture (sca)

Mike Williams and Vince Kovarik

PrismTech

Migrating Legacy Waveforms to the SCA

20th October 2011

Copyright PrismTech 2011

The Software Communications Architecture

The adoption of the SCA as a common software infrastructure for software defined radios continues to grow.

Porting an SCA waveform between two platforms is not necessarily a straightforward process.

Migrating legacy, non-SCA waveforms to an SCA environment presents some additional challenges in making the existing waveform SCA compliant.

2


SCA Waveform Portability

The DreamWaveform implementations would be reusable across multiple radio systems.

No modifications would be necessary to bring the waveform up on another system.

The RealityInitially, SCA waveform implementations were not reusable.

Extensive modifications were required.

There seemed to be no correlation between use of the SCA and portability of the waveform.

3


The Problem…

The architecture and design of a Software Defined Radio has multiple perspectives:

ProcessorsGPP, DSP, FPGA

Design ParadigmsSequential Stack State Machine v. Parallel State Machine

Implementation LanguagesC/C++, HDL, SystemC

Systems EngineeringHardware and software engineering architecture tasks are performed semi-independently of each other.

4


General Waveform and Radio Design Flow 5

analysis Wav eform Dev elopment

Algorithm Development

Functional Block Architecture

Prototype Waveform

Deployment Allocation

Functional Block Achitecture

Hardware Selection

Engineering Prototype

Manufacturing«process»

Form Factor Implementation

Integrated System Testing

Modeling and simulation of core waveform algorithms in MATLAB, SIMULINK, Mathematica, System View, etc.

Allocation of functional waveform components to a processor type: GPP, DSP, FPGA, GPU, etc.

Non-real-time implementation in C/C++ MATLAB, SIMULINK, Mathematica, SystemView, etc.

Grouping of algorithm elements into logical waveform components. Use of UML component modeling techniques and tools.

Make / buy tradeoff analyses, preliminary hardware prototype, basic electrical design, power budget, etc.

Requirements specification and analysis. Initial hardware architecture, processor types, identify performance and form factor constraints

Functionally equivalent engineering prototype (not to form factor), develop final Bill of Materials (BOM). Base platform software implemented, e.g. device drivers, board support packages, SCA infrastructure software including SCA devices and services.

Air interface compliance, RF performance, error rates, throughput, etc.

Formal qualifications testing, air interface testing by regulatory body, e.g. Joint Interoperability Test Command (JITC) for JTRS radios.

Waveform Requirements

Platform Requirements

Code Design and Development

Target language selection, real-time prototyping, detailed design and implementation. Implement SCA waveform component architecture. system level verification, test and integration.

RadioWaveform

guide

«flow»

«flow»«flow»





Prototype Waveform



Hardware Selection


















RadioWaveform

guide

«flow»

«flow»«flow»

Platform v. Waveform Development 6

As a organization becomes proficient using the SCA, there is a tendency to evolve towards an organizational model built around

a Platform (radio) team and a Waveform (application) team.





Prototype Waveform



Hardware Selection


















RadioWaveform

guide

«flow»

«flow»«flow»

SCA Influence on WF and Radio Design 7

Insertion points for SCA implementation however….





Prototype Waveform



Hardware Selection


















RadioWaveform

guide

«flow»

«flow»«flow»

SCA Influence on WF and Radio Design 8

Insertion points for SCA implementation however ….

… the SCA must be factored into the radio and waveform architecture process before

the insertion points.


What are the aspects of waveform porting?

Adherence to the SCA promotes portability but does not guarantee it, i.e. it is necessary but not sufficient.

Hardware abstraction is insufficient.

Migrating non-SCA legacy waveforms to an SCA environment presents some additional challenges.

Let’s start by looking at porting an SCA-compliant waveform from one SCA radio to another.

9





Prototype Waveform






Waveform

«flow»

Source versus Target Radio Platforms 10



Hardware Selection






Radio

«flow»

SCA waveformSCA radio

Waveform developed and then integrated with an SCA compliant radio.

Target radio may have a different implementation of

the SCA, hardware architecture, memory, etc.





Prototype Waveform






Waveform

«flow»

Source versus Target Radios 11



Hardware Selection






Radio

«flow»


Port





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»

1) What are the processor differences?Impacts development tools and design

and potentially deployment.


Port





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»




2) What are the physical transports?Impacts drivers and BSPs for

middleware transports.

Port





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»




2) What are the physical transports?

Impacts drivers and BSPs for middleware transports.

3) What is the hardware abstraction level?Impacts waveform deployment model and

configuration and control.

Port





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»






3) What is the hardware abstraction level?Impacts waveform deployment model and

configuration and control.

4) How modular is the waveform design?Impacts rebuilding for new processors and

refactoring control and I/O code out of functions

Port





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»






3) What is the hardware abstraction level?

Impacts waveform deployment model and configuration and control.



Port

Differences in the radio hardware architecture (2) and degree detail in the

SCA model of the hardware (3) can have a significant impact on the time and cost

required to port the waveform.





Prototype Waveform






Waveform

«flow»




Hardware Selection






Radio

«flow»










Port

Differences in the radio hardware architecture (2) and degree detail in the

SCA model of the hardware (3) can have a significant impact on the time and cost

required to port the waveform.

So, What a

bout a non-

SCA waveform

?


Many of the concerns remain the same… 18



Hardware Selection






Radio

«flow»

SCA radio




Prototype Waveform




Waveform

«flow»










Many of the concerns remain the same… 19



Hardware Selection






Radio

«flow»

SCA radio




Prototype Waveform




Waveform

«flow»









However, there are some additional considerations


Platform-specific elements in the waveform 20



Hardware Selection






Radio

«flow»

SCA radio




Prototype Waveform




Waveform

«flow»









5) What is the existing logical protocol?Effort required to move from a POSIX queue, as

an example, to CORBA.





Hardware Selection






Radio

«flow»

SCA radio




Prototype Waveform




Waveform

«flow»











6) What is the implementation language(s)?Impact if the waveform is in a different language than the

language used for the target radio, e.g. a mix of C/C++ may require multiple ORB libraries, encapsulation strategies, etc.





Hardware Selection






Radio

«flow»

SCA radio




Prototype Waveform




Waveform

«flow»











6) What is the implementation language(s)?Impact if the waveform is in a different language than the

language used for the target radio, e.g. a mix of C/C++ may require multiple ORB libraries, encapsulation strategies, etc.

7) What dependencies exist for OS and services?Access to operating system calls in SCA is limited and services implemented

on the source radio may not exist on the target radio.


Parameterizing Waveform Porting Effort 23

Modifying the I/O and Control differences between the source and target systems are often the biggest cost driver.Model the waveform, the deployment, the target radio hardware and asses the deltas.

Processor Architecture

Co

ntr

ol A

rch

itec

ture

Portability Cost Space

GPP

FPGADSP

• Radio architecture differences impact waveform porting effort in three areas*:– Control – Change in control and synchronization of waveform components– I/O – Change of data paths and transports– Processor – Change in algorithm

DSP

GPP

FPGA

I/O and Control changes between source and target

($$$)

Processor change

($)

Source Target

*The underlying assumption is that the functional design of the waveform is not modified

$$$??

I/O A

rch


Reuse as a Cost Function

The cost of the reuse is driven by the differences in the source and target platforms:

Processor – Algorithms, Waveform Design, Control

I/O – Physical bus, Data Marshalling, buffers

Control – Timing, Interrupts, Flow

Reuse does not imply zero cost.

If reuse of a waveform is viewed as a cost function, can the advances in software cost modeling over the past 25 years be applied.

24


25Reuse Cost Curve*

1.0

1.0

0.75

0.750.5

0.5

0.25

0.25

1.0

0.70

0.55

0.046

There is roughly a 5% cost of reuse when no changes are made!

Roughly 55% of the cost of development is attributable to reuse of approximately 13% of the code!

Relative Cost

Percent Modified

The initial assumption was that there would be a (roughly) linear relationship between the relative cost and the percentage of code modified.

*(Selby 85) analyzed the cost of reuse at NASA.Approximately 3,000 software modules were included in the analysis.

Cost increases moderately up about 75% of code change.


Waveform Network Layer Model 26

Layer 3

Layer 2

Layer 1

nwk

dlc

mac

phl

Hcinwk

dlc

mac

phl

out_to_dlc

data_outNwkdata_in

in_from_dlc out_to_dlc

data_out

hci

rx_to_dlc

tc_to_phl

Mactx_from_dlc

hci

rx_to_dlc

rx_from_phl

carrier_detecttc_to_phl

out_to_nwk

tx_to_mac

Dlc out_to_nwkin_from_nwk

hci

rx_from_mac tx_to_mac

rx

carrier_detect

antenna

voice_out

Phytx

hci

voice_in

rx

carrier_detect

antenna

voice_out

data_in data_out

antenna

voice_in voice_out

FM3TR Network Layers

PHY layer typically ends up on an FPGA

for more complex waveforms, e.g.

Wideband Network Waveform (WNW)

Layer model provides a view from the air

A/D boundary at the PHY layer to the network layer.

Much of the waveform processing can be performed in high-level languages

on GPP or DSP


Waveform Component Model 27

hci

tx_inc

rx_inc

crc_inc

t_cd_ont_cd_off

config

«block»Phy::HCI

hci

tx_inc

rx_inc

crc_inc

t_cd_ont_cd_off

config

t_cd_on

t_cd_off

carrier

detect

«block»Phy::Cd

t_cd_on

t_cd_off

carrier

detect

rx_inc

crc_incout

in

«block»Phy::Rx

rx_inc

crc_incout

in

voice_in

rf_in

config

tx

trans_sec

resetrf_out

rf_freq

carrier

rx

voice_out

«block»Phy::Fsm

voice_in

rf_in

config

tx

trans_sec

resetrf_out

rf_freq

carrier

rx

voice_out

rf_freqrf_out

antenna

rf_in

«block»Phy::Radio

rf_freqrf_out

antenna

rf_invoice_outvoice_in

reset

«block»Phy::Ptt

voice_outvoice_in

reset

in

out

tx_inc

«block»Phy::Tx

in

out

tx_inc

trans_sec

«block»Phy::TransSec

trans_sec

rx out to Mac

RF to/from antenna

analog voice in

analog voice out

HCI input/output

tx in from Mac

carrier detect out to Mac

FM3TR PHY Layer

Layer 3

Layer 2

Layer 1

nwk

dlc

mac

phl

Hcinwk

dlc

mac

phl

out_to_dlc

data_outNwkdata_in

in_from_dlc out_to_dlc

data_out

hci

rx_to_dlc

tc_to_phl

Mactx_from_dlc

hci

rx_to_dlc

rx_from_phl

carrier_detecttc_to_phl

out_to_nwk

tx_to_mac

Dlc out_to_nwkin_from_nwk

hci

rx_from_mac tx_to_mac

rx

carrier_detect

antenna

voice_out

Phytx

hci

voice_in

rx

carrier_detect

antenna

voice_out

data_in data_out

antenna

voice_in voice_out

Internal layer interfaces may be

API calls or a message passing

protocolEach layer has some

level of finite state machine

implementation

External Layer interfaces define primary boundary

between components


Deployment Analysis

Once the waveform and the constituent components have been logically modeled, build a deployment model of the waveform for the existing implementation.

The objective is to identify the deployment dependencies related to processors, physical transports and logical interfaces.

This provides a baseline for identifying changes required to port to the new platform.

28


Source Radio Waveform Deployment Model 29

Presented in MILCOM Tutorial, “Waveform Development and Deployment with the SCA”© 2007 Harris, Zeligsoft, and Spectrum Signal Processing


Waveform Deployment Analysis 30


1) Identify nodes, assemblies and

processor blocks.


Processor Differences

Mapping the source deployment components processors identifying any existing dependencies on processor types, operating systems and performance./

This provides the initial starting point for identifying and assessing porting effort for the functional components of the waveform.

31





processor blocks.

2) Identify physical interfaces


Transport Protocols and Data Paths

Identifying the physical connections between nodes, card assemblies and processors delineates the physical transports and transports.

This provides a baseline for comparison to the target radio platform for identifying the differences between the source and target machines.

33





processor blocks.


3) Identify mapping of waveform components to

hardware elements.


Deployment Analysis

Specify current deployment information:Processor type / model / memory / mips

Implementation language

Operating system (if applicable)

Identify other dependenciesLibraries and version

COTS packages (including IP cores on FPGA)

35





processor blocks.


4) Identify logical interfaces between

waveform components.

3) Identify mapping of waveform components to

hardware elements.


Logical Interfaces

Identify each pairwise set of interfaces between waveform components

Describe interface:Call direction (Uses / Provides port in SCA)

Synchronization (function return, delivery only)

Content of call (parameters, description)

Build a map of dependencies (N2 chart, sequence diagram)

Identify performance critical areas

37


Summary

Porting a waveform is a superset of traditional, i.e. GPP, software porting.

Lack of an industry standard for signal processing hardware, e.g. standard protocols and hardware abstractions, introduce complexities requiring more detailed analysis.

Similar to traditional software cost estimation, factors such as the level of experience the target SDR radio and the existing waveform code reduce porting effort and cost.

Although a complex problem, it is not intractable.

38


SCA SDR Requires a Change in Mindset 39

Steve Jobs in Four Easy StepsWhat the electronics industry can learn from his tenure at AppleBy G. Pascal Zachary / October 2011

“Jobs refused to accept that software and hardware were best designed and engineered separately. For him, the venerable insight summarized by Thomas Hughes, the grand historian of American technology, as `the system must be first’ became a lodestar.”

The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the SanityAlan Cooper / 1999

Question: “What do you get when you cross a camera with a computer?”Answer: “A computer!”

“We don’t build radios anymore. We build computers that transmit.”- Mark Turner, Harris

http://spectrum.ieee.org/computing/hardware/steve-jobs-in-four-easy-steps

http://en.wikipedia.org/wiki/Thomas_P._Hughes

http://en.wikipedia.org/wiki/Alan_Cooper


What’s Next…

Following sessions will discuss experience, approaches, techniques and tools with respect to:

Modeling waveform software architecture

Potential for reverse engineering to assist in the process

Deployment analysis to provide a “quick look” assessment of complexity and potential effort.

40


Further Information

For additional information on PrismTech’s Spectra products and services:

E-mail:[email protected]

Website:www.prismtech.com/spectra

41

mailto:[email protected]

http://www.prismtech.com/spectra


42

Thank You

migrating legacy waveforms to the software communications architecture (sca)

Technology

sca waveform implementations

sca waveform portability

general waveform

radio design flow

waveform application

dream waveform implementations

flow architecture

sca environment