Sff Sca Dp - User's Guide

SSFFFF SSCCAA DDeevveellooppmmeenntt PPllaattffoorrmm

UUsseerr’’ss GGuuiiddee

MMaarrcchh 22000088

Revision history

Revision Date Comments

1.0 March 2008 First version.

© Lyrtech Inc. All rights reserved.

No part of this document may be reproduced or used in any form or by any means — graphical, electronic, or mechanical (which includes photocopying, recording, taping, and information storage/retrieval systems) — without the express written permission of Lyrtech Inc.

To ensure the accuracy of the information contained herein, particular attention was given to usage in preparing this document. It corresponds to the product version manufactured prior to the date appearing on the title page. There may be differences between the document and the product, if the product was modified after the production of the document.

Lyrtech Inc. reserves itself the right to make changes and improvements to the product described in this document at any time and without notice.

Version 1.0

iii

Trademarks Acrobat, Adobe, and Reader are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. IBM is a registered trademark of International Business Machines Corporation in the United States, other countries, or both. Intel and Pentium are registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Microsoft, MS-DOS, Windows, Windows NT, and the Windows logo are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. MATLAB, Simulink, and Real-Time Workshop are registered trademarks of The MathWorks, Inc. Xilinx, Spartan, and Virtex are registered trademarks of Xilinx, Inc. Texas Instruments, Code Composer Studio, C62x, C64x, and C67x are trademarks of Texas Instruments Incorporated. All other product names are trademarks or registered trademarks of their respective holders.

The TM and ® marks have been omitted from the text.

WARNING Do not use Lyrtech products in conjunction with life-monitoring or life-critical equipment. Failure to observe this warning relieves Lyrtech of any and all responsibility.

FCC WARNING This equipment is intended for use in a controlled environment only. It generates, uses, and can radiate radio frequency energy and has not been tested for compliance with the limits of personal computers and peripherals pursuant to subpart J of part 15 of the FCC rules. These rules are designed to provide reasonable protection against radio frequency interference. Operating this equipment in other environments may cause interference with radio communications, in which case the user must, at his/her expense, take whatever measures are required to correct this interference.

SFF SCA development platform - User's guide - v1.0

iv

This page was left intentionally blank.

Introduction

v

Introduction

Congratulations on the purchase of the software configuration architecture (SCA) version of the SFF SDR development platform.

Organization This user’s guide, intended to guide you in the uses of the SFF SCA development platform, is organized as follows:

SFF SCA development platform infrastructure introduces the infrastructure used on the platform.

CORBA FPGA development with VHDL explains how to develop VHDL applications for the platform.

Examples outlines the examples supplied with the SFF SCA development platform.

Partial reconfiguration of FPGA delves into how to partially reconfigure the FPGA with non-CORBA and CORBA applications.

Conventions In a procedure containing several steps, the operations that the user has to execute are numbered (1, 2, 3…). The diamond (♦) is used to indicate a procedure containing only one step, or secondary steps. Lowercase letters (a, b, c…) can also be used to indicate secondary steps in a complex procedure.

The abbreviation NC is used to indicate no connection.

Capitals are used to identify any term marked as is on an instrument, such as the names of connectors, buttons, indicator lights, etc. Capitals are also used to identify key names of the computer keyboard.

All terms used in software, such as the names of menus, commands, dialog boxes, text boxes, and options, are presented in bold font style.

The abbreviation N/A is used to indicate something that is not applicable or not available at the time of press.

Note The screen captures in this document are taken from the software version available at the time of press. For this reason, they may differ slightly from what appears on your screen, depending on the software version that you are using. Furthermore, the screen captures may differ from what appears on your screen if you use different appearance settings.


vi

Glossary of terms Throughout this document, you will find references to the following terms. Refer to the following table as to their definitions.

Table 1 Glossary of terms

Term Definition

Application programming interface (API) An application programming interface is the interface that a computer system, library, or application provides to allow requests for services to be made of it by other computer programs or to allow data to be exchanged between them.

Base design Empty design or template that is incapable of data processing and is not instantiated in the custom logic of the board’s FPGA.

Board software development kit Abbreviated BSDK, this kit gives users the possibility to quickly become fully functional developing C/C++ or assembly code for the DSP, and HDL code for the FPGA through an understanding of all Lyrtech boards’ major interfaces.

Computer communication development Refers to developing custom communications applications to communicate with Lyrtech boards.

Default design Design loaded by default on Lyrtech boards used for FPGA design.

Digital signal processing Digital signal processing is the study of signals in a digital representation and the processing methods of these signals. The algorithms required for DSP are sometimes performed using specialized devices that use specialized microprocessors called digital signal processors (DSP).

Digital signal processor (DSP) A digital signal processor is a specialized microprocessor designed specifically for digital signal processing, generally in real time.

Example Refers to examples used to demonstrate functions or applications supplied with the board software development kit. For this reason, examples come in two flavors: application examples and functional examples.

HDL Stands for hardware description language.

Host A host is defined as the device that configures and controls a Lyrtech board. The host may be a standard computer or the CPU board of the cPCI chassis system where the Lyrtech board is installed. You can develop applications on the host for Lyrtech boards through the use of an application programming interface (API) that comprises protocols and functions necessary to build software applications. These API are supplied with the Lyrtech board.

Model-based design Refers to all the Lyrtech board-specific tools and software used for development with the boards in MATLAB and Simulink and the Lyrtech model-based design kit(s).

Reception Any data received by the referent is a reception. Abbreviated RX.

Reference design Blueprint of an FPGA system implanted on Lyrtech boards. It is intended for others to copy and contains the essential elements of a working system (in other words, it is capable of data processing), but third parties may enhance or modify the design as necessary.

Software development Refers to development performed with and for the platform with a software development kit. Software development for a board comes in three flavors: host software development, DSP software development, and FPGA software development.

Transmission Any data transmitted by the referent is a transmission. Abbreviated TX.

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

Introduction

vii

Term Definition

VHDL Stands for VHSIC hardware description language.

VHSIC Stands for very-high-speed integrated circuit.

Technical support Lyrtech Inc. is firmly committed to providing the highest level of customer service and product support. If you experience any difficulties when using our products or if it fails to operate as described, we suggest that you first consult the user’s guide, and then, if you are still in need of assistance, call our technical support department:

Telephone: (1) 418-877-4644 (1) 888-922-4644 Hours: Monday to Friday, 9:00 AM to 5:00 PM (EST) Fax: (1) 418-877-7710 E-mail: [email protected]

mailto:[email protected]


viii


Introduction

ix

Table of contents

Introduction ........................................................................................................................................................... v Organization.......................................................................................................................................................... v Conventions........................................................................................................................................................... v Glossary of terms .................................................................................................................................................vi Technical support ................................................................................................................................................vii List of figures and tables ......................................................................................................................................xi

SFF SCA development platform infrastructure..........................................................................1 SCA component structural overview..................................................................................................................... 1 SFF SCA development platform transports........................................................................................................... 2

TCP/IP transport ........................................................................................................................................... 2 VPSS transport.............................................................................................................................................. 2 DSPLink transport ........................................................................................................................................ 2

SFF SCA development platform device nodes...................................................................................................... 3 DSP ...................................................................................................................................................................... 7

RFFE proxy .................................................................................................................................................. 7 ADAC proxy................................................................................................................................................. 7 PCM3008 proxy............................................................................................................................................ 8

Example FRS application...................................................................................................................................... 9 Importing an FRS application in SCA Architect .......................................................................................... 9 Deploying an FRS application .................................................................................................................... 10 ARM processor ........................................................................................................................................... 11 DSP ......................................................................................................................................................... 11

Deploying the SFF SCA development platform.................................................................................................. 13 Design flow................................................................................................................................................. 13 NFS server setup......................................................................................................................................... 15 Starting the SCA Core Framework ............................................................................................................. 15 Deploying the SFF SCA development platform’s FRS example application ............................................. 16 Radio Manager............................................................................................................................................ 16

CORBA FPGA development with VHDL..................................................................................19 Preliminary readings ........................................................................................................................................... 19 Overall structure and tool compatibility.............................................................................................................. 19

SCA-specific reference design folder structure .......................................................................................... 19 Hardware description language tool compatibility ..................................................................................... 20

FPGA VHDL design block diagram ................................................................................................................... 20 CORBA-specific module list ...................................................................................................................... 20 CORBA application block .......................................................................................................................... 22

CORBA application design and implementation examples ................................................................................ 23 Generic folder structure for the examples................................................................................................... 23 Simple counter examples ............................................................................................................................ 23 FRS application examples........................................................................................................................... 25

