Fall 2007 • Vol. 16, No. 3

Pentek, Inc.One Park Way, Upper Saddle River, NJ 07458Tel: (201) 818-5900 • Fax: (201) 818-5904email: pipeline@pentek.comhttp://www.pentek.com

© 2007 Pentek, Inc. Newsletter Editor: TNT ResourcesTrademarks are properties of their respective owners.Specifications are subject to change without notice.

A quarterly publication for engineering system design and applications.

Tools for Real-Time Embedded System DevelopmentIn This Issue

● Real-Time Embedded SystemsReal-Time Embedded SystemsReal-Time Embedded SystemsReal-Time Embedded SystemsReal-Time Embedded SystemsDDDDDevelopmentevelopmentevelopmentevelopmentevelopment is driven by theunique requirements of eachapplication. More about the natureof hardware and software in thefeature article.

● Product Focus: Product Focus: Product Focus: Product Focus: Product Focus: Model 7142multichannel transceiver withinstalled core -428. Click hereClick hereClick hereClick hereClick here

Technical ResourcesDownload the 6th edition of theDigital Receiver Handbook:

pentek.com/go/pipedrhbpentek.com/go/pipedrhbpentek.com/go/pipedrhbpentek.com/go/pipedrhbpentek.com/go/pipedrhb

Download the 3rd Edition of FPGAsfor Software Radio Handbook:

pentek.com/go/pipefpgahbpentek.com/go/pipefpgahbpentek.com/go/pipefpgahbpentek.com/go/pipefpgahbpentek.com/go/pipefpgahb

Download the 2nd Edition of Criti-cal Techniques for High-Speed A/DConverters in Real-Time SystemsHandbook:

pentek.com/go/pipehshbpentek.com/go/pipehshbpentek.com/go/pipehshbpentek.com/go/pipehshbpentek.com/go/pipehshb

Rodger Hosking, Pentek VicePresident and Cofounder

Figure 1. Real-Time Record/Playback System Hardware Components

“The philosophy of the hardwareand software architectures

presented hereshould provevaluable inhelping youmake the cor-rect decisionswhen start-ing your

nextdesign of a real-time embedded

system”

With each new opportunity, real-timeembedded system developers con-front a unique set of challenges

specific to the requirements at hand. Althoughmethodology and lessons learned in previousprojects are invaluable, each new system intro-duces increasingly more complex hardware andsoftware. Estimating correctly how long develop-ment will take, choosing the right approach, andselecting the appropriate tools are crucial fordelivering the project on time and coming outahead on the bottom line. Towards that end,the strategies, considerations and tradeoffs pre-sented here should offer some useful insights.

Hardware EnvironmentA typical real-time embedded system, like the

one shown in Figure 1, includes high-speed A/Dand D/A converters plus the associated circuitryfor clocking, gating, triggering and synchroniz-ing multiple channels. Digital upconverter anddownconverter ASICs provide frequency transla-tion for communications and radar applications.FPGAs handle tough real-time signal processingtasks like FFTs, encoding and decoding, encryptionand decryption, modulation and demodulation,and beamforming. A fast memory, buffers signal

data to support efficient block transfers to andfrom other system resources. Often, a fast harddisk allows the system to handle real-time storageand playback of signal data. A control processormanages system resources and often performssome additional signal processing and data for-matting tasks.

Connected through an Ethernet link, a hostPC workstation running Windows or Linux pro-vides essential non-real-time hardware resourcesfor the operator interface including a monitor,keyboard and mouse. The PC also provideshigh-capacity disk storage for archiving data filesand network connections to the office or facility.

All the necessary hardware components arepresent, but which software components willensure that the system performs the way it should?

Software ConsiderationsA good choice for the real-time control pro-

cessor is usually a DSP or RISC processor. Itshould be free of tasks not directly related toessential data movement, formatting or process-ing. During real-time operation, there should beminimum interaction with the PC. However, be-fore and after real-time operations, the Ethernetlink can be extremely useful for initializing the ➤

2

Figure 2. Real-Time Record/Playback System Software Components

Tools for Real-Time Recording System Development

➤ real-time hardware, configuring modesof operation and for moving data betweenthe real-time disk and the PC disk file system.

Figure 2 is a proposed software modelfor the real-time recording system shown inFigure 1, partitioned into real-time and non-real-time domains and joined by Ethernet.While this diagram looks complicated atfirst, each software module serves a well-defined, essential function to maintainperformance while easing software devel-opment tasks.

Inside the Real-Time SystemThe real-time system on the left side of

Figure 2 uses a real-time operating system(RTOS) with low latencies and determinis-tic behavior to guarantee that no data willbe lost while managing the critical tasks itneeds to perform. The Board Support Li-braries feature well-defined subroutine callsto implement low-level control for all ofthe real-time front-end hardware resources.This includes configuring the A/Ds and D/As,setting parameters for the digital up- anddownconverters, and defining modes in thetiming section for triggering, gating andsynchronization.

