Signalogic SigC667x, SigC641x User Manual

Download

Page 1

SigC667x / SigC641x

User Guide

Includes Installation and Test for:

•

• SigC6xxx Hardware 1

••

•

• DirectCore® Software

••

•

• CIM® Software 2

••

Revision B8

January 2015

Signalogic, Inc.

9617 Wendell @ Skillman

Dallas, TX 75243

Tel: 214-349-5551

Fax: 214-343-0163

http://www.signalogic.com

tech_support@signalogic.com

Includes SigC667x 32-core and 64-core PCIe cards, and SigC641x PCI/PCIe

cards and PTMC modules

Includes Texas Instruments code gen tools installation

Page 2

1/27/15 SigC667x / SigC641x User Guide, Rev B7

TABLE OF CONTENTS

1 SigC667x Hardware Installation 5

1.1 SigC667x Card Overview ............................................................................................... 5

1.2 Installing SigC667x Cards .............................................................................................. 6

1.3 SigC667x Card and Firmware Revisions ........................................................................ 9

2 SigC641x Hardware Installation 11

2.1 SigC641x Module Overview ........................................................................................ 11

2.2 Installing SigC641x Modules ....................................................................................... 12

2.3 SigC641x Loopback Connections................................................................................. 14

2.4 SigC641x Module and Logic Revisions ....................................................................... 15

2.5 SigC641x Processor and SDRAM Clock Rates............................................................ 16

3 Server Installations 17

3.1 HP DL380p Proliant Series ........................................................................................... 17

3.2 Supermicro 1U .............................................................................................................. 18

3.3 Desktop and Other PC Enclosures ................................................................................ 20

3.4 External Power Cables .................................................................................................. 20

4 Software Installation 23

4.1 Building the Loadable Kernel Module (LKM) Driver ................................................. 27

4.1.1 Linux Kernel-Devel Installation Requirement ...................................................... 29

4.2 Building DirectCore Libraries ...................................................................................... 31

4.3 Test Programs ............................................................................................................... 34

4.3.1 memTest ................................................................................................................ 35

4.3.2 boardTest............................................................................................................... 42

4.3.3 fftTest .................................................................................................................... 45

4.3.4 videoTest ............................................................................................................... 48

4.3.5 appTest .................................................................................................................. 51

4.3.5.1 appTest Output Description 52

4.3.5.2 RTP Audio Test Program 54

4.3.5.2.1 Installing and Running RTP Audio 54

4.3.5.3 Call and Voice Processing Test Procedures 56

4.3.5.4 Interactive Command Summary 59

4.3.5.5 Basic Call, Media, and DTMF Test Procedures 61

4.4 Texas Instruments Tools Installation ............................................................................ 82

4.4.1 TI Code Generation Tools Download ................................................................... 82

4.4.2 TI BIOS-MCSDK Download ............................................................................... 84

4.4.3 TI SYSBIOS, IPC, and XDCtools Download ...................................................... 86

4.5 RTAF Software Usage .................................................................................................. 87

4.5.1 RTAF Configuration Options ............................................................................... 87

2 / 109

Page 3

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.5.2 RTAF Peripheral Support ..................................................................................... 88

4.5.3 RTAF Development and Host Platform Notes ..................................................... 88

4.5.3.1 Linux Platform Builds 90

4.6 CIM Software Installation............................................................................................. 92

4.6.1 Running User Programs with CIM ....................................................................... 92

4.6.2 h264_encode demo ............................................................................................... 93

5 pn4Test Host Program 98

6 pn4Test Theory of Operation 104

6.1 MCBSP Test Mode ..................................................................................................... 107

6.2 UART Test Mode ....................................................................................................... 107

6.3 GPIO Test Mode ......................................................................................................... 108

6.4 Host Operation ............................................................................................................ 109

3 / 109

Page 4

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Revision History

Created Rev A Jul 2012

Modified Rev B Nov 2012 – Jan 2013, merged SigC677x documentation

Modified Rev B2 Feb 2013, updated with software changes

Modified Rev B3 Feb 2013, added server installations, added initial CIM software sections, updated with hardware revision and software changes

Modified Rev B4 Mar 2013, added video encoding test sections

Modified Rev B5 Jun 2013, added RTAF software usage section, updated memTest

Modified Rev B6 Aug 2013, added apptest and call test procedures

Modified Rev B7 Nov 2014, added fftTest and videoTest DirectCore demo program sections, CIM software install and build details, and CIM h264_encode demo section

Modified Rev B8 Jan 2015, added 64-core card install instructions, added target software install and build instructions, additional driver build notes, additional library build notes

4 / 109

Page 5

1/27/15 SigC667x / SigC641x User Guide, Rev B7

1 SigC667x Hardware Installation

The sections below cover installation of specific SigC66x and SigC64x card types. Note that section 3, Server Installations, covers a few different types of popular servers and may have some additional hardware installation information that could prove useful, depending on your type of server.

1.1 SigC667x Card Overview

The SigC6678-32 and SigC6678-64 are 32-core and 64-core Gen2 and Gen3 PCIe cards, respectively. These cards combine CIM (Compute Intensive Multicore) cores with high bandwidth PCIe interface and large amounts of memory per core, both shared between cores and dedicated external core memory. From the top of the card, the CIM devices can be seen as shown in Figures 1-1a and 1-1b below.

embedded fan that cover most of the top surface of the card

Note that production cards have a heat sink and

Figure 1-1a, SigC6678-32 top view, without heat sink

Figure 1-1b, SigC6678-64 top view, without heat sink

5 / 109

Page 6

1/27/15 SigC667x / SigC641x User Guide, Rev B7

The SigC6678-32 card has one fan and the SigC6678-64 card has two fans. Including the heat sink and fan(s), the overall card thickness remains within the single-slot height limit given in the PCIe specification.

1.2 Installing SigC667x Cards

To install the SigC6678-32 and SigC6678-64 cards, they should be inserted in a x8 or larger Gen2 or Gen3 PCIe slot. An example of a SigC6678-32 card installed vertically in a x16 PCIe slot is shown in Figure 1-2 below.

Figure 1-2, SigC667x installed in x8 or larger PCIe slot

Cards may also be installed horizontally, depending on the riser configuration with the host server. Additional airflow from the server is typically not required due to the self-contained heat sink and fan. Maximum power consumption is about 54W for the 32-core card, and about 110W for the 64-core card.

CAUTION! Power should be fully removed from the motherboard prior to card installation. Be

sure that the card is correctly “justified” in the slot, the backplate on the card is not obstructed, the card is fully seated and flat relative to the PCIe connector, and that any part of the card that overhangs the PCIe connector is not touching components on the motherboard, for instance heat sinks or tall capacitors.

The SigC667x cards support two boot modes: emulation boot mode and I2C boot mode. Boot mode is selected by Switch 1 (labeled “SW1” on the card), as shown in Figure 1-3 below. I2C boot mode is the default setting and should be used for normal SigC667x card operation.

6 / 109

Page 7

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Emulation boot mode is reserved for low-level card testing and debug, and is sometimes known as “JTAG debug”.

Figure 1-3, SigC667x SW1 (boot mode)

CAUTION! It is a known issue that in some servers SigC667x cards with A101 revision

firmware may not complete their on-card I2C boot process before the server completes its internal BIOS scan of the PCIe device tree (which includes PCIe slots). There are four (4) PCIe LEDs on the SigC667x card that will flash to indicate valid PCIe initialization after boot. The placement of these LEDs is shown in Figures 1-4 and 1-5, as shown below.

7 / 109

Page 8

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 1-4, PCIe boot LEDs, top side

If after boot all PCIe LEDs are not flashing, then a system reset, either through software (for example ‘shutdown –r now’ Linux command) or front-panel switch, can be performed. This is not an issue on cards with A102 revision firmware.

Figure 1-5, PCIe boot LEDs, bottom side

8 / 109

Page 9

1/27/15 SigC667x / SigC641x User Guide, Rev B7

1.3 SigC667x Card and Firmware Revisions

For SigC6678-32, card and firmware revision is printed on the back side of the card, near the inner edge of the PCIe connector, as shown in Figure 1-6 below:

Figure 1-6, SigC6678-32 card and firmware revision information

For SigC6678-64 cards, card and firmware revision information is printed on the back side of the card, as shown in Figure 1-7 below:

Figure 1-7, SigC6678-64 card and firmware revision information

Card revision information is given in the Table 1-1 below:

9 / 109

Page 10

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Hardware Version Table Card Type, Revision

Silkscreen labeling on back of card SigC6678-32 SigC6678-64

9692868100E

A101 or

9692868100

9692868101E A102

9692868102E A103

19C2868200 A101

19C2868201-01 A102

Table 1-1, SigC667x card and firmware revision information

10 / 109

Page 11

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2 SigC641x Hardware Installation

2.1 SigC641x Module Overview

The SigC6415T PMC module has eight C6415T single-core devices and a PCI interface. From the top of the card, two C6415T devices can be seen as shown in Figure 2-1 below.

Figure 2-1, Top view of SigC6415T PMC module

From the bottom of the card, the remaining six C6415T devices, PCI interface logic (FPGA), PN4 interface logic (FPGA) and PMC interface connectors can be seen. The PN4 connector is at the upper right as shown in Figure 2-2.

Figure 2-2, Bottom view of SIGC6415T PMC module

11 / 109

Page 12

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2.2 Installing SigC641x Modules

In order to use a SigC641x PMC module, it must first be inserted onto a PMC-to-PCIe adapter card. The module has been tested with a Dynamic Engineering PMC to PCIe adapter (PCIeBPMCX1), shown in Figure 2-3, and an Integrative Innovation PMC to PCIe adapter, shown in Figure 2-4. Ensure that a complete connection is made on the PMC interface when inserting the module: press firmly but gently, and press at the edges of the module; i.e. not directly on components. After insertion, check carefully for any gaps around the edges of all four (4) PMC connectors. Also, make sure the module rests completely flat and in parallel with the adapter card, and the module’s front bezel fits correctly into the adapter’s end-plate cut-out.

Figure 2-3, SigC6415T module on Dynamic Engineering adapter

Figure 2-4, SigC6415T module on Integrative Innovation adapter

12 / 109

Page 13

1/27/15 SigC667x / SigC641x User Guide, Rev B7

After inserting the module into an adapter, the adapter card can now be placed in a PCIe slot (or PCI slot if a PMC to PCI adapter is used instead). Ensure that the card is inserted into the PCIe slot with the proper orientation. The bezel plate should be on the edge of the motherboard with the 4-wire internal power connector towards the interior. The card installed into a PCI express slot using a Dynamic Engineering adapter is shown in Figure 2-5. In the case of using a PCI-X adapter in a PCI slot, make sure that the extra PCI-X connector section does not hit anything on the motherboard. Make sure that the 4-wire internal power connector is inserted before turning on the system.

Figure 2-5, SigC6415T module on adapter board, inserted into PCIe slot

13 / 109

Page 14

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2.3 SigC641x Loopback Connections