Examples .......................................................................................................................................29 Performing examples — Generic procedure ....................................................................................................... 29

Counter examples ....................................................................................................................................... 29 Configuring examples................................................................................................................................. 29 Procedure .................................................................................................................................................... 30 Expected results .......................................................................................................................................... 30


x

Partial reconfiguration of FPGA................................................................................................31 Recommended readings ...................................................................................................................................... 31 Overall structure and tool compatibility.............................................................................................................. 31

Hardware description language tool compatibility ..................................................................................... 31 FPGA PR-specific reference design folder structure .................................................................................. 32 Suggested project folder structure............................................................................................................... 32 Design module hierarchy ............................................................................................................................ 33

PR design flow .................................................................................................................................................... 34 Batch file descriptions ......................................................................................................................................... 34 Loading PR bitstreams to the platform................................................................................................................ 35 Generic CORBA design for PR........................................................................................................................... 35

PR CORBA design considerations ............................................................................................................. 35 Using the Lyrtech development platform command shell to load designs.................................................. 36

PR design examples ............................................................................................................................................ 36 Non-COBRA PR design ............................................................................................................................. 36 CORBA PR design ..................................................................................................................................... 36

List of figures and tables

xi

List of figures and tables

Figure 1 SCA component structural overview.............................................................................................................. 1 Figure 2 ORB transport localization ............................................................................................................................. 2 Figure 3 SFF SCA development platform ARM node.................................................................................................. 3 Figure 4 Example FRS SCA application ...................................................................................................................... 9 Figure 5 Workspace Launcher dialog box .................................................................................................................... 9 Figure 6 New Project dialog box .................................................................................................................................. 9 Figure 7 New Project dialog box (2)........................................................................................................................... 10 Figure 8 Open Perspective dialog box ........................................................................................................................ 10 Figure 9 Deployed nodes displayed inside Radio Manager........................................................................................ 16 Figure 10 Radio Manager ORB selection ................................................................................................................... 16 Figure 11 Radio Manager connection parameters ...................................................................................................... 17 Figure 12 CORBA FPGA VHDL design block diagram............................................................................................ 20 Figure 13 Generic folder structure.............................................................................................................................. 23 Figure 14 FRS multi-application example block diagram .......................................................................................... 26 Figure 15 FRS client-to-servant data paths block diagram......................................................................................... 27 Figure 16 Suggested PR project folder structure ........................................................................................................ 32 Figure 17 PR hierarchy block diagram ....................................................................................................................... 33 Figure 18 block diagram of SFF SDR SCA design modified for PR. ........................................................................ 35

Table 1 Glossary of terms............................................................................................................................................vi Table 2 RFFE device properties mapping..................................................................................................................... 4 Table 3 ADAC device properties mapping................................................................................................................... 4 Table 4 ADC-CHHANEL_A_GAIN property ............................................................................................................. 5 Table 5 ADC-CHHANEL_B_GAIN property ............................................................................................................. 5 Table 6 PCM3008 device properties mapping.............................................................................................................. 5 Table 7 CODEC_SAMPLING_FREQUENCY property values .................................................................................. 6 Table 8 SFF SCA development platform reference design folders............................................................................. 19 Table 9 Supported HDL tools ..................................................................................................................................... 20 Table 10 Folder description ........................................................................................................................................ 23 Table 11 Supported HDL tools ................................................................................................................................... 31 Table 12 SFF SCA development platform PR reference design folders..................................................................... 32 Table 13 Suggested PR project folder structure description ....................................................................................... 33 Table 14 Batch file descriptions ................................................................................................................................. 34


xii


SFF SCA development platform infrastructure

1


This document provides software communications architecture (SCA)-related information about the SFF SCA development platform. The platform’s SCA environment is the Communications Research Centre Canada (CRC)’s Core Framework, hosted by the ARM processor of the platform. This processor also runs Green Hills Software’s INTEGRITY RTOS. The DSP of the platform runs Texas Instruments’ DSP/BIOS real-time kernel. Refer to the quick start guide for version information.

Notes • At this time, the DSP does not run native SCA components, but still supports OIS’ ORBexpress. • Before proceeding, it is important for you to be familiar with SCA concepts and be familiar with the

documentation of the software necessary to this platform, as outlined in the quick start guide.

The platform supplies one SCA node and one SCA application implementing a Family Radio Service (FRS) waveform (for illustration purposes). The FRS application includes software components over several processing elements. Within the context of the FRS example application, the ARM processor hosts the Core Framework and it is only used to control and deploy devices and applications. As delivered, the ARM does not perform any signal processing functions. The DSP, on the other hand, performs digital signal processing on the TX data stream coming from the hardware codec and going to the FPGA. On the opposite side, it performs digital signal processing on the RX data stream coming from the FPGA and going to the hardware codec. The FPGA performs signal processing functions before/after sending/receiving the data to/from the DAC/ADC and RF front-end hardware devices.

SCA component structural overview Because native SCA components are not yet supported by the DSP, proxy objects are used on the DSP instead. Their primary functions are to control the hardware devices and process signals for the FRS waveform application supplied with the platform. The proxy objects are controlled by the SCA devices and resources of the ARM.

Note The word proxy is used in this context because the objects to which it refers perform work that the logical devices cannot perform themselves. In other words, the proxy objects work on behalf of the logical devices.

Figure 1 SCA component structural overview


2

The above figure gives an overview of how the system is partitioned and the communication mechanisms used between components:

• Resources and devices on the ARM configure the proxy objects on the DSP with CORBA through the DSPLink ORB transport.

• Data is exchanged between the FPGA and the DSP through CORBA by the VPSS transport. • In the DSP’s address space, proxy objects use CORBA to exchange data with each other. • Proxy objects communicate with device drivers through standard C functions. • The ARMExecutableDevice uses device drivers to load DSP and FPGA images during the FRS application

deployment.

SFF SCA development platform transports The SFF SCA packages use three different CORBA transports to handle communications across every SCA devices on the platform. The following diagram illustrates where each transport is used.

Figure 2 ORB transport localization

TCP/IP transport

The TCP/IP transport is a standard transport distributed with OIS ORBexpress. See its documentation details.

VPSS transport

The VPSS transport is used to exchange CORBA messages between the DSP and the FPGA of the platform. This transport only has one upstream and one downstream channel, but does not support dynamic channel allocations, unlike the TCP/IP transport. Because there is only one channel available in each direction, connections are implicitly established when clients bind to servers. The same applies to servers — instead of listening for incoming connection requests at the end point, servers listen for CORBA requests at that end point.

The name of the transport’s end point is VPSS:ChannelID, where ChannelID can be any number as it is ignored by the transport.

Note The VPSS transport is limited to 800 bytes per message. The total size of CORBA messages, headers, and payload should therefore be equal to or less than 800 bytes.

DSPLink transport

The DSPLink transport is used to exchange CORBA messages between the DSP and the ARM of the platform. This transport can handle up to five bidirectional channels on which up to eight different client could be attached at the same time.

The name of the transport’s end point is DSPLINK:ChannelID, where ChannelID is a number between 0 and 4.

The first client that attach to a channel is designed the default listener on that channel. The default listener will handle every communication on the channel that has no local client. The default listener is used by the ORB transport acceptor to create new connection over a channel.


3

SFF SCA development platform device nodes The SFF SCA development platform has four logical devices — ARMExecutableDevice, RFFEDevice, ADACDevice, PCM3008Device — each controllable through the SCA. The mechanism used to control the devices is the PropertySet interface, as defined by the SCA specifications, which means that configuration operations and queries are used to configure devices’ parameters. Users can perform these operations through the CRC’s RadioManager. When they receive configuration request, the logical devices forward said requests to the appropriate proxy objects on the DSP. In turn, the proxy objects call device drivers to configure the appropriate hardware devices.

Figure 3 SFF SCA development platform ARM node

The above figure illustrates the components running on the ARM processor. Components to be deployed and connections to establish are described in the device configuration descriptor (ArmNode.dcd.xml). When it starts, DeviceManager reads ArmNode.dcd.xml. DeviceManager then deploys the components and establishes connections to the logger and incoming domain management (IDM) event channel.

Log

The standard log component coming from CRC’s SCARI++ is deployed on the ARM node to accept log messages from other components. SCA components on the SFF SCA development platform are connected to this service during deployment.

ArmExecutableDevice

This device provides services to:

• Load and run INTEGRITY binary code files on the ARM processor. • Load bitstream files (.bit) on the Virtex-4 FPGA.


4

• Load software output files (.out) on the DSP.

You do not have to interact directly with this device. The services provided are used by the Core Framework’s deployment machinery during the example FRS application’s deployment phase.

RFFE device

