1

10.3 A General Purpose FPGA Based

Radar Controller and Signal Processor
Charles Martin*, Eric Loew, Chris Burghart
National Center for Atmospheric Research, Boulder, Colorado

applications of this system are presented, followed

by a discussion of benefits and pitfalls.
1 Introduction
1 2 The Field Programmable Gate Array
Radar implementations began as fully analog
systems. Digital technologies have held The FPGA is simply an integrated circuit with
substantial roles for many years, but until the last an extremely large number of generic digital logic
two decades the major digital functionality largely cells. These cells can be dynamically connected to
began at the analog to digital and digital to analog create building blocks capable of basic digital
conversions that occurred at baseband. Signal functions. These components are then combined
down- and up-conversion, as well as specialized to produce more sophisticated logic, and so on
pulse shaping, were performed with discrete until very complex functionality is realized. For
hardware modules. As analog converters became example, devices with the complexity of complete
capable of operating at IF sample rates, it became CPUs, DMA memory controllers, and PCI bus
possible to migrate the IF processing into the interface controllers can be synthesized for
digital realm. Typically this was performed by modern FPGAs. In fact a single FPGA will often be
custom circuit boards designed around specialized performing all of these functions and more at
components coupled with onboard digital signal once. The FPGA is also well suited to
processors. This hardware and embedded implementing pipelined computations that can be
software solution then performed the up- and highly parallelized, such as filtering, frequency
down-conversion and other signal processing conversion, and the fast Fourier transform. These
functions, and allowed the communication with the allow us to implement much of the functionality,
host computer to occur at baseband sample rates. originally located in analog or discrete digital
In the past decade, new capabilities have components, in the re-configurable digital
emerged in the digital arena, due to the increased environment of the FPGA.
capabilities of the Field Programmable Gate Array The FPGA device will have digital I/O
(FPGA). This device provides a foundation for connections for bringing signals into and out of the
building general-purpose hardware that can be chip. The number of digital I/O lines can number in
adapted to the signal processing needs of many the hundreds for the larger devices. Processing
types of radar (or other) systems. Because the within the FPGA is driven by numerous clock
FPGA is a re-configurable, generic, and high- signals, which gate the digital data through the
performance computing device, it can serve as the configured cells. Clock management is one of the
central component in a general-purpose control more challenging aspects of firmware design,
and signal processor subsystem. Indeed, there are when dealing with mixed frequency applications.
now commercial transceivers available that can be This is common for designs that are connecting
utilized in just this manner. Radar system signals that are derived from IF rates to computer
designers can configure a purchased transceiver buses, memories, etc. Fortunately the FPGA
card, rather than having to develop complex and development tools provide capabilities for correctly
specialized hardware. managing the intersection of clock domains.
The purpose of this paper is to summarize one
3 The FPGA Workflow
such project, and provide guidance for those who
are exploring the idea of developing similar The FPGA configuration is commonly
capabilities. A brief introduction to the FPGA is specified with a hardware specification language
given first, followed by a description of the such as the VHSIC Hardware Description
processor architecture. Examples of some diverse Language (VHDL). A sample of VHDL code is
presented in Figure 1. The developer creates text
*
Corresponding author address: Charles Martin, descriptions that define the connections and
National Center for Atmospheric Research, P.O. operations of entities such as signals, registers,
Box 3000, Boulder, CO 80307; and busses. Basic logic and numeric operations,
email:martinc@ucar.edu for example latching, addition and shifting, are
 2

properly on the FPGA. Crafting and successfully