In order for test software to operate correctly, loopback connections on the correct PN4 and backplate connector pins should be established (see Figures 6-1 and 6-2 for PN4-to-backplate connector mapping diagrams). In the case of the Dynamic Engineering adapter, wires can be inserted into the connector holes to connect the corresponding pins of the SCSI connector, shown in Figure 2-6. For the Integrative Innovation adapter, a connector with these loopback connections should be made to be attached to the alternate SCSI connector on this adapter, shown in Figure 2-7.

Figure 2-6, Dynamic Engineering adapter loopback wires,

inserted into P2 external I/O connector

Figure 2-7, Integrative Innovation adapter loopback connector,

mated with JP2 external I/O connector

14 / 109

Page 15

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2.4 SigC641x Module and Logic Revisions

The module revision number is printed on the silkscreen along the left edge (with the bezel plate towards you) of both sides of the module as shown in Figure 2-8. The logic revision number is affixed to the Xilinx boot PROM (U39) as shown in Figure 2-9.

Figure 2-8, SigC641x module revision number

Figure 2-9, SigC641x logic revision number

15 / 109

Page 16

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2.5 SigC641x Processor and SDRAM Clock Rates

The processor clock rate for the particular module used is affixed to the flash memory chip (marked U8 on the module silkscreen) which is located next to the module status LEDs (marked D1-D16 on the module silkscreen) and is shown in Figure 2-10 below. The clock rate can also be determined from the part markings on the C6415T processors (e.g. 7E3 for 720 MHz and 1GHZ for 1 GHz). The SDRAM clock rate is the processor clock rate divided by 6 which would be 120 MHz for 720 MHz processors and 166.67 MHz for 1 GHz processors.

Figure 2-10, SigC641x processor clock rate module labeling

16 / 109

Page 17

1/27/15 SigC667x / SigC641x User Guide, Rev B7

3 Server Installations

The Server Installations section contains information on specific types of servers. This information does not cover all servers, but some of the physical and configuration procedures and requirements documented here may also apply to other server enclosures.

3.1 HP DL380p Proliant Series

Figures 3-1a and 3-1b below show a SigC6678-64 card installed in an HP DL380p Gen8 server. Note the power cable required to connect the card to the 12V connector on the riser.

12V

Power

Cable

Figure 3-1a, SigC6678-64 card installed in DL380p server, side angle view

Figure 3-1b, SigC6678-64 card installed in DL380p server, top view

17 / 109

Page 18

1/27/15 SigC667x / SigC641x User Guide, Rev B7

The additional power cable is required when the card has a PEG (PCI Express Graphics) type of connector, which has become a de facto industry standard due to the proliferation of PCIe GPU boards. SigC6678-32 cards do not have a PEG connector as their power consumption is limited to about 50W. The HP part number of the power cable down in Figure 3-1 is:

P/N 504660-003

This HP cable is also shown in Figure 3-5 below (in the picture, the HP cable is on the left, with a bar code tag).

3.2 Supermicro 1U

Figure 3-2 below shows a four (4) SigC6678-32 cards installed in a Supermicro 1U server. In this case, an unusual narrow motherboard and “dual slot riser” configuration makes it possible to insert PCIe cards on both sides of the server. Note that for SigC6678-32 cards, no additional power cables are used.

Figure 3-2, Four (4) SigC6678-32 cards installed in a Supermicro 1U server, top angle view

Figure 3-3 below shows a SigC6678-64 card installed in a 1U server. The card length is about

12.2", which requires a full-length PCIe slot. In this example, the riser card (see annotation in

18 / 109

Page 19

1/27/15 SigC667x / SigC641x User Guide, Rev B7

the picture) has two (2) PCIe slots, which would allow two (2) SigC6678-64 cards to be installed.

Figure 3-3, SigC6678-64 card installed in a 1U server, top view, with 6-pin external power

Note that it's also possible to “mix and match” cards, for example one SigC6678-32 card and one SigC6678-64 card installed on the same riser, or otherwise installed in different PCIe slots in the same server.

connection highlighted (red square)

19 / 109

Page 20

1/27/15 SigC667x / SigC641x User Guide, Rev B7

3.3 Desktop and Other PC Enclosures

Installation for non-server PC enclosures, for example desktop, tower and shuttle cases, is very similar to server installation, with the exception of external power cables for SigC6678-64 cards. Note that for SigC6678-32 cards, no additional power cables are used. See the following sections for more information on external power connection.

3.4 External Power Cables

Figures 3-4 and 3-5 below show different external power cables that can be used with SigC667864 cards, for example in "tower" or other traditional PC box enclosures. Note that for SigC667832 cards, no additional power cables are used.

Figure 3-4, External power cable for SigC6678-64 cards that connects to standard 4-pin

peripheral power cables inside a desktop or other non-server form-factor PC enclosure

Figure 3-4 above shows an external power cable that mates with standard 4-pin power cables found inside a desktop or other PC enclosure that provide power to peripherals, such as hard disk

20 / 109

Page 21

1/27/15 SigC667x / SigC641x User Guide, Rev B7

drives, DVD players, etc. For the SigC6678-64 card, a minimum of two connectors should be mated, but it's preferable if all 3 connectors are mated (see notes below).

Figure 3-5 below shows external power cables that mate with a server internal riser card.

Note that typically yellow wires are +12V and black wires are Gnd.

Figure 3-5, External power cable for SigC6678-64 cards that connects to an internal riser card

If for any reason you are unsure about which connector to use, and you want to absolutely verify voltages prior to card installation, a simple test step is to attach the power cable to the server or

21 / 109

Page 22

1/27/15 SigC667x / SigC641x User Guide, Rev B7

(or other PC enclosure) internal connector, without the SigC6678-4 card installed and with the top panel or lid open on the enclosure, boot the machine, and use a voltmeter (set to DC volts) to measure the pins. Measured voltages for the external power cable should match up to the pin assignment shown in Figure 3-6 below:

Figure 3-6, 6-pin external power cable pin assignment

Figure 3-6 above shows voltage pin assignment for the 6-pin end of cables shown in above figures and pictures. Notes about Figure 3-6:

• View is facing the connector, i.e. as if you're "standing" on the card, looking at the end of

the cable

• COM means Common, or Gnd

• Some cables may "break out" the 6 wires, for example Figure 3-4 above shows the 6

wires distributed among 3 peripheral power connectors, in 2-wire pairs (one +12V wire and one Gnd wire for each pair). For the SigC6678-64 card, at least 4 wires (2 yellow, 2 black) should make electrical connection

• These connectors are sometimes called PEG connectors (PEG = PCI Express Graphics).

Using this terminology may help when ordering cables and/or connectors

22 / 109

Page 23

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4 Software Installation

Signalogic software consists of (i) Linux host software and (ii) target software and build tools. “Host” in this case means the server, ATCA, embedded system, or other platform / enclosure that hosts the “target” hardware. Host and target can be physically interfaced in multiple ways:

• via PCIe slot, for example PCIe cards containing one or more multicore CPUs or other

compute devices, such as neural net chips. The SigC6678-32 and SigC6678-64 are accelerator cards with containing multicore CPUs

• via SRIO or shared memory connection

• via network connection

Note the definition of host and target is flexible as there is not always a clear physical boundary; for instance in an SoC device with one or more ARM cores and one more compute intensive cores the ARM cores would be the Linux host and the compute cores the target.

The table below shows host and target software folders after installing the distribution .rar files.

Subfolder Name Type Description / Comments

DirectCore Host Key subfolders include “driver”, "lib" (libraries), "include" (API

and CIM header files), and "apps" (test/demo programs, organized according to hardware type)

CIM Host CIM pre-processing tools, utilities and scripts, and demo programs

mCPU_target Target Includes target (multicore CPU, DSP, neural net, etc) run-time test

and demo programs and source code, RTAF components, and CIM components

The host software .rar file should be unzipped to the "/root" directory, creating a main Signalogic software folder, with subfolder hierarchy as shown in Figure 4-1 below:

23 / 109

Page 24

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-1, Signalogic host and target software folder hierarchy

Note! The main Signalogic software folder may be suffixed with "_2010v3",

"2012v4", or "2014v5", but in all cases is prefixed with “Signalogic”

For SigC667x cards and SigC641x cards/modules, a target software .rar file is also provided, which includes software specific to these cars. In general, target software includes run-time test and demo programs (and source code), RTAF components, and CIM components for different types of hardware, such as multicore CPU, DPDK, neural net, DSP, etc. RTAF (Real-Time Algorithm Framework) provides target software support for host software, including DirectCore software, CIM software, and user-defined projects. The target software .rar file consists of source code and other necessary files to build with Texas Instruments command line code generation (build) tools. For more information about RTAF, see section 4.5 below, RTAF Software Usage. Configuration, project, and other files needed for use with Texas Instruments build tools are also included in the target .rar file.

For SigC667x cards, all TI code generation and configuration is handled either with make files or using the fully automated CIM build process, and intended to be used with TI's command line build tools. The software build process does not interact with TI's Code Composer Studio IDE

24 / 109

Page 25

1/27/15 SigC667x / SigC641x User Guide, Rev B7

environment, although that mode is supported if needed due to user preference or applicationspecific reasons. For target software, the target .rar file installs in the “mCPU_target” subfolder under the main Signalogic folder on a Linux machine, as shown in Figure 4-1 above and Figure 4-2a below.

Figure 4-2a, Target software folder hierarchy for SigC667x cards

Note in Figure 4-2a above, RTAF software is stored on the “mCPU_target” subfolder, meaning multicore CPU or other target hardware. This naming convention refers to run-time software for multicore CPU or other target hardware; e.g. CIM accelerator, DSP card, video or telecom card, network processing card, neural net card, etc. Note that the various supported multicore CPU and other target hardware types are collectively referred to throughout the User Guide as "targets", and code that runs on the target as executable target code and files, or "run-time" code.

For older generation SigC641x processor software, the target .rar file should be installed (unzipped) on a WinXP or Win7/8 machine, to the C:\ directory. This allows all project file and subfolder references inside the .rar file to remain intact. CCS3 and CCS5 project files and DSPBIOS and SYSBIOS configuration files (.tcf and .cfg files, respectively) are provided.

For SigC641x modules, the target software folder hierarchy is shown in Figure 4-2b below.

25 / 109

Page 26

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-2b, Target software folder hierarchy for SigC641x modules

For SigC641x cards, TI code generation and configuration is not automated and must be performed with TI's Code Composer Studio IDE environment, using project files included in the target software. In this case, the target .rar file has to be installed on a Win machine, as shown in Figure 4-2b above.

26 / 109

Page 27

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.1 Building the Loadable Kernel Module (LKM) Driver

Files for the host software DirectCore driver reside on the “driver” subfolder under the “DirectCore” subfolder (see Figure 4-1 above). Key files include:

sig_mc_hw.c - SigC667x and SigC641x driver source code Makefile - Makefile to build and load the driver sig_mc_hw.h - driver include file (located under ../DirectCore/include)

The DirectCore unified host driver supports all target hardware with interfaces including PCIe, SRIO, and onchip (SoC). User applications that make DirectCore API calls or incorporate CIM source code generation should contain no user space calls (e.g. ioctl, pread, pwrite, etc) directly to the DirectCore driver; instead, these calls are made by DirectCore libraries via user application API calls. Applications that make user space calls directly to the driver are not supported.

Note 1: To build the DirectCore driver, certain Linux kernel header files are required.