This logical device encapsulates the RF front-end hardware device functionalities. The following table presents the properties-to-device driver mapping. Remember that device driver functions are not directly called by the logical device, but by the corresponding proxy object. They are, however, included in the table because configuring a given property ultimately results in calling the associated device driver.

Table 2 RFFE device properties mapping

Property Type Mode Driver call

RX_POWER Long Read/Write RFFE_GetPowerRX()/ RFFE_SetPowerRX

TX_POWER Long Read/Write RFFE_GetPowerTX()/ RFFE_SetPowerTX

PLL1_LOCK_STATE Long Read only RFFE_GetPllLockState(ID_PLL1)




The RFFE logical device implements the standard CF::Device IDL interface and a proprietary IDL interface. The proprietary interface is used to register a reference to the associated proxy object running on the DSP. When it starts, the associated proxy object registers with the logical device. The logical device then stores the proxy object’s reference, which is later used to communicate with the proxy object. The registration interface appears below:

module Lyrtech

{

interface RFFEController : CF::Device

{

void registerRFFEDeviceProxy(in RFFEDeviceProxy proxy);

};

};

ADAC device

This logical device encapsulates the ADC/DAC hardware device functionalities. The following table presents the properties-to-device driver mapping. Remember that device driver functions are not directly called by the logical device, but by the corresponding proxy object. They are, however, included in the table because configuring a given property ultimately results in calling the associated device driver.

Table 3 ADAC device properties mapping


DAC_CHANNEL_A_GAIN User-defined Read/Write conv_mod_SetDACChanGain( , CHAN_A, , )

DAC_CHANNEL_B_GAIN User-defined Read/Write conv_mod_SetDACChanGain( , CHAN_B, , )

ADC_CHANNEL_GAIN Long Read/Write Conv_mod_SetADCChanGain()


5

The DAC_CHANNEL_A_GAIN and DAC_CHANNEL_B_GAIN properties are user-defined structures used to set the gain of the DACs, as follows.

DAC_CHANNEL_A_GAIN

The ADC_CHANNEL_GAIN property is a sequence of two long values. The first long element of the sequence contains the gain value of channel A and the second element contains the gain value of channel B.

Table 4 ADC-CHHANEL_A_GAIN property

Structure member Type Possible values

DAC_CHANNEL_A_GAIN_TYPE Long 0 = Fine, 1 = Coarse

DAC_CHANNEL_A_GAIN_VALUE Long –128 to 127

DAC_CHANNEL_B_GAIN

Table 5 ADC-CHHANEL_B_GAIN property

Structure member Type Possible values

DAC_CHANNEL_B_GAIN_TYPE Long 0 = Fine, 1 = Coarse

DAC_CHANNEL_B_GAIN_VALUE Long –128 to 127

The ADAC device implements the standard CF::Device IDL interface and a proprietary IDL interface. The proprietary interface is used to register a reference to the associated proxy object running on the DSP. When it starts, the associated proxy object registers with the logical device. The logical device then stores the proxy object’s reference, which is later used to communicate with the proxy object. The registration interface appears below:

module Lyrtech

{

interface ADACController : CF::Device

{

void registerADACDeviceProxy(in ADACDeviceProxy proxy);

};

};

PCM3008 device

This logical device encapsulates the PCM3008 codec hardware device functionalities. The following table presents the properties-to-device driver mapping. Remember that device driver functions are not directly called by the logical device, but by the corresponding proxy object. They are, however, included in the table because configuring a given property ultimately results in calling the associated device driver.

Table 6 PCM3008 device properties mapping


CODEC_SAMPLING_FREQUENCY Long Read/Write Pcm3008_SamplingFrequency()

Possible values are:


6

Table 7 CODEC_SAMPLING_FREQUENCY property values

Integer value Corresponding frequency

0 FREQ_48_KHZ

1 FREQ_44_1_KHZ

2 FREQ_32_KHZ

3 FREQ_16_KHZ

4 FREQ_8_KHZ

Note The FRS example application supplied with the SFF SCA development platform does not allow changing the codec frequency because the sampling rate is fixed in the FPGA design.

Further, this logical device supports two data ports. They are connected to the DSP resource during the example FRS application’s deployment. The first data port is used to read data from the codec and implements the PullPorts::ShortSeqProducer IDL interface. The second data port is used to send data to the codec and implements the PushPorts::ShortSeqConsumer IDL interface.

The PCM3008 device implements the standard CF::Device IDL interface and a proprietary IDL interface. The proprietary interface is used to register a reference to the associated proxy object running on the DSP. When it starts, the associated proxy object registers with the logical device. The logical device then stores the proxy object’s reference, which is later used to communicate with the proxy object. The registration interface appears below:

module Lyrtech

{

interface PCM3008Controller : CF::Device

{

void registerPCM3008DeviceProxy(in PCM3008DeviceProxy proxy);

};

};


7

DSP This section introduces the proxy objects running on the DSP. You do not have to directly communicate with proxy objects as the logical devices running on the ARM processor serve as mediators between you and the objects.

RFFE proxy

An IDL interface is defined to communicate with this CORBA proxy object. The interface maps the properties defined in Table 2 for the corresponding logical device running on the ARM processor. The mapping allows the logical device to forward configuration calls to the proxy object by manipulating minimal amounts of data.

module Lyrtech

{

interface RFFEDeviceProxy

{

long getTxPower(out long value);

long setTxPower(in long value);

long getRxPower(out long value);

long setRxPower(in long value);

long getPLL1LockState(out long state);




};

};

ADAC proxy


module Lyrtech

{

enum GainType { FINE,

COARSE };

interface ADACDeviceProxy

{

long setADCGains(in long channelAGain,

in long channelBGain);

long setDACChannelAGain(in GainType type, in long value);

long setDACChannelBGain(in GainType type, in long value);

};

};


8

PCM3008 proxy


The same way its logical device counterpart does, the PCM3008 proxy object implements the PushPorts::ShortSeqConsumer and PullPorts::ShortSeqProducer IDL interfaces. Implementation code for these interfaces represents the data ports of the proxy object. The data ports perform the actual data transfers to and from the PCM3008 hardware.

module Lyrtech

{

enum SamplingFrequencyType { FREQ_48_0_KHZ,

FREQ_44_1_KHZ,

FREQ_32_0_KHZ,

FREQ_16_0_KHZ,

FREQ_8_0_KHZ };

interface PCM3008DeviceProxy : PushPorts::ShortSeqConsumer, PullPorts::ShortSeqProducer

{

long setSamplingFrequency(in SamplingFrequencyType freq);

};

};


9

Example FRS application This section of the document explains the deployment sequence of the example FRS application within the context of the Core Framework.

Figure 4 Example FRS SCA application

Figure 4 illustrates the connections between the application’s components, running on the ARM. The connections are described in more details in the software assembly descriptor FRSApplication.sad.xml file.

Importing an FRS application in SCA Architect

1. Make the Eclipse workspace point to a folder of your choice.

Figure 5 Workspace Launcher dialog box

2. Create a new project using files from the provided FRS example application. ♦ On the Eclipse Files menu, point to New, and then click Project.

The following dialog box appears.

Figure 6 New Project dialog box


10

3. Expand General, select Project, and then click Next. 4. Type the following information in the dialog box that appears.

Figure 7 New Project dialog box (2)

You can now change the Eclipse perspective to use the one from SCA Architect. 5. On the Eclipse Windows menu, point to Open Perspective, and then click Other. The following dialog box appears.

Figure 8 Open Perspective dialog box

6. Select SCA Architect and then click OK.

Deploying an FRS application

When deploying an FRS application, the following is performed, in sequence.

1. The Core Framework’s ApplicationFactory loads an FPGA image with ARMExecutableDevice’s load() operation.

2. ApplicationFactory loads a DSP image with ARMExecutableDevice’s load() operation. This triggers the instantiation of all the proxy objects on the DSP. 3. DSP Proxy objects register with their associated logical devices on the ARM processor.


11

Registration is achieved through the controller IDL interfaces. 4. ApplicationFactory loads the DSP resource binary file to the ARM processor with ARMExecutableDevice’s

load() operation. 5. ApplicationFactory loads the FPGA resource binary file to the ARM processor with ARMExecutableDevice’s

load operation. 6. ApplicationFactory runs the DSP resource binary file on the ARM processor with ARMExcecutableDevice’s

execute() operation. When instantiated, the resource attempts to find the reference to the corresponding proxy object running on

the DSP. (The proxy object is instantiated at step 2). 7. ApplicationFactory runs the FPGA resource binary file on the ARM processor with

