Migrating Legacy Waveforms to the Software Communications Architecture (SCA)

Migrating Legacy Waveforms
to the SCA
20th October 2011

Mike Williams and Vince Kovarik
PrismTech

The Software Communications Architecture 2

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.
Copyright PrismTech 2011

SCA Waveform Portability 3

The Dream
Waveform implementations would be reusable across
multiple radio systems.
No modifications would be necessary to bring the
waveform up on another system.
The Reality
Initially, 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.


The Problem… 4

The architecture and design of a Software
Defined Radio has multiple perspectives:
Processors
GPP, DSP, FPGA
Design Paradigms
Sequential Stack State Machine v. Parallel State
Machine
Implementation Languages
C/C++, HDL, SystemC
Systems Engineering
Hardware and software engineering architecture tasks
are performed semi-independently of each other.

General Waveform and Radio Design Flow 5

analysis Wav eform Dev elopment

Waveform Radio
Modeling and simulation of Requirements specification
core waveform algorithms guide
and analysis. Initial hardware
in MATLAB, SIMULINK, «flow» architecture, processor types,
Mathematica, System Platform
Waveform «flow» identify performance and form
View, etc. «flow» Requirements
Requirements factor constraints
Functional Block
Grouping of algorithm Algorithm Achitecture
elements into logical Development Make / buy tradeoff
waveform components. analyses, preliminary
Use of UML component hardware prototype, basic
modeling techniques and electrical design, power
tools. Functional Block budget, etc.
Architecture Hardware
Selection
Non-real-time
implementation in C/C++ Functionally equivalent engineering
MATLAB, SIMULINK, Formal qualifications prototype (not to form factor), develop final
Prototype Bill of Materials (BOM). Base platform
Mathematica, testing, air interface
Waveform software implemented, e.g. device drivers,
SystemView, etc. testing by regulatory Engineering board support packages, SCA
body, e.g. Joint Prototype
Interoperability Test infrastructure software including SCA
Allocation of functional devices and services.
waveform components to a Deployment Command (JITC) for JTRS
processor type: GPP, Allocation radios.
DSP, FPGA, GPU, etc.
Integrated Air interface compliance, RF
System Testing Form Factor performance, error rates,
Target language selection, Code Design and Implementation
real-time prototyping, Development throughput, etc.
detailed design and
implementation.
Implement SCA waveform
component architecture.
system level verification,
test and integration.

Manufacturing
«process»


Platform v. Waveform Development 6


Waveform Radio
Functional Block
Selection
Non-real-time
detailed design and
implementation.

Manufacturing
«process»
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.

SCA Influence on WF and Radio Design 7


Waveform Radio
Functional Block
Selection
Non-real-time
detailed design and
implementation.
Insertion points for SCA
implementation however….
Manufacturing
«process»


SCA Influence on WF and Radio Design 8

… the SCA must be factored

Waveform the radio and waveform
into Radio
core waveform algorithms
in MATLAB, SIMULINK,
process before
architecture«flow»
guide
architecture, processor types,
Mathematica, System the insertion points. Platform
«flow» Waveform
«flow» identify performance and form
View, etc. Requirements
Functional Block
Selection
Non-real-time
detailed design and
implementation.
Insertion points for SCA
implementation however ….
Manufacturing
«process»


What are the aspects of waveform porting? 9

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. Copyright PrismTech 2011

Source versus Target Radio Platforms 10

Waveform
Radio

«flow» Waveform
Platform
Requirements «flow»
Requirements
Algorithm
Development Functional Block
Achitecture

Functional Block Waveform developed and
Architecture
then integrated with an Hardware
SCA compliant radio. Selection

Prototype
Waveform

Target radio may have a Engineering
Prototype
Deployment
Allocation
different implementation of
the SCA, hardware
Integrated
System Testing
architecture, memory, etc.
Code Design and Integrated
Development System Testing Form Factor
Implementation

Manufacturing
SCA waveform «process»
Manufacturing
«process» SCA radio


Source versus Target Radios 11

analy W
sis aveformDevelopment
Waveform
Radio

«flow» Waveform
Platorm
f
Requirement
s
Algorithm
Achitecture

Functional Block
Architecture
Hardware
Selection

Prototype
Waveform

Engineering
Prototype
Deployment
Allocation

Integrated
Code Design and System Testing Integrated
Development Sys Tes
tem ting Form Factor
Implementation

Port

Manufacturing
Manufacturing