These are available if the “kernel-devel” RPM has been installed, and a symlink has been created for “/usr/src/linux”. See section 4.1.1 below for more information.

Note 2: In the instructions below, the “#” symbol is used to denote a Linux command-

line prompt. It should not be part of any actual command entry.

First go to the driver directory:

#cd Signalogic_2012v4/DirectCore/driver

To clean the build directory (optional), enter:

#make clean

To build the driver, enter:

#make

To load the driver, enter:

#make load

As a test, you can perform the following command to verify the driver loaded correctly:

#ls /dev/

For SigC6678-32 cards, you should see at least four (4) entries of the form:

/dev/sigc667x_n

27 / 109

Page 28

1/27/15 SigC667x / SigC641x User Guide, Rev B7

where n is 0 to 7. For SigC6678-64 cards you should see at least eight (8) entries, and for SigC641x cards or modules, you should see at least one (1) entry. More entries will be shown if multiple cards are installed.

Figure 4-3 below is a screen capture showing the driver process -- clean, make, and load -- and successful results verified with the ls /dev/ command:

Figure 4-3, SigC641x / SigC667x driver build, load, and verify process

In Figure 4-3, areas outlined in red show a SigC6678-32 card installed (4 6678 devices, 32 CIM cores total), and a SigC641x module installed on a PCIe adapter card (8 C641x devices, 8 CIM cores total). In this case, both cards were installed in the same server simultaneously.

Note

If the ls /dev/ command does not show device entries as noted above, you may need to reboot the system. This is a rare occurrence, but can happen in some systems and/or depending on which firmware revision is loaded on the SigC641x or SigC667x card. For the latter case, see the notes in section 1.2 above, “Installing SigC667x Cards”.

To unload the driver, enter:

#rmmod sig_mc_hw

28 / 109

Page 29

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note that when loading and removing the driver, the following system device entries are automatically updated:

/dev/sigc641x_n

/dev/sigc667x_n

Where n is the device number for SigC667x, and card number for SigC641x.

Figure 4-4 below is a screen capture showing files on the driver subfolder and the driver unload process:

Figure 4-4, SigC641x / SigC667x driver unload process

4.1.1 Linux Kernel-Devel Installation Requirement

To build the DirectCore driver, the "kernel-devel" package, which contains partial Linux source (in particular, certain header files), must be installed. Also, a symlink for "/usr/src/linux" must be created. Instructions for these steps are given below. Note that full kernel source code is not required, as the DirectCore driver is an external driver, not incorporated within the kernel that can be loaded -- and removed -- as needed after the kernel is already booted and running (i.e. loadable kernel module, or LKM).

Note: The commands below assume that you are logged in as root.

1. Step 1. If you are running a standard Linux kernel you can install the kernel-devel package

by following the commands below.

For CentOS and Fedora:

[root@host]# yum install kernel-devel.$(uname -r)

For Ubuntu and Debian:

[root@host]# apt-get install linux-headers-$(uname -r)

Note the use of an embedded “uname –r” command in the above command lines. The

purpose of this is to ensure installation of the kernel-devel package that matches the currently running kernel.

29 / 109

Page 30

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note that the “uname –r” command can be used separately to determine the version of the currently running kernel:

[root@host]# uname -r

The result will look similar to this (depending on what kernel revision is installed):

2.6.18-400.1.1.el5xen

Here are some examples without using an embedded “uname –r” command. Note that these may or may not have exactly correct entry (comments in italics):

[root@host]# yum -v install kernel-devel.i686 (for 32-bit CentOS)

[root@host]# yum -v install kernel-devel.x86_64 (for 64-bit CentOS)

[root@host]# apt-get install linux-headers-x86_64 (for 64-bit Ubuntu)

2. Step 2. In addition to installing the kernel-devel package, a symlink for “/usr/src/linux” must

be created, using a command similar to the following:

[root@host]# ln -s /usr/src/linux-xx.xx.xx /usr/src/linux

where “xx.xx.xx” matches the kernel version returned by the “uname –r” command shown above.

After the symlink is created, the following ls (list) command can be used to verify the symlink (shown as the last line of the ls command result):

[root@localhost bin]# ls -l /usr/src/

total 8

drwxr-xr-x. 2 root root 4096 Sep 23 2011 debug

drwxr-xr-x. 5 root root 4096 Apr 8 2014 kernels

lrwxrwxrwx. 1 root root 34 Nov 13 2012 linux -> kernels/2.6.32-279.14.1.el6.x86_64

After these two steps have been performed, the DirectCore driver makefile can be executed, as described in section 4.1 above.

30 / 109

Page 31

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.2 Building DirectCore Libraries

Source code for DirectCore libraries is located on subfolders under:

../Signalogic_2010v3/DirectCore/lib/

as shown in Figure 4-1, above. If libraries are being built for the first time on a new system, or being rebuilt for a software update on an existing system, the build sequence should be as follows:

1. Enmgr

2. Hwmgr

3. Hwlib

4. Cimlib

5. Filelib

6. Tdmlib

7. Sessionmgr

8. Voplib

For each library, after building, either an archive (.a) or shared object (.so) file should be copied to the default system library directory, typically /usr/lib. Note that the Makefiles do this automatically, but it’s always a good idea to verify that library files are being copied; otherwise, application layer programs that use DirectCore APIs may not build correctly.

For each library, use the following build sequence:

#cd ../lib/<libname> #make clean #make

Figure 4-5 below shows some of the DirectCore libraries being rebuilt.

Note: Currently these libraries are supported by all

hardware types.

Note: Currently these libraries are only supported by

SigC641x hardware. Building and/or running these libraries should not be attempted for SigC667x hardware.

31 / 109

Page 32

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-5, DirectCore library rebuild process

After building each library, resulting library filenames should be:

32 / 109

Page 33

1/27/15 SigC667x / SigC641x User Guide, Rev B7

• libenmgr.a (or libenmgr.so)

• libhwmgr.a (or libhwmgr.so)

• libhwlib.a (or libhwlib.so)

• libcimlib.a (or libcimlib.so)

• libfilelib.a (or libfilelib.so)

• libtdmlib.a (or libtdmlib.so)

• libsessionmgr.a (or libsessionmgr.so)

• libvoplib.a (or libvoplib.so)

Note: See notes above

about whether to build these libraries.

33 / 109

Page 34

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3 Test Programs

The following test programs are available after default software installation.

Test Program Card Connections Required Comments

memTest None . No loopback connections

or other hardware connections are required for this tests

Can be used to validate the card and driver installation. No DirectCore APIs are used, and only executable code for purposes of one-time initialization runs on the target. This is the most minimal test available

boardTest None. No loopback connections

or other hardware connections are

Can be used to validate the card, driver,

and library installation required for these tests. The demo "simulates" analog input using interrupt driven executable code running on the target, but no actual physical connection is required

fftTest None Example of algorithm parallelization and

acceleration

videoTest None Example of video codec acceleration (this

example does video encoding)

streamTest Ethernet Example of high performance video

transcoding and streaming. UDP/RTP

streaming output can be routed to a

mobile device, for example an Android

tablet running the Videolan VLC player.

h264_encode None CIM software demo, showing example

appTest Ethernet

34 / 109

OpenMP superset pragmas in C source

code, source code stream separation and

generation, and run-time execution on the

target hardware (note -- this example is

covered in section 4.6.2, h264_encode

demo)

Only supports SigC641x hardware.

Can be used to set up voice and video

connections and perform testing and

measurements. The minimum required

for appTest is Ethernet (IP) interfaces

between the host server and at least one

other test server or PC

Page 35

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.1 memTest

Note: this section assumes you have already built and loaded the DirectCore target

multicore CPU driver, as explained in section 4.1 above, Building the Loadable Kernel Module (LKM) Driver.

The purpose of memTest is to test hardware and driver software directly and at the lowest possible level, with no libraries and minimal user space code. This is not the normal or recommended method of using SigC641x modules and SigC667x cards but serves instead as a diagnostic and measurement tool. The memTest program has several test modes as follows:

• diagnostic test

• random block test

• broadcast test

• performance test

To build memTest, enter:

#cd .. /DirectCore/apps/SigC641x_C667x/memTest

#make

To run memTest, first enter:

#./memTest -h

This will bring up the help menu showing command line options that can be used to configure the test program and SigC641x or SigC667x hardware.

memTest command line options are shown below (‘+’ indicates mandatory entry):

-c<string> + card designator, e.g. -cSIGC66XX or -cSIGC64XX

-B<num> block size

-d diagnostic test (default if –d, -r, or –z not entered)

-D direct mode (access HPI registers directly)

-m<num> bitmask for core list (1 = core0, 3 = cores 0 and 1, etc)

-M<string> memory region for SigC667x, enter -Moc, -Mos, or –Me (onchip mem, onchip shared mem, or external mem)

-n<num> number of loops (otherwise runs until keyboard exit)

-p<char> performance measurement, enter –p or –pt (-pt measures data transfer time only)

-P master push mode (wait for transfer to complete)

-r random address block test

-R read only

-W write only

-z broadcast test

<num> entries may be specified in either decimal or hex format; if hex, then use a ‘0x’ prefix.

35 / 109

Page 36

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note that –d, -r, and –z are the possible test types; if none are entered, then the default test type is diagnostic (-d). If more than one test type is entered, then tests are run in the following sequence:

diagnostic, broadcast, random block

Note that diagnostic test runs until a key is pressed, so if multiple test types are entered including diagnostic, then you must exit the diagnostic test (press a key) in order to complete all tests.

Here are sample command lines to run memTest for cores 0 and 1, using the diagnostic test type:

#./memTest -m3 –d –bSIGC66XX #./memTest -m3 –d –bSIGC64XX

memTest Output Description

Figure 4-6 below is a screen capture of a successful memTest run for 3 cores by running the following command:

#./memTest –m7 –d –cSIGC66XX

#./memTest –m7 –d –cSIGC64XX

The screen capture in Figure 4-6 below shows an incrementing loop counter at the top of the terminal display and the error counters for the first 3 cores remain zero as the loop counter value increases. The remaining error counters represent cores not included in the “-m” “core list” parameter given in the command line. These are shown as “n/a” to indicate they are not subject to the ongoing test.

To exit from the program, press any key.

Note! For SigC667x hardware, “core list” with multiple bits set may span one or more

target multicore CPUs. For SigC641x hardware, “core list” has the same meaning as “processor list”, as the C641x series of devices is single-core, and thus any core list value with more than one bit set specifies more than one device (CPU).

36 / 109

Page 37

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-6, memTest running diagnostic test for 3 cores on SigC667x or SigC641x hardware

Figure 4-7 below is a screen capture of a memTest diagnostic run for 32 cores, using SigC667x hardware, by executing the following command:

#./memTest -cSIGC66XX -d -m0xffffffff -B98304 -P

37 / 109

Page 38

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-7, memTest running diagnostic test for 32 cores on a SigC667x card

Figure 4-8 below is a screen capture of a successful random block memTest run for 3 cores, using SigC641x hardware, by executing the following command:

#./memTest –m0xa8 –r–B204 –n20 –cSIGC64XX

38 / 109

Page 39

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-8, memTest running random block test for 3 cores on a SigC641x module

Note that in the above command, the

–n20