ARMExcecutableDevice’s execute() operation. 8. ApplicationFactory requests input and output ports with the getPort() operation on the PCM3008 logical

device port objects (CodecDataIn and CodecDataOut). Instead of returning the port object residing on the ARM processor, the logical device returns the proxy object

reference residing on the DSP. This reference is the one previously registered by the proxy with the registerPCM3008DeviceProxy() operation.

9. ApplicationFactory requests the toCodec and fromCodec port objects with the getPort() operation on the DSP resource port objects.

10. ApplicationFactory transfers the proxy reference from step 8 with the connectPort() operation on the DSP resource port objects (toCodec and fromCodec are obtained at step 9).

11. The DSP resource forwards the PCM3008 proxy object reference to the resource proxy object with the connectToCodecPort() and connectFromCodecPort() operations.

12. Steps 8 to 11 are repeated to establish connections between the DSP resources and the FPGA resources.

Note Remember that two sets of parallel connections are established during the application’s deployment. The first set is established with the ARM and are considered virtual because no data is exchanged over them. The second set is automatically established between proxy objects running on the DSP when connections are established on the ARM. Data flows over these connections.

ARM processor

The following section describes the example FRS application components running on the ARM processor and DSP.

DSP resource

This resource represents the signal processing software running on the DSP and its main purpose is to forward connection requests to the corresponding proxy object on the DSP. Similarly, it forwards start and stop requests to proxy objects. It also plays the role of assembly controller for the example FRS application, which means that a start()on the application results in start() being called on the resource.

FPGA resource

This resource does not communicate with the DSP or the FPGA. It represents the firmware running on the FPGA at the SCA level. It is deployed on the ARM processor with the DSP resource.

DSP

DSP resource proxy

This is the main component of the example FRS application. When calling the start() operation on this component, a thread is created to perform the following:

1. Retrieves data from the PCM3008 proxy object. 2. Runs signal processing functions on the data.


12

3. Sends the processed data to the FPGA.

Upon calling the stop() operation, the thread is destroyed.

An IDL interface is defined to communicate with this CORBA proxy object. The interface is mainly used to establish connections between proxy objects on the DSP by the DSPP resource on the ARM processor during the application’s deployment. It also provides operations to start and stop application processing, and is used by the FPGA to send data to the DSP.

module Lyrtech

{

interface DSPResourceProxy : PushPorts::ShortSeqConsumer

{

void connectToCodecPort(in PushPorts::ShortSeqConsumer toCodecPort);

void connectFromCodecPort(in PullPorts::ShortSeqProducer fromCodecPort);

// this operation is only used to trigger the OE bind() operation

// inside the DSP, no reference is actually passed

void connectToFPGAPort(in PushPorts::ShortSeqConsumer toFPGAPort);

void start();

void stop();

};

};

This proxy object has one input port that implements the PushPorts::ShortSeqConsmer IDL interface. The port is used to receive data from the FPGA.

Digital signal processing is performed by the proxy on the data streams from or to the FPGA. Interfaces to the signal processing functions are C functions:

void FRS_TX_Processing(const int16_T* audioIn, int16_T* audioOut);

void FRS_RX_Processing(const int16_T* audioIn, int16_T* audioOut);

The first function is used for the transmit data streams from the codec, through the DSP, to the FPGA. The second function is used for the receive data streams from the FPGA, through the DSP to the codec. The first parameter used by the functions is a pointer to the input data buffer. The second parameter is a pointer to the output data buffer. The caller retains the ownership of both buffers. After the call, the output data buffer contains the processed data.


13

Deploying the SFF SCA development platform This section presents information necessary to use the SFF SCA development platform.

Design flow

This section presents the design flow used in rebuilding all the components of the platform.

Requirements

The DomainManager, DeviceManager, and LogImplServer components must be compiled before preparing the system for deployment. The components do not reside in the product installation hierarchy — they are the default SCARI++ installation folders:

DomainManager: <scari_install>\components\domainmanagers\

DeviceManager: <scari_install>\components\devicemanagers\

LogImplServer: <scari_install>\components\services\Log\

Use the provided MULTI IDE build files to compile these components. Refer to CRC’s SCARI Software Suite, Configuration and Demonstration SCARI++ for Core Framework 2.4 for details.

Note The paths to these components’ binary files must be supplied to SCA Architect. This is necessary for SCA Architect to find the binary files during the packaging process. Therefore, in the SCA Architect window, open the relevant resource. On the resource’s tab, click the Implementations Form tab. On the Code tab, specify the relevant path in the Native path text box. Perform this for each component.

The CORBA Name Service server must also be compiled with the appropriate IP address. You can use the name service example supplied with ORBexpress to compile the naming service executable.

The server_main.cxx file also must be modified to specify the correct IP address. Locate the section of code in the file specific to INTEGRITY, and then modify the highlighted portion with an appropriate IP address and port number:

//---------------------------------------------------------------------// has a 'main', but no args

#elif defined(OE_OS_INTEGRITY) || defined(OE_OS_INTEGRITY178b)

//---------------------------------------------------------------------

int main()

{

int argc = 3; char* argv[4] = { "server", "-ORBep", "tcp://127.0.0.1:5000", 0 };

char* envp[1] = { 0 };

return server_main(argc, argv, envp);

}

The Core Framework uses 15000 as the default port number. Follow ORBexpress instructions to compile example programs. After successfully compiling, the resulting binary file can be placed into the exported NFS folder. It is started by the SCALoader application (previously described).


14

Product components

No modifications to the source code are necessary to run the FRS example application. However, if you want to modify the source code, you must rebuild the system afterwards. Follow the procedure below to do so.

Note <install_dir> is where the project is installed.

1. Rebuild logical devices and resources with MULTI. Note

The build macros of MULTI projects may need adjustment if the necessary folders are not in their default locations. In MULTI, on the Edit menu, click Set Build Macros to modify build macros.

♦ Open the following projects and build them — on the Build menu, click Build Project. The executable binary files of each component are located in the INTEGRITYORBexpressARM folder in the component’s main folder.

<install_dir>\SCAA\src\RFFEDevice\RFFEDevice_ARM_INT_OEProject.gpj <install_dir>\SCAA\src\ADACDevice\ADACDevice_ARM_INT_OEProject.gpj <install_dir>\SCAA\src\PCM3008Device\PCM3008Device_ARM_INT_OEProject.gpj <install_dir>\SCAA\src\DSPResource\DSPResource_ARM_INT_OEProject.gpj <install_dir>\SCAA\src\FPGAResource\FPGAResource_ARM_INT_OEProject.gpj <install_dir>\SCAA\src\ArmExecutableDevice\ExecDevice_ARM_INT_OEProject.gpj

2. Rebuild the DSP image with Code Composer Studio. a) Open the following project in Code Composer Studio. <install_dir>\DSProject\LyrtechFRS.pjt b) On the Project menu, click Build. This operation generates the LyrtechFRS.out file in the Debug folder.

3. Copy the appropriate FPGA .bit file in the same folder as the DSP image file. SCA Architect searches in this folder for the .bit file when packaging the FRS application. By default, this

location is <install_dir>\DSPProject\LyrtechFRS\Debug\. 4. Package the node components with SCA Architect.

a) In SCA Architect’s Project Explorer, expand Nodes, right-click ARM, and then click Export. b) In the dialog box that appears, select SCA Doman Profile Assembly Package, and then click Next. c) Specify the name and location of the archive file (.zip). The name of this file may be anything — it does not have any impact on the system. d) Click Finish.

5. Package the domain manager component with SCA Architect. a) In SCA Architect’s Project Explorer, expand Domain Manager Configuration, right-click

SFF_SDRConfiguration, and then click Export. b) In the dialog box that appears, select SCA Doman Profile Domain Manager Package, and then click

Next. c) Specify the name and location of the archive file (.zip). The name of this file may be anything — it does not have any impact on the system. d) Click Finish.

6. Package the application components with SCA Architect. a) In SCA Architect’s Project Explorer, expand Applications, right-click FRSApplication, and then click

Export. b) In the dialog box that appears, select SCA Doman Profile Assembly Package, and then click Next. c) Specify the name and location of the archive file (.zip).


15

The name of this file may be anything — it does not have any impact on the system. d) Click Finish.

7. Extract the node package. The files for the node must be extracted in the runtime folder where they will run.

♦ Extract the .zip file created at step 4 with an archiving utility (e.g. WinZip or WinRAR). If an NFS file system is used, the target folder should be located in the exported NFS folder.

8. Extract the domain manager package. The files for the domain manager must be extracted in the runtime folder where they will run.

♦ Extract the .zip file created at step 5 with an archiving utility (e.g. WinZip or WinRAR). If an NFS file system is used, the target folder should be located in the exported NFS folder.