1) What are the processor differences? Wav eform Dev elopment
analysis
Waveform Impacts development tools and design
Radio
and potentially deployment.
«flow» Waveform
Platform
Requirements
Algorithm
Achitecture

Functional Block
Architecture
Hardware
Selection

Prototype
Waveform

Engineering
Prototype
Deployment
Allocation

Integrated
Implementation

Port

Manufacturing
Manufacturing



analysis
Radio
«flow» Waveform
Platform
Requirements
Algorithm
2) What are the physical transports?
Functional Block
Development Impacts drivers and BSPs for Achitecture
middleware transports.
Functional Block
Architecture
Hardware
Selection

Prototype
Waveform

Engineering
Prototype
Deployment
Allocation

Integrated
Implementation

Port

Manufacturing
Manufacturing



analysis
Radio
«flow» Waveform
Platform
Requirements
Algorithm
Functional Block
Functional Block
Architecture 3) What is the hardware abstraction level?
Hardware
Impacts waveform deployment model and Selection

Prototype
configuration and control.
Waveform

Engineering
Prototype
Deployment
Allocation

Integrated
Implementation

Port

Manufacturing
Manufacturing



1) What are the processor differences?analysis Wav eform Dev elopment
Radio
«flow» Waveform
Platform
Requirements
Algorithm
Functional Block
Functional Block
Hardware

Prototype
Waveform
4) How modular is the waveform design?
Engineering
Impacts rebuilding for new processors and Prototype
Deployment
Allocation refactoring control and I/O code out of functions
Integrated
Implementation

Port

Manufacturing
Manufacturing



analysis
Waveform Impacts development tools and design and
Radio
potentially deployment.
«flow» Waveform
Platform
Requirements
Algorithm
Functional Block
Functional Block
Hardware

Prototype
Waveform
Engineering
Deployment
Integrated
Implementation

Port
Differences in the radio hardware
Manufacturing
architecture (2) and degree detail in the Manufacturing
SCA model of the hardware (3) can have
a significant impact on the time and cost
required to port the waveform.


analysis
Radio
«flow» Waveform
Platform
Requirements
Algorithm
Functional Block
Functional Block
Hardware

Prototype
Waveform
Engineering
Deployment
Integrated
Implementation

Port
Differences in the radio hardware
Manufacturing
architecture (2) and degree detail in the Manufacturing
SCA model of the hardware (3) can have
a significant impact on the time and cost
required to port the waveform.

Many of the concerns remain the same… 18

analysis

Radio
«flow» Waveform Platform
«flow»
Requirements Requirements
Algorithm Functional Block
Functional Block
Architecture
3) What is the hardware abstraction level?
Hardware
Prototype
Waveform
Engineering
Deployment
Allocation
refactoring control and I/O code out of functions

System Testing Form Factor
Development Implementation

Manufacturing


Many of the concerns remain the same… 19

analysis

Radio
«flow»
Functional Block
Architecture
Hardware
Prototype
Waveform
Engineering
Deployment
Allocation

Development Implementation

Manufacturing


Platform-specific elements in the waveform 20

analysis

Radio
«flow»
Functional Block
Architecture
Hardware
Prototype
Waveform
Engineering
Deployment
Allocation

Code Design and
5) What is the existing logical protocol? Integrated
Development Effort required to move from a POSIX queue, as Implementation

an example, to CORBA.

Manufacturing



analysis

Radio
«flow»
Functional Block
Architecture
Hardware
Prototype
Waveform
Engineering
Deployment
Allocation

5) What is the existing logical protocol?
Integrated
Code Design and
Development
Effort required to move from a POSIX queue, as
Implementation

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.
Manufacturing



analysis

Radio
«flow»
Functional Block
Architecture
Hardware
Prototype
Waveform
Engineering
Deployment
Allocation

5) What is the existing logical protocol?
Integrated
Code Design and
Development
Effort required to move from a POSIX queue, as
Implementation

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.
Manufacturing
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

• 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 Source $$$?? Target
– Processor – Change in algorithm

Modifying the I/O and
Control differences
between the source Processor
change
and target systems are
Control Architecture 
($)
often the biggest cost DSP
FPGA

driver.
Model the waveform,
FPGA
the deployment, the DSP
I/O and Control
target radio hardware changes between
and asses the deltas. source and target
GPP GPP ($$$)
*The underlying assumption is that the
functional design of the waveform is not Processor Architecture 
modified

Reuse as a Cost Function 24

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.


Reuse Cost Curve* 25

Relative Cost
1.0 Cost increases 1.0
Roughly 55% of the cost of
moderately up
development is attributable
about 75% of code
to reuse of approximately
change.
13% of the code!