parameter specifies the test to run for 20 iterations.

Without the –n parameter the test runs for one iteration by default.

Figure 4-9 below is a screen capture of a successful random block, write-only, test of onchip core memory (i.e. core-specific L2 memory) for 32 cores by executing the following command:

#./memTest –cSIGC66XX –B98304 –pt –P –r –m0xffffffff –Moc –n10 –W

39 / 109

Page 40

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-9, memTest running random block test of onchip core-specific memory for 32

cores, with performance measurement enabled

Note that in the above command, the –W parameter indicates “write only”. Also –R can be entered for read-only. If neither is entered, then the test assumes both read and write.

Also note in the above command that “performance measurement” has been specified using the

-p

option; in this case, specifically, the

–pt

option, which measures “transfer time only”,

excluding any intermediate software functions such as data preparation, error checking, etc.

Figure 4-10 below is a screen capture of a successful random block test of onchip shared memory (i.e. MCSM, or multicore shared memory) for 32 cores, using SigC667x hardware, by executing the following command:

#./memTest –cSIGC66XX –B0x100000 –pt –P –r –m0xffffffff –Mos –n10

Figure 4-10, memTest running random block test of onchip shared memory for 32 cores,

with performance measurement enabled

40 / 109

Page 41

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note in the above command, if the memory area specified by the memTest command is shared between all cores of a multicore CPU or target device (e.g. MCSM memory or external DDR3 SDRAM memory), then the memory area is actually tested only once. In this case, memTest will report test results only for the first core of multiple cores per device, which can be seen in Figure 4-10 above by examining the “mask” value printed along with test results.

Block Size Parameter Notes

1. For SigC641x, 4 kByte is the maximum block size for all memory areas. For SigC667x, 1 MByte is the maximum block size for external memory and shared memory (MCSM), and 96 kByte is the maximum size for core-specific L2 memory.

2. Up to a point, larger block sizes will increase measured performance; however, improvement is marginal beyond some point. Smaller block sizes are likely to decrease performance. Using SigC667x as an example, from 1 MByte down to 100 KByte block size, performance may decrease about 40 MByte/sec, at 50 KByte block size performance may decrease another 35 MByte/sec, and at 10 KByte block size performance may decrease as much as 200 MByte/sec and be as low as 350 MByte/sec.

3. If a SigC641x module is being used with a PCIe adapter containing the IDT (formerly Tundra Semiconductor) TSi384 PCIe-toPCI bridge chip, then a carefully selected block size should be specified in memTest commands, for example:

#./memTest –m0xa8 –r –B204 –n20 –cSIGC64XX

The

–B204

parameter specifies the block size at 204 bytes. This is the maximum block size for burst reads/writes that can be used without errors occurring when using a PCIe adapter with the Tundra chip. Specifying this block size compensates for an apparent limitation on PCIe transfer throughput with the TSi384 bridge chip.

41 / 109

Page 42

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.2 boardTest

Note: this section assumes you have already (i) built and loaded the DirectCore target

multicore CPU driver, as explained in section 4.1 above, Building the Loadable Kernel Module (LKM) Driver, and(ii) built all DirectCore libraries, as explained in section 4.2 above, Building DirectCore Libraries.

The boardTest program gives an example of communicating with target code as it runs in realtime, demonstrating DirectCore library API calls.

The boardTest project is written in 2 flavors: straight C code and C++ using a “target class”:

1. "Straight C" code, which minimizes use of C++ programming constructs.

2. C++, which uses a "target class” to reduce the number of library calls an application needs to make and simplifies the amount of code necessary to gain basic target card / module connectivity and data transfer.

To build the boardTest program, enter the following:

#cd ./DirectCore/apps/SigC641x_C677x/boardTest #make (default uses C source code)

or enter the following:

#make cpp (uses C++ source code)

Currently, the “make” is the standard (default) option, and should be tested first.

Before running boardTest, first enter:

#./boardTest –h

This will bring up the help menu in order to configure SigC667x or SigC641x hardware.

Command line option syntax (options with “+” sign are mandatory):

-f<num> Device clock rate in MHz (e.g. -f1000)

-m<num> + Core select bit mask (e.g. -m1, means core0, -m2 means core1. (Note: in this test, only one core can be selected at a time)

-e<string> + Target executable file (in ELF or COFF format, e.g. -ebdtest.out)

-c<string> + Card designator (e.g. -cSIGC66XX)

-T Run with talker enabled

-v Run in verbose mode

-h Display this help list

Here are some example boardTest command lines:

# ./boardTest -m1 –f1000 -ebdtest.out -cSIGC64XX

Note! The C++ class is only supported for SigC641x.

42 / 109

Page 43

1/27/15 SigC667x / SigC641x User Guide, Rev B7

# ./boardTest -m1 –f1250 -ebdtest.out -cSIGC66XX

Note that in the above command-line, the

“-ebdtest.out”

option specifies a target CPU executable code file (in ELF or COFF format). The clock rate will be 1 GHz or 1.25 GHz as specified by the

–f1000

–f1250

command line parameters (note that the –f command line

parameter uses MHz as its units).

boardTest Output Description

Figure 4-11 below is a screen capture of output from the boardTest test program, executed using the following command for a SigC667x PCIe card:

# ./boardTest -m1 –f1250 -ebdtest.out -cSIGC66XX

for the following command for a SigC641x PCIe card or PTMC module:

# ./boardTest -m1 –f1000 -ebdtest.out -cSIGC64XX

The screen capture in Figure 4-11 shows a sequence of low frequency sinusoidal signal values. The values are read by the boardTest program from dual real-time data buffers in target memory and displayed repeatedly (about 1 sec rate), and will change in each read cycle. Figure 4-11 shows about four (4) of the read cycles -- note the changing data pattern.

43 / 109

Page 44

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-11, Example boardTest display

To exit from the boardTest program, press the q (Quit) or ESC keys.

Note: you can also exit using Ctrl-C, but using the interactive keyboard commands is

preferred as that allows the test program to free (de-allocate) the card handle, close its instance of the driver, and perform other clean up operations. This helps to maintain "clean" host Linux / server operation, and avoid memory leaks, driver errors, etc

44 / 109

Page 45

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.3 fftTest

Note 1: This section assumes you have already (i) built and loaded the DirectCore target

Note 2: Currently fftTest is only supported by SigC667x hardware.

The fftTest program gives an example of running a parallelized algorithm on multiple target cores, using DirectCore library API calls.

To build the fftTest program, enter the following:

#cd ../DirectCore/apps/SigC641x_C677x/fftTest #make

Before running fftTest, first enter:

#./fftTest –h

This will bring up the help menu in order to configure SigC667x hardware.

Command line option syntax (options with “+” sign are mandatory):

-f<num> Device clock rate in MHz (e.g. -f1000)

-m<num> + Core select bit mask (e.g. -m1, means core0, -m2 means core1. (Note: in this test, only one bitmask values of 2n-1 can be selected, specifying the number of cores to run in parallel)

-e<string> + Target executable file (in ELF or COFF format, e.g. -efft.out)

-c<string> + Card designator (e.g. -cSIGC66XX)

-a<num> Algorithm flag, 0 = parallel FFT, 1 = serial FFT (default parallel)

-n<num> FFT order, from 2 to 20 (default = 6)

-I<num. input waveform type, 0=ramp, 1 = Dirac Delta pulse

-i<string> input waveform file (in .wav or .tim format)

-v Run in verbose mode

-h Display this help list

Here are some example fftTest command lines:

# ./fftTest -m1 –f1250 -efft.out -cSIGC66XX -

Note that in the above command-line, the code file (in ELF or COFF format). The clock rate will be 1 GHz or 1.25 GHz as specified by the

–f1000

–f1250

command line parameters (note that the –f command line parameter uses MHz as its units). Parameters -a, -n, -I, and -i can be used to specify algorithm and input options.

“-efft.out”

option specifies a target CPU executable

45 / 109

Page 46

1/27/15 SigC667x / SigC641x User Guide, Rev B7

fftTest Output Description

Figure 4-12 below is a screen capture of output from the fftTest test program, executed using the following command for a SigC667x PCIe card:

# ./fftTest -m1 –f1000 -efft.out -cSIGC66XX -n4

The screen capture in Figure 4-12 shows output for a small FFT order using a parallelized method based on Bailey's "Four Step" algorithm 1, which "factors" an FFT of order No into an NxM matrix of FFTs, where N and M are as close as possible to √No. FFTs in the matrix are then run on multiple target CPU cores concurrently.

A small FFT order is used for the test to allow results to conveniently viewed, and the test to be repeated in serial (non-parallelized) FFT mode in order to compare values for correctness.

FFTs in External or Hierarchical Memory, David H. Bailey, 1989. Journal of Supercomputing,

vol. 4 no. 1 Mar 1990. http://www.davidhbailey.com/dhbpapers/fftq.pdf

46 / 109

Page 47

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-12, Example fftTest display output

47 / 109

Page 48

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.4 videoTest

Note 1: This section assumes you have already (i) built and loaded the DirectCore target

multicore CPU driver, as explained in section 4.1 above, Building the Loadable Kernel Module (LKM) Driver, , and(ii) built all DirectCore libraries, as explained in section 4.2 above, Building DirectCore Libraries.

Note 2: Currently videoTest is only supported by SigC667x hardware.

The videoTest program gives an example of running a video codec algorithm on multiple target cores, using DirectCore library API calls.

To build the videoTest program, enter the following:

#cd ../DirectCore/apps/SigC641x_C677x/videoTest #make

Before running videoTest, first enter:

#./videoTest –h

This will bring up the help menu in order to configure SigC667x hardware.

Command line option syntax (options with “+” sign are mandatory):

-f<num> Device clock rate in MHz (e.g. -f1000)

-m<num> + Core select bit mask (e.g. -m1, means core0, -m2 means core1. (Note: in this test, only one core can be selected at a time)

-e<string> + Target executable file (in ELF or COFF format, e.g. -evideo.out)

-c<string> + Card designator (e.g. -cSIGC66XX)

-i<string> input waveform file (in .yuv format)

-s<num>........Scaling option

-v Run in verbose mode

-h Display this help list

Here are some example videoTest command lines:

# ./videoTest -m1 –f1250 -evideo.out -cSIGC66XX -iairshow_p352x288.yuv

Note that in the above command-line, the executable code file (in ELF or COFF format). The clock rate will be 1 GHz or 1.25 GHz as specified by the

–f1000

–f1250

parameter uses MHz as its units). Parameters -i, and -s can be used to specify and input scaling options.

videoTest Output Description

Figure 4-13 below is a screen capture of output from the videoTest program, executed using the following command for a SigC667x PCIe card:

“-evideo.out”

option specifies a target CPU

command line parameters (note that the –f command line

48 / 109

Page 49

1/27/15 SigC667x / SigC641x User Guide, Rev B7

# ./videoTest -m1 –f1000 -evideo.out -cSIGC66XX -itouchdown_pass_1080p_tr.yuv

The screen capture in Figure 4-13 shows typical videoTest run-time output, and Figure 4-14 shows the resulting H.264 encoded output file viewed using the Videolan VLC player.

Figure 4-13, Example videoTest display output

As a progress update, videoTest will continuously update the current frame (after the line “Num frames encoded” in Figure 4-13 above). If videoTest hangs for any reason, you can exit by pressing the q (Quit) or ESC keys.

Note: you can also exit using Ctrl-C to exit test programs, but using the interactive

keyboard commands is preferred as that allows the test program to free (de-allocate) the card handle, close its instance of the driver, and perform other clean up operations. This helps to maintain "clean" host Linux / server operation, and avoid memory leaks, driver errors, etc

Figure 4-14 below shows playback of the resulting “encoded.h264” file using the Videolan VLC player (other widely used video players can also be used, such as Windows Media Player).

49 / 109

Page 50

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-14, Example of encoded videoTest output. In the above screen capture, H.264

encoded data has been stored to a file, and then played back for test / comparison purposes

using the Videolan VLC open source video player

50 / 109

Page 51

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.5 appTest

Note 1: This section assumes you have already (i) built and loaded the DirectCore target

Note 2: Currently appTest is only supported by SigC641x hardware. Building and/or

running appTest should not be attempted for SigC667x hardware.

The appTest program gives an example of communicating with target code as it runs in realtime, demonstrating several DirectCore library API calls.

The appTest program is written in C++ and uses Call Manager APIs to perform target-related functions and to reduce the number of API calls needed to initialize and control the target multicore CPU farm.

To build the appTest program, enter the following:

#cd /root/Signalogic_2012v4/DirectCore/apps/SigC641x_C667x/apps/appTest #make

Note that the libraries mentioned in section 4.2 above, including Session Manager, must be built before appTest can be built successfully.

To run the appTest program, first enter:

#./appTest –h

This will bring up a help menu. Command line option syntax (options with “+” sign are mandatory):

-c<string> + Card designator (e.g. -cSIGC64XX)

-f<num> Device clock rate in MHz (e.g. –f1000)

-m<num> + Core select bit mask. (e.g. -m1, means core0,-m2 means core1, -m255 means cores 0-7, etc)

-e<string> + Target executable file (in ELF or COFF format, e.g. -esigc64xx.out)

-p<num> Number of devices (e.g. -p8)

-t Run with TDM interface enabled

-C Run with continuous diagnostic display enabled

-T Run with target HPI driver ('talker') enabled

-v Run in verbose mode

-h Display this help list

For a 1 GHz SigC64x card, the default configuration used to run appTest would be:

#./appTest -m1 –f1000 -etmsc64xx.out -cSIGC64XX -t

For a 1.25 GHz SigC66x card, the default configuration used to run appTest would be:

#./appTest -m1 –f1250 -etmsc66xx.out -cSIGC66XX

51 / 109

Page 52

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note that SigC66xx cards do not support a TDM interface. Note also that in the above command-line, the

“-etmsc64xx.out” or “-etmsc66xx.out”

option specifies a executable code file generated by Texas Instruments CGT (Code Generation Tools), v7.2.x or higher. See “Host Test Programs” section for a table showing the corresponding CCS projects and target executable code files for each host test program.

4.3.5.1 appTest Output Description

Figure 4-15 below is a screen capture of a successful appTest run, executed using the following command:

#./appTest -m1 -f720 -etmsc64xx.out -cSIGC64XX –t -C

The screen capture in Figure 4-15 below shows continuous target multicore CPU memory diagnostic data capture and display (enabled with –c command-line option) and results of the "display call list" command, showing several calls currently active.

52 / 109

Page 53

1/27/15 SigC667x / SigC641x User Guide, Rev B7

appTest program interactive keyboard commands include:

Main Level

A Algorithm Mode Control C Show list of currently active call IDs D Display diagnostic data (currently shows per-channel state and

flag information, target code probe points, and IP/UDP/RTP packet

information) F Freeze/unfreeze continuous target data display L Load media M Show list of currently active media IDs

Figure 4-15, Example appTest display

53 / 109

Page 54

1/27/15 SigC667x / SigC641x User Guide, Rev B7

P Play media O Operating Mode Control S Set up call T Tear down call U Unload media Q Quit

NOTE: The above command summary is only an abbreviated list given for example and

reference purposes. This summary should be solely for quick test runs of the appTest program. For detailed information on appTest program interactive commands, see the following section 4.3.5, Voice and Call Processing Test Procedures.

4.3.5.2 RTP Audio Test Program

The RTP Audio test program is a WinXP program that:

 receives UDP/RTP streams from the network and plays to the sound card (headphones or

speaker), and

 transmits sound card input data (microphone) or waveform file data (.wav file) over the

network via UDP/RTP streams

The RTP Audio program can be set to work in different modes, including half duplex, full duplex, .wav file data or microphone source, and with flexible RTP parameters, such as 16-bit linear and 8-bit compressed payload formats and variable payload lengths.

Following are some command line examples.

1) Here the command line specifies source data as microphone and destination as a UDP/RTP stream to IP address 10.0.0.53, using 8-bit uLaw RTP payloads:

-smic –d10.0.0.53 -u8

2) Here the command line specifies source data as a UDP/RTP stream received from a remote PC with IP address 10.0.0.53, and destination as the sound card, using 16-bit linear PCM format (also known as “L16”):

-s10.0.0.53 -dsnd

3) The following command lines set up an “RTP call” between two PC’s, allowing full-duplex, real-time audio communication via UDP/RTP streams:

-smic -d10.0.0.53 -u8 -f

-s10.0.0.29 -dsnd -u8 -f

4.3.5.2.1 Installing and Running RTP Audio

1) To install the RTP Audio test program, download “WinXP_01Apr09.rar” or “RtpAudio.zip” or similar compressed file from Signalogic’s website, and extract to a suitable folder on your

54 / 109

Page 55

1/27/15 SigC667x / SigC641x User Guide, Rev B7

target PC. For full-duplex operation between two PCs, two copies of RtpAudio should be installed, on one each PC.

2) To run the RTP Audio test program, open a console application window (e.g. run “Cmd” under WinXP), go to the directory on which you installed the executable, and run “rtpaudio” followed by command-line entries such as those shown above.

Note: For detailed information about the RTP Audio Test Program, please refer to the

“RTP Audio Test Program Users Guide”, which contains system diagrams, program usage screen captures, RTP payload and header tables, and more.

55 / 109

Page 56

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note: The HW400c2 and WTRB500 are

sis

PC Test

T1/E1

Adapter

FXS/FXO

Adapter

X86 CPU

4.3.5.3 Call and Voice Processing Test Procedures

Note: This section only applies if a TDM interface is being used. If not, ignore this

section and skip to section 4.3.6, Interactive Command Summary.

The test procedures given in this section assume a test setup as shown in Figure 4-16 below:

Signalogic Inc. Rev 5 Title: Push To Talk Test Setup Project: WTRB Compatibility Copyrights © Signalogic 2008

SS7 Signaling

RTX CHASSIS

Page 1/2

Phone1

Phone2

Phone1

Signaling Generator

INET Box

RTM

WTRB500

installed in the same RTX chas

1……………..24

GbE Backplane

Phone2

Patch Panel

To DS3 module

(see page2)

DSP Farm

Station

1……………28

DEMUX

LIU

Framer

T8110

RTX CHASSIS

8.192 MHz clock

8 kHz frame clock

Line loopback

DS3 Module

2 c 0 0 4

W H

From T3 Demux output

(see page1)

DSP

ule

DSP loopback

RXTX

GbE Backplane

Figure 4-16, TDM call equipment and setup

56 / 109

TXRX

LIU

Framer

loopback

T8110

loopback

Page 57

1/27/15 SigC667x / SigC641x User Guide, Rev B7

In Figure 4-16 above, “Phone 1” and “Phone 2” refer to standard handsets with RJ-11 connectors. The handsets are used for verbal and aural confirmations in the test procedures below.

TDM Setup Procedures

1) First make sure both SigC641x module and DS3 module drivers (module names sigc641x and wan256t3, respectively) are loaded. Test program sequences below will fail immediately if both drivers are not loaded and functioning correctly. For the SigC641x module driver, the command lines to do this are

cd ../BaseFolder/SigC641x/driver make load

To make (build) the DS3 module driver (wan256t3), type the following:

cd /usr/src/linux/ make modules make modules_install

To load the DS3 driver, type:

modprobe wan256t3

To unload the driver, type:

rmmod wan256t3

To see driver options, type:

modinfo wan256t3

2) Run the DS3cfg script, using the following command line sequence:

cd ../BaseFolder/DS3 ./DS3cfg

The DS3cfg script performs basic configuration and initialization of the TECT3 framer and T8110 devices on the DS3 module. With the T8110, all channel mapping and connections are reset (cleared). If a digital scope is connected to the CTBus between the DS3 module and SigC641x module, as shown in Figure 4-17 below, then the CTD0 and CTD1 traces should show “flat lines” (no data). Even though T3 input/output to the DS3 module may be active, and TECT3 framer on the DS3 module configured as needed, without T8110 channel connections the no data will be present on the CTBus.

57 / 109

Page 58

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Note: TECT3 framer and T8110 chip setup contained in the DS3cfg script is

progressively being replaced by test program code. Running the script beforehand is always a safe step, even if the test program Resets these chips and rewrites chip registers.

Figure 4-17, CTBus between SigC641x and DS3 modules, with voice data inactive

In the appTest program, no connections are made until a call is set up. If for testing or debug purposes connections are needed prior to call setup, the DS3cfg script can be modified. A version of the script called DS3cfg_mapping is available as an example of how to do this – look near the end of the script.

(Note – this step is optional. Updated test procedures do not require this step).

Initialize a call using the CPU blade software, WTRB500 media board, and Inet signaling test/generation unit (connected to SS7 signaling module located on the CPU blade). At least one call has to be initialized in the system to ensure valid T3 output from the WTRB500 board. After this is done, the T3 cabling should be adjusted so the WTRB500 output is bypassed; in other words, T3 output from the Adtran MX2800 demux output should be routed to both the WTRB500 board and DS3 module (use a splitter connector) and DS3 module T3 output should be routed back to the MX2800 mux input.

58 / 109

Page 59

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4) Run the appTest program, using the following command line:

cd /root/Signalogic_2012v4/DirectCore/apps/SigC641x_C667x/appTest #./appTest -m1 -f720 -etmsc64xx.out -cSIGC64XX –t

The current version of the test program will initially show a substantial amount of debug information related to hardware and driver initialization, and pause three (3) times for keyboard prompt. At the first two prompts, push a space key, and at the third prompt enter a ‘c’ key (“Continue”) or ‘q’ key to Quit if debug information shows any type of hardware initialization error.

The test program will initialize with:

• Target voice code loopback on all channels (logic loopback disabled)

• TDM mapping set to “non reversed”, which assumes the Motorola WTRB500 board is

not present in the T3 circuit

• No calls connected

• No medias downloaded into target multicore CPU memory

4.3.5.4 Interactive Command Summary

Below is a summary of interactive key commands available when running the test program. Commands are in two levels, a Main level and a Second level

Main Level Second Level

A Algorithm Mode Control

| |__ A Exit algorithm mode control

|____ D Display VAD and DTMF status

|____ E Toggle Echo Reduce (default = active)

|____ G Toggle AGC (default = active)

|____ T Toggle DTMF (default = active)