9. Replace the default IP address in XML and .execparam files. By default, SCA Architect generates the XML and .execparam files with an unspecified IP address. The

string IPAddress specified in the –ORBInitRef and –ORBep and parameters must be replaced with the actual IP address of the target. These parameters are typically specified in implementation-specific .prf.xml files and in the DeviceManager.execparam and DomainManager.execparam files. The ORBInitRef parameter is used to specify the initial reference of the naming service. Note

For this parameter, the port number and IP address must be specified. The ORBep parameter is used to specify the CORBA listening end point of the component.

NFS server setup

The SFF SCA development platform needs a file system to store all the SCA-related files. The easiest way to provide a file system to the platform is using INTEGRITY’s ability to connect to a remote NFS server.

If your host device is a Linux system, an NFS server application is normally included. If you are using a host device running on Windows, it does not supply an NFS server. You should therefore install one beforehand. You can use Cygwin to provide an NFS server. Refer to the quick start guide for details.

Once the NFS server is running, INTEGRITY must mount the exported drive (see Deploying the SFF SCA development platform’s FRS example application).

Starting the SCA Core Framework

To begin deploying nodes, you must first start the SCALoader application. This INTEGRITY application automatically starts the following components:

• Name service • Domain manager • Device manager

The SCALoader also searches for the following files and path names:

• /nfs/sca_runtime/standalone-dyn.mod • /nfs/sca_runtime/DomainManager/IntegrityORBExpressARM/DomainManagerImplServer • /nfs/sca_runtime/ArmNode/IntegrityORBExpressARM/DeviceManagerImplServer

Node configuration is described in the ArmNode.dcd.xml file — the device manager reads this file when it starts. The device manager then runs each device’s executable file onto the ARM processor. After successfully starting all devices and services, the components should be visible in the Radio Manager’s user interface (see Figure 9).


16

Figure 9 Deployed nodes displayed inside Radio Manager

Deploying the SFF SCA development platform’s FRS example application

1. Make sure that an NFS server is running on the host computer and that the SCALoader.iae application is present in the flash file system of the platform.

2. Turn on the SFF SCA development platform. 3. Connect to the SFF SCA development platform through Telnet. 4. Right-click the FRSApplication icon, and then select the instantiate option. 5. After a successfully instantiating the application, right-click the application icon, and then click Start.

Radio Manager

Installing Radio Manager

Radio Manager must be installed with the ORBexpress remote ORB option to be able to connect to the SFF SCA development platform without errors. This option must be selected during the Radio Manager’s installation process. It cannot be modified afterward. The figure below presents the installation process dialog box where this option is specified.

Figure 10 Radio Manager ORB selection


17

Connection parameters

Connection parameters must be supplied to Radio Manager so that it can connect to the SFF SCA development platform.

Here, we introduce the necessary parameters so that Radio Manager can connect to the SFF SCA development platform at IP address 10.116.23.103. We also assume that Radio Manager is installed on a computer at IP address 10.116.23.102.

In Radio Manager’s Search dialog box, the Connection Name text box allows specifying a name for the connection, effectively indentifying a specific connection. The Host text box is used to specify the location of the host where Core Framework is currently running. The ORBInitRef text box is used to specify the name service used by the target Core Framework. The ORB End Points text box allows specifying a listening end point for Radio Manager. For details, refer to the Radio Manager’s user guide.

Figure 11 Radio Manager connection parameters

In the dialog box above, type the following values, and then click OK:

• Connection Name: SFF-SDR_home • Host[:port]: 10.116.23.103:15000 • OrbInitRef: NameService=corbaloc:iiop:[email protected]:15000/%B5Ad%B6ExpressNames%

B5DomainServer%B5RootPOA%B5NamingRoot • ORB End Points: tcp://10.116.23.102:0


18


CORBA FPGA development with VHDL

19


This chapter describes FPGA CORBA design for SCA on the SFF SCA development platform. It describes how ORBexpress is implemented on the FPGA of the digital processing module. It also describes how to create your own CORBA applications and interface them with the FPGA’s ORB.

Preliminary readings

Before reading this documentation, you will need first to read and understand the following documentations:

SFF SDR development platform user’s guide from Lyrtech, supplied with this product and available on the Windows Start menu.

ORBexpress FPGA user’s guide from Objective Interface Systems. This guide describes CORBA concepts for FPGA development and design with ORBexpress FPGA.

ORBexpress FPGA transport adapter design guide from Objective Interface Systems. This guide describes how to design a transport adapter for ORBexpress FPGA.

ORBexpress FPGA idl2vhdl compiler user’s guide from Objective Interface Systems. This guide describes how to work with OIS’ idl2vhdl compiler to generate object adapter VHDL code from an IDL file. Object adapters are the modules interfacing user applications to the ORB base system, making it CORBA-compliant.

Note The ORBexpress documentation is supplied by Objective Interface Systems and accompanies the software, available on the Windows Start menu.

Overall structure and tool compatibility

SCA-specific reference design folder structure

In addition to the reference design folder structure described in the FPGA development with VHDL section of the platform’s user’s guide, there are SCA-specific folders, the structure of which are described in the table below. The platform’s FPGA VHDL reference design is installed along with the supplied software tools. All the folders described below are in the <SFFSDRLOC>\SFF_SDR\ folder, where SFFSDRLOC is the path to the installation root of the software.

Table 8 SFF SCA development platform reference design folders

Folder Description

fpga\SCA\netlist\ Precompiled netlists for Lyrtech VHDL modules (TA, FIFO, etc.).

fpga\SCA\src\ VHDL common source code.

examples\SCA\ CORBA examples for SCA.

For details about the ORBexpress FPGA netlist folder structure, refer to the ORBexpress FPGA user’s guide.


20

Hardware description language tool compatibility

The CORBA FPGA VHDL reference design is compatible with the following HDL tools. Refer to the platform’s quick start guide for version details.

Table 9 Supported HDL tools

HDL tool Description

ISE Foundation Fully compatible. All the examples supplied with the FPGA VHDL reference design have an associated ISE Foundation project file.

Xilinx Synthesis Technology (XST) Partially compatible. XST is only compatible with the default user constraints files (.ucf) supplied with the FPGA VHDL reference design.

FPGA VHDL design block diagram

App

P

ort

#1

TA

App

Port #0

ORB

CORBA application 2

CORBA application 3

App

P

ort

#3

CORBA application 4

App

P

ort

#4

CORBA application 5

App

P

ort

#5

CORBA application 6

App

P

ort #

6A

pp

Por

t #2

To or from

VPSS

communication

module

7 portswitch

To or fromcustom

logic I/Os

CORBA application 1

Figure 12 CORBA FPGA VHDL design block diagram

CORBA-specific module list

The following list of modules presents the CORBA design hierarchy. It corresponds exactly to the CORBA FPGA VHDL design block diagram above.

• Custom logic (where the CORBA base system design and user CORBA applications design are placed) • ORB base system (CORBA design independent modules)

• Crossbar switch • ORBexpress (object request broker) • Transport adapter (TA)


21

• SCA application • Op_adapt_recv (adapter receive operation) • Op_adapt_send (adapter transmit operation) • User application

• Receive message processor (not necessary when application can only send) • Send message processor (not necessary when application can only receive) • User application core logic

Custom logic

The custom logic contains the user logic and the ORB base system. The user logic can be any CORBA or non-CORBA application module. Only CORBA application modules can be connected to the ORB base system by object adapters. Non-CORBA modules can be directly connected to a CORBA application without interface modules.

ORB base system

The crossbar switch, ORBexpress, and the transport adapter ORB base system are grouped to form a top module called the ORB base system. It is a design-independent module that should not be modified. To learn more about these modules refer to the ORBexpress FPGA user’s guide.

ORB system

An ORB system is a group of one ORB base system and one or more applications. A CORBA application is said to belong to (or reside into) a given ORB system if it is connected to the system.

Transport adapter

The TA is platform dependent and is designed to support the VPSS communication module of the digital processing module. The VPSS communication module is the communication interface between the FPGA and the DSP of the platform. You do not need to modify the TA regardless of your CORBA design.

The main role of the TA is to interface the FPGA’s VPSS communication module and ORBexpress. It is used when a CORBA application must communicate with another CORBA application residing outside the FPGA’s ORB system (such applications are located in the DSP’s ORB system). The TA has three logical channels — one for the control (channel 15) and two for data transfers (channel 0 and channel 1). Channel 0 is always allocated to the ORB transmit-to-VPFE direction. Channel 1 is always allocated to the VPBE-to-ORB receive direction.

