Crimson TNG User Guide - pervices.com

CRIMSON TNG USER MANUAL

PER VICES CORPORATION

Contents

Contents 2Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Product Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1 Specifications and Interfaces 9Absolute Maximum Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Observed Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10External Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Network Interface Card (NIC) Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13Mechanical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13RF Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 System Architecture 15Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Power Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Digital board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Time Board . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Receive Board Radio Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Transmit Board Radio Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19FPGA DSP Chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Bandwidth, Sample Rates, and Networking . . . . . . . . . . . . . . . . . . . . . . . . . . 20Flow Control and Start of Burst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Installation and Configuration 27Hardware Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Crimson TNG Network Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Network Set Up: Host PC Management IP Address . . . . . . . . . . . . . . . . . . . . . 31Network Set Up: Host PC SFP+ IP Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32Network Set Up: Modifying Crimson Management IP Address . . . . . . . . . . . . . . . 36

Testing the Management IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Add New Management IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Removing Management IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Persistently Update Management IP address . . . . . . . . . . . . . . . . . . . . . . 39

LED Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2

CONTENTS 3

4 Use and Operation 40UHD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Web UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40SSH and Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5 Crimson TNG Device Data Format 41Data Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Troubleshooting 42

7 Updating Crimson TNG 44MCU Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Automatic MCU Update Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . 44Automatic MCU Update Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Manual MCU Update Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Manual MCU Firmware Update Procedure . . . . . . . . . . . . . . . . . . . . . . . 45

FPGA Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47FPGA Update Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47FPGA Update Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

FPGA Signal Tap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50FPGA Signal Tap Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50FPGA Signal Tap Attachment Procedure . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Crimson TNG Mechanical 51

CONTENTS 4

Change Log

Date and Revision Notes

2016-05-02: Rev A: Initial Release

2016-05-18: Rev B: Populating Specifications

2016-07-12: Rev C: Update System Architecture Section and Diagrams

2016-09-22: Rev D: Update Top Level and Digital Board Architecture Diagrams

2016-10-20: Rev E: Include SMA Torque Specifications

2016-12-08: Rev F: Update Installation and Configuration Chapter

2017-06-12: Rev G: Update Networking section to include instructions on how to update CrimsonIP address

2017-07-24: Rev H: Adding RTM5 Clocking architecture, additional flow charts, troubleshootingsection.

2017-09-18: Rev I: Additional clocking information, sample rate information, and adding externalreference input limitations.

2017-11-08: Rev J: Adding additional information on jitter.

2017-12-07: Rev K: Adding flow control stub, fixing reference output section to indicate Crimsonoutputs its own reference.

CONTENTS 5

Preface

Crimson TNG

Crimson TNG is a high performance, wide band, high gain, direct conversion quadrature softwaredefined radio transceiver and signal processing platform. It has four channels, each comprised ofindependent receive and transmit blocks, capable of processing up to 325MHz of instantaneousRF bandwidth from DC to 6.8GHz and synchronized using a JESD204B subclass 1 link to ensuredeterministic latency. Data may be processed on the device itself (there is an Altera Arria VST FPGA SoC on-board), or sent over low latency dual 10GB Ethernet links by connecting theintegrated SFP+ headers to a compatible 10GBASE-R network device.

Crimson TNG is intended for advanced signal processing and data collection applications.

CONTENTS 6

Congratulations!

Congratulations on your purchase of the Per Vices Crimson TNG Transceiver! This manual isintended to provide you with useful information regarding the safe operation and use of your newtransceiver. Although it may be updated from time to time, you’ll always be able to find the latestversion of the manual on the Per Vices website1.

In building Crimson TNG, we aimed to provide advanced capabilities at the lowest possible price.This product provides a sophisticated platform capable of advanced RF Signal processing andincludes a robust and fully integrated RF chain.

Our hope is that you will find Crimson TNG to be a useful and dependable companion in yourengineering, development, and research efforts.

We welcome your feedback so please feel free to contact us.

Copyright © Per Vices Corporation, 2017. All rights reserved.

Contact Information:Per Vices Corporation2440 Dundas St West Unit 204Toronto, OntarioM6P [email protected]

1http://www.pervices.com

Obligatory Warnings

This chapter contains important safety and regulatory information. Please pay attention to thefollowing disclaimers, warnings, and cautions. This device is intended for engineering, research, orscience laboratory use only - it is not for open office or residential use.2

Disclaimer

This product is provided «As Is». Per Vices is under no obligation to provide updates, upgrades,support, or maintenance of any kind. Per Vices specifically disclaims any and all warranties andguarantees, express, implied, or otherwise, arising with respect to the use of this product including,but not limited, to the warranty of merchantability, the warranty of fitness for a particular purpose,and any warranty of non-infringement of the intellectual property rights of any third party. PerVices neither assumes nor authorizes any person to assume for it any other liability.

Use of this device is at your own risk. Per Vices shall not be liable for any damages, direct orindirect, incurred or arising from the use of this product. In no event will Per Vices be liable for lossof profits, loss of use, loss of data, business interruption, nor for punitive, incidental, consequential,or special damages of any kind, however caused, and on any theory of liability, whether in contract,strict liability, or tort (including negligence or otherwise), arising in any way out of the use of thisproduct, even if advised of the possibility of such damages.

Product Functionality

Every effort has been made to ensure that the device you receive is fully functional - each device isfully tested prior to shipping. Risk of damage or loss is transferred immediately upon delivery toyou - we do not generally accept returns or refunds on successfully delivered packages. That beingsaid, we do want to ensure your experience with Per Vices and Crimson TNG is a pleasant oneand we encourage you to contact us at [email protected] if you have any problems.

Specifications

Every effort has been made to test and measure the validity of this equipment. However, we cannotguarantee the accuracy of specifications, and they may change at any time.

2This device has not been tested or approved by any agency or approvals body for Electrical Safety, Electromag-netic Compatibility, or Telecommunications at the time of distribution! Use this device at your own risk.

7

CONTENTS 8

Warnings

WARNINGRISK OF ELECTRIC SHOCK

Do not attempt to modify or touch the internals of this device.Ensure host computer is properly grounded during operation.

Disconnect AC power during installing or removal.

WARNINGHOT SURFACE

This device may become very hot during operation; avoid contact.Ensure adequate ventilation and that unobstructed fan inlets.

WARNINGLABORATORY USE ONLY

This device has not been approved by any agency or approvalsbody for Electrical Safety, Electromagnetic Compatibility, or

Telecommunications at the time of distribution. Research use only!

ATTENTIONOBSERVE ESD PRECAUTIONS

This device contains electrostatically sensitive components: itmay be damaged by static discharges. Observe ESD precautions &proper grounding when handling, installing, or removing device.

ATTENTIONRF TRANSMITTER

This device is capable of RF transmission on bands or frequenciessubject to regulatory oversight. Operators are responsible to ensureuse of this device meets local regulatory and legal standards, as

they may apply to you and the band of interest.This device is intended for test and measurement use only.

1

Specifications and Interfaces

Crimson TNG is a wide band, high gain, direct conversion quadrature transceiver1 and signalprocessing platform. Using analogue and digital conversion, it is capable of processing signal band-widths up to 325MHz from approximately DC to 6.8GHz. Crimson TNG is compatible with GNURadio and includes source code for many of its drivers and peripherals.

Absolute Maximum Ratings

Stresses beyond those listed in the Absolute Ratings Table (Table 1.1) may cause permanent damageto the device. These ratings are stress specifications only. Functional operation of the product atthese conditions is not implied. Exposure to absolute maximum rating conditions for extendedperiods of time may affect reliability and is, therefore, not recommended.

Table 1.1: Absolute Ratings: Exposure or sustained operation at absolute ratings may permanentlydamage Crimson TNG. Ensure fan inlets (located on both sides of the device) are not blocked duringoperation.

Specifications Min Max Units Notes

Operating Temperature 5 40 C At fan inletOperating Humidity 5 100 % Non-CondensingStorage Temperature 0 40 CStorage Humidity 20 95 % Non-CondensingInput RF Power 10 dBm Do not exceed.External Reference 3 Vpp Do not exceed.SMA Torque 0.6 0.7 Nm

1As Crimson TNG is capable of Digital Down/Up Conversion, superhet architectures can be implemented usingDigital Down/Up Conversion on the FPGA.

9

1. SPECIFICATIONS AND INTERFACES 10

Observed Performance

Crimson TNG is a very flexible radio and signal processing platform that supports high bandwithcommunications over a wide tuning range. The hardware and signal processing capabilities may beconfigured to support a very wide variety of applications, each with their own figures of merit. Itis, therefore, fairly challenging to provide uniform performance specifications across those differentconfigurations.

To provide a general idea of what this product is capable of, Table 1.2 on the next page lists someconservative figures of its out-of-box performance. Configuration of the product towards a specificapplication may see some of these figures exceed at the expense of others. For more information,please do not hesitate to contact us at: [email protected].


Table 1.2: Observed Performance. These specifications reference observations taken during internaluse and development. Calibration Measurements relative to 20˚C

Specification Min Nom Max Units

Common Radio RF Stage (ADF4355) 110 6800 MHzBaseband Stage 0.1 140 MHzDyn. Range 25 70 dBSFDR 65 dB

Receive Radio RF Input Power -40 dBmNoise Figure, Rx RF St 3.1 7 dB

Power GainLow 15 45 dBHigh -10 65 dB

Group Delay (Radio Chain)1Low 13.7 nsHigh 20 ns

ADC Independent Channels 4 -(Receive Converter) ADC resolution 16 bits

ADC Sample Rate 325 325 MSPSRx Sampling Bandwidth 325 MHzLatency (input to serial)1 50 ns

Receive DSP and FPGA Decimation ( fsn

) 1 256 -Specifications Latency (FPGA DSP)1 50 500 750 ns(Default firmware)

Transmit RadioTransmit Power

Low -30 18 dBmHigh -10 15 dBm

Group Delay (radio chain)1Low 5 nsHigh 11 ns

DAC Tx Output Bandwidth 325 MHz(Transmit Converter) DAC resolution 16 bits

DAC Sample Rate 325 MSPSLatency (serial to output)1 50 655 804 ns

Transmit DSP and FPGA Interpolation (n · fs) 1 256 -Specifications Latency (FPGA DSP)1 96 160 ns

Digital FPGA - Arria V ST SOC 5ASTMD3E3F31 -On Board Processor Core ARM Cortex-A9 MPLPDDR2 RAM 4 GbNAND Flash (x8) 4 Gb

Networking 10GBASE-R, Full Duplex2 each 10 GbpsDefault IP, SFP+ Port A 10.10.10.2 -Default IP, SFP+ Port B 10.10.11.2 -

Int. Reference (10MHz) Frequency Calibration -5 5 ppbExt. Reference (10MHz) Voltage Swing 2.2 2.4 3 Vpp

1For additional information on latency, please refer to the Latency section on page 22.2For additional information on bandwidth and sample rate, Bandwidth section on page 22.


External Interfaces

Crimson TNG has a number of user accessible interfaces through which the device can connectto external sources and sinks. Management functions are carried out over a web page hosted bythe Crimson TNG transceiver and accessible using the Management ethernet port on the frontface of the device. Data is sent over the 10Gbps SFP+ ports and receive and transmit antennasconnect to the SMA connectors on the front of the device. Other peripherals ports provide accessor the capability to improve functionality.

10/100 Management Port This connects to a Linux system running on the Hard Processing Sys-tem located on the FPGA silicon, and provides a unified interface bywhich to control and configure the remaining devices.

10GBASE-R SFP+ There are two SFP+ ports on the front panel of the device that use10GBASE-R encoding to directly communicate with an optical moduleand interface with a ten gigabit network. These ports directly inter-face with the FPGA fabric and support high bandwidth, low latencycommunication between the ADCs and DACs.2

50Ω SMA There are sixteen standard SMA headers. These are used to connectto external antennas, sinks, or sources, including:

Rx (x4) The four independent receive channels may be connectedto external sources or antennas

Tx (x4) The four independent transmit channels may be connectedto external antennas or sinks

Ext. Osc For the most demanding applications, an external oscillatormay be used to drive the LMK04828 outputs. This impliesa completely external synchronization solution

Ext. PLL A reference clock for local oscillator generation for the fre-quency synthesizers for receive and transmit PCBs

Ext. Sys The system reference clock for converter devices and theFPGA; only present when a sysref command is issued

Ext. Dev An external 322.265625MHz clock directly to the converterdevices as well as the FPGA

Ext. Ref An external 10MHz reference may be applied to this portin lieu of the default, internal, 10MHz reference

Ref. Out Crimson TNG may output its internal reference clock toother systems.

PPS This port can be used to synchronise internal time keeping(note: this will be enabled in future releases)

TRIG This port can be used as a trigger (note: this will be enabledin future releases)

USB 2.0 A USB port connects to the Linux system running on the Hard Pro-cessor System.

2Please note, not all 10Gbps NICs support 10GBASE-R protocols - it is important that you ensure the card youselect supports communication using 10GBASE-R. If you have questions about this, please do not hesitate to contactus.


Micro-SD Slot The FPGA and Hard Processor System may be rebooted or configuredusing an external Micro-SD card.

Industrial Mini I/O GPIO connects to the FPGA

IEC320 C14 Power A standard «computer» cable plugs into this connector to power theunit. The power supply accepts 120V or 240V.

Operating System

Crimson TNG may be used with any operating system. After connecting the Crimson TNGTransceiver to an external network or computer using its dedicated Ethernet management port,you may configure the device using the provided web interface. It is also possible to SSH into thesmall Linux distribution running on the on-board processor.

Network Interface Card (NIC) Requirements

Crimson TNG uses a 10-gigabit Ethernet connection to quickly send and receive data. TheCrimson TNG uses a 10GBASE-R3 PHY that interfaces with each SFP+ port using a single,10.3125Gbps serial lane and a scrambled 64B/66B coding scheme. It is very important to ensurethat network devices or interfaces intended to be used to connect to Crimson TNG support10GBASE-R. The 10GBASE-R family includes 10GBASE-KR, 10GBASE-SR, 10GBASE-LR, and10GBASE-ER interfaces.

Note that Crimson TNG also requires active cabling: using passive, direct connect, SFP+ ca-bles is not supported. We recommend using active optical cabling (AOC) with integrated SFP+transceivers. Alternatively, you may also choose to use a fibre cable and a compatible 10GBASE-RSFP+ optical transceiver module.

If you have any questions or concerns about NIC card requirements, please do not hesitate tocontact us.

Mechanical

Crimson TNG conforms to a 1U form factor and 19-inch+ rack. A mechanical diagram is includedin Chapter 8.

3There is a significant difference between a 10GBASE-X interface (4 serial lanes specified to 3.125Gbps using8b/10b coding), and the 10GBASE-R interface (1 serial lane specified to 10.3125Gbps using 64b/66b coding) thatCrimson TNG uses. Although both standards may expose the same mechanical SFP+ interface (and therebyallowing you to mechanically connect the two interfaces) the standards are fundamentally incompatible. ConnectingCrimson TNG (10GBASE-R) to a network card that only supports 10GBASE-X or 10GBASE-T will not work.


RF Chain

Simulated RF chain performance (based on component specifications) yield the simulated perfor-mance indicated in Table 1.3. As both the receive and transmission chains use variable stages,the figures were calculated using midpoint references for attenuation and gain stages. With propertuning and calibration, you should expect better values. More information on the specific RF chainused may be found in the System Architecture Chapter 2 on the following page.

Table 1.3: These specifications are intended to serve as a broad guide, with variable gain and at-tenuation stages set at midpoints. As variable stages are adjusted, performance generally improves.

Specification Value Units

Input Parameters Input Power -55 dBmFrequency 2000 MHzAnalysis B/W 150 MHz

Rx Chain Analysis lna lna+paNF 4.8 3.1 dBSFDR 55 47 dBIMD -113 -81 dBIIP3 -1.3 -17 dBmSNR 32 33 dBRx Sensitivity -86 -87 dBmInput P1dB -28 -44 dBm

Tx Chain Analysis Power Gain -20 – 5 dBmSFDR 40 – 70 dB

2

System Architecture

Overview

Crimson TNG uses a highly modular design consisting of five boards. Each board is connectedusing shielded, high speed cabling to support its operation (Figure 2.1). The power board providespower to the digital, time, receive (Rx), and transmit (Tx) boards. The digital board provides aninterface to control, configure, and send/receive data to/from the receive (Rx), transmit (Tx), andtime boards. Clock distribution extends from the Time board, which provides a very clean andstable clock distribution network. The default receive and transmit boards each comprise of fourfully independent channels.

FPGA

HPS

HPS - FPGABridge

ARRIA V

DIGITAL

POWER

RESET

Rx A

MCU

ADC A

ADC B

ADC C

ADC D

RFE A

RFE B

RFE C

RFE D

RECEIVE (RX)

Rx B

Rx C

Rx D

MCU

DAC A

DAC C

RFE A

RFE B

RFE C

RFE D

TRANSMIT (TX)

Tx A

Tx B

Tx C

Tx D

SFP+A

SFP+B

TIME

RESET

SYSREF

DEVCLK

PLL

OSCOUT

REFOUT

REFCLK10GBASER

10GBASER

10/100 ETHERNET MGMT

TX

RX

TIME

DIGITAL

(RxA, RxC, TxA, TxC)

(RxB, RxD, TxB, TxD)

Figure 2.1: Overall system block diagram.

15

2. SYSTEM ARCHITECTURE 16

Power Distribution

Crimson TNG is powered by an internal 12V, 200W, overcurrent protected, DC power supplyplugged into a standard IEC320 C13 120-240VAC computer power cable at the rear of the unit.The power board distributes power to the four daughter boards as shown in Figure 2.2.

Power

Debug &Programming

5.5V3.6VProg.

Debug &Programming

5.5V3.6VProg.

Debug &Programming

5.5V3.6VProg.

Debug &Programming

5.5V3.6VProg.

Time TX RX Spare

5.5V Spare

5.5V Digital

12V, 200WDC Power Supply

IEC320 C14120-240V

Figure 2.2: Power board system block diagram

Digital board

The Crimson TNG digital board provides the digital processing that powers the Crimson TNGtransceiver. It consists of an Altera Arria V ST SOC FPGA, which includes an ARM Cortex-A9processor on the FPGA (Figure 2.3 on the next page). The ARM (HPS) portion of the board hoststhe web server through which Crimson TNG can be configured, and a UART serial port, which isused to communicate with the Rx, Tx, and time modules. A separate high speed link allows serialdata to be shared directly between the Rx and Tx boards and the FPGA fabric. This link alsoallows the data to be shared between the FPGA fabric and the 10Gbps interface (accessed usingthe SFP+ ports on the front of the device). Other peripherals, including USB devices, are accessedthrough the HPS portion of the FPGA.


SFP+A

SFP+B

10GBASER

10GBASER

ADC A

ADC B

ADC C

ADC D

DAC A

DAC C

TX

RX

TIME

DAC A

DAC C

10/100 ETHERNET MGMT

FPGA

HPS

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

FIFO DSP JESD 204B

10G BASERPHY

10G BASERPHY

Rx A

Rx B

Rx C

Rx D

Tx A

Tx B

Tx C

Tx D

SERVER UARTUSB

HPS - FPGABridge

ARRIA V ST SoC

RESET POWER

Figure 2.3: Digital board system block diagram.

Time Board