|____ V Toggle VAD (default = active)

C Show list of currently active call IDs

D Display diagnostic data (currently shows per-channel state and flag

information, taret probe points, and IP/UDP/RTP packet information)

F Freeze/unfreeze continuous target data display

59 / 109

Page 60

1/27/15 SigC667x / SigC641x User Guide, Rev B7

L Load media

M Show list of currently active media IDs

O Operating Mode Control

| |____ O Exit operating mode control

|____ D Enable target voice processing (default = enabled) | |____ I Prompt for entry of IP address for IP call testing

|____ L Enable logic loopback of CTBus streams (default = | disabled)

|____ N Enable CTBus stream registers (default = enabled) | |____ P Toggle debug prompt enable | |____ > Toggle IP Test Mode (default = enabled)

|____ W Toggle whether WTRB500 board is in series in the T3 | circuit (default is not in the circuit) | |____ V Toggle verbose mode for diagnostic data display

(default is disabled)

P Play media S Set up call T Tear down call U Unload media Q Quit

60 / 109

Page 61

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.3.5.5 Basic Call, Media, and DTMF Test Procedures

Note: This section includes references to a TDM interface (e.g. CTBus). If no TDM

interface is installed or configured, those references may be ignored. References to IP calls, DTMF events, and Media playouts, and interactive command interface remain valid.

1) First enter Operating Mode (press ‘o’ key) and verify that if you alternately press the ‘n’ and ‘d’ keys you can alternately not hear / hear voice loopback on any connected phone (by default, loopback is enabled on all channels on all streams).

2) If you have a digital scope connected as shown in Figure 4-18 below, you can press ‘L’ key (still within Operating Mode) to verify that with Logic Loopback enabled, input and output CTD0 and CTD1 traces show identical bit patterns. This only occurs if no delay is present in the CTBus circuit, which is the case with logic loopback, but not with target voice processing. Press the ‘d’ key to re-enable target voice processing.

3) If in Operating Mode, then exit by pressing the ‘o’ key again. Use the ‘s’ key to set up calls. The call setup prompt entry is of the format (brackets indicate optional entry):

type[Id].a.b[.dsp]

where type is Call Type (either ‘c’ for conference or ‘p’ for PTT) Id is an optional Call Id, a and b specify call leg information, and dsp is a target CPU number (from zero to 7).

A and b can specify:

 two call legs to create a 2-party call, with a and b each specifying a call leg in the form of

a channel or endpoint. Some examples:

c.0.1 creates a conference call having Call Id of 1, channels 0

and 1

p.e3.e4 creates a PTT call having a Call Id of 2, with the talker

channel initially assigned to endpoint 3, and first listener channel assigned to endpoint 4

 one call leg, when a and b both specify a channel and/or endpoint. In this case, the Call

Id must be given. Some examples:

c3.4.e5 create a call leg on channel 4, endpoint 5, with Call Id

assigned a value of 3

p4.5.e6 create a PTT talker call leg on channel 5, endpoint 6,

with Call Id assigned a value of 4

61 / 109

Page 62

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Channel format can be:

where N is a channel number from 0 to 127 and ‘i’ specifies an IP channel (default with no prefix specified is a TDM channel). For an IP channel, no endpoint or T1 stream information should be entered.

Endpoint format can be:

eNtM

where ‘e’ indicates an “endpoint” (time-slot on a T1 stream, from 1 to 24), ‘t’ indicates call leg source is T1, and M is a T1 stream number from 1 to 28. For example, an explicit entry of:

c.e1t1.e1.t2

would set up a call between endpoint 1 on T1 stream #1 and endpoint 1 on T1 stream #2.

If a target CPU number is not specified, then the “currently active” DSP is assumed. Normally this is zero (first target CPU).

Note that partial entry is allowed for call and call leg input. For example, when creating calls, if no endpoint information is given, then the first available endpoint is assigned. If no channel is specified then the first available channel is assigned. If no call leg source information is given, then the first available T1 is assumed.

Call legs may be added to an existing call by specifying an existing Call Id. Given the above examples, the following commands would add a third leg to Call Ids 3 and 4:

c3.9.e21 add a leg to conference Call Id 3, assigned to channel 9 and

endpoint 21 (on T1 stream #1).

p4.27.e1t2 add a listener leg to PTT Call Id 4, assigned to channel 27 and

endpoint 1 on T1 stream #2

With the above information as a guide, use the ‘s’ key to set up the following five (6) calls:

c.0.1 c.e3.e4 c.e9.e10 c.6.7 c5.8.e8 c10.20.e20 c10.21.e21

62 / 109

Page 63

1/27/15 SigC667x / SigC641x User Guide, Rev B7

The above sequence will set up six (6) calls. In the first call, endpoints are not specified so endpoints 1 and 2 are allocated. In calls 2 and 3, channels are not specified, so channels 2-5 are allocated. In the fourth (4th) call, endpoints 5 and 6 are assigned, as they are the “next available” endpoints. In the fifth line above, a new call leg is created with channel 8 and endpoint 8 specified, and Call Id 5 assigned (given explicitly). In the sixth call, each leg is set up separately. Notes about the above call setups:

 Call Ids 1 thru 4 are assigned for first 4 calls, a Call Id value of 5 is given explicitly for

the fifth call, but only one leg of the call is active, so this call ID is reserved. A Call Id value of 10 is given explicitly for the sixth call

 only one call can be set up each time ‘s’ is pressed

 Call Id values are “one based”. The maximum Call Id value is 255

If a digital scope is connected to the CTBus between the DS3 module and SigC641x modules, then the scope should show a display similar to Figure 4-18 below.

Figure 4-18, CTBus between SigC641x and DS3 modules, with voice data active

63 / 109

Page 64

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4) A call type of ‘p’ can be used to set up a PTT call. The following entry:

p.10.11

will set up a PTT call on channels 10 and 11 (using available endpoints 7 and 11), with the PTT “talker” assigned to channel 10 and the first PTT “listener” assigned to channel 11. When a PTT call is first established, a “PTT Buffering Start” event should be displayed. There are two types of this event: a) VAD, and b) Delay. The VAD version indicates that PTT talker voice was detected and PTT buffering started upon voice detection. The Delay version indicates that PTT buffering started after some non-voice when no PTT talker voice was detected (currently this includes a “dead channel” which is useful for lab testing, and a user-specified arbitrary delay).

Upon creation of the PTT call, a “PTT buffering start (VAD)” event should be displayed. About 8 seconds after the buffering start event, a “PTT Buffering Wrap” event should be displayed. Figure 4-19 below shows examples of PTT Buffering Start and Done events:

Figure 4-19, PTT Buffering Start and Done events after PTT call setup

5) Adding legs to an existing call. The following entry:

64 / 109

Page 65

1/27/15 SigC667x / SigC641x User Guide, Rev B7

p6.12.e13

will add a third leg to PTT call with Call Id value of 6 (note that the value of 6 was assigned in the ‘p.10.11’ call setup entry in step 4 above, as 6 was the next available Call Id). This call leg will become the second PTT “listener” on the call. Multiple listeners can be assigned to a PTT call.

6) Now press 'c' key to verify the active call list. The test program should display currently active calls, as shown in Figure 4-20 below.

Note that Call Id’s are assigned in the order of call setup, unless Call Id is specified explicitly during the call setup entry. When a call is deleted (using the tear down command), then the deleted Call Id is returned to zero and made available again. Other active Call Id’s are not changed when a call is deleted.

7) Updating a call. The following entry:

Figure 4-20, Active call list display

65 / 109

Page 66

1/27/15 SigC667x / SigC641x User Guide, Rev B7

p.14.15

would first establish a PTT call on channels 14 and 15 (using next available endpoints of 15 and

16), with channel 14 (endpoint 15) acting as the talker leg and channel 15 (endpoint 16) the listener leg. The following entry:

c7.14.e15

will convert the PTT call to a 2-way conference call. Note that the channel + endpoint entry specification exactly matches the talker leg of the existing call.

8) Using test system equipment as shown in Figure 4-16 above, or similar equipment, verify one or more currently active TDM calls using handset phones.

9) To set up IP calls, take the following steps. First, enter source and remote IP addresses and UDP ports as shown below:

1) press ‘o’ to see operating control mode options

2) Choose ‘>’ to disable IP-to-IP test mode

3) Type ‘i’ to enter a source IP address, press the ‘Enter’ key, and enter a remote IP address

4) Type ‘o’ to exit operating control mode

66 / 109

Page 67

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-21, Setting up an IP call

10) Next press ‘s’ to set up an IP call using the following command line:

c.i9.13

After setting up the call, press ‘Enter’, you should see the following screen.

67 / 109

Page 68

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-22, After setting up a TDM-to-IP call

11) Set up three (3) more IP calls as shown below:

c.16.i17 c.18.i19 c.i22.23

12) Now press 'c' key to verify the current call list. The test program should display all currently active calls, as shown in Figure 4-23 below. Note that IP channels are indicated with “ip” in the “src” column.

68 / 109

Page 69

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-23, Call display including IP calls

13) Run “RTP Audio” test program on a separate WinXP machine to verify IP calls, using handsets (for TDM side of call) and headsets connected to the WinXP PC sound card (for IP side of call). For example run this RTP Audio command line:

RtpAudio -s10.0.1.62:16384 –dsnd –u8 –f

RtpAudio -smic -d10.0.1.62:16384 –u8 –f

Notes

1) Above IP addresses and UDP ports are only examples. These values may be different from one test system to another.

2) Make sure the WinXP machine IP address matches one of the remote IP addresses previously entered (in step 9 above).

69 / 109

Page 70

1/27/15 SigC667x / SigC641x User Guide, Rev B7

3) Only one IP call can be connected to a WinXP machine at one time. This is a limitation of the RTP Audio test program. To test multiple IP calls, use more than one WinXP machine.

For detailed information about the RTP Audio test program, please see the document “RTP Audio Test Program Users Guide”.

Figure 4-24, Full-duplex IP call testing using RTP Audio test program

14) Verify effects of AGC by pressing the ‘a’ key (Algorithm Mode) and then the 'g' key several times and noting slight difference in voice levels and background noise. When you do this you should see a display similar to Figure 4-25 below:

70 / 109

Page 71

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-25, Display after entering Algorithm Mode and toggling AGC Active

If a digital scope is connected as shown in “Notes and Equipment” section above, note that effects of AGC are visible on the scope. If AGC is not active, then the output trace (green) will show a flat line (zero pattern) for any unused channels. If AGC is active, then the output trace will show a constant, non-zero pattern for any unused channels. (Remember that if N calls are set up, then unused channels start after 2*N channels on the scope display).

15) Exit Algorithm Mode (press ‘a’ key again) and then press the ‘d’ key to display a “diagnostic readout” showing current call state information maintained by the target code. You should see a display similar to Figure 4-26 below:

71 / 109

Page 72

1/27/15 SigC667x / SigC641x User Guide, Rev B7

The diagnostic data display includes target code “probes” (used for monitoring certain sections of target code), IP call transmit (send) packet values (RTP payload only), and a target channel table, which shows a 32-bit encoded “channel information” value for each channel (channels 0 to

127). Channel information values have the following format:

31-28 27-24 23-16 15-8 7-4 3-0