After the FPGA is initialized, the TA immediately begins negotiating with the ORB to open channel 1. When this channel is open, the TA begins monitoring the VPBE and forwards any incoming data to the ORB without alterations. In the other direction, the TA waits for the ORB to request opening a connection. The ORB opens a connection for the first time when it has a message to transfer outside its own system. The TA assigns channel 0 to the ORB. Once the connection is established it remains open and the ORB does not need to reopen it.

For details about the channel opening and closing request mechanisms, refer to the ORBexpress FPGA transport adapter design guide.

The TA handles the close connection command that may be issued by the FPGA ORB when errors occur. The TA closes the connection on channel 0 when the ORB requests it. The TA waits for the ORB to request a connection to be opened for the ORB transmit-to-VPFE direction, in which case the TA again allocates channel 0 for this given connection.


22

CORBA application block

The CORBA application block contains the idl2vhdl-generated interface modules and the user application. For details about idl2vhdl-generated files and object adapters, refer to the ORBexpress FPGA user’s guide and ORBexpress FPGA idl2vhdl compiler user’s guide. The user application core contains three modules — the user logic, the receive message processor, and the send message processor.

Idl2vhdl-generated modulesUser application core

To or fromORB base

system

To or from

custom logic I/Os

Obj_adapt_recv

Obj_adapt_send

Data

Recv_msg_Proc

Send_msg_Proc

Data

Flow control

Flow control

Data

Flow control

Data

Flow control

CORBA application

User logic

Figure 2 CORBA application block diagram

The receive message processor module and the send message processor module contain FSM and logic needed to interface the user logic to object adapters. The two modules are application-specific and may differ according to the CORBA application. The interfaces to object adapters of the two modules, however, are oft the same. When the modules interface with user logic, the interfaces differ. The logic of the modules may be significantly reduced should they interface with an application without data transfers during its operation call or serve. An example of this is a counter increment operation call or serve.

If a user application is only a servant, it does not need a send message processor module. If a user application is only a client, it does not need a receive message processor module. Whether user applications are client or servant, they must be connected to the receive object adapter and sent object adapter.

VHDL source code of the send message processor and receive message processor is supplied with the examples of the SFF SCA development platform. You can use the source code in your applications, modifying it as necessary. For details about the modules’ design requirements, refer to the ORBexpress FPGA user’s guide.


23

CORBA application design and implementation examples This section presents detailed descriptions of the examples supplied with the SFF SCA development platform. These examples are divided into two categories — software functional examples (providing simple, low-level CORBA examples) and application examples (providing more complex practical examples). Examples in this latter category use the CRC’s high-level SCARI tools for SCA design.

Generic folder structure for the examples

A generic folder structure of an SFF SCA development platform example appears below:

Figure 13 Generic folder structure

Table 10 Folder description

Folder Description

host Contains the Lyrtech development platform command shell launcher with a script to automatically load the generated FPGA and DSP configuration files to the platform with the platform’s CCE.

ise ISE Foundation projects working folder.

src Contains source files for the custom logic module, CORBA applications, and UCF file.

App Contains IDL files, user logic, and object adapter source code

Custom Contains custom logic modules

ucf Contains user constraints files

Simple counter examples

Two simple counter examples are supplied with the platform to introduce you to FPGA CORBA application design. The first is a counter implemented in the DSP as a server. In this example, the FPGA acts as a client sending an incremental operation call at the push of a button.

The second example is a counter implemented in the FPGA as a CORBA server application. In this case, the DSP acts as a client sending an incremental operation call at the push of a button. In both examples, the counter is 5 bits in width and is connected to the five user LEDs on the digital processing module. Each time the counter is incremented, the result is reflected by the user LEDs.


24

DSP-hosted counter example

Every time that a user button is depressed, the FPGA CORBA application sends an incremental operation call to the DSP CORBA application, where the FPGA CORBA application is the client and the DSP CORBA counter application is the server. The user application logic only contains a button debouncer that also generates one positive pulse each time a button is depressed and released. The message send processor module triggers the object send adapter to generate one operation call each time it receives this positive pulse. Because this application is a client, it does not have a message receive processor. Object adapters are generated with the same standard IDL file used to generate the DSP CORBA servant application, as follows:

interface Counter

{

readonly attribute unsigned long value;

void increment();

};

The above generates the following .fis file:

fpga_block <TBD>

{

serves interface Counter

{

__get_value; // from Counter

increment; // from Counter

}

}

By default, interface counters are generated as servers, which must be modified to calls interface counter because the application is a client that only generates calls. The __get_value attribute is not used in this case and must be commented out. The server application called by the FPGA client resides outside the FPGA ORB system, thus the CORBA message containing the operation call must go through the crossbar switch, ORBexpress, and the TA. To do so, the generated .fis file must be updated to contain the bind from the FPGA client to the DSP servant. This bind should be reflected at the DSP CORBA application (i.e. the same parameters must be used in the DSP than in the FPGA bind). The resulting .fis file looks like this:

fpga_block counter

{

calls interface Counter

{

//__get_value; // from Counter

//FPGA bind to DSP

object remote_obj1 = Bind( "clas", "Inst", "RootPOA", "ObjId_0", "VPSS:0");


}

}

In the bind, VPSS:0 represents the platform’s transportation system. Because it is the only available transportation, this parameter is always the same, regardless of the IDL file. Other parameters can be changed to reflect given applications.


25

FPGA-hosted counter example

In this example the CORBA application’s roles are switched between the DSP and the FPGA — the FPGA CORBA application is the servant that holds the counter and the DSP CORBA application is the client that generates one incremental operation call each time a user button is depressed. The FPGA counter is 5 bits in width and directly connected to the user LEDs to reflect its state. Because the FPGA application is the servant, it does not need to have a send message processor. The object adapters are generated using the same IDL file used to generate the previous example and the DSP CORBA client application. The generated .fis file is the same as the one generated from the example above, only this time the serves interface counter must be kept, removing the need to specify a bind. However, the DSP CORBA application must know where the FPGA CORBA application is located. The FPGA CORBA application was connected to switch port number 1 (or port A). The DSP bind must include this information for the DSP and FPGA ORB systems to correctly route the CORBA message. The edited .fis file should look as follows:

fpga_block counter

{

serves interface Counter

{

//__get_value; // from Counter


}

}

FRS application examples

Two FRS examples are supplied to demonstrate more complex FPGA CORBA designs for SCA. The first FRS example is implemented as a single CORBA application connected to the crossbar switch. The other FRS example is exploded into three modules. Each module is implemented as a separate, independent CORBA application and connected to the crossbar switch.

Note The TX and RX portions of the FRS design were imported as netlists from the MATLAB SFF SDR development platform’s Family radio service example.

The RX portion of this example is optimized to maximize FPGA space for the FPGA to accommodate the platform’s base design, the ORB base design, and the FRS example application with ease.

FRS as a single CORBA application example

As explained above, this example is implemented as one CORBA application. User logic contains the FRS TX and RX portions of the example. This FPGA CORBA application has one servant (TX) and one client (RX).

The RX down samples and demodulates the ADC channel A’s IF data, and then writes the resulting audio data to the send message process module’s input FIFO. When the FIFO is of the required length (128 × 32-bit words; 256 short integers), a finite state machine (FSM) is triggered. The FSM prepares and sends the header, followed by the payload data to the object adapter send module. The module reformats the header, adding a processShortMsg operation call to it and then forwarding the result to the crossbar switch. Because the operation calls a server outside the FPGA ORB system, the crossbar switch directs the message to the ORB. The ORB reformats the message header to a CORBA header and then forwards it and its data payload to the TA. The TA forwards the CORBA message to the DSP ORB system through the VPSS communication interface. The DSP ORB system processes the message and sends the resulting audio data to the platform’s audio codec output.

In the TX direction, the audio input data from the platform’s audio codec input is processed by the DSP TX COBRA client each time a button is depressed and held down. This DSP client gathers 256 short integers and sends a processShortMsg operation to the FPGA FRS TX servant. The FPGA TA receives the CORBA message


26

and flags connection 1 as ready. The ORB reads the CORBA message, analyzes it, reformats the header, and then sends it to the crossbar switch. The crossbar switch forwards the reformatted CORBA message to the CORBA application’s object adapter receive. The latter verifies that the received processShortMsg operation name is present in its operation names list. If so, the object receive adapter reformats the header and sends the message to the receive message processor module. The FSM of the module analyzes the message header and stores the payload data in an output FIFO. The FRX TX reads the data from the FIFO, modulates it, up-samples it, and then sends it to the platform’s DAC.