The SCSI file system uses RTOS calls tomanage real-time transfer to and from thelocal Fibre Channel hard disk. A FibreChannel protocol layer provides a completehigh-speed file system interface suitable forreal-time recording and playback.

Nearly every RTOS also provides a nativestack for Ethernet, TCP/IP drivers and sup-port for sockets, a very popular applicationlayer protocol for networks.

Each of these three resource groups—the Board Support Libraries, the Fibre Channelinterface and a network socket interface—are integrated by the Record /Play ServerAPI (Application Programming Interface)into a set of intuitive high-level functions tosimplify development of custom serverapplications.

The Record/Play Server Application ontop, acting as the executive in charge, hascomplete access to generate and receiveEthernet commands and status, directingreal-time data streams on and off the FibreChannel hard disk, and controlling all oper-ating parameters and modes of the frontend data acquisition hardware.

With these software components, thereal-time hardware has now assumed therole of a complete, stand-alone functionalserver subsystem. It is capable of respondingto Ethernet commands that are interpretedby the server application and then dispatchedefficiently by the server API. When thefunction is complete, the server applicationcan issue an Ethernet message along withany relevant parameters about the operation.

By extending the code in the serverapplication so that it understands andimplements different or more complexcommands, the real-time subsystem canacquire new features. These new commandssimply implement a new set of calls to theexisting collection of Record/Play ServerAPI functions. For example, a new Ethernetcommand might fetch data from the FibreChannel disk and deliver back through theEthernet port.

Inside the Workstation PCThe Workstation PC on the right side of

Figure 2 assumes the role of the client, bysending and receiving Ethernet messagesto and from the real-time server subsystem.Virtually all workstation operating systemsinclude native support for Ethernet, TCP/IP,and sockets to support the message transfers.

The Client API manages the socket mes-sage traffic by appropriately formingoutgoing Ethernet commands so they areunderstood by the real-time server and in-terpreting status messages that are returnedby the server. Like the Record/Play ServerAPI, it presents a set of easy-to-use high-level commands suitable for client userapplications.

Additional socket connections deliverEthernet data from the server into theSignal Viewer. This application delivers agraphical representation of signals on thePC screen, providing the operator with anoscilloscope display for viewing signaldata. This can be useful for checking snap-shots of live data from the A/D converterbefore recording, for verifying the live out-put of a digital downconverter, and forviewing the data recorded on the FibreChannel hard drive after the recording.

Any such operations required by the cli-ent application, must first be implementedin the client API and then supported as for-mal commands by the server application.Of course, the necessary functions toexecute those commands need to be avail-able in the Record/Play Server API. If not,additional API functions can always be cre-ated as required. ➤

3

Figure 3. Candidates for System Hardware and Software Components

Tools for Real-Time Recording System Development

➤ One typical client application is a virtualinstrument panel GUI (graphical user inter-face) displayed on the monitor. Withbuttons, knobs, sliders, switches, indica-tors, status windows and parameter entrywindows, the operator simply uses themouse and keyboard to control operations.Such an application can be written in VisualC, Visual Basic or JAVA to make a visuallyattractive and functional layout. The GUIwould make the appropriate calls to theclient API according to which buttons arepushed or which parameters are entered.

Another type of client application couldbe a larger application that needs a record/play subsystem as an I/O resource. In thiscase, the larger application might be writ-ten in C or C++, or any other languagesupported by the operating system. Likethe GUI, it would also make calls to the cli-ent API to setup up the hardware, start andstop the recording and then fetch databack into the application. By adding thistype of functional subsystem that is easy touse and fully characterized, system devel-opers can slash development time andreduce risks.

The rationale for each of the many soft-ware blocks shown in Figure 2 should nowbe appreciated. The modular architectureof this system helps custom applicationdevelopers to take advantage of the stan-dardized, well-defined interfaces betweenthe modules to add new features, commandsand functions. The existing commands andsubroutine structures offer excellentexamples for building new ones that arefully compliant with the rest of the system.Operating system revisions, maintenanceupgrades, and ports to different operatingsystems all benefit from this modularity.

Figure 3 shows some appropriate candi-dates for the various modules discussed toillustrate the many choices available. Clientworkstation platforms for these systemsrange from handheld devices, blade servers,embedded PCs, laptops, and desktop PCsto networked clusters of high-end multi-processing systems. In each case, theprocessors must support a diverse set ofinfrastructure functions best handled byoperating systems like Windows, Linux,Unix, or Solaris.

Client applications and the client APIcan be written in C or C++, and GUI com-ponents can use visual versions of thesetools. A popular trend towards using JAVAfor both the client applications and APIhelps with portability across platforms andoperating systems. The signal viewer applica-tion is an ideal candidate for LabVIEWwhich offers tools specifically orientedtowards signal processing and display, andis now available for many workstationenvironments.