VAD Score DTMF Detect Call Index Channel

Encoded field values are explained in the table below:

Figure 4-26, Diagnostic data display

Flags

72 / 109

Call State Channel

Source

Page 73

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Field Description Encoded Values

VAD Score Current VAD score for

the channel

DTMF Detect Most recent DTMF tone

detected on the channel

0-15, with increasing score indicating higher confidence that voice has been detected

0-15, corresponding to touch pad keys (or digits) on the handset as follows:

Encoded Value Key or Digit 0 1 1 2 2 3 3 A 1 4 4 5 5 6 6 7 B 1 8 7 9 8 10 9 11 C 1 12 * 13 0 14 # 15 D 1

Call Index Index of call to which

this channel is connected.

A call can have multiple nodes, so an index value of N indicates “this channel is a node of call N”.

Channel Flags Indicators for activity on

the channel. Note that flags use “power of 2” encoding as more than one channel flag can be active at any one time

Call State Current state of the call

to which this channel is connected.

1-255

1 Indicates channel is a PTT listener 2 Indicates channel is a PTT talker 4 Indicates a media playout is currently active on the

channel 8 Indicates a DTMF tone has been detected on the

channel

0 Loopback 1 PTT Call 2 2-Party Call 3 Conference Call

73 / 109

Page 74

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Channel Source Voice / data source for

the channel

0 None 1 TDM (CTBus, McBSP0) 2 2 IP 3 3 H.110 (McBSP1) 4 Inter-DSP (McBSP1)

Notes

If handset has a fourth (4

th)

column of keys.

A TDM channel connects to one of 28 T1 streams on the DS3/T3 module.

In “basic IP” mode, IP channels are processed by the host CPU; i.e. the appTest program reads/writes IP/UDP/RTP packets from target CPU memory, and sends/receives the packets over the network. In “Advanced IP” mode, IP channels are processed by target CPU code; i.e. target CPU code sends/receives IP/UDP/RTP packets using the GbE interface on the SigC641x module. In both cases the receive-side jitter buffer is implemented in target CPU code and memory.

74 / 109

Page 75

1/27/15 SigC667x / SigC641x User Guide, Rev B7

16) Press keypad keys on a connected handset and verify that you see DTMF event display as shown in Figure 4-27 below.

Note that DTMF events are detected only on channels currently allocated for calls; i.e. if a channel is not connected to a phone, then no DTMF events are detected or displayed.

Figure 4-27, DTMF event display

75 / 109

Page 76

1/27/15 SigC667x / SigC641x User Guide, Rev B7

17) Press the ‘L’ key to load one or more medias. For example load in_begin_low.wav as first media, test.wav as second media, test2_mu.wav as third media, etc. The following waveform file formats are supported:

 .wav, PCM (16-bit linear)  .wav u-Law (8-bit)  .wav A-Law (8-bit)  .tim, PCM (16-bit linear)  .ton, PCM (16-bit linear after de-compression)

Note that only mono (single-channel) waveform files are supported.

18) Press ‘m’ key to show a list of loaded medias, as shown in Figure 4-28 below.

Figure 4-28, Example list of loaded Medias

19) Press ‘p’ key to play medias. The media playout prompt entry is of the format:

id, rc, ch

76 / 109

Page 77

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Where id is Media Id, rc is Repeat Count, and ch is Channel on which to play the media. For example, to play Media Id 1 on channel 0, enter at the playout prompt:

1,1,0

To play Media Id 2 on channel 1, enter:

2,3,1

20) To unload (delete) a media, press the ‘u’ key, and enter the Media Id to be deleted.

Media Playout Notes

 A “media playout completed” event is displayed when each media playout is complete.

An example is given in Figure 4-29 below

 If a media playout is attempted on a channel already playing a media, then an error

message is displayed.

 If a media is played on a channel not used in a currently active call, then a temporary

T8110 channel connection is made, in only one direction, to allow the media playout to be audible

77 / 109

Page 78

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-29, Media playout event display

21) When media playout is finished, use the handsets to verify calls continue to function correctly.

22) Measuring CPU usage, open another terminal window (use putty again) and connect to the HW400c/2 board. After you login and get a command-line prompt, enter the command ‘top’. You should see the CPU usage of different processes, shown as a percentage. Figure 4-30 below shows CPU usage by the appTest process as varying from 3 to 4%.

78 / 109

Page 79

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-30, Example of running Linux Top process

23) Use ‘t’ key to tear down calls 1-7 and call 10. Note effects on scope if connected. Verify using handsets that no calls are active (per-Channel loopback state is restored).

24) Press ‘c’ key again to verify no calls are active. Figure 4-31 shows the call list after the calls are tear down.

79 / 109

Page 80

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-31, Call list after call tear down

80 / 109

Page 81

1/27/15 SigC667x / SigC641x User Guide, Rev B7

25) Optional Lab equipment Verification. If a digital scope is connected to the CTBus between the DS3 module and SigC641x modules, then the scope should show a display similar to Figure 4-32 below.

Figure 4-32, Capture of active CTBus data between SigC641x and DS3 modules

26) When necessary, press the ‘q’ key to exit the appTest program.

81 / 109

Page 82

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.4 Texas Instruments Tools Installation

Note 1

This section covers installation of TI Linux command-line tools, which are required for SigC667x systems. For SigC641x systems, TI Code Composer Studio installation is required on a WinXP or Win7/8 system -- see the SigC5x / SigC6x Hardware Reference Guide for more information.

Note 2

If during installation of TI files in “.bin” format you get what looks like an “immediate abort”, i.e. the install doesn’t appear to do or print anything and bounces you back to the command line, you may need to first run one or both of the following apps:

apt-get install ia32-libs (for example if you’re running Ubuntu 12.xx)

apt-get install libc6:i386 (for example if you’re running Ubuntu 14.xx)

This issue can arise since the TI installer doesn't appear to work for some 64-bit Linux distributions, but it will work with correct 32-bit libs installed.

4.4.1 TI Code Generation Tools Download

The first step is to download TI Code Generation tools (commonly referred to as CG Tools). Go to the following page:

https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm

Note that this page requires a log-in and you have to register with TI for an account (if you don’t already have one). For more information, go to this TI page:

http://processors.wiki.ti.com/index.php/Compiler_Releases

Notes about the above page:

1. If you click under “Free Compiler Downloads” (on link labeled “Here”), it will take you to

the CG Tools download page (first link above).

2. You do not need to have Code Composer Studio (CCS) installed.

After you are logged-in, you should see a CG Tools download page similar to Figure 4-33 below.

82 / 109

Page 83

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-33, TI Code Generation Tools download page

83 / 109

Page 84

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.4.2 TI BIOS-MCSDK Download

The second step is to download TI’s BIOS-MCSDK, which will download the following components:

• SYSBIOS (Real-time operating system for TI multicore CPUs)

• IPC (Interprocessor Communication)

• XDCtools (utilities and libraries)

• PDK (Platform Development Kit)

To download BIOS-MCSDK, go to the following page:

http://software-dl.ti.com/sdoemb/sdoemb_public_sw/bios_mcsdk/latest/index_FDS.html

and locate the product download link with the following label:

bios_mcsdk_02_01_02_06_setuplinux.bin

and click on that to start the download. Note that the version number portion of the label will change over time (in the link above, this is v2.01.02.06).

Notes about SYSBIOS, IPC, and XDCtools:

1. The version of SYSBIOS installed should be 6.32.05.54 or higher. The version of XDCtools

installed should be 3.22.04.46 or higher. These version numbers have been tested in Signalogic labs, although older versions may still work.

2. IPC (Interprocessor Communication) is currently not used by DirectCore and CIM software,

but may be in the future. For C667x devices, IPC includes SRIO and HyperLink. The SigC6678 cards have SRIO connections between all C667x devices. SRIO is a fast way to move data between C667x processors. HyperLink is also fast, but connects only pairs of devices together.

3. PDK (Platform Development Kit) is installed with BIOS-MCSDK. PDK is currently used by

DirectCore and CIM software. Also, PDK includes TI’ CSL (Chip Support Library), which is not used currently DirectCore and CIM software, but is likely to be used in the future.

After downloading and installing TI tools as described in preceding sections, you should have a TI software folder hierarchy similar to that shown in Figure 4-34 below. Note that the default location for TI software is the /opt/ti folder, at the same level as /root, /home, etc.

84 / 109

Page 85

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-34, TI software folder hierarchy, including Code Gen tools, SYSBIOS, IPC,

XDCtools, and PDK

85 / 109

Page 86

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.4.3 TI SYSBIOS, IPC, and XDCtools Download

If needed, SYSBIOS, IPC, and XDCtools can be downloaded separately, for example to upgrade one of the components without downloading all of BIOS-MCSDK. To download components separately, go to the following page:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/index.html

Note that currently, PDK can’t be downloaded separately, and must be obtained via BIOSMCSDK download.

86 / 109

Page 87

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.5 RTAF Software Usage

This section covers use of the Real-Time Algorithm Framework (RTAF) software. RTAF software includes the following components and run-time functionality:

• for TI targets, SYSBIOS configuration, including run-time initialization and memory

allocation, timer configuration (OS tick, profile timers, etc)

• CSL, NDK, and other library and initialization

• Run-time initialization, including CPU boot

• Peripheral drivers and interrupt service routines (both hardware and software interrupts)

• Utility functions

• Algorithm functions

• DirectCore properties used for host communication with certain utility and algorithm

functions

• CIM software support

4.5.1 RTAF Configuration Options

The RTAF software build process supports the following pre-processor definitions

Pre-Processor Definition Description

_USE_CM_

_PERIPH_TEST_

_BIOS_

_CIMF

_ANALOG_IO_

_TDM_

_H110_

_USE_PN4_

Enables Call Manager support

Enables POST and other test options for peripherals

Enables SYSBIOS compatibility in the build process

Enables support required for CIM software builds

Enables analog I/O support on SigC641x modules (default peripheral interface is McBSP0)

Enables TDM support on SigC641x modules (default peripheral interface is McBSP1)

Enables H.110 support on SigC641x modules (default peripheral interface is McBSP2)

Enables PN4 connector interface on SigC641x modules

Pre-processor definitions can be set in the CCS project (under Project main menu item, Build Options, Compiler tab), or in Linux command-line build / make files.

87 / 109

Page 88

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.5.2 RTAF Peripheral Support

RTAF supports the following C64x / C66x peripherals:

Peripheral Comments

Host (HPI or PCIe) HPI32 is supported on SigC641x, PCIe is supported on SigC667x

Ethernet If present on the hardware. In the case of SigC667x, the oncard 1

GbE interface is supported, using TI’s NDK and PA (Packet Accelerator) interfaces

McBSP For SigC641x, supports audio/analog I/O, TDM, H.110, and user-

defined interfaces. Not currently supported on SigC667x (Telecom Serial Port, or TSIP, may be supported at a future point)

GPIO Supports both SigC641x and SigC667x

Flash devices Typically connected to EMIFB interface

FPGA Logic If present on the card, for example host / CTBus FPGA on SigC641x

modules

UART If present on the hardware

RS-422 If present on the hardware

4.5.3 RTAF Development and Host Platform Notes