Note RX is always receiving data from the platform’s ADC, while TX only sends data to the platform’s DAC when a user button is depressed. To prevent RX from receiving what is being sent on TX, RX is disabled when there is data in the TX FIFO to be processed by TX.

FRS as multiple CORBA applications example

In this example, TX and RX interact with the CORBA applications that reside in the DSP as they do in the previous example. The difference is that the FRS CORBA application is separated into three separate CORBA applications — TX, RX, and ADC/DAC interface. TX and RX do not directly connect to the ADC and DAC interfaces through non-CORBA I/Os as it is the case in the first example. Instead, the ADC and DAC interfaces form a third COBRA application that communicates with the RX and TX applications through CORBA operation calls. The user logic portion of the ADC/DAC application is composed of a FIFO that connects directly to the platform’s ADC and DAC. When the required 256 short integers of payload data are in the ADC interface CORBA client’s FIFO, an operation call is sent to the RX CORBA server application. In the TX direction, when the TX CORBA client receives the 256 short integers of payload data, it sends an operation call to the DAC interface CORBA server.

The block diagram below illustrates how the FRS TX CORBA application, the FRS RX CORBA application, and the ADC/DAC interface CORBA application are connected to the crossbar switch. Figure 15 illustrates the client-to-servant call data paths.

ORB base system

FRS TX CORBA application

ADC/DAC interface CORBA application

FRS RX CORBA application

Connected to GND

To and from

VPSStransport

To DAC

From ADC

RX disable

Figure 14 FRS multi-application example block diagram


27

Figure 15 FRS client-to-servant data paths block diagram

The standard IDL file of this example is used in generating the object adapters for the three CORBA applications of the example. FIS files, however, are edited along the same lines as explained in the counter examples, exception aside of when a client must communicate with a servant connected to the same switch on a different port, where behavior is different. For example, if an ADC client application forwards the received ADC IF data to the FRS RX CORBA application (residing in the same ORB system and connected to the same crossbar switch, on port 3), the bind added to the FIS file generated for the ADC/DAC CORBA application looks like:

object FrsRxObj = 3,0; // Location for the FRS RX block

3 is the port number where the called servant application is connected. 0 is the object number (there is only one object in the FRS RX CORBA application).

Similarly, the FRS TX CORBA application must forward up-sampled data to the ADC/DAC CORBA application. The latter is connected on switch port 2 and only has one object. The bind added to the FIS file generated for the FRS TX CORBA application looks like:

object DacObj = 2,0; // Location for the adc_dac object

If you open the IDL file of this actual example, you see that the operation processShortMsg has the following option:

oneway void processShortMsg(in PortTypes::ShortSequence msg, in CF::Properties options);

This option is used in most radio communications-related IDL files to transmit commands with data. The option’s data type is defined as any, which cannot be implemented in an FPGA, thus is ignored by the idl2vhdl file. However, because this application example uses SCARI tools to create, manage, and deploy SCA blocks, support for the option is vital. Therefore, a null operation option is used in the example, which requires sending a null 32-bit word at the very end of the data payload in the CORBA message sent to or received by the FPGA. To support this, the RX CORBA application’s send message processor module is modified to add this null word at the end of the payload data to be sent. Similarly, the TX CORBA application’s receive message processor module is modified to ignore the last word of the payload data.


28


Examples

29

Examples

This chapter presents an overview of how to perform ORB functional examples. More specifically, it explains where you can find the ORB functional examples, how to create an FPGA bitstream for your specific target with ISE Foundation. It also explains how to use Code Composer Studio to generate code for your DSP. Finally, it briefly introduces how to use the Lyrtech development platform command shell and macros to run parts of the examples.

Performing examples — Generic procedure

Example folder structure

ORB examples are located in the following folder:

<SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\

Counter examples

The counter examples illustrate how to design a simple ORB application on the FPGA, the DSP, and the ARM using ORBexpress. They also illustrate how to use platform-specific transports. Four versions are included:

• <SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\Counter\ARMHostedForDSP\ This version implements a counter in the ARM accessed by the DSP client using the DSPLink transport. • <SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\Counter\DSPHosted\ This version implements a counter in the DSP accessed by the FPGA client using the VPSS transport. • <SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\Counter\DSPHostedForARM\ This version implements a counter in the DSP accessed by the ARM client using the DSPLink transport. • <SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\Counter\FPGAHosted\ This version implements a counter in the FPGA accessed by the DSP client using the VPSS transport.

Configuring examples

The examples are supplied with prebuilt executables that you can use before trying to build you own. In examples involving the ARM processor, you must copy the ARM executable and the DSP executable to the flash file system of the platform beforehand.

If you take the example located at <SFFSDRLOC>\SFF_SDR\examples\sca\soft_func_ex\ Counter\ARMHostedForDSP\, you can locate the associated executable in arm\CounterServer\ (ARM executable) and in dsp\pjt\Debug\CounterClient.out (DSP executable).


30

Procedure

All the supplied examples involving the DSPLink transport must be executed with a rebooted platform because underlying components of the transport do not support cancelled connections.

Procedure for counter examples involving the ARM

1. Make sure that the platform contains all the needed files to run the example. Refer to the SFF SDR development platform’s user’s guide for details about how to copy files to the

platform’s internal flash file system. • For the DSPHostedForARM, CounterClient and CounterServer.out must be flashed. • For the ARMHostedForDSP, CounterServer and CounterClient.out must be flashed.

2. Open a Telnet session with your platform. Refer to the SFF SDR development platform’s user’s guide for details. 3. Run one of the examples by typing Load /Flash/CounterServer or Load /Flash/CounterClient at the Telnet

command prompt.

Procedure for counter examples involving the FPGA

Use the same method described in Using Lyrtech development platform command shell macros in batch mode in the SFF SDR development platform’s user’s guide. You can also use the same method described above, i.e. copy the compiled .out and .bit files to the platform’s internal flash memory.

Expected results

In the serial console, you can see messages print by the ARM application:

• ARMHostedForDSP Four counter instances run on the ARM and they print a message every time their increment method is called

by the DSP. Because the DSP runs four clients bound to one counter server instance, each counter on the ARM is incremented. The examples use four different DSPLink channels.

• DSPHostedForARM One counter instance runs on the DSP. On the ARM, four clients bind to the unique counter server on the

DSP using one DSPLink channel. The four clients on the ARM prints a message every time they invoke the counter increment method.

• DSP hosted and FPGA hosted counters Each time a user button is depressed, a counter is incremented and the result is displayed on the user LEDs in

binary format.

Partial reconfiguration of FPGA

31


The partial reconfiguration (referred to hereafter as PR) of an FPGA is a feature that allows several modules to time-share physical resources. Partially reconfigurable design modules (referred to as PRMs) can be interchanged while the base design continues to operate without interruptions.

There are two methods of partially reconfiguring a Xilinx FPGA. The first involves using a script-based project and the second involves using PlanAhead from Xilinx. In this chapter, only the script-based project approach is covered. Refer to the PlanAhead documentation published by Xilinx for details about this approach.

Recommended readings

Before continuing, you should be familiar with the information in Xilinx’s UG208 — Early-access partial reconfiguration user’s guide. It is available from the Xilinx Web site.

Note You need a Xilinx account to gain access to this documentation.

Overall structure and tool compatibility

Hardware description language tool compatibility

The FPGA PR VHDL reference design is compatible with the following HDL tools. Refer to the quick start guide for version details.

Note The necessary ISE Foundation should be modified to support the PR designs. To do so, refer to the UG208 — Early-access partial reconfiguration user’s guide.

Table 11 Supported HDL tools

HDL tool Description

ISE Foundation Fully compatible. All the examples supplied with the FPGA PR VHDL reference design have an associated ISE Foundation project file.

Xilinx Synthesis Technology (XST) Partially compatible. XST is only compatible with the default user constraints files (.ucf) supplied with the FPGA VHDL reference design.

http://www.xilinx.com/


32

FPGA PR-specific reference design folder structure

The specific folders structure is presented in Table 12. The folders are project folders for two PR design examples. The folders described below are in the <SFFSDRLOC>\SFF_SDR\ folder, where SFFSDRLOC is the path to the installation root of the software.

Note The PR VHDL design uses the same netlists as a regular VHDL design. However, it does not use the same common VHDL sources for the I/O ring, SDR Top, or custom logic. Because of PR design restrictions, these VHDL sources must be modified to suite the PR design, becoming design-dependent. Therefore, each design project must contain its own VHDL source files.

Table 12 SFF SCA development platform PR reference design folders

Folder Description

fpga\PReconfig\Default\ Complete project with source code for PR with a regular VHDL design.

Fpga\ PReconfig SCA\ Complete project with source code for PR with an SCA/CORBA VHDL design.