--! Determine if we are on the even or odd pulse
passing simulation test benches are critical to
--! by counting the gates.
even_odd: process (CLK, RST, g, even)
creating reliable FPGA firmware designs.
begin The synthesis step is where the VHDL
if (RST = '1') then description is converted into a specification for the
even <= '1'; digital cell connections on the FPGA. There are
g <= std_logic_vector(conv_signed(0, 16)); several sub-steps in this process. First the
language description is translated into a network
elsif (rising_edge(CLK)) then of logical register specifications. The register
if (VALID_IN = '1') then specification is then mapped onto the basic
if (g = GATES-1) then
component types available on the particular FPGA
even <= not even;
g <= std_logic_vector(conv_signed(0,
being used. Finally, this logical network must be
16)); assigned to the actual logic cells within the
else physical FPGA. This last activity is known as
g <= g + 1; “place and route”, and it is a significant
end if; computational challenge. The place and route task
end if; is both combinatorial and heuristic, and there is no
Figure 1. Example VHDL source code. guarantee that the tool will be able to reach a
solution that will meet the timing constraints of the
defined in the language. Sophisticated design. The development tools provide facilities
computational components are constructed from that allow the human to provide some guidance,
these building blocks. These components are then such as suggesting logical locations to place major
“wired” together to implement a complete control components of the design. The place and route
and signal processing system. algorithm is iterative, as the software attempts to
The complete FPGA configuration will be converge on a solution that meets the timing
defined in a collection of VHDL text files that can requirements. It is not uncommon for the place
be modified using any source code text editor. and route task to require 12 hours or more on a
However, the editing activity is usually performed capable workstation. For this project, place and
within an integrated development environment. route runs in about 20 minutes.
The Xilinx Integrated System Environment (ISE) is The synthesis part of the workflow can cause
a very well known development package. It the FPGA workflow to be tedious. This is another
provides an integrated collection of tools that reason why simulation can greatly enhance the
manage the complete FPGA workflow. The typical development cycle.
sequence of development is as follows: The product of synthesis is the “bitstream”,
• Edit the VHDL file(s) which is the lowest level specification of the FPGA
• Test via simulation connections. The bitstream must now be made
• Synthesize a bitstream available to the FPGA. It can be downloaded
• Download the bitstream to the FPGA directly to the FPGA, but it is more common to
• Test and debug “burn” it into a non-volatile memory such as an
• Return to editing EEPROM, which will later be loaded into the
Some of these steps can be quite lengthy, and volatile FPGA. In either case, the download can be
so one cycle through the workflow can be very performed via a JTAG interface, which provides a
time consuming. direct hardware connection to the FPGA device. If
Simulation is essential to efficient FPGA the FPGA is part of a card located on a host
development. A test vector of simulated inputs are computer’s backplane, there will often be a
created and wired to the component, and the clock mechanism for loading the FPGA directly across
input is driven in order to run the simulation. The the host bus. This eliminates the need for
outputs are verified for correct behavior. Higher- specialized hardware to support the JTAG
level modules comprised of multiple components capability. In some cases only the volatile FPGA
are simulated and tested in the same manner. load can be performed via the host backplane, and
Tools for facilitating simulation are provided by the the JTAG capability is still required for
development environment. The simulations are programming the non-volatile storage.
accurate enough that in general if the VHDL Once the FPGA has been configured with the
simulates properly, and the synthesis step is free bitstream, system testing and debugging can be
of errors, the generated firmware will execute performed. If FPGA problems are detected,
debugging can be initiated. Usually this must be
 3

done indirectly, such as by altering the system

configuration in order to expose and diagnose the
FPGA behavior. Xilinx also provides a very
powerful method (ChipScope) for inserting
firmware probes into the VHDL code so that the
logic behavior can be tracked directly within the
operating FPGA.
Another powerful technique exists for creating
firmware components. A processing algorithm can
be written in a high-level language, such as
Matlab. This code is then compiled to produce a
firmware component that can be integrated with
the VHDL code. Matlab provides a complete
toolbox for crafting signal processing elements
such as filters, fast Fourier transforms, etc. The full
functionality of Matlab is available to investigate
and characterize the performance of these
components.
4 Transceiver Cards
The FPGA provides the computational Figure 2. The Pentek 7142 FPGA transceiver.
foundation for a radar controller and signal The FPGA integrated circuit is enclosed within
processor, but it must be integrated with other the heat sink.
hardware. A transceiver card is required which can
contain explicit user blocks embedded in the data
provide receive, transmit and control signal
flow, to facilitate insertion of custom processing.
functions. Commercial vendors provide products
The board support for the Pentek card was found
that provide this general-purpose functionality. The
to be top notch in this regard.
FPGA is typically combined with analog-to-digital
and digital-to-analog converters, local memory, 5 Radar Implementations
digital I/O lines and bus interfaces. The Pentek
High-level diagrams depicting radar systems
Model 7142 (Figure 2) was employed for this
both with and without an FPGA based transceiver
project. As is common with these products, this
card are shown in Figure 3. The transceiver card
compact card is based on the Portable Mezzanine
replaces a large number of discrete components.
Card (PMC) format. A wide variety of carrier cards
This consolidation has several benefits. The
are available to host the PMC in common
design, construction and testing of some
computer backplanes.
expensive analog sections are completely
The hardware vendor typically offers a board
eliminated. Because the frequency conversion and
support package, which provides drivers and
filtering occur in the digital domain, the processing
application libraries for the host system, and
responses are completely matched and
firmware source code for the FPGA. The first two
characterized without any measurement
provide facilities to access the card on various
procedures. Most important though, is that all of
operating systems. The firmware package can be
these functions can be tailored for specific
a version of VHDL code that will run on the FPGA
applications, with no additional hardware
and provide baseline functionality, so that the card
modification.
can be used in some cases without any VHDL
development. The end user can customize the
supplied VHDL for their specific purposes. 6 The Software-Defined Digital Down
It should be noted that the quality of the firmware Converter (SD3C)
package will have a significant impact on the
The SD3C is a framework that implements the
success of the development. It should be logically
radar signal processing and control functions. It is
organized and well documented, both in the VHDL
built on: (a) firmware operating on a Pentek 7142
files and with other documents. Schematic type
transceiver card, and (b) software support libraries
drawings are invaluable. Ideally it will come with a
for the host computer system. These two
complete project specification for a development
subsystems interact via the computer bus that the
environment such as ISE. The best packages will
card is attached to.
 4