As noted in section 4 above, Software Installation, for SigC667x cards, RTAF software is installed under the mCPU_target folder on Linux systems as shown in Figure 4-35a below.

88 / 109

Page 89

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-35a, RTAF software folder hierarchy for SigC667x cards

For SigC641x modules on Windows systems, target software is handled differently (as explained in section 4 above, Software Installation, with additional explanation below), and RTAF software is installed as shown in Figure 4-35b below.

Figure 4-35b, target software folder hierarchy for SigC641x modules. RTAF software is

included under the C6xxx subfolder

There are a few fundamental points about RTAF development and host platform to keep in mind:

1. RTAF software supports SigC641x modules installed in Linux systems, but SigC641x

RTAF software is not generated or rebuilt on a Linux system. Instead, the software must be maintained on a WinXP or Win7/8 system with Texas Instruments CCS software installed. Conversely, SigC667x RTAF software builds may be handled using CCS software or Texas Instruments command-line code generation tools (TI’s Linux version of CGT). This is one reason why RTAF software installation looks different for C64x vs. C66x based hardware.

89 / 109

Page 90

1/27/15 SigC667x / SigC641x User Guide, Rev B7

2. In Linux systems, RTAF software is stored on the “mCPU_target” subfolder. This naming

convention refers to run-time software for multicore CPU or other target hardware; e.g. CIM accelerator, DSP card, video or telecom card, network processing card, neural net card, etc.

4.5.3.1 Linux Platform Builds

In Linux platform builds, there are two (2) important files:

• Makefile

• cimf_build.lst

The cimf_build.lst file is only used if CIM software is being used by host applications. It’s located in:

/root/Signalogic_2012v4/mCPU_target/C6xxx/BIOS/

Building without CIM

1. First, go to the folder

/root/Signalogic_2012v4/mCPU_target/C6xxx/BIOS/cStandard/

2. Then, use the 'make' command, which invokes the contents of the 'Makefile' file. Note that this file will be overwritten if/when a host-side CIM build script is used.

Building with CIM

To build with CIM host-side software use the CIM script 'cimpp.sh' located in:

/root/Signalogic_2012v4/CIM/cimrt/

The command

./cimpp.sh -h

will display the command line options. An example build command might look like this:

./cimpp.sh -s/root/Signalogic_2012v4/CIM/apps/test/ffmpeg_demo/ -px86 -ati66x -cSIGC66XX fft.c

The file 'template_Makefile' in that directory can be edited for changes to the build.

Makefile Notes

1. ORDERED_OBJS includes any libraries (“lib files”) that need to be linked. More

libraries can be added as needed.

2. CIM_DEFINES are all the preprocessor macro defines used.

3. CIM_INCLUDES are the include directories for the build process.

90 / 109

Page 91

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4. LINKER_INCLUDES are the include directories for the linker process.

There are 3 targets used in the makefile under the '# All Target' comment. The first one can be edited to change the platform used by changing the -p parameter. The second one builds the source files in the cimf_build.lst file. If CIM software is used by host applications then 2 additional source files will be added to the command to be built. The last tool is the linker, which uses ORDERED_OBJS and all the .obj files in the directory:

/root/Signalogic_2012v4/mCPU_target/C6xxx/BIOS/cStandard/

91 / 109

Page 92

1/27/15 SigC667x / SigC641x User Guide, Rev B7

4.6 CIM Software Installation

To install CIM software unzip the sig_sw_host_cim_vNN.rar file. You should see the following

Figure 4-36, CIM host software folder hierarchy, after installation

4.6.1 Running User Programs with CIM

To run user programs with the CIM source code stream generation process, generally follow these guidelines

1) First modify the system PATH environment variable as follows:

export PATH=$PATH:/root/Signalogic_2012v4/CIM/cimrt

this can be done each time the system boots, or made an automatic boot setting inside the shell profile configuration file, for example /etc/profile, etc.

2) cd (change directory) to the folder with your input C source files.

3) Give a command in the following form to run the CIM pre-processor:

cimpp <file1.c> <file2.c> <fileN.c> [-pPlatformType] [-aAccelType] [-cCardType]

where PlatformType, AccelType, and CardType parameters are described in the table below. If no parameters are entered, all output source streams are generated to run on a generic x86

92 / 109

Page 93

1/27/15 SigC667x / SigC641x User Guide, Rev B7

platform with no optimizations. Allowable PlatformType, AccelType, and CardType parameters are listed below:

PlatformType Description Support Status

none x86 + Linux Y

x86 x86 + Linux Y

ARM ARM + Linux N

AccelType Description Support Status

none Plain Intel x86 code, no optimizations Y

x86 Intel x86 with OpenMP, IPP, other optimizations Y

ti64 Texas Instruments C64x N (Partial, but not

supported)

ti66 Texas Instruments C66x Y

CardType Description Support Status

none If not entered, then default CardType containing CPU

matching AccelType is used

SIGC6678 Signalogic 32-core C6678 accelerator Y

SIGC6678-64 Signalogic 64-core C6678 accelerator Y

Note that it's also possible to run the CIM pre-processor from an arbitrary location, for example:

cimpp -s/root/Signalogic_2012v4/CIM/apps/test_demo/ffmpeg_demo/ -px86

-ati66x -cSIGC66XX file1.c file2.c

4.6.2 h264_encode demo

To run the CIM software h264_encode demo, first cd (change directory) to the h264_encode folder:

cd /root/Signalogic_2014v5/CIM/apps/test_demo/h264_encode

Then enter

cimpp -px86 -ati66x -cSIGC66XX h264_encode.c

cimpp.sh -px86 -ati66x -cSIGC66XX h264_encode.c

h264_encode CIM Build Description

Figures 4-37a-c below show expected output during the CIM build process for h264_encode.

93 / 109

Page 94

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-37a, h264_encode CIM build process output display

94 / 109

Page 95

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-37b, h264_encode CIM build process output display, cont.

95 / 109

Page 96

1/27/15 SigC667x / SigC641x User Guide, Rev B7

Figure 4-37c, h264_encode CIM build process output display, cont.

After the CIM build process completes, the h264_encode executable file will be created, and can be run as a typical Linux program:

./h264_encode

which should produce screen display output similar to Figure 4-38 below.

96 / 109

Page 97

1/27/15 SigC667x / SigC641x User Guide, Rev B7

h264_encode$ ./h264_encode DSInitCores: qwCoreList = 0xff SlotIndx = 0 Card_Type 0x8106 Talker not used DSXInitCard SigC66x ds66xInitCard: InitCardT50 success DSXInitCard Successful! Loading input video .yuv data... Clearing output video mem region... Loading cores, core list = 0xff DDR3 Time lapsed in microseconds : count 11878204 12 L2SRAM Time lapsed in microseconds : count 920 8 MSMCSRAM Time lapsed in microseconds : count 740 11 DSXRunCard Successful! Core 1 Finished Core 2 Finished Core 3 Finished Core 4 Finished Core 5 Finished Core 6 Finished Core 7 Finished Core 0 Finished Reading output video data, saving to file... C66x testrun[0, 0x85f95c] = 9003 C66x cores error code[0x85ec28] = 0 numFramesEncoded[0x8597b4] = 40 h264_encode$

Figure 4-38, h264_encode demo output display.

Note that on the h264_encode folder, only the files h264_encode.c, zero.dat, and any .yuv (video input data) are required. Except for the "encoded.h264" output file, which is created when h264_encode demo executable code is run (as shown in Figure 4-38 above), all other files on the h264_encode folder are auto-generated by the CIM build process.

97 / 109

Page 98

1/27/15 SigC667x / SigC641x User Guide, Rev B7

5 pn4Test Host Program

Note

This section only applies to SigC641x DSP systems.

The pn4Test host program controls and tests the McBSP1 and GPIO devices on the selected DSPs. During pn4Test operation, data is transmitted and received between selected DSPs, and real-time results are displayed in a Linux terminal window.

To build pn4Test, enter:

#cd .. /SigC641x/apps/SigC64x/pn4Test

#make

Running pn4Test with the command

./pn4Test –h

will list the available command line options noting which options are mandatory for running pn4Test with a “+” sign. Supported command line options are listed below:

0 – Detail display is disabled.

1 – Probe counters for each time the specified ISR (GPIO, TX, or RX) is entered are displayed on each display updated.

2 – FPGA revision numbers and memory symbol addresses are displayed once. Sync data for MCBSP and MCBSP_GPIO test modes is displayed once. A message indicating a signal was received with the DSP number that HINT was generated on is displayed each time the signal handler runs.

-d<0…2>

-f<N>

-m<bitmask>

Sets the processor clock rate in MHz. (e.g.

Sets the processor select bit mask. Values can be entered in decimal or hex (e.g.

–m17

0-3) and only one DSP from group B (DSPs 4-7) should be selected for testing. If other settings are used, the first DSP from each group will be used, but the data display may not reflect the desired testing mode.

-e<DSP COFF file name>

-c<designator>

-M<Test Mode>

Sets card designator (e.g. Available options are listed below

is equivalent to

(e.g.

-etmsc64xx_rtaf_ccs3.out

–f720 or -f1000

–m0x11

). Only one DSP from group A (DSPs

-cSIGC64XX

)

98 / 109

Page 99

1/27/15 SigC667x / SigC641x User Guide, Rev B7

MCBSP – Test only the serial mode sides of McBSP1 in serial mode

UART – Test only the serial mode sides of McBSP1 in UART mode

GPIO – Test only the GPIO sides of McBSP1

MCBSP_GPIO – Test MCBSP and GPIO modes concurrently

UART_GPIO – Test UART and GPIO modes concurrently

Ctrl” register in FPGA #2. Takes a 32 bit value (e.g.

-r<Routing Config>

Routing configuration in FPGA logic. Sets the “PN4-McBSP

–r0x300

, the default value)

with the following bit definitions:

31-11 Reserved

10 Group B Strobe Trigger Routing 0 = rev 2.4a 1 = rev 2.4b

9 PN4_FSX1_B direction 0 = output to PN4 1 = input from PN4

8 PN4_CLKX1_B direction 0 = output to PN4 1 = input from PN4

2 Group A Strobe Trigger Routing 0 = rev 2.4a 1 = rev 2.4b

1 PN4_FSX1_A direction 0 = output to PN4 1 = input from PN4

0 PN4_CLKX1_A direction 0 = output to PN4 1 = input from PN4

Note revision numbers and signal names (e.g. PN4_FSX1_B) are based on specifications shown in Figures 6-1 and 6-2, in section 5 below, “pn4Test Theory of Operation”.

99 / 109

Page 100

1/27/15 SigC667x / SigC641x User Guide, Rev B7

After entering the mandatory command line options and running pn4Test, the entered options are echoed back to the terminal display. DSP, FPGA and on-chip memory tests are then run and DSPs are reset. Next, the SDRAM on each selected DSP is checked and results are displayed. Figure 5-1 below shows an example command line input followed by the first set of display and the SDRAM test results for DSP 0. This was run with the command:

# ./pn4Test –m0x11 –f1000 -etmsc64xx_rtaf_ccs3.out -cSIGC64XX –r0x300 –MGPIO –d2

Figure 5-1, pn4Test initial display

100 / 109

Signalogic SigC667x, SigC641x User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual