You are on page 1of 6

A STRUCTURED APPROACH TO WAVEFORM DELIVERY FOR FPGA-BASED DESIGNS

Hieu Nguyen, Joseph Chapman, Karl Wagner


The MITRE Corporation
Bedford, MA

Extending the SCA concepts to the modem architecture of


ABSTRACT an SDR is a natural step toward a fully integrated
heterogeneous processing platform that includes GPPs,
Today’s advanced MILSATCOM terminals depend heavily DSPs, and FPGAs [1]. Thus far, the focus of the industry
on Field Programmable Gate Array (FPGA) devices to has been at high level Application Programming Interface
support the increased demands of Above 2 GHz, high (API), commercial middleware [2], and the hardware
bandwidth high throughput (HBHT), high data rate (HDR) abstraction layer (HAL) to the modem [3]. A critical
waveforms. One critical issue is that the delivery approach requirement for FPGA-based waveforms is the need to
of FPGA-based waveforms is not standardized. However, substantially increase reuse of the firmware running on the
the techniques developed by the Software Communications FPGAs. To address the waveform reuse aspect of the
Architecture (SCA) for software defined radio (SDR) modem, the PRT Lab created a set of guidelines and
platforms to enable waveform porting on general purpose constraints for the developers. These guidelines ensure that
processor (GPP) devices can be extended to FPGA-based the waveform is designed to be configurable and scalable.
modem architectures. Leveraging existing SCA concepts, To streamline the porting process, the PRT Lab also
this paper advocates a structured approach to waveform developed a verification environment to aid the contractors
delivery for FPGA-based designs. The MITRE with the deployment of the ported HDR-RF Test
Programmable Radio Technology (PRT) Laboratory Waveform onto their target hardware platforms.
demonstrated such an approach through the development,
and delivery of a scalable and portable High Data Rate There are constraints and tradeoffs associated with every
Radio Frequency (HDR-RF) Test Waveform. The proposed design approach, such as size, weight, and power (SWAP)
approach provides a structured delivery methodology that or development effort verses integration effort. For the
significantly reduces the risk of porting FPGA-based PRT Lab’s development of the HDR-RF Test Waveform,
waveforms across SDR platforms. the primary objectives are design for reuse and waveform
portability. The tradeoff decisions made in the design
INTRODUCTION approach are based on those two objectives.

The MITRE PRT Laboratory is a multidiscipline The Background section describes the traditional
electronic system rapid prototyping team focused on risk waveform porting procedure. The remaining sections
reduction and requirements specification with the mission discuss various aspects of the PRT Lab’s proposed
of assisting the government in the successful acquisition of approach to structured waveform delivery.
state-of-the-art communication, networking, sensor and
navigation systems. The HDR-RF Test Waveform BACKGROUND
developed by the PRT Lab is a risk reduction effort for the
HDR-RF ground terminal program. The power efficient Without structured design guidelines and a standard
Test Waveform uses a strong low-density parity-check delivery approach, porting an FPGA-based waveform onto
(LDPC) forward error correction (FEC) code with Offset a new hardware platform is often a daunting task. This is
Quadrature Phase Shift Keying (OQPSK) modulation, and reflected in [4] where it is argued that porting a poorly
operates at four different data rates. The first goal of the designed and delivered waveform can actually exceed the
PRT Lab is to deliver a complete handoff package of the costs of a new development. Why is porting FPGA-based
HDR-RF Test Waveform to the ground modem waveform so difficult and costly? The answer lies in the
contractors. The contractors are responsible for porting the tasks that a porter must perform - namely FPGA
Test Waveform to demonstrate the HBHT capability of repartitioning, retargeting and interfacing.
their hardware platforms currently under development.
The second goal is to demonstrate to the government a Repartitioning is the act of mapping the waveform to fit
powerful reuse strategy for FPGA-based waveforms. onto the hardware resources available on the target
platform. A waveform can be viewed as a chain of signal