Figure 2. Schematics of a radar system with and without an FPGA transceiver. The yellow boxes denote
functions that are performed by the FPGA firmware.

The SD3C implementation is described here in GateFlow provides specific “user blocks” that
terms of the Pentek card that it currently runs on, intercept the data flow through the FPGA, and into
but it should be noted that a very similar which the user can insert custom processing. The
architecture could be realized using many of the user blocks meet some but not all of the SD3C
commercially available transceiver cards available. needs. The down conversion, matched filtering,
Much of the firmware could be reused with other pulse tagging, coherent integration and
vendor hardware. complimentary code processing are implemented
in VHDL components that are instantiated in the
6.1 SD3C Firmware user blocks.
Figure 4 presents a high level diagram of the GateFlow is oriented towards communications
SD3C signal-processing pipeline. processing, and therefore does not inherently
The SD3C firmware builds upon the Pentek provide the functions needed for pulsed systems.
“GateFlow” infrastructure. GateFlow provides a This required other areas of GateFlow to be
reference firmware design that is capable of modified so that the down-converted data signals
running the transceiver card with basic A/D could be sampled on the pulse repetition
sampling, D/A output and digital I/O. The Pentek frequency (PRF) boundaries. Similarly, the
card is quite sophisticated, providing flexible transmit pulse is generated by feeding baseband
capabilities for onboard memory capture, data values to the up-converter, and GateFlow was
routing and device configuration. modified to also allow this to be synchronized with
the PRF.
 5

Figure 3. The SD3C firmware architecture

A programmable VHDL timer component was and writing SD3C configuration and
created in order to generate timing signals. control registers.
Multiple copies of the timer are instantiated for the Down Combines an fs/n down converter, a
required timing signals, such as the PRF, blanker, Converter Kaiser filter and a Gaussian filter.
and amplifier power control. These signals can be Pulse Prepends an incrementing PRF
used within the FPGA to gate the signal Tagging pulse number, I/Q identifier, format
processing, and they are routed to the FPGA I/O identifier, and channel number to
pins, where they can be brought off board for each received pulse.
connection to other hardware. The current design Coherent Sums the samples for each range
provides eight independent timers. If additional Integration gate, for I and Q, for each channel.
signals are required, it is a simple matter to If complimentary coding is enabled,
instantiate additional timers. the sums are further segregated by
Many of the custom functions within the SD3C even and odd pulse.
are configurable. Typical parameters include filter Table 1. SD3C VHDL components.
coefficients, timer periods, integration intervals,
etc. GateFlow has a control register module that 6.2 SD3C Host Software
allows host software to write and read
configuration registers for the existing GateFlow The transceiver card and its firmware provide
functions. This module was extended to allow the the hardware component for the SD3C. A software
same configuration for SD3C functions. infrastructure implements a high level capability for
Table 1 summarizes the SD3C custom VHDL the host computer to interact with the card.
functions that are incorporated into the GateFlow As is common with most commercial
foundation. transceiver cards, the vendor markets a low-level
software interface that controls the basic card
functions. In this case, Pentek provides the
Block Function
“ReadyFlow” package to support the P7142.
Timer Implements a gang of timers for
ReadyFlow allows the user to configure and
timing signal generation. All timers
capture data from direct memory access (DMA)
are started by a common pulse, but
bus transfers, and to configure other functions in
are free running after that.
the FPGA.
Control Provides the interface for reading
 6

Class Function
p7142sd3c Overall transceiver control
P7142sd3cDn Down-conversion channels
P7142Up Up-conversion channels
Table 2. SD3C main C++ classes.

Figure 4. Simplified C++ SD3C class diagram.

The SD3C package builds upon ReadyFlow to

create a programming interface that represents
the characteristics of a radar processor, and
manages the custom capabilities of the SD3C
firmware. This takes the form of a C++ class
library, whose class hierarchy is shown in Figure
5. The functions of the primary classes are
described in Table 2. These three classes are all
that is required in order to operate the transceiver
as a radar system. The typical program sequence
is as follows:
• Create a p7142sdc3 object, representing a
Pentek P7142 card.
• Create a p7142Up up-converter object, for Figure 6. A typical host software architecture.
configuring the transmit pulse generation.
• Create p7142sd3cDn down-converter objects,
one per channel.
• Configure the timers on the p7142sdc3.
• Issue a start command to the p7142sdc3.
• Loop on read() calls to each of the
p7142sd3cDn objects, ingesting the baseband
received data.