Clock distribution on the Crimson TNG transceiver is fairly robust. The internal reference sourceis an oven-controlled crystal oscillator (OCXO) that provides a very stable (5ppb) and accurate10MHz signal and may be tuned using the AD5624R nanoDAC. A single ended external referenceclock may also be used, provided it meets the input swing requirements listed on the specificationspage1.

For RTM5 units (Figure 2.5), the default clock onfiguration sees the 10MHz reference input fre-quency divided by two, and passed to the CDCLVP1204 2:1 clock buffer, where it is distributed tothe LMK low jitter integrated PLL+VCO synthesizers. One of the buffered outputs is also accessi-ble using the “Ref Out” port. Note that the default configuration uses an internal 5MHz signal tosupport the default 325MHz sample rate, and to support phase coherent operation.

For RTM4 devices (and Figure 2.4), the CDCLVP1204 2:1 clock buffer selects either the internal orexternal references and provides two outputs. The secondary output is a buffered reference output(see Ref. Out on front panel of transceiver). The primary output (which originates from either theinternal or external reference, depending on the configuration) goes to the HMC988. The HMC988provides additional dividers (disabled by default) and phase shift/group delay capablities. Afterthe HMC988, the output goes to the first LMK04828 low jitter clock generator.

The LMK04828, by default, has a 10MHz input and uses the internal Phase Locked Loop (PLL1)tocontrol a 100MHz low phase-noise VCXO. This locks the ultra low phase-noise 100MHz VCXO tothe stability provided by the 10MHz input. The 100MHz VCXO output subsequently drives PLL2of the first LMK04828. This provides a 322 MHz JESD204B (subclass 1) device clock and sysrefclock to the converters and transceivers (ADC, DAC, and FPGA).

1The default external reference frequency should be 10 MHz, but it is possible to use an unless using customdividers/logic (the hardware supports various external reference frequencies, but this is not exposed to the user).


A buffered copy of the 100MHZ VCXO output is also provided to a second LMK04828, througha second HMC 988. The buffered output drives the second PLL of the second LMK04828 andprovides clocking to all frequency synthesisers for each front end channel. A buffered output ofthe analog reference signal is also provided (Ext.PLL) and a buffered copy of the original 100MHzreference signal is available on Ext. OSCout.

The default configuration has been factory calibrated to provide a known (in-phase), deterministicrelationship for all LMK04828 outputs. The Leading edge of all outputs and internal VCOs havebeen synchronised at the reference inputs of all frequency synthesizers, converters, and transceivers.

CDCLVP1204

AOCJY-10.000MHz

Vtune

Δt RX ADC

Δt TX DAC

Δt FPGA

Δt

Δt Ext. PLL

TX PLLΔt

Δt RX PLL

FPGA PLL

,÷NΔtHMC988

LMK04828

,÷NΔtHMC988

LMK04828

Ext. RefClk

Ref. Out

CVHD-950-100

Ext. SysRefΔt

Ext. DevClkΔt

AD5624R

nanoDAC

JESD204BClass 1

CW Referenceto Frequency

Ext. OSCout

FPGA REF

Figure 2.4: RTM4 Time Board Architecture.

CDCLVP1204

AOCJY-10.000MHz

Vtune

Δt RX ADC

Δt TX DAC

Δt FPGA

Ext. PLL

RX PLL

Ext. RefClk

Ref. Out

CVHD-950-100

Ext. SysRefΔt

Ext. DevClkΔt

AD5624R

nanoDAC

JESD204BSubclass 1

LOReference

to Rx and Tx

Ext. OSCout

FPGA PLL

TX PLL

LMK04828

Δt

Δt

Δt

CVHD-950-100

LMK04821

Δt

FPGA REF

,÷NΔtHMC988

,÷NΔtHMC988

Figure 2.5: RTM5 Time Board Architecture.


Receive Board Radio Chain

The Crimson TNG receive board consists of a radio front end terminating with the Texas In-struments dual channel ADC16DX370 analog-to-digital converter, as shown in Figure 2.6. Thisarchitecture is duplicated four times, once for each channel.

PE43704

High Stage

Low Stage

I

Q

AG403-89G

ADL5380BFP843

PMA3-83LN+

PE42920

Low Noise AmplifierRF Gain

VariableAttenuator

Frequency Synthesizer

BB Gain

Gain Bypass

ADF4355

Low

LowSMAInput

IQ DownConverter

LMH6521

ADC Driver

ADC16DX370

ADC

Altera Arria V ST

5ASTMD3E

FPGA + HPS

Anti AliasingFilter

Anti AliasingFilter

SKY13374-397LF

SKY13374-397LF SKY13374-397LF

Figure 2.6: Rx Board RF Channel

Transmit Board Radio Chain

The Crimson TNG transmit board consists of a radio front end originating with the Texas In-struments quad channel DAC38J84 digital-to-analog converter, as shown in Figure 2.7. The radiofront end is duplicated four times. Channels A and B connect to one DAC, and channels C and Dconnect to another DAC.

AI Filter

ADF4355

Frequency Synthesizer

RF Gain

BB Gain

IQ UpConverter

DAC

5ASTMD3E

FPGA + HPS

DAC38J84

TRF370417 PHA-1+ PHA-1+

PE43704 PHA-1+AG403-89G

PE43704

High Stage

Low Stage

I

Q

I

Q

SMAOutput

Altera Arria V ST

PE42920 SKY13374-397LF

RF GainVariable

Attenuator

VariableAttenuatorBB Gain

Figure 2.7: Tx Board RF Channel


FPGA DSP Chains

A simplified illustration of the DSP chains for transmit (Figure 2.8) and receive (Figure 2.9) providesa broad outline of the FPGA processing from the SFP+ ports to the convertors.

SFP+Input

ARRIA V FPGA

DAC

Trig R10G Ethernet

CORDICMixerResamplerVITA/Trig FIFODeframing

Figure 2.8: Simplified Tx DSP Chain.

SFP+Output

ARRIA V FPGA

ADC

TrigR 10G Ethernet

CORDICMixer Resampler VITA/Trig FIFO Framing

Figure 2.9: Simplified Rx DSP Chain.

Bandwidth, Sample Rates, and Networking

Each radio chain can have up to 325MHz of instantaneous stare bandwidth at the FPGA. However,due to the bandwidth limitations of the SFP+ protocol, transmission and reception at that raterequires storing or receiving waveforms on the FPGA for processing. This is because the systembandwidth is limited by two 10GBASE-R SFP+ ports.

In the default configuration, RF Rx and Tx channels A and C are directed to SFP+ port A, andRx and Tx channels B/D are directed to SFP+ port B.

Each SFP+ port can sustain a throughput of 10Gbps. However, at 32bits per sample (16bits I, 16bitsQ), at 325MSPS = 10.4Gbps. This exceeds the channel capacity of the SFP+ port. As a result, inorder to transmit data, we need to decimate by integer multiples (or else use the 4/5 decimationblock). Accordingly the maximum sustained sample rate over a single SFP+ ports, using the 4/5decimation block, is 325MSPS*4/5*32bits = 260MSPS*32bits = 8320Mbps for a single channel.We can additionally assume an additional 5% protocol overhead, assuming a 1400 byte payload,and 64 byte header, which yields a final throughput of 8736Mbps. This is acheived using the 4/5decimation block, which automatically performs the required interpolation and decimation, butwhich, due to resource constraints, may introduce DSP artifacts. For superior performance, youcan use the native clocking chain (without the 4/5 resampler), and would therefore get maximumSFP+ performance of 162.5MSPS per channel per SFP+ connector.

As the default configuration combines RF channels A and C on SFP+ A, and RF Channels B andD on SFP+ B, this means the largest combined sample rate for two channels on a single SFP+port is: 130MSPS on each channel (using the 4/5 resampling), or 162.5MSPS on one channel, and108.33MSPS on another (using the native clocking scheme).

Additionally, due to transceiver limitations on the stock product, the transmit channels on SFP+C/D have an FPGA limitation of 81.25MSPS. This means that the maximum default transmissionbandwidth on those channels is 81.25MHz. It is possible to obtain the full 325MSPS bandwidth onall four output channels with custom firmware, however, this limits the number of available recieve


channels. If your application demands full bandwidth on each channel, please contact us and wecan provide you with custom firmware.

Further note that, in baseband mode, we do not implement a complex upconvertor in hardware.As a result, for baseband operation, the maximum bandwidth is 161.5MHz. If you need largerbaseband bandwidth, it is possible to extend operation of the high frequency stage and mixers tobelow 160MHz, allowing users to obtain full bandwidth at lower frequencies. Please contact us ifthis is required to support your application.

Flow Control and Start of Burst

This section addresses some of the mechanisms behind flow control and start of burst.

The current code requires the error between the Host PC and Crimson to be less than 20ppm forconvergence to be achieved. On non-realtime operating systems, it is sometimes the case that underload the system performs differently, which causes us to occasionally lose convergence, and thoughwe have mechanisms to handle this gracefully, we recommend a direct 10G connection betweenCrimson and the Host PC.

In order to ensure deterministic data transmission, accurate and precise time synchronization be-tween the Host PC and Crimson is required to ensure:

1. All channels have data in their buffers *prior* to the start time.

2. That transmission data streams start at an appropriate time to ensure that the Crimson trans-mission packet buffer is neither exhausted (causing underflows because we started streamingdata too late), or saturated (resulting in overflows because we started sending data too early).

3. That we preserve sufficient buffer margin to absorb any variations in latency introduced byNetwork cards or switches. If incoming data is delayed for too long, then the transmit bufferwill be exhausted before that data arrives (causing an underflow).

In the event of an underflow, the current implementation keeps track of exactly how many sampleswe have dropped. When the updated samples come in, we drop as many samples as is required toensure that relative coherency (with respect to our first packet sent) is preserved.