1-6
978-1-4244-2677-5/08/$25.00 ©2008 IEEE
processing stages which the developer breaks up into the target hardware platform, but also a detailed
discrete segments called waveform components. The knowledge of the original design implementation, thus
porter can combine multiple components to fit into a larger making hardware retargeting a difficult and labor intensive
FPGA or rework a large component to fit into a smaller task.
device. Reworking may involve choosing an alternate
implementation or splitting the functionality into two or Interfacing requires the waveform porter to create
more smaller components. Repartitioning is continued specialized gaskets to translate waveform specific interface
until the waveform is completely mapped to the new to platform specific transport protocol and I/O standard.
hardware. Figure 1 below shows an example waveform The difficulty of this task is based on the uniformity of
being mapped to target platforms FPGA1 and FPGA2. component interfaces. If the waveform interface is
Note that WC3 had to be broken up into two pieces consistent across the components, the number of different
because the original implementation was too big to fit onto gaskets can be kept to a minimum. On the other hand, if
the target device. To effectively partition the waveform, the waveform interface varies from component to
the porter must have detailed knowledge of the resource component, the porter may need to develop more custom
utilization of each component. gaskets to interface the waveform to the hardware
platform. Figure 1 illustrates the worst case scenario where
every component in the waveform has slightly a different
interface as depicted by the different shapes. To port this
example waveform to the new FPGA devices, the porter
has to create custom gaskets at each point the component
interfaces with hardware I/O on FPGA1 and FPGA2. The
porter is again required to have detail understanding of the
waveform properly construct the corresponding gaskets for
the hardware platform.

Currently, the main reason for the complexity in the


porting of FPGA-based waveform is that the porter must
have intimate knowledge of the waveform at various levels
of the modem. This paper acknowledges the difficult tasks
facing waveform porters and proposes an approach which
introduces guidelines to the waveform development and
delivery process. First, this approach aims to resolve the
ambiguity of the component interface and the waveform
Figure 1. Traditional FPGA-based Waveform Porting hardware resource utilization. Second, to reduce the
learning curve of the porting process, the porter is no
Retargeting is the act of identifying and replacing device- longer required to understand the specific details of the
specific architectures within the waveform. Modern FPGA waveform implementation. This is accomplished by
fabrics contain a variety of specialized hardware structures developing configurable and scalable firmware at the
that are optimized for common functionalities such as FPGA level. Last, the PRT Lab advocates a structured
multiplication and memory. Although these structures waveform delivery process that leverages the Intellectual
offer increased performance over similar functions Property (IP) delivery methodology used by the
implemented with standard logic resources, they are often commercial industry, where the delivered IP is fully
not compatible between different FPGA families. verified and properly documented. The waveform
Significant risk can be introduced to the process since the deliverables include CAD tools, models, and testbenches
waveform porter is required to modify the original source to aid the porter with the verification of the waveform.
code to migrate the design to the new hardware platform. While this proposed approach increases the initial
Not only does the functionality need to match the original development effort, it significantly decreases the high cost
design, the overall system performance must also be and schedule risk associated with the porting of complex
maintained. Depending on the new target platform and the waveforms. The following sections elaborate on the design
complexity of the device-specific features used in the approach used by the PRT Lab on HDR-RF Test
original waveform, the difficulty of hardware retargeting Waveform.
of HBHT waveforms ranges from challenging to quite
formidable. To accomplish this task, the waveform porter
is required to not only have a complete understanding of

2-6
DEVELOPMENT GUIDELINES device, thus increasing the chance of a successful
waveform port. The HDR-RF Test Waveform is simulated
Coding for reuse must be considered at every stage of the with Mentor Graphic and Synopsys simulator, and
waveform development process to reduce overall porting synthesized to target both Altera and Xilinx FPGA family.
effort. The focus of design for reuse is minimizing the
amount of rework of the waveform components during the
hardware retargeting and repartitioning process. The
guidelines below provide one approach toward design for
reuse and waveform portability.

Each component must incorporate appropriate hooks to