Suggested project folder structure

The following is the suggested project folder structure for PR implementation. It was elaborated to represent as faithfully as possible the folder structure recommended by Xilinx.

Figure 16 Suggested PR project folder structure


33

Table 13 Suggested PR project folder structure description

Folder Description

FpgaCounter Project top folder.

base Implementation folder for static parts of designs.

bit Contains copies of all versions of final bitstreams of non-PR and PR variants of designs.

host Contains scripts to start the Lyrtech development platform command shell and to detect the SFF SCA development platform.

merges PRMs are merged with the base design in this folder. Each PRM has its own merge subfolder.

non_pr Implementation folder of non-PR, full version designs for initial system design and testing. There is one non-PR, full version design per PRM.

reconfigmodules PRMs are implemented in separate subfolders in this folder.

script Contains batch script files for design implementation automation.

src Contains all the source files for design implementation.

synth Contains ISE Foundation synthesis subfolders for base, top, and each PRM design module.

top Contains top-level netlists.

Design module hierarchy

Because of PR design module rules, the platform’s design modules hierarchy was slightly altered. All DCMs and clock primitives are now I/O ring top-level modules. The custom logic module only contains a user, static portion of the design. The user PRM portion of the design resides as submodules directly in the I/O ring’s top-level module. The SdrTop module is seen as the top entity of a base design, its static portion.

I/O ring

Clock primitivesBMsSdrTop

PRMs

Figure 17 PR hierarchy block diagram

• I/O ring: Top module of the design. Only contains black-box instantiations of the base design, bus macros, partially reconfigurable modules, clocks primitives, and I/Os. Cannot contain any synthesizable logic.

• SdrTop: Top module of the base design, the static portion of a design. Contains the custom logic and the necessary modules for platform design support. The custom logic contains the non-reconfigurable portion of a user design. No SdrTop module can contain any clock-related primitives (DCMs and BUFGs).

• PRM: Partially reconfigurable modules. Cannot contain clock-related primitives. In a given region, all PRMs must have the same port definition, entity name, and file name.

• Clock primitives: DCM and BUFG modules necessary to provide the necessary system clocks. Must only be instantiated in the top level design, the I/O ring.

• BM: Bus macros necessary to connect PRMs to a static design. All non-global signals (i.e. all signals other then clock signals) between PRMs and a base design must go through BMs.


34

PR design flow Perform the following to implement a PR design:

1. Using your ISE Foundation version modified to support PR (as outlined by Xilinx), separately synthesize each PRM, the top and base designs.

In Synthesis properties, configure the Keep Hierarchy option to yes only for the top design. To prevent ISE Foundation from adding I/O buffers to low-level designs, disable Add I/O for the base and PRM designs synthesis.

2. Edit the UCF constraints file to add timing and area group constraints. 3. Implement all the non-reconfigurable versions of the designs (base and PRMs). 4. Perform a functional check of the design. 5. Perform a timing/placement analysis. If the analysis fails, consider revising your design and repeat the above procedure up to this point again. 6. Implement the base design. 7. Implement the PRM design. 8. Merge the base and PRM designs.

Instead of performing steps to 8, you can use the batch files described in the next section. You must modify the files according to your design module names, as well as the number of PRM modules and PR regions before you do, however.

Batch file descriptions

The following table describes the batch files used in the PR flow in the order they are executed.

Table 14 Batch file descriptions

Batch file name Description

DOALL A parent batch file that runs all the following batch files, performing a full design implementation.

Copynetlist Copies the netlists generated during the synthesis to the working folders.

doNon_pr Fully implements non-reconfigurable versions of a design. Used to validate the functionality of a design and for timing analyses.

doBase Translates a top-level design, as well as maps, places and routes a base design.

doPrmodules Maps, places and routes a PRM design.

MergeDesign Merges a base design with PRMs and generates the full and partial final bitstreams.

CleanAll Cleans all folders by deleting all the generated files and temporary folders. Never double-click this file. Instead, call it from DOS Command Prompt window.


35

Loading PR bitstreams to the platform To save time, you can use the Lyrtech development platform command shell to load the full and partial bitstreams in the FPGA. The platform’s central communication engine (CCE) automatically detects the type of bitstream (full or partial) to be loaded, avoiding the need for users to use the command shell to specify the type of bitstream to be loaded to the platform. However, the CCE uses the SelectMAP interface to load bitstreams to SFF SCA development platforms (because of the embedded ARM MCU). Thus, in the command line, BitGen’s persist option must be set to yes, preventing the SelectMAP data pins from becoming user I/Os after configuring the FPGA with the full bitstream and allowing the CCE to load the platform with the other PR bitstreams afterwards. Refer to the Xilinx Virtex-4 configuration guide (ug071) for details about configuration interfaces. The persist option is already set to MergeDesign.bat located in the script folder. The pr_verifydesign and pr_assemble tools used in this batch file pass the selected option to the BitGen tool.

Generic CORBA design for PR The figure below illustrates a generic SCA CORBA design modified for PR. In this design, because the COBRA application acts as the PRM, it is at the top level of the design and connected to the rest of the design through a BM.

The ORB base module remains in the custom logic because it is part of the static design. Similarly, any non-reconfigurable CORBA applications must remain in the custom logic.

StaticCORBA application

ReconfigurableCORBA application

Unused application ports connected to the GND

BM

BM

To or from I/Os

To or from custom I/Os

Figure 18 block diagram of SFF SDR SCA design modified for PR.

PR CORBA design considerations

During partial reconfiguration, a CORBA application can be swapped with another with a completely different operation name or different .fis file. The ORB is updated with the new configuration data as soon as the new CORBA application is active. Because all CORBA applications have the same port interface, you need not worry about PRM compatibility. The top-level module of CORBA applications used in this manner must still have the same entity and file name, however.

On the down side, CORBA application cannot be swapped when sending a message to the ORB base module. Applications can be swapped when receiving a message from the ORB base module — the new CORBA application simply dumps the message.


36

Using the Lyrtech development platform command shell to load designs

your development platform. Load the full bitstream and then load the DSP .out file with the fpgaload and dspload commands. Then, you can load partial bitstreams designed for you design. You can reload partial bitstreams any number of times — you need not reload the full bitstream or DSP .out file each time you want to reload partial bitstreams.

An FPGA global reset is applied only once after the FPGA is loaded with a full bitstream. You can use a partial reset in your PRM design, instead. This partial reset is applied each time you load a partial bitstream with the Lyrtech development platform command shell.

The command used to apply a partial reset is:

dw, d,x 4008040 2

The command used to release a partial reset is:

dw, d,x 4008040 0

Note If you load the full bitstream to the FPGA through JTAG, the global and partial resets remain active. You can release the FPGA resets with the following command at the Lyrtech development platform command shell prompt:

dw, d,x 4008040 0

You can also use the DSP to release the resets by altering your DSP main application code consequently.

PR design examples

Non-COBRA PR design

The blinking LED example demonstrates how to implement a PR design on the SFF SCA development platform. The base design is used in making two user LEDs blink at a determined rate. The PRM design is used in making the remaining three LEDs perform a Johnson counter pattern at a determined rate. The direction of the Johnson counter depends on the loaded PRM.

In this example, the reconfigurable module uses the partial reset and the base design uses the global reset. The LEDs controlled by the base design always blink at the same rate and are not interrupted even when the PRM is loaded. This example does not require any DSP program.

To compile this example, start the Windows Command Prompt, go to the script folder, and then run doall.bat. PR flow tools start and PR design implementation through batch files begins.

Note You can run each batch file separately, as described above.

CORBA PR design

This FPGA counter example is a COBRA example illustrating how to implement a COBRA PR design on the SFF SCA development platform. The example is a derivate of the examples described above, modified to support PR design (the DSP portion of the example remains unchanged).

The PRMs are on the CORBA application level, which means that when PRM modules are swapped, the CORBA application is completely modified. In this example, this changes how the CORBA FPGA counter application reacts to the operation call from the DSP. It also changes the direction of the LED increments, according to the loaded PRM.

The reconfigurable module uses the partial reset and the base design the global reset. The user static portion of the design — a free-running counter that makes two user LEDs blink continuously — is in the custom logic. The


37

LEDs controlled by the base design always blink at the same rate and are not interrupted even when the PRM is loaded.

To compile this example, start the Windows Command Prompt, go to the script folder, and then run doall.bat. PR flow tools start and PR design implementation through batch files begins.

Note You can run each batch file separately, as described above.

Sff Sca Dp - User's Guide

Documents

manipulating

left intentionally

digital signal

const int16t

objective

code composer

digital signal

digital processing