Motivation

In the ideal case, we would not need flow control; the entire network stack would be entirelydeterministic, and packets would be sent at uniform intervals. As a practical matter, this is notthe case. Consider the following case of an ideal network card, a switch with substantial jitter, andCrimson.

1. The ideal network card happens to send packets at perfectly uniform intervals, with zerojitter.

2. The 10G switch introduces a fixed latency component and a variable latency component(jitter).

3. You start streaming data, and achieve steady state. At this point, your host PC is sendingradio data in UDP packets at uniform intervals, which are being re-transmitted by the switch.

4. The Crimson transmission sample buffer holds steady at 85% - the default value which helpsprovide sufficient margin for start of burst, and damp out any routine fluctuations.


a) We use the sample buffer level to help ensure that the sample rate of the hostPC isaligned with the actual sample rate at which Crimson sends data. This is because, whentransmitting data, the clock that matters most is the transmit device clock, which isfound within Crimson. Taking this clock as an absolute reference, we need to compensatefor any drift or variation between the hostPC clock and the Crimson reference clock -we can use the buffer level as a very reasonable proxy for this difference, and adjust thetransmission rate from the HostPC accordingly.

5. You’ve achieved steady state, and then (randomly) your switch delays the transmission of apacket. During this time, your network card continues to send packets to the switch, whichare buffered.

a) This is the difference between a store-and-forward switch, and a cut-through switch.A store-and-forward switch waits for the entire Ethernet frame to be cached prior toforwarding the data. A cut-through switch starts forwarding frames immediately aftergetting the first 12 bytes of the Ethernet header. (This doesn’t necessarily do what youthink to latency, though).

6. At this point, the Crimson transmit buffer is still reasonably full, so there is no interruption.However, depending on your sample rate we might be consuming samples very quickly - inwhich case we will underflow (run out of samples). At this point, Crimson will send zero-valued samples to the DAC (the chain does require data), and keep track of how many zerovalued samples it has sent.

7. At this point, the switch releases all the buffered data - All at once, and at the 10G line rate.

8. The packet handler on Crimson then drops the first N packets or samples (depending on howmany zeros we have inserted), to ensure phase coherency, and then start buffering data oncewe’re back in sync.

9. At this point, the crimson sample buffer may be very low - so it’s very susceptible to additionalvariations. Our flow control routine detects this and ensures the buffer returns to the nominallevel.

If you are observing issues with glitches in the output, confirm that the network route to the devicehas as low a latency as possible - this helps improve the reliability with which you can send packetsto Crimson.

Latency

This section addresses requirements and concerns associated with latency critical applications. Asthe stock product is not optimized for latency, we encourage users with latency sensitive applicationsto contact us directly to help determine the optimal implementation.

For the purposes of this section, we will concern ourselves with two types of latencies: the receiveor transmit latency and the round trip latency. Recieve or transmit latency is the time required forthe unidirectional reciept or transmission of data between the antenna of the radio chain and thehost computer. The round trip latency is the time required for radio data that is received on oneradio chain to be transmitted on another chain (or vice versa).

Receive or Transmit Latency

This measurement concerns itself with measuring the time elapsed from when an signal incident onthe antenna is processed and presented to the user. Alternatively, it is the time elapsed from whena user application sends radio samples, to the time those samples are transmitted over the antenna.


Various sources contribute to this latency, including the radio chain, converters, FPGA DSP, packe-tization, buffering, and network transmission latency, and OS recieve latency. Equations 2.1 and 2.2summarize the major latency contributors when considering recieve and transmit latency:

τlat,Rx = τRF,Rx + τADC + τDSP + τbuf,Rx + τframe + τnet + τos,Rx + τapp,Rx (2.1)

τlat,Tx = τapp,Tx + τos,Tx + τnet + τdeframe + τbuf,Tx + τDSP + τDAC + τRF,Tx (2.2)

Where, τlat,rx and τlat,tx are the total receive and transmit latency, is the total system latency,τRF,Tx and τRF,Rx represent the transmit and receive group delay associated with the radio frontends, τADC and τDAC is the total converter (de)serialization delay, τDSP which is the DSP pro-cessing delay on the FPGA, and which accounts for Digital Up/Down Conversion, Decimation,Interpolation, and filtering, τbuf,Rx and τbuf,Tx represent the FPGA receive and transmit samplebuffers, τdeframe and τframe represent the time required for the FPGA to frame or deframe theethernet packets, τnet is the total network latency, (τos,Tx and τos,Rx) is the host PC operatingsystem network stack latency, and τapp,Tx and τapp,Rx is the userspace client recieve or transmitlatency.

It is worth noting that not all of these sources have a constant latency contribution. Examiningsome components in more detail, we find that the radio chain group delay, τRF , is an approximatelyconstant and largely invariant to changes in sample rate, or frequency. In contrast, the networklatency, and especially the transmit latency (τnet,Tx ), and operating system latencies (τos,Rx andτos,Tx) can be especially variable, with a strong dependancy on the type of network card, operatingsystem, and system load. This latency may be reduced by purchasing a 10GBASE-R NIC that isoptimized for low latency, and made more determinate by running a real-time operating system tohelp limit variance. Taking this variance into account is especially important when transmittingat high sample rates on multiple channels (ie. over 30MSPS on 4 channels). This is because thetransmit FIFO is specified as a fixed number of samples - at very high sample rates, the cumulativeperiod represented by the fixed number of samples stored in the FIFO is reduced, which makesthe overall system more susceptible to the transmit NIC variance2. Also note that due to thedeterminism of Crimson, the delivery and reciept of samples to and from the FPGA 10G PHY hassubstantially lower variance and jitter compared to that of the host PC. If this potentially impactsyour application, please contact us for more specific advice.

In addition, the sample buffer latencies (τbuf,Rx , τbuf,Tx ) strongly depends on sample rate. Thisis because the sample buffers are located immediately before and after the 10GBASER framingcode, as shown in Figures 2.8 and 2.9. In the case of the recieve chain, the samples accumulatein the sample buffer, at divisor of the sample rate clock, until a sufficient number of sampleshave accumulated to make up a complete UDP payload. Once a sufficient number of sampleshave accumulated to make up an entire UDP packet payload, those samples are popped from theFIFO, at the network clock rate, and assembled into a complete UDP packet that is immediatelytransmitted (and accounted for in τframe and τdeframe ).

As a result of this, we can expand τbuf,Rx and τbuf,frame into:

τbuf,Rx =Ppkt,bytes

Ssmpl,size,bytes·(

1

fs

)(2.3)

τ(de)frame =Ppkt,bytes

Sframesize·(

1

fc,nw

)(2.4)

2Note that in the event of a buffer underflow or overrun, the default FPGA configuration inserts zero valuedsamples, or discards samples, to preserve the initial sample coherency.


Given that Crimson uses complex samples of 32 bits each, Ssmpl,size = 4, and the ethernet frameris 64 bits, Sframesize = 8, with a network clock of fc,nw = 156.25MHz , and the default specifiedpacket size is Ppkt,bytes = 1600 bytes, we can simply 2.3 on the preceding page and this means thedefault latency is:

τbuf,Rx,default ≈400

fs(2.5)

τ(de)frame,default ≈ 1.28µs (2.6)

When analyzing transmission latency, consideration needs to be applied to the transmit samplebuffer. Crimson communicates over a packetized Ethernet network - that is, the minimum unit ofsample data transmission is a UDP packet, with a payload (made up of a number of complex radiosamples) size is generally determined by the amount of data the application passes to Crimson whensending it data.3. In otherwords, the stock Crimson firmware image product does not have anyprovisions for the regular and monotonic transmission of individual samples, but rather aggrigates anumber of samples into UDP packets which are sent at the 10GBASE-R line rate to Crimson. Thisaspect is somewhat analagous to how the FPGA queues samples from the ADC until a sufficientnumber have accumulated, and, in a well designed system, the actual radio sample generationis not a limiting factor, and the transmission buffer latency analysis is identical to the receivecase. However, this analysis does not take into account, or compensate, for other system variance.Therefore, in order to complete the analysis of τbuf,Tx, we need to consider the impact of τos,Tx

and τnet,Tx.

In an ideal system, the host PC would transmit individual radio samples to Crimson at exactly thecorrect sample rate, and perfectly regularly. Such a perfect and ideal system would not require anybuffering - because the host PC and application sample rates and jitter are perfectly matched, theFPGA would always have exactly the correct number of samples to send to the DAC. The closestpractical approximation to such a system would be when interfacing the SDR to a synchronousdata processing source, such as another FPGA, that shares the same reference source and clock.In such cases it is comparatively easy to design and optimize the amount of buffering required tocompensate for sample rate clock variances (due to random drift, thermal variance, noise, or siliconvariations), and thereby minimizing the latency contribution of τbuf,Tx.

When interfacing with an external PC, running a traditional operating system, a number of differentconsiderations come into play. In addition to not sharing a common clock (which requires us toaddress crossing clock domains with a potentially large variance), there are two major sources ofvariance: the operating system (τos,Tx ) and the 10GBASE-R NIC (τnet,Tx ). When a host PCapplication calls send(), the UHD library needs to make a number of system calls to the operatingsystem in order to actually send the data over the network, to the correct address, at the correcttime. The time required for these calls to be serviced by the operating system (τos,Tx ), canvary quite substantially. Additionally, most host computers lack the stable and precise time sourcerequired to preserve a frequency reference (and that is included by default in Crimson), and thereforecannot immediately agree on the duration of 1 second.

In addition to this, different 10GBASE-R ethernet PHYs can have substantially different latencies(τnet,Tx ) that can also vary substantially. Part of this behaviour is intrinsic to the Ethernet protocol,which requires random back-off periods, and part of it is due to the design and implemention ofspecific network cards, which are broadly optimized for throughput, and not latency. Table 2.1 onthe next page provides some very rough figures for the round trip time of simple packet.

3More specifically, when calling the UHD library send() command, the nsamps_per_buff argument is used todetermine the number, and size, of the UDP packets that will actually encapsulate the sample data. While thesmallest meaningful payload consists of a single sample, the maximum payload size is bounded by the maximumindividual Ethernet packet size (9000 bytes when using jumbo frames), and Crimson protocol support (which doescurrently allow for fragmented UDP packets).


Table 2.1: Round Trip Time (RTT) comparison for Crimson-PC communication between variousNICs.

NIC Part Number Manufacturer Round Trip Time (µs) Std.Dev(µs)

IPG(µs)min avg max

FFRM-NS12-000 Atto Technologies 6 8 908 3 13

OCe14102B-UM Emulex Corporation 9 13 271 4 21

ADD-PCIE-2SFP+ AddOn 5 9 400 4 13

This table compares the round trip time between a host PC and Crimson using various networkcards. These figures are not intended to be a performance proxy, and are not statistically significantor even rigourous. They are simply intended to illustrate real world NIC variances. Using the defaultCrimson image, the results of: ping 10.10.10.2 -f -c 1000000 were used to populate the table (thisconstitutes a comparatively small sample size, and took between 13-24 seconds to complete).

As user samplerate increases, the variation in τos,Tx and (τnet,Tx ) can rapidly become greaterthan the temporal duration represented by the payload of a single UDP packet. For example,assuming an approximate payload of 1500 bytes, we can use 2.5 on the preceding page to determinethe amount duration of radio samples encapsulated by a single packet. With a sample rate of1MSPS, this represents 400µs, which is approximately comparable to maximum round trip timewe observed in Table 2.1. But with a sample rate of 10MSPS, each payload now represents only40µs. At this point, because the NIC variance is greater than duration of time represented byone packet, in the absence of a compensation mechanism, transmitting a single packet at a timemeans that the duration of time represented by those samples could be less than the maximumamount of time it requires the next sample to be transmitted. In otherwords, although the timeaveraged throughput of the system may be constant (over a sufficiently long period) because theperiod-to-period variation between subsequent packets is greater than the duration of radio datarepresented by the sample within a packet, we will temporarily run out of data to send.

Of course, this poses a very substantial and critical problem. Because the transmission of radiodata requires a tightly coupled and synchronous dataflow in order to effectively represent arbitrarywaveforms, when we run out of user data to transmit to the DAC (ie: we are in an underflowcondition), we need to insert zero valued samples. In addition, due to the realtime requirements ofa radio system, data that comes in late is not particularly useful - oftentimes, it is better to keeptrack of how many samples the system inserted, and, on reciept of a packet, discard late data andresume from the correct point (the better to preserve phase coherency).

Moreover, depending on the application implementation, the fact that data is delayed does notmean it’s not arriving (eventually). Depending on the duration of the delay, sufficient packets mayhave accumulated that Crimson does not have time to store all the late data (overflow).

As a direct result of these considerations, Crimson includes a fairly robust flow control mechanismto ensure synchronous data transmission and timing. Using a fairly large sample buffer (65,536),Crimson targets an 80% utilization when streaming data. This substantial buffer serves to com-pensate for variations of τos,Tx and τnet,Tx to avoid underflow or overflow conditions.

As a result, using the default stock product, the transmit buffer latency may be modelled as;

τbuf,Tx = Ctgt,buf ·(Sfifo,smpl

fs

)(2.7)

Where Sfifo,smplis the size of the FIFO, in samples (by default 65,536), fs is the user specifiedsample rate, and Ctgt,buf is the target buffer utilization co-efficient (ranging from 0 to 1, with adefault value of 0.8). For the default product, equation 2.7 may be simplified to approximately;


τbuf,Tx,default ≈52429

fs(2.8)

while the deframing delay remains approximately the same, as specified by Equation 2.6 on page 24.

Round Trip Latency

We can calculate the total round trip latency by adding the host PC processing time to equations 2.1on page 23 and 2.2 on page 23. This results in;

τlat,rtt = τlat,Rx + τapp,process + τlat,Tx (2.9)

Note that the application τapp,process can vary substantially. For example, GnuRadio companionflow graphs impose a fixed delay between Rx and Tx to ensure sufficient buffering, there exists afixed latency of about 0.2s when the program is instantiated. This latency is may be substantiallyreduced when using a C++ program.

Minimizing Latency

As the default product is not specifically optimized for latency (focusing instead on ensuring sat-isfactory operation of as wide a range of parameters as possible), operation at high sample raterequires a number of different considerations. One of the primary considerations when interfacingwith a host PC is reducing the variation in latency. The greatest non-deterministic contributors tolatency are τos and τnet. Moving to a realtime operating system (such as the realtime linux kernel),using the latest kernel drivers (to ensure optimal network card performance), and processor andcore affinity provide the most immediate benefit. In addition, purchasing a network card optimizedfor low latency applications provides additional benefit.

Lower latency applications may benefit from a modified stock image that uses a low latency IPcore, and reduces sample buffer size - please contact us directly for more information. In addition,interfacing with another FPGA or a realtime, synchronous system, allows for reductions in payloadsize, which can also provide substantial opportunities to reduce transmission latencies. In ultra-lowlatency applications, custom interface protocols using the SFP+ connectors can be implemented tofurther reduce the latency between the SDR and application.

Of course, for the lowest latency applications, you can consider embedding application logic on theFPGA; please contact us to discuss your specific requirements.

3

Installation and Configuration

Installation and configuration comprises of four parts: physically setting up the hardware, config-uring the host network interfaces, building and installing the Per Vices libUHD library on the hostcomputer, and installing GNURadio, as shown in Figure 3.1.

Connect Crimson

Configure Host

Compile Per Vices libUHD

Test

Figure 3.1: Overall installation and configuration proceedure.

Hardware Set Up

Hardware set up is reasonably straight forward. As shown in Figure 3.2, you must connect theports in the correct order, with the following proceedure.

1. Ensure the Micro SD card is fully inserted inside the Micro SD card reader.

2. Plug in the power cable at the rear of Crimson TNG.

3. Connect ethernet cable from host computer to Management port on front of Crimson TNG.

4. Connect 10G SFP+ cables from 10GBASE-R network card installed in host computer toSFP+ ports on front of Crimson TNG.

5. Turn on the unit and wait for the LEDs on the front of Crimson TNG to light up.

27

3. INSTALLATION AND CONFIGURATION 28

Connect Power Plug

Attach Antennae (or sources/sinks) to Receive and/ or Transmit PortsReceive port can be connected to an antenna or external source (ie a signal generator)

Transmit port can be connected to an antenna or external sink

Connect RJ-45 Ethernet Cable from Management Port to Host

Connect 10G SFP+ Cable from SFP+A or SFP+B port to HostSFP+ A for Channels A and C | SFP+B for Channels B and D

Turn on CrimsonWait for Solid Green Light

Figure 3.2: Physical installation of Crimson hardware.

Crimson TNG Network Configuration

Crimson TNG boasts three network ports: there is a dedicated management port, and two dataports. Each port must be correctly configured to ensure proper operation, as indicated in Figure3.3.


Configure Host interfaces (Management, Data A, Data B)Host interfaces must be assigned IP addresses that share the same subnet with Crimson

Test ConfigurationOnce Host computer has been configured, type 192.168.10.2 into browser

If the Management Interface has been correctly configured, you should see the default Crimson Home screen.

OPTIONALCrimson IP address and host

name can be reconfigured

Configure SFP+ Interfaces

Ping Test Management IP

Ping Test SFP+ Ports

Figure 3.3: Overall network port configuration proceedure.

The Management port is used to configure the device, while the two SFP+ ports are used to senddata. To properly configure Crimson, each port must be properly configured, as shown in Table.

Each SFP+ data port is connected to a specific antenna port. The default configuration has dataon channels A and C sent over SFP+ A, and channels B and D sent over SFP+ B, as illustrated inFigure 3.4. The default network values are listed in Table 3.1. A recommended client networkingconfiguration is shown in Table 3.2.

Table 3.1: Default Crimson TNG Interface Addresses, Including UDP Destination Ports for SFP+Headers.

SFP+ Interfaces Management

SFP+ A SFP+ B MGMTCrimson TNG IP Address 10.10.10.2 10.10.11.2 192.168.10.2Radio Channels A C B D -Destination IP (Rx) 10.10.10.10 10.10.11.10 -Rx UDP Ports 42820, 42822 42821, 42823 -Source IP (Tx) any any -Tx UDP Ports 42824, 42826 42825, 42827 -


Table 3.2: Example Host Computer Network Configuration for Crimson TNG Default Settings

SFP+ Interfaces Management

SFP+ A SFP+ B MGMTHost IP Address 10.10.10.10/24 10.10.11.10/24 192.168.10.3/24Net Mask 255.255.255.0 255.255.255.0 255.255.255.0Broadcast 10.10.10.255 10.10.11.255 192.168.10.255MTU 9000 9000 1500

Management PortRJ-45, 100BASE-TIP: 192.168.10.4Netmask: 255.255.255.0Broadcast: 192.168.10.255

Data Port ASFP+, 10GBASE-RIP: 10.10.10.10Netmask: 255.255.255.0Broadcast: 10.10.10.255

Data Port BSFP+, 10GBASE-RIP: 10.10.11.10Netmask: 255.255.255.0Broadcast: 10.10.11.255

MGMTManagement PortRJ-45, 100BASE-TDefault IP: 192.168.10.2

SFP+ AData Port ASFP+, 10GBASE-RDefault IP: 10.10.10.2

SFP+ BData Port BSFP+, 10GBASE-RDefault IP: 10.10.11.2

RxADefault Send To: IP: 10.10.10.10 Port: 42820

RxCDefault Send To: IP: 10.10.10.10 Port: 42822

RxBDefault Send To: IP: 10.10.11.10 Port: 42821

RxDDefault Send To: IP: 10.10.11.10 Port: 42823

TxADefault Listen On: IP: Data Port A Port: 42824

TxCDefault Listen On: IP: Data Port A Port: 42826

TxBDefault Listen On: IP: Data Port B Port: 42825

TxDDefault Listen On: IP: Data Port B Port: 42827

Website: IP: Management IP Port: 80

SSH: IP: Management IP Port: 22Host Computer

Crimson TNG SDR

Figure 3.4: Default networking set up for Crimson TNG. The destination IP addresses for receiveports may be modified using the web GUI. The default configuration sees information from Rx Asent to the destination IP address of 10.10.10.10.


Network Set Up: Host PC Management IP Address

The Management port allows you to configure Crimson TNG through the web user interface. Inorder to access the web UI, you will need to configure your host IP address to share the same subnet (setting your machine to an IP of 192.168.10.4, and net mask of 255.255.255.0 should work), andthen type the IP address into the browser; 192.168.10.2. This will bring up the default connectionscreen for Crimson TNG, as shown in Figure 3.5.1,2

Figure 3.5: Home page of Crimson TNG Web UI, accessible through connection to the manage-ment port.

Linux (Arch/ Debian/ Ubuntu/ Kubuntu)

Assign a static IP address in the console:

$ ip addr add XXX.XXX.XXX.XXX/YY broadcast ZZZ.ZZZ.ZZZ.ZZZ dev <interface>

For example:

$ ip addr add 192.168.10.3/24 broadcast 192.168.10.255 dev eth0

To confirm that the network interface is enabled, type «ip addr show». The following output is anexample of what should appear indicating the link is up:

$ ip addr show1: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP groupdefault qlen 1000 link/ether NN:NN:NN:NN:NN:NN brd ff:ff:ff:ff:ff:ff

Now that you know the network interface is up, you can confirm that you have properly configuredthe Management IP address by pinging the MGMT port on Crimson TNG:

$ ping 192.168.10.2PING 192.168.10.2 (192.168.10.2)56(84) bytes of data64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=0.997 ms64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=1.04 ms...

1You can reconfigure the IP address and host name by clicking on the «Debug» tab of the home page.2You can also SSH into Crimson TNG with user name root. By default, there is no password set up.


Windows (generic)

The following describes the generic method of changing your IP address using a Windows machine.

1. Open Control Panel

2. View Network Connections

3. Right click on Local Area Connection and click on Properties

4. Under the Networking tab select Internet Protocol Version 4 (TCP/IPv4) and click on Prop-erties

5. Select «Use the following IP address»

6. Populate the IP address and subnet mask as described above

7. Click OK

To confirm that you have successfully configured the Management port, type 192.168.10.2 into yourweb browser. If you have successfully configured the IP, you will be taken to the Crimson TNGweb UI shown in Figure 3.5.

Network Set Up: Host PC SFP+ IP Addresses

Assuming that the 10GBASE-R network card has already been installed into your host computer,the following instructions will guide you in properly configuring the SFP+ ports. From here, wewill assume that the SFP+ port A is named XXXNXY. The IP address for this port will need tobe configured to 10.10.10.10.

Linux (Arch/ Debian/ Ubuntu/ Kubuntu)

Assign a static IP address in the console:

$ ip addr add XXX.XXX.XXX.XXX/YY broadcast ZZZ.ZZZ.ZZZ.ZZZ dev <interface>

For example:

$ ip addr add 10.10.10.10/24 broadcast 255.255.255.0 dev XXXNXY

Next, set the MTU:

$ ip link set dev XXXNXY mtu 9000

Type «ip addr show» into the console and the following output should appear to indicate that thelink is up:

5: XXXNXY: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP groupdefault qlen 1000 link/ether 6c:b3:11:3b:44:3d brd ff:ff:ff:ff:ff:ff


Ping the Crimson TNG SFP+ port A address 10.10.10.2 to ensure proper operation:

$ ping 10.10.10.2PING 10.10.10.2 (10.10.10.2) from 10.10.10.10 XXXNXY: 56(84) bytes of data.64 bytes from 10.10.10.2: icmp_seq=1 ttl=5 time=0.922 ms64 bytes from 10.10.10.2: icmp_seq=2 ttl=5 time=1.03 ms...

To configure SFP+ port B, repeat the instructions for SFP+ port A using the SFP+ port B IPaddresses shown in Table 3.2 on page 30. Remember to configure the correct device interface onyour host computer.

Windows (generic)

Please refer to the previous Windows (generic) IP address configuration section.

Build Per Vices libUHD Driver and Install GNU Radio

At run-time, GNU Radio compares the version of the UHD library used during compilation withthe presently installed version. If there is a difference, it generates an error message. This is mostoften caused when using a distribution provided version of GNU Radio that has been compiledwith the Ettus libUHD version. Ensuring that you have correctly installed the Per Vices libUHDversion, and then recompiling GNU Radio ensures consistency in the library versions and fixes anyerrors. Figure ?? summarizes the required steps to correctly install the UHD drivers.

Download Per Vices UHD sources

Confirm repository is complete and contains all dependencies.

Install Per Vices libUHD sources

Figure 3.6: Overall network port configuration proceedure.

If you already have GNU Radio installed on your host computer, you need to first uninstall it (alsouninstall the Ettus libUHD library, if applicable). Next, ensure the Per Vices libUHD version iscorrectly installed and reboot the computer. Finally, compile and install GNU Radio from source.3

Download the Per Vices UHD Sources

You can easily download the Per Vices UHD sources from github using the command line:

$ git clone https://github.com/pervices/uhd.git

3While the required procedure isn’t complicated, it definitely assumes familiarity with the Linux environmentand build flow. If you run into difficulty, please contact [email protected].


Download the Dependencies

Once you have downloaded the Per Vices UHD repository, you may want to confirm that you haveall the dependencies required. Detailed instructions, including the dependencies, are available at:http://files.ettus.com/manual/page_build_guide.html

Note: In order to use Crimson TNG with UHD, you must download the Per Vices UHD versionas it contains all the required modifications needed to support the Per Vices drivers.

http://files.ettus.com/manual/page_build_guide.html


Quick Install Instructions

We recommend that you carefully read the UHD build instructions. However, if you are confidentthat you have all the dependencies, you should be able to successfully install UHD with the followingcommand lines:1) Download the dependencies:

$ git clone https://github.com/pervices/uhd.git

2) Enter the host directory:

$ cd <uhd-repository-directory>/host$ mkdir build$ cd build

3) Run cmake with the appropriate compile flags:

$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr/ \-DPYTHON_EXECUTABLE=/usr/bin/python2 \-DENABLE_EXAMPLES=OFF \-DENABLE_UTILS=ON \-DENABLE_TESTS=OFF \-DENABLE_E100=OFF$ make -j4$ make install

Install GNURadio

Once you have installed Per Vices libUHD, you must obtain a version of GNU Radio. If you arenot familiar with git, make, and various build flow, we suggest you use the latest release:http://gnuradio.org/releases/gnuradio/gnuradio-3.7.10.1.tar.gz.4

If you are comfortable with git, use these commands:

Clone the repo:

$ git clone git://github.com/gnuradio/gnuradio.git

Enter the gnuradio directory:

$ cd gnuradio

Initialize and update the VOLK submodule:

$ git submodule init$ git pull --recurse-submodules=on origin v3.7.10$ git submodule update

After obtaining the sources, you can extract them and enter the relevant source directory, andfollow from section 3 (Start the Build Process) of the guide:http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide.

4NOTE: You should either clone the repo or use the release tarball. It is not necessary to do both.

http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide

http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide


Network Set Up: Modifying Crimson Management IP Address

ATTENTIONREAD THIS SECTION CAREFULLY

Read section very carefully prior to changing device IP address.Failure to follow instructions may render your device unreachable,

and may require you to manually edit the SD card filesystemor make a new SD card.

This procedure is broken down into three distinct sections: Adding the new IP address, removingthe old one, and then making the modifications persistent. This is a bad section in which to tryand take short-cuts: if you make a mistake, you’ll need to either mount the SD card filesystem onanother computer to try and fix your changes, or else use a new SD card.

Testing the Management IP address

Prior to, and immediately after, making any changes to the IP address, you should test to ensurethat communication to the device, and management port, is working properly. The best way todo this is to run a test sequence that attempts to ping the management port, is able to accessthe website on the management IP address, is able to successfully execute uhd_find_devices, anduhd_usrp_probe, and then tests the entire chain by running a simple GNUradio script.

The following tests are all completed from the host computer. This also serves to ensure thatyour host computer is correctly configured to access the device - just because you have correctlyconfigured Crimson, does not mean that you have correctly configured the host PC to communicatewith Crimson.

Ping test

This is the most basic test and serves to check if a route exists between your host computer andthe specified IP address. Assuming the management IP address is W.X.Y.Z, then you can run thistest by typing;

[host_pc]$ ping W.X.Y.Z -c 3

The output from a sucessful test is shown in Figure 3.7, and the output from a failed test is shownin Figure 3.8 on the following page.

PING W.X.Y.Z (W.X.Y.Z) 56(84) bytes of data.64 bytes from W.X.Y.Z: icmp_seq=1 ttl=64 time=0.912 ms64 bytes from W.X.Y.Z: icmp_seq=2 ttl=64 time=0.917 ms64 bytes from W.X.Y.Z: icmp_seq=3 ttl=64 time=0.917 ms--- W.X.Y.Z ping statistics ---3 packets transmitted, 3 received, 0% packet loss, time 2.746msrtt min/avg/max/mdev = 0.912/0.915/0.917/0.019 ms

Figure 3.7: Expected output from a successful ping test.


PING W.X.Y.Z (W.X.Y.Z) 56(84) bytes of data.From A.B.C.D icmp_seq=1 Destination Host UnreachableFrom A.B.C.D icmp_seq=2 Destination Host UnreachableFrom A.B.C.D icmp_seq=3 Destination Host Unreachable--- W.X.Y.Z ping statistics ---3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2013ms

Figure 3.8: Expected output from a failed ping test. In this figure, A.B.C.D is the IP address ofthe HOST PC interface used to send the request, and W.X.Y.Z, is the management IP addressbeing tested. This result indicated that you are unable to reach the specified IP address. Checkto ensure you are using the correct IP address on the host machine, that this IP address sharesa netmask with the target Crimson machine, and that you have correctly configured your hostmachine interface prior to continuing.

Website test

The following test is used to determine whether you can access the website. This is helpful inensuring that the IP address you are attempting to reach is, in fact, a Crimson device. To run thistest, simply open a browser, and attempt to access the website by typing in the management IPaddress.

If you are able to successfuly access the website, then you have connected with a Crimson device.

If you are unable to access the website, then double check to ensure that you have correctly specifiedthe management IP address, or that your netmask is correctly assigned.

uhd_find_devices, uhd_usrp_probe tests

This is the first test to determine whether UHD is capable of finding the Crimson device. It’sworth running this test twice; the first time by specifying the management IP address, and thesecond time without. In a correct configuration, with a single Crimson device, you should be ableto automatically find the device without specifying the address.

To run this test, and assuming the management IP address is W.X.Y.Z, type the following;

[host_pc]$ uhd_find_devices --args ’addr=W.X.Y.Z’

The output from a sucessful test is shown in Figure 3.9, and the output from a failed test is shownin Figure 3.10 on the following page. A failed output from from a uhd_usrp_probe is shown inFigure 3.11 on the next page.

linux; GNU C++ version 6.3.1 20170306; Boost_106300; UHD_003.008.000-382-gef596087---------------------------------------------------- UHD Device 0--------------------------------------------------Device Address:type: crimson_tngaddr: W.X.Y.Zname:serial: 001

Figure 3.9: Expected output from a successful uhd_find_devices test.


linux; GNU C++ version 6.3.1 20170306; Boost_106300; UHD_003.008.000-382-gef596087No UHD Devices Found

Figure 3.10: Expected output from a failed uhd_find_devices ping test: no UHD device was found,indicating that the network configuration does not work.

linux; GNU C++ version 6.3.1 20170306; Boost_106300; UHD_003.008.000-382-gef596087Error: LookupError: KeyError: No devices found for ----->Device Address:addr: 192.168.10.2

Figure 3.11: Expected output from a failed uhd_usrp_probe test. No UHD device was found atthe specified address, indicating that the network configuration does not work.

Add New Management IP address

Make sure that you’ve already configured the host IP address, following the instructions above.This will ensure that once you update Crimson, you’ll be able to communicate with it.

To temporarily add a new IP address, SSH into crimson, and then add the new IP address usingthe IP tool;

[dev0@crimson]$ sudo ip addr add Y.Y.Y.Y/ZZ dev eth0

Then, log out of crimson, and, without powering down the unit, test to confirm that the new IPaddress works, and that your host can communciate. The best test series is to first attempt to pingthe new management port, then to run uhd_find_devices, and uhd_usrp_probe, and then to runa simple GNUradio script that is known to work - making

It si You will very Note that you will likely have to specify the If you are able to get all of thoseprograms to work - and you will neespecifying the

Removing Management IP address

To remove the default management IP address, first ADD the new one using the proceedure above.Then, log out of crimson, and SSH back in, using the NEW ip address. This will prevent yoursession from being terminated once you delete the old address.

To delete the old address on Crimson, we can again use the IP address tool;

[dev0@crimson]$ sudo ip addr del W.W.W.W/XX dev eth0

Again, log out of the machine, and ensure that you can ping the device, that the website is reachable,and that you can use uhd_usrp_probe and uhd_find_devices.

If you are unable to reach the website, or run any scripts, then STOP here and FIX the problem.At this point, your Crimson device is effectively configured with the new address, but the changeis not persistent. This means that if you have to debug problems, do so now.


Persistently Update Management IP address

CAREFULLY TEST CHANGES TO NETWORK PARAMETERS,AND ENSURE FUNCTIONALITY, PRIOR TO MAKING THESE

CHANGES PERSISTENT ACROSS REBOOTS

Carefully test network settings, using the previously described proceedures totemporarily set and remove IP address, prior to making those changes persistent.If you are not able to get the configuration working temporarily, then persistentlyapplying these settings across reboots, will prevent communication with Crimson.

To ensure that the new IP address is persistent across reboots, SSH into Crimson, and modify thefile located at: /etc/network/interfaces

Make sure that you have tested ALL configuration settings PRIOR to writing them to this file. Ifyou weren’t able to get your configuration working temporarily, using the previous two instructions,than making them persistent accross reboots SHALL NOT work. Making a broken configurationpersistent will only serve to rebooting the device to undo your changes and fix any earlier mistakes.Once you write to this file, the changes will be applied on the next reboot.

LED Sequence

When Crimson TNG is powered on, the four status LEDs next to the SD card will begin to lightup. A normal LED sequence is shown in Figure 3.12.

(a) (b) (c) (d) (e) (f)

Figure 3.12: Crimson TNG Status LEDs Normal Boot Sequence

Each step of the LED boot sequence is detailed below:

(a) Device is powered on

(b) FPGA is operating with a stable clock

(c) FPGA is up and linux is booting

(d) HPS is up and linux has booted

(e) Server is booting up

(f) Server has booted up

4

Use and Operation

This device is designed to be used and configured over a dedicated management port. The devicemay be configured using the UHD drivers, and also provides a web interface. You may also directlyconfigure the device over SSH.

UHD

The device can be configured using the Per Vices UHD drivers. This allows for easy interface withsoftware devices, and provides some compatability with USRP devices.

Web UI

You can access the web interface by typing the IP address of the device into your browser. Thisdirects you to a SCADA-like interface where you can easily visualize and configure the radio chainand DSP carried out on the device.

SSH and Command Line

You can also access and configure the device over SSH using command line parameters. This isprimarly done using two programs: «uart-app» and «mem». The uart-app programs allow you tosend commands over the UART bus to radio peripherals (like ADCs, DACs, or Amplifiers), andthe mem application allows you to read and write to the memory space shared between the HPSand the FPGA.

40

5

Crimson TNG Device Data Format

Crimson TNG uses complex, signed, 32-bit integers to communicate data over the SFP+ ports.

Data Format

Data are transmitted in IQ pairs. Each IQ pair is 32 bits, with the I and Q components representedby two 16 bit signed integers. The specific format is represented in Table 5.1. To read this datainside GNU radio, you can use a flow chart similar to that shown in Figure 5.1.

Table 5.1: Data structure

Bit Position 31:24 23:16 15:8 7:0Representation Re[7:0] Re[15:8] Im[7:0] Im[15:8]

Figure 5.1: Sample gnuradio data sink, visualizing waterfall data.

41

6

Troubleshooting

Table ?? on the following page shows some of the common problems you may encounter when firstconfiguring Crimson TNG. If you continue to experience problems, please contact us for support.

42

6. TROUBLESHOOTING 43

Problem Possible Cause SolutionUnable to connect No Micro SD card 1. Turn off Crimson TNG unitto Crimson TNG 2. Insert Micro SD cardManagement Web 3. Turn on unit, wait until unit boots upUI 4. Type 192.168.10.2 into web browser

Micro SD card is 1. Turn off Crimson TNG,not inserted 2. Remove Micro SD cardproperly 3. Re-insert card ensuring it has been properly connected

4. Turn on unit, wait until it boots up5. Type 192.168.10.2 into web browser

Ethernet cable isnot connected

Ensure ethernet cable is properly seated in both hostcomputer and Crimson TNG MGMT port

Management IP Confirm you have enabled the network interface:address is not $ ip addr show output should say:configured properly <BROADCAST, MULTICAST, UP, LOWER_UP>

Confirm you have configured the correct network interface.If the Crimson TNG MGMT port does not respondto ping, try configuring a different network interface withthe settings listed in Table 3.2 on page 30.

Unable to send/receive data

SFP+ cables areswapped

Try swapping SFP+ cables, or reconfiguring SFP+ IPaddresses with swapped device addresses

SFP+ cables arenot connected

Ensure SFP+ cables are properly seated in both hostcomputer and Crimson TNG SFP+ ports

SFP+ IP(s) are Confirm you have enabled the network interface:not configured ip addr show output should say:properly <BROADCAST, MULTICAST, UP, LOWER_UP>

Confirm you have configured the correct networkinterfaces. If the Crimson TNG SFP+ port(s) do notrespondto ping, try configuring a different network interface withthe settings listed in Table 3.2 on page 30.

GNURadio error Version mismatch 1) Uninstall all versions of GNURadio and Ettus libUHDmessages between 2) Reboot computer

GNURadio and 3) Download and install Per Vices libUHDPer Vices libUHD 4) Compile and install GNURadio from source

Dropped packets MTU size not set Set SFP+ IP addresses MTU size to 9000

uhd_find_devicesdoes not working

NetworkConnection orFirewall errors

Confirm your network connection is properly configured,and that you do not have any security policy or firewallblocking broadcast packets.

7

Updating Crimson TNG

This chapter discusses the procedure required to update the Crimson TNG transceiver firmware.Broadly speaking, Crimson TNG has two primary firmware sources: the FPGA firmware (con-taining the Linux file system and FPGA firmware), and the MCU firmware (the Atmel processorcode used to control and configure the radio and time boards)1 This chapter explains the procedureto update the MCU firmware, and configure the FPGA firmware to program the MCU.

MCU Firmware

The MCU code is responsible for controlling the various components on each radio board. Whena command is issued from the digital board, the MCU interprets the command and configures oradjusts the various components on the board to the desired mode of operation.

The capability exists to update this code through the existing UART interface; the optimal updatemethod takes advantage of the exposed SATA headers to directly update the Atmel Controller.The following provides the recommended procedure to update the MCU firmware.

Automatic MCU Update Pre-requisites

In order to automatically update from Crimson TNG, you require;

1. Firmware binaries (eg; rx.hex, tx.hex)

The actual MCU firmware and binaries are available from Per Vices. If you are updatingfrom the MCU, you only require the application binaries (rx.hex, tx.hex, synth.hex). Pleasecontact us for more information.

2. A client terminal with SSH and SCP installed.

Automatic MCU Update Procedure

1. Copy the firmware binaries over to Crimson TNG, and place them within the /home/root/pv_mcudirectory. If you are using the default configuration and wish to update all the MCUs, youcan use the following scp invocation:

cd <firmware_directory>

scp rx,tx,synth.hex [email protected]:/home/root/pv_mcu2

1More information on the architecture behind Crimson TNG may be found 2 on page 15.2If you have changed the default management IP address, then you will have to use that address.

44

7. UPDATING CRIMSON TNG 45

2. Once you have copied the MCU binaries, you must program them. This is done from withinCrimson TNG. Accordingly, you need to SSH into the machine, then run the MCU updateroutine located in the /home/root/pv_mcu directory:

ssh [email protected]

# cd /home/root/pv_mcu

# ./flash.sh all3

3. Once you have completed this process, restart Crimson TNG.

Manual MCU Update Pre-requisites

You require the following programs and items prior to updating the MCU firmware:

1. avrdude

avrdude is a program that allows you to program Atmel MCUs. It is generally available inthe package repositories of most Linux distributions.4We presently use version 6.1.

2. Firmware binaries (eg; rx.hex, rx-boot.hex)

The actual MCU firmware and binaries are available from Per Vices. Please contact us formore information. In order to fully program each board, you may require up to two binariesfiles per board. One is used to program the board boot-loader (identified by the -boot suffix),the other is an application binary (eg., «rx.hex, tx.hex, or synth.hex).

3. AVR-ISP-MK2 programmer

A programmer is required to interface to the header ports on the power board, and thecomputer with the firmware. We use the AVR-ISP-MK2 from Olimex5, though any compatibleprogrammer should work.

Manual MCU Firmware Update Procedure

1. Unplug the Crimson TNG chassis, and remove the cover.

• Locate the relevant board firmware header.

1. Mate the programming dongle with the appropriate board programming port.

2. Program the application firmware, taking care to ensure you program the correct board withthe correct firmware.

Your specific programmer and port may vary, requiring you to modify the port (-P) andcontroller (-c) options.

We use an avrispmkII compatible programmer over a usb connection, and want to programthe rx.hex application firmware to the receive (Rx) board. We can use the following avrdudesyntax:6

avrdude -P usb -c avrispmkII -p x256a3u -B 8 \-U application:w:rx.hex

3You can update a specific board by specifying it; rx, tx, synth.4It is also available from: http://savannah.nongnu.org/projects/avrdude/5https://www.olimex.com/Products/AVR/Programmers/AVR-ISP-MK2/open-source-hardware6Remember to confirm that you are burning the correct application firmware file to the correct board!

http://savannah.nongnu.org/projects/avrdude/


Syntax notes:

We use a programmer controller (-c) that is avrispmkII compatible, uses aport (-P) usb connection, and sets a bit clock period in nanoseconds (-B) to 8. Thepart (-p) is an ATxmega256A3U, specified as x256a3u. We carry out a memoryoperation (-U) that writes the application binary rx.hex to memory.

3. (Optional) Program the board boot-loader.

Your specific programmer and port may vary, requiring you to modify the port (-P) andcontroller (-c) options.

We use an avrispmkII compatible programmer over a usb connection, and want to programthe rx-boot.hex boot loader to the receive (Rx) board. We can use the following avrdudesyntax:7

avrdude -P usb -c avrispmkII -B 8 -e \-p x256a3u -U boot:w:rx-boot.hex -U fuse2:w:0xBF:m

Syntax notes:

We use a programmer controller (-c) that is avrispmkII compatible, uses aport (-P) usb connection, and sets a bit clock period in nanoseconds (-B) to 8, afterfirst performing a chip erase (-e). The part (-p) is an ATxmega256A3U, specified asx256a3u. We carry out a memory operation (-U) that writes the xboot-boot.hexfile to the boot loader, and subsequently carries out another memory operation (-U)to set the fuses to (fuse2:w:0xBF:m).

4. Congratulations! You have successfully updated the Crimson TNG MCU firmware.

7Remember to confirm that you are burning the correct boot loader firmware file to the correct board!


Figure 7.1: A sample Atmel Programmer.

FPGA Firmware

The FPGA firmware used by Crimson TNG is stored on the provided Crimson TNG SD cardand is loaded onto the FPGA during boot. This procedure describes how to replace or update theFPGA code stored on the SD card.

It is also possible to update the FPGA firmware using the command line, or directly over JTAGusing a USB Blaster.8

FPGA Update Pre-requisites

You require the following items prior to updating the FPGA firmware stored on the FPGA firmware:

1. FPGA Binaries (soc_system.rbf)

This contains the FPGA firmware as a raw binary file (rbf) named soc_system.rbf. If you arecompiling from source, or from within Quartus 2, you will have to convert the default outputfile (with an .sof extension - SRAM object file) to an appropriate RBF file. To do this, youmust first compile the project. After compiling the project, open the Convert Programmermenu (File > Convert Programming Files) and use the settings shown in Figure 7.2 on thefollowing page.

2. Crimson TNG SD Card

8Updating firmware using the USB Blaster is not recommended if you are also using the SoC, as it may adverselyimpact SoC operation.


Figure 7.2: Quartus 2 IDE Convert Programming Files GUI. The settings illustrate the conversionof the default (.sof) file format to the desired raw binary file (.rbf), with a mode of Passive Parallelx16, and an output filename of soc_system.rbf.

The SD Card shipped with your Crimson TNG platform.

3. Mini SD Card Reader

All Crimson TNG transceivers ship with a USB card reader. Alternatively, you may useyour own.

4. A computer to copy over the SD Card.

In order to copy over the SD Card, you will need a computer to copy the updated or generatedFPGA firmware to the SD Card.

FPGA Update Procedure

1. If you are generating from your own Quartus Project, ensure that you have converted thenewly generated source code to a Raw Binary File (see Figure 7.2).

2. Confirm the file name is:

soc_system.rbf

3. Power down Crimson TNG, and remove the mini SD Card.

4. Insert the SD Card into the provided USB mini-SD Card reader, and insert the assembly intoa computer.

5. Identify the partition containing the existing soc_system.rbf file.

The SD Card contains three partitions. Depending on your operating system, the number ofviewable partitions may vary. Using a reasonable operating system, you should be able toview three partitions. For example:


sdX1 - partition 1- type b - W95 FAT32 partition (This contains the RBF file!)

sdX2 - partition 2 - type 83 - Linux ext3 partition (Contains SoC file system)

sdX2 - partition 3 - type a3 - UBOOT and boot loader (It’s best not to touch this)

6. Once you identify the correct partition, replace the existing RBF file with the new one, andcleanly unmount the partition.9

7. Remove the USB mini-SD Card adapter from your computer and pull out the mini-SD Card.Insert the bare SD card back into the Crimson TNG mini-SD Card receptacle.

8. Congratulations! You should have successfully updated the Crimson TNG FPGA code.

9You must ensure you cleanly unmount the partition. You risk corrupting the firmware image (and possibly evenCrimson TNG) if you simply remove the USB key without first unmounting (safely removing) the USB key! Foradded security, type «sync» to flush filesystem buffers prior to removing the SDCard.


Figure 7.3: FPGA JTAG header location on digital board. You may use this jumper to attacha USB Blaster 2 device on to Crimson TNG, which enables you to use Signal Tap or carry outJTAG searches.

FPGA Signal Tap

So you’re swimming along, developing your own FPGA firmware when disaster strikes! There is aproblem in your code. Despite countless hours simulating your code, you have discovered a bug.Worse, you aren’t sure exactly where it might lie, though, you suspect that the problem mightcome from that new code that Laura (from accounting) introduced. Before escalating the issue (orpoisoning your relationship with your colleague), you want to debug the issue with Signal Tap. Thefollowing procedure indicates how to attach a USB Blaster to Crimson TNG.

FPGA Signal Tap Pre-requisites

You require the following items prior to updating the FPGA firmware stored on the FPGA firmware:

1. Altera USB Blaster (or clone) with serial input.

2. Crimson TNG Transceiver Platform

FPGA Signal Tap Attachment Procedure

1. Remove the cover from Crimson TNG.

2. Locate the Signal Tap header on the digital board (see Figure 7.3).

Default boards may not include a Signal Tap header, in which case you will need to solder ona dual row 10 position header.

3. Attach the Signal Tap header to the Jumpers.

4. Congratulations! You have successfully attached a USB Blaster to Crimson TNG.

8

Crimson TNG Mechanical

51

8. CRIMSON TNG MECHANICAL 52

CR IMSON TNG

SD PWR USB

MGMT

A

B

IO PPS TRIG

SFP+A

SFP+B

RX D

TX D

RX A

TX A

RX B

TX B

RX C

TX C

OSC PLL SYS DEV REF REF

OUT INPer Vices Corporat ion

Figure 8.1: Crimson TNG Mechanical

Crimson TNG User Guide - pervices.com

Documents