allow configuration of the component from the top level of
the waveform. There are two types of configurations:
static and dynamic. Static configuration is set when the
system is built (e.g. using generics in VHDL or parameters
in Verilog). Dynamic configuration, on the other hand, can
be updated at runtime. While dynamic configuration
settings provide greater flexibility, they come at a cost of
hardware resources; therefore it falls upon the developer to
decide whether a component parameter should be static or
dynamic. By having all the component configurations
accessible from the top level of the waveform, the porter
can modify component settings without changing the Figure 2. Proposed FPGA-based Waveform Porting
original source code.
A common, well defined interface at the RTL waveform
The waveform must be scalable to support the multitude of component boundaries reduces ambiguity and allows the
hardware platforms expected to host it. For the HDR-RF porter to clearly understand the transactions of the
Test Waveform, scalability refers to the different levels of components within the system. A common interface also
parallelism supported by each component. With the helps to abstract the internal design implementation of the
understanding that overall system performance can be component. As a consequence, the porter can treat every
achieved by maintaining a certain ratio between the waveform component as a black box. Furthermore, the
component parallelism and the hardware clock rate, the common interface enables standardization and automation
waveform porter can pick a specific parallelism and clock in the design and verification process, thus lowering the
rate that is optimized for the target platform. For the HDR- cost and reducing the length of the development cycle. The
RF Test Waveform, the parallelism setting is a static proposed methodology encourages waveform developers
configuration on each component. Figure 2 illustrates the to use non-propriety common interfaces defined by open
waveform porting strategy proposed by PRT Lab, where industry standards to foster reuse and interoperability
the waveform is designed to be configurable, and scalable. between waveforms. Figure 2 illustrates the example
As the result, the porter is not required to make any waveform using a standard interface on all of the
modification to the source code when repartitioning and components. The advantage of using common interface is
retargeting the waveform to new hardware platforms. shown in target FPGA1 and FPGA2, where the gaskets
developed by the porter to link the waveform to the
The original waveform developer should design the platform specific I/O are reused on both devices. The
waveform to be tool and architecture independent to avoid HDR-RF Test Waveform uses Open Core Protocol (OCP)
locking the porter into a specific design flow. This [5] as the standard interface on all of the RTL components.
requirement enables the porter to use their own tool set and
reduces the hardware retargeting effort. The HDR-RF Test The next generation of FPGA devices, as specified by the
Waveform is verified against multiple mainstream device vendors, can support clock rates of 400-500 MHz
simulators to ensure compatibility across different tools. or higher. However, the waveform developer should not
Furthermore, to verify hardware independence, the rely on excessively high operating frequencies to meet the
waveform is synthesized to target different FPGA system requirement of the waveform. Synthesizing and
architectures. These extra measures ensure that the RTL deploying a design with tight timing constraints poses an
source code is not tailored to a specific tool or FPGA additional risk to the porting process. First, synthesis tools
take much longer to converge on designs with tight timing

3-6
requirements. Second, a component developed to run at a porter. Therefore, the burden falls upon the developer to
fast clocking rate on a high-end FPGA may not work in a provide the porter with the necessary information and tools
less capable device. By limiting the operating frequency of to ensure efficient porting of the waveform. The PRT Lab
the component, the designer maximizes waveform reuse looked to industry best practice for IP delivery approach to
across a variety of commercial hardware. create a release package for HDR-RF Test Waveform.

A similar argument exists for limiting the size of each


waveform component. Imposing a limit on the number of
logic cells and block RAMs per component gives the
porter more flexibility when repartitioning the waveform.
For instance, a large waveform component may fit into a
large FPGA device but not into a smaller device. Thus, a
larger waveform component is less flexible. As shown in
Figure 2, since the original components are properly sized,
the porter is not required to split the WC3 component to
make waveform fit onto the target platform as previously
illustrated in Figure 1. By forcing the developer to take
resource utilization of individual components into account
early in the design cycle the final waveform becomes more
portable.

There are tradeoffs associated with the above development


guidelines. First, in order for the waveform to be hardware
independent the RTL source code is written more
generically, thus the waveform cannot take advantage the
specialized hardware structures beyond those that are Figure 3. FPGA Partitioning Tool
inferred during synthesis. Second, there is a resource
overhead associated with using a common interface on the Since the developer has invested much effort to make each
waveform component compared to designing a specific component reusable, it might be in their interest to protect
interface as required. Third, setting a limit on the clock the IP within the waveform. Because the components use a
rate of the component means the waveform is not realizing common interface and are designed to be configurable, the
the full capability of the hardware. Last, the requirement to porter is no longer required to know the implementation
constrain the size of the component could result in unused details. Every waveform component can now be treated as
resources on the deployment platform if the components a black box. A natural result of this black box approach is
do not pack neatly into the FPGA devices. These are valid that the developer can protect sensitive IP and trade secrets
arguments against the proposed development approach, inside the components. This practice is consistent with
but the tradeoffs are necessary to meet the design for reuse commercial IP industry. The caveat is that the protected IP
and waveform portability objectives of HDR-RF Test must still be in compliance with all the development
Waveform. Furthermore, the above guidelines are intended guidelines and constraints. The PRT Lab used a
for high data rate designs, where specialized hardware commercial tool to encrypt the RTL source code for the
features and high clock frequency alone are not guaranteed HDR-RF Test Waveform.
to meet the system performance. Following the proposed
design approach, the HDR-RF Test Waveform exceeds the As discussed previously, repartitioning is traditionally a
274 MBits/sec design requirement using a clock frequency manual process that requires the porter to have a detailed
of only 116 MHz. The Test Waveform also has the understanding of the waveform. To simplify repartitioning,
flexibility to make tradeoffs between decreased parallelism the PRT Lab created an FPGA-partitioning tool which
(i.e. less hardware resources) and increased clock abstracts the waveform’s implementation details from the
frequency while maintaining the data rate requirement. porter. As shown in Figure 3, the tool provides a Graphical
User Interface (GUI) for the porter to define FPGA
STANDARD RELEASE PROCESS boundaries and to configure the waveform. The output
from the tool is an Extensible Markup Language (XML)
Generally, as with the HDR-RF Test Waveform, the description of the waveform’s configuration and
waveform developer is not necessarily the waveform connections. PERL scripts are then used to parse the XML
and automatically generate RTL top level files that

4-6
instantiate the components contained in each FPGA the porter to the FPGA-partitioning tool and the
partition. To ensure that the waveform is properly verification facilities provided in the handoff package. It is
configured and partitioned, an RTL testbench is the porter’s guide for running the tools, the scripts, and the
automatically generated to verify the partitioned design. simulation with the waveform model. Second, the
The RTL testbench has the capability to read test vectors Application document provides the porter an overview of
and compare them against the simulated data stream. the entire waveform. The document defines the specific
Figure 4 shows an example of an RTL testbench with three static and dynamic settings of the constituent components
FPGA partitions. It is important to note that the waveform to achieve the expected system performance. The dynamic
components and the RTL top level files both use the same settings are used to configure the system during platform
common OCP interface. integration. Third, the Component document describes the
high level function and interface of each waveform
component. This document is intended to be generic, since
the component may be reused with other waveforms. For
the porter, the component document serves as additional
reference to the waveform application document.

The entire HDR-RF Test Waveform is delivered to the


modem contractors on a Virtual Machine (VM) [7]. A VM
behaves like a virtual computer that can run its own
operating system (OS). First, the VM environment is
configured to run all the scripts and tools associated with
the waveform. Second, the documents, the RTL source
code, the models, and the testbench are copied to the VM
image. The porter can perform waveform repartitioning to
generate RTL top level files and run simulations directly
on the VM without installing the tool or setting up the OS
Figure 4. Auto-generated RTL Testbench environment on a local machine. This approach provides
the porter a completely preconfigured package and enables
Typically, IP is delivered with test vectors to help the user waveform porting tasks to be performed more efficiently.
verify functionality and proper usage. However, for the To protect the released IP, the VM is created with a
HDR-RF Test Waveform, it is not practical to deliver test password protected account. Finally, The VM image itself
vectors to exhaustively exercise all the different modes and is delivered to the contractors on an encrypted portable
configurations within the design. Instead, the waveform is hard drive (HD), making the waveform release package
delivered with an abstract model which provides the porter secure and compact for the porter.
the flexibility to configure and dynamically generate test
vectors for any mode of operation. The abstract model is PORTING STRATEGY
implemented using SystemC, a high-level modeling and
verification language [6]. As with the details of the For the HDR-RF Test Waveform, the PRT Lab provided
waveform implementation, the details of the model can be the modem contractors a strategy guide to help port the
abstracted from the porter. The propriety IP in the abstract waveform onto their hardware platform. To reduce the
model can thus be compiled into an executable. For the number of debug iterations on the hardware, the porting
HDR-RF Test Waveform, there are four requirements for process is divided into two stages to isolate potential
the model. First, the model must be bit accurate with sources of error. Figure 5 provides an overview of the
respect to the RTL. Second, it must use a data drive porting strategy.
interface. Third, it must accept the same parameter and
configuration settings as its RTL counterpart. Fourth, the In the first stage of the porting process, the porter
model must be able to generate test vectors at the boundary configures and repartitions the waveform for the target
of each waveform component. As shown in Figure 4, these hardware, using the FPGA partitioning tool provided in the
test vectors are used in conjunction with the RTL release package. Then, running simulation with the
testbench. Together they provide the porter the capability waveform model, the porter generates test vectors for a
to quickly assemble and verify the partitioned waveform. specific test scenario. These test vectors are used in
The HDR-RF Test Waveform handoff package has three combination with the generated RTL testbench to verify
layers of documentations: Environment, Application, and the RTL top files. Once the simulation successfully
Component. First, the Environment document introduces completes, the porter can move forward with confidence

5-6
that the waveform has been properly configured and CONCLUSION
partitioned.
To support Above 2 GHz, high bandwidth high throughput
(HBHT), high data-rate (HDR) FPGA-based waveforms,
development and delivery of the firmware for advance
MILSATCOM terminals must be standardized. The
proposed waveform design guidelines push the
requirement for scalability and configurability down to the
waveform components. The result is a waveform that is
portable from the RTL up through the SCA framework.
Combined with a structured release process, the porting of
FPGA-based waveforms becomes much more efficient and
ultimately reduces the overall schedule and cost risk
associated with complex waveforms.

This paper acknowledges that some design optimization


have been sacrificed to achieve design for reuse and
waveform portability. Furthermore, the proposed approach
is optimized for the waveform porter, while the developer
is doing most of the heavy lifting to streamline the porting
effort. Future work for the PRT Lab includes building on
the existing approach to create a more balanced waveform
development flow, where the burden on the developer is
decreased.

Figure 5. Waveform Porting Process Using the proposed guidelines, the HDR-RF Test
Waveform has met all of its requirements and objectives
In the second stage, the porter develops the hardware on design, system performance, IP delivery and waveform
dependent gaskets to connect the FPGA partitions to their portability. The PRT Lab structured methodologies
platform specific interface. These gaskets are verified discussed in this paper serve as a starting point for a wider
using bus functional model (BFM) of the I/O and device discussion on a structured approach to portable FPGA-
transports to check the links between the waveform and based waveform development.
the platform. The gaskets connections are shown at the
bottom of Figure 5. After the waveform is tested with the
hardware testbench, the waveform is ready to be deployed REFERENCES
onto the platform. This incremental approach to
verification makes the porting process much more [1] “Component Portability Infrastructure”, Mercury
predictable. Computer System, Inc 2007
[2] Lee Pucker, Geoff Holt, “Extending the SCA Core
Even with the structured delivery and extensive Framework inside the Modem Architecture of a Software
documentation, it is not reasonable for a developer to Defined Radio”, IEEE Radio Communication March 2004
consider every possible issue the porter might face. In [3] JTRS JPEO, “Joint Tactical Radio System (JTRS)
addition to the physical delivery of the waveform, it is Standard Modem Hardware Abstraction Layer Application
necessary that the developer provide some degree of Program Interface (API)”, Version 2.11.1, May 2007.
training to the porter in the use of the environments and [4] Manuel Uhm, “The Myths and Realities of Code
waveform. Furthermore, technical support during the Portability”, Xilinx, 2008
porting process can help resolve special conditions which [5] Open Core Protocol International Partnership, see:
were not considered during initial development. Since the http://www.ocp-ip.org
waveform components are treated as black boxes by the [6] IEEE Standard SystemC Language Reference Manual,
porter, the developer may be required to make any IEEE Standard 1666-2005, 2006
changes. [7] VMware Virtual Machine
see: http:// www.vmware.com/virtualization

6-6

You might also like