0.75 0.70

0.55

0.5
There is roughly a 5%
The initial assumption was that
cost of reuse when no
there would be a (roughly) linear
changes are made!
relationship between the relative
cost and the percentage of code
modified.
0.25
*(Selby 85) analyzed the cost of reuse at NASA.
Approximately 3,000 software modules were
included in the analysis.
0.046

0.25 0.5 0.75 1.0
Percent Modified

Waveform Network Layer Model 26

FM3TR Network Layers
Layer model provides
data_in data_out a view from the air
A/D boundary at the
data_in Nwk data_out PHY layer to the
Layer 3

Hci
nwk hci network layer.
in_from_dlc out_to_dlc

Much of the
in_from_nwk waveform processing
Layer 2

Dlc out_to_nwk
dlc hci can be performed in
rx_from_mac tx_to_mac high-level languages
on GPP or DSP
tx_from_dlc rx_to_dlc
Mac
mac hci
rx_from_phl
tc_to_phl
carrier_detect PHY layer typically
Layer 1

ends up on an FPGA
for more complex
tx rx
Phy waveforms, e.g.
phl hci carrier_detect
antenna Wideband Network
antenna
voice_in
Waveform (WNW)
voice_out

voice_in Copyright PrismTech 2011 voice_out

Waveform Component Model 27

External Layer FM3TR PHY Layer
interfaces define
primary boundary
«block»
between components «block» Phy::Cd
Phy::HCI
HCI input/output t_cd_on detect carrier detect
hci t_cd_on out to Mac
t_cd_off
tx_inc t_cd_off
config carrier
rx_inc
data_in data_out

data_in data_out
crc_inc
Layer 3

Nwk
Hci
nwk hci
in_from_dlc out_to_dlc

in_from_nwk
tx in from Mac
Layer 2

Dlc out_to_nwk
dlc hci
rx_from_mac tx_to_mac

tx_from_dlc
Mac rx_to_dlc
«block»
mac hci
Phy::Rx
rx_from_phl
tc_to_phl
«block»
carrier_detect
Layer 1

Phy::Tx rx_inc
rx

phl
tx
hci
Phy
carrier_detect in tx_inc crc_inc
antenna antenna
in
voice_in out
voice_out
out rx out to Mac
voice_in voice_out

«block»
Phy::Fsm
«block» config carrier
Phy::TransSec tx rx
trans_sec trans_sec voice_out
Internal layer analog
voice out «block»
interfaces may be API «block» Phy::Radio RF to/from
antenna
Phy::Ptt rf_freq rf_freq
calls or a message analog voice_in voice_out rf_out rf_out
antenna
voice_in rf_in
passing protocol voice in reset
rf_in
reset

Each layer has some
level of finite state
machine Copyright PrismTech 2011
implementation

Deployment Analysis 28

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.

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 31

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.



2) Identify physical 1) Identify
interfaces nodes, assemblies
and processor blocks.


Transport Protocols and Data Paths 33

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.



2) Identify physical 1) Identify nodes,
interfaces assemblies and
processor blocks.

3) Identify mapping of
waveform components to
hardware elements.


Deployment Analysis 35

Specify current deployment information:
Processor type / model / memory / mips
Implementation language
Operating system (if applicable)
Identify other dependencies
Libraries and version
COTS packages (including IP cores on
FPGA)



2) Identify physical 1) Identify nodes,
interfaces assemblies and
processor blocks.

3) Identify mapping of 4) Identify logical
waveform components to interfaces between
hardware elements. waveform components.


Logical Interfaces 37

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

Summary 38

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.

SCA SDR Requires a Change in Mindset 39

Steve Jobs in Four Easy Steps
What the electronics industry can learn from his tenure at Apple
By 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 Sanity
Alan 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

What’s Next… 40

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.


Further Information 41

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

E-mail:
info@prismtech.com

Website:
www.prismtech.com/spectra


42

Thank You


Migrating Legacy Waveforms to the Software Communications Architecture (SCA)

Recommended

Recommended

More Related Content

What's hot

What's hot (6)

Viewers also liked

Viewers also liked (15)

Similar to Migrating Legacy Waveforms to the Software Communications Architecture (SCA)

Similar to Migrating Legacy Waveforms to the Software Communications Architecture (SCA) (20)

More from ADLINK Technology IoT

More from ADLINK Technology IoT (20)

Recently uploaded

Recently uploaded (20)

Migrating Legacy Waveforms to the Software Communications Architecture (SCA)