By its nature, the real-time server systemis less heterogeneous and runs under oper-ating systems like VxWorks, eCos, or LynxOS.Most of the components, including the boardsupport libraries, server application andAPI, and the network and disk drivers areall written in C or C++, with some lowerlevel functions coded in assembly language.

Putting It All TogetherPentek’s SystemFlow® is an implementa-

tion of this software framework. It wasdeveloped to address hardware platformslike the real-time recording/playback systemof Figure 1, which is similar to the PentekRTS 2504 Real-Time Recorder/Playbacksystem.

SystemFlow includes the software mod-ules shown in Figure 2 written with thesoftware tools highlighted in color in Fig-ure 3. By following this proposed softwarearchitecture, SystemFlow successfully ful-fills two different product objectives forthe same hardware: 1) a ready-to-userecord/playback instrument, and 2) a real-time signal processing development platform.

To meet the needs of the record/play-back instrument, special enhancementswere made. These include a complete vir-tual instrument GUI, a real-time file manager,and a full-featured signal viewer. The work-station GUI, shown in Figure 4 on the nextpage, was written in JAVA and runs underboth Windows and Linux.

Intuitive buttons, indicators, status win-dows and parameter entry windows aregeared for novice users who simply wantto capture signals and transfer files to theirworkstation.

A sophisticated File Manager, imple-mented through extensions to both theclient API (also written in JAVA) and theserver API (written in C), supports user-named files and headers that automaticallystore important system parameters in eachrecording. ➤

4

➤ The client Signal Viewer shown in Fig-ure 5 is written in LabVIEW and includesdisplay windows for both time and frequencydomains, dual annotated cursors, and auto-matic calculation of critical signal parameterssuch as harmonic distortion and signal tonoise ratio.

To meet the alternate needs of a real-time signal processing development platform,SystemFlow includes source code for thesoftware modules that were created for therecord/play instrument. System developerscan start with this fully functioning instru-ment and incrementally extend, replace, ormodify each module as required to meetthe custom requirements they need.

For customizing workstation modules,JAVA source is provided for the client GUIapplication and client API, and the LabVIEWscript is provided for the Signal Viewer.

For customizing server modules, a com-plete eCos development environmentrunning under Windows offers license-free,open-source tools including the GNUcompiler, Insight for the GDB debugger,CYGWIN make utilities, an eCos kernelconfiguration utility, and a TFTP server. Csource code is supplied for the record/playserver application and server API, the filemanager and the socket interface. Pentek

Tools for Real-Time Recording System Development

For FPGA code development, the XilinxISE Foundation Tool Suite is installed in theWindows workstation. The PentekGateFlow® FPGA Design Kit contains allISE project files and VHDL source code forthe specific hardware boards. In this way,FPGA developers can build upon the stan-dard interfaces and structures alreadyinstantiated. An FPGA code loader utilitytransfers newly created FPGA bit streamsthrough the Ethernet link into the FPGA.

All software development tasks for theworkstation, the real-time server, and theFPGAs are performed on the Windowsworkstation. All real-time server develop-ment tasks are supported across theEthernet link through drivers and utilities.Except for the optional Xilinx ISE tools andGateFlow Design Kit, all these resourcesare bundled into the SystemFlow package.

The unique requirements of each real-time embedded system will drive choicesin the hardware, the nature and function ofthe software modules, the operating sys-tems and software languages. However,the philosophy of the software architec-ture outlined here should prove valuable inhelping you make those decisions whenstarting your next design. ❑

Figure 4. Pentek RTS 2504 VirtualInstrument GUI

Figure 5. Pentek RTS 2504 Signal Viewer

ReadyFlow® Board Support Libraries includeC source code for the data movement,mode and parameter initialization, timingand control of all hardware resources onthe boards.

5

Model 7142-428

GateFlow Transceiver with Four Multiband DDCsand Interpolation Filter - PMC/XMC

7142-428 Installed Core

Features● Complete software radio transceiver

solution● Four 125 MHz 14-bit A/Ds● Two Xilinx Virtex-4 FPGAs● One 500 MHz 16-bit D/A● GateFlow Core 428 with four high-

performance multiband DDCs andInterpolation Filter factory-installed

● Two sets of 18-bit user-programmableFIR filter coefficients

● Decimation range from 2 to 65,536● Interpolation range from 2 to 32,768● I/O bandwidths from 8 kHz to 40 MHz● Multiple module synchronization

General InformationModel 7142-428, Digital Transceiver with

Multiband DDC Core and Interpolation Filter,is a complete software radio system in aPMC/XMC module. It includes four A/D andone D/A converters capable of bandwidthsto 40 MHz and above for connection to HF orIF ports of a communications or radar system.

The front end accepts four full scaleanalog HF or IF inputs on front panel MMCXconnectors at +10 dBm into 50 ohms withtransformer coupling into Linear TechnologyLTC2255 14-bit 125 MHz A/D converters.

The digital outputs are delivered to theVirtex-4 FPGA for signal processing or forrouting to other module resources.

A TI DAC5686 digital upconverter (DUC)and D/A accepts a baseband real or complexdata stream from the FPGA with signal band-widths up to 40 MHz.

When operating as an upconverter, itinterpolates and translates real or complexbaseband input signals to any IF centerfrequency between DC and 160 MHz. Itdelivers real or quadrature (I+Q) analogoutput samples at up to 320 MHz to the 16-bitD/A converter. Analog output is througha front panel MMCX connector at +4 dBminto 50 ohms. If translation is disabled, theDAC5686 acts as an interpolating 16-bit D/Awith output sampling rates up to 500 MHz.

Core 428 Multiband DDCsThe Core 428 downconverter translates

any frequency band within the input band-width range down to zero frequency. TheDDCs consist of two cascaded decimatingFIR filters. Each filter is capable of any deci-mation from 2 to 256. The decimations ofthe first stage filter and the second stagefilter multiply to yield overall decimationfactors up to 65,536.

The NCO provides over 108 dB spuri-ous-free dynamic range (SFDR). The FIRfilter is capable of storing and utilizing two

independent sets of user-programmable18-bit coefficients.

Four identical Core 428 DDCs are factoryinstalled in the 7142 FPGA. An input multi-plexer allows any DDC to independentlyselect any of the four A/D sources. The totaldecimation range from 2 to 65,536 providesoutput bandwidths from 50 MHz downto 1.52 kHz for an A/D sampling rate of125 MHz and assuming an 80% filter.

Core 428 Interpolation FilterThe Core 428 interpolation filter increases

the sampling rate ofreal or complex base-band signals by afactor of 16 to 2048,programmable in stepsof 4, and relieves thehost processor fromperforming upsamplingtasks. The interpolationfilter can be used in se-ries with the DUC’sbuilt-in interpolation,creating an interpolationfactor up to 32,768.

For more informationand a price quotationclick here:

pentek.com/go/pentek.com/go/pentek.com/go/pentek.com/go/pentek.com/go/pipe7142-428pipe7142-428pipe7142-428pipe7142-428pipe7142-428 ❑

CH ARF In

SampleClock In

CLOCK &SYNC

GENERATOR

LTC2255125 MHz

14-bit A/D

XILINX XC4VSX55 FPGA WITH GATEFLOW FACTORY INSTALLED CORE 428

XTALOSC A

RFXFORMR

MEM WFIFO

PCI 2.2INTERFACE

PCI BUS64 bits/66 MHz

Clock/SyncBus XTAL

OSC B

A

MEM RFIFO

A/D AFIFO

A/D BFIFO

A/D CFIFO

A/D DFIFO

USER INFIFO

USER OUTFIFO

128 MBDDR SDRAM

MEMORYCONTROL

&DATA ROUTING

A/D DA/D CA/D BA/D A

MUXA/D A

MUXA/D B

DDC A

DDC B

MUXMEMORYD/A A FIFO

A/D AA/D BA/D CA/D DD/A

128 MBDDR SDRAM

256 MBDDR SDRAM

CFIRFILTER

CICFILTER

INTERPOLATION: 16 - 2048

CH BRF In

LTC2255125 MHz

14-bit A/D

RFXFORMR

RF Out RFXFORMR

CH CRF In

LTC2255125 MHz

14-bit A/D

RFXFORMR

CH DRF In

LTC2255125 MHz

14-bit A/D

RFXFORMR

DIGITALDOWNCONVTER A

STAGE 2DEC: 1 - 256

DIGITALDOWNCONVTER A

STAGE 1DEC: 2 - 256

MUX

D/AFIFO

MUXA/D C

MUXA/D D

DDC C

DDC D

16-BIT500 MHz

D/A

DAC5686DIGITAL

UPCONVERTER

A/D DA/D CA/D BA/D A

DIGITALDOWNCONVTER B

STAGE 2DEC: 1 - 256

DIGITALDOWNCONVTER B

STAGE 1DEC: 2 - 256

A/D DA/D CA/D BA/D A

DIGITALDOWNCONVTER C

STAGE 2DEC: 1 - 256

DIGITALDOWNCONVTER C

STAGE 1DEC: 2 - 256

A/D DA/D CA/D BA/D A

DIGITALDOWNCONVTER D

STAGE 2DEC: 1 - 256

DIGITALDOWNCONVTER D

STAGE 1DEC: 2 - 256

MUX

MUX

MUX

TOTAL DECIMATION: 2 - 65536