Because the SD3C prepends identifying tags

to each received pulse, the p7142sd3cDn class is
able to detect if data are dropped during the DMA
transfer between the transceiver and the host
system. This can become an issue on a heavily
loaded host with a large data bandwidth. The tags
also allow accurate time stamps to be applied to
the pulses, which would otherwise be ambiguous
due to data transmission lags through the system. Figure 7. A software spectrum analyzer and
Using the SD3C C++ class library, a complete oscilloscope.
radar system can be developed. A typical host
these processes may publish results for other
software architecture is shown in Figure 6. The
downstream subscribers. Segregating the
digital transceiver (DRX) process controls the
functions using a publish/subscribe model allows
transceiver card, reads baseband data from it, and
the processing to be distributed among multiple
publishes the real-time stream to multiple
hosts on the network, as needed. Figure 7
subscribers. The subscribers are visualization,
illustrates a real-time visualization application.
archive, and derived product processes. Some of
 7

449 MHz Wind Profiler W-Band Cloud Radar Ka-Band Microphysics Radar
Application Boundary layer Cloud microphysics Cloud microphysics and water
dynamics vapor retrieval (with S-band
radar)
Frequency
Gate spacing 449
150mMHz 94.4
37m GHz 34.7
75 mGHz
Range 7 km 15 km 7 km

PRF 40 kHz 10 kHz 1 kHz

Peak Power 3 kW 1.5 kW 35 kW

Table 3. SD3C radar applications.

Experience has also shown that separating • Gain confidence by starting with the basics of
specific functions into independent processes VHDL, implementing very simple components
leads to a system which is simpler to construct, that can quickly transit the workflow, and that
more robust, and easier to troubleshoot. It is can be tested easily.
important that the data distribution scheme allows • Make the design as modular as possible, and
the connections between two processes to reuse VHDL code wherever possible.
arbitrarily come and go, without negatively • Create and run simulation test benches for all
impacting either process. The NCAR 449 MHz components.
wind profiler has successfully employed this • Make full use of embedded VHDL probes (e.g.
architecture, using the Open Data Distribution ChipScope) to diagnose problems right on the
Service (OpenDDS) as the data transport FPGA chip.
mechanism.
Use of FPGA technology transforms many
7 Example SD3C Applications aspects of radar system development into a major
software activity. This work benefits greatly by
The SD3C is currently employed in three employing standard software engineering
operational radars, whose characteristics are practices. Designing from a software architecture
summarized in Table 3. These systems cover a perspective, using tools such as integrated
wide range of capabilities. development environments, source code revision
Images of the FPGA transceiver host, the control and bug tracking, and creating embedded
antennas, and sample observations are presented documentation will all greatly enhance the project
in figures 8 through 16 for each system. productivity.
8 Conclusions The SD3C project has demonstrated that an
FPGA solution, based on commercial hardware,
FPGA development has usually been the brings many benefits to system developments
domain of specialized digital hardware engineering such as those described here. The FPGA is
teams. In contrast, the SD3C project was capable of very high signal processing
executed by a very small group of RF system and performance, thus mitigating large data
software engineers, who had to learn the bandwidths and host CPU loads. The technology
technology “on the fly”. The learning curve is facilitates very flexible applications: the same
challenging, and required gaining expertise in hardware can be customized to meet quite
VHDL concepts and FPGA system design. The different requirements simply by loading the
development workflow is intricate and time application specific firmware. Total system costs
consuming, and the support tools are complicated are reduced by leveraging the use of a single
and often non-intuitive. Debugging and testing can FPGA card among several systems, and by the
be very difficult. Based on our experience, the consolidation of functions from many discrete
following recommendations can be made to hardware components onto a single card.
engineers just starting with this technology:
 8

The NCAR 449 MHz Wind Profiler

Figure 8. The spaced antenna array.

Figure 9. The host workstation. The FPGA

transceiver is the card with the three attached
coax cables.

Figure 10. Time-height cross sections of signal-to-noise, vertical velocity, and horizontal winds.
 9

The NCAR W-Band Cloud Radar

Figure 12. The host computer chassis. The FPGA

transceiver is mounted in the carrier card; second
Figure 11. The transmit and receive antennas, with a slot from the left.
horizontal reflector for ground testing.

Figure 13. A time-height cross section of reflectivity.

 10

The NCAR S-Band/Ka-Band Microphysics Radar

Figure 5. The host computer chassis. The

FPGA transceiver is mounted in the compact
Figure 6. The large S-Band antenna carrying the PCI carrier below the four larger coax cables.
smaller Ka-band antenna on the lower right.

Figure 7. A reflectivity PPI display from the Ka-band radar.