Video Over IP Reference Design

Version 1.3, October 2005

Application Note 374

Introduction

The Altera® video over IP reference design demonstrates transmission of MPEG-2 transport stream (TS) data over internet protocol (IP)-based networks. The reference design bridges between one or more compressed video streams and IP packets carried over 100 megabits per second (Mbps) or 1 gigabit per second (Gbps) Ethernet. The reference design accepts TS data and encapsulates it for transmission over Ethernet. The design can also receive frames from Ethernet and generate TS data. The TS interface supports 188 and 204 byte packets as standardized for Digital Video Broadcasting (DVB) MPEG-2 transport. The reference design supports both multi-program TS (MPTS) and single-program TS (SPTS) data. The reference design does not make any attempt to identify or separate individual programs from an MPTS input. The Altera Asynchronous Serial Interface (ASI) Reference Design can connect the TS interface to a DVB-ASI.

f

For more information on the Asynchronous Serial Interface (ASI) Reference Design, see AN344: Asynchronous Serial Interface (ASI) Reference Design. Encapsulation of the TS data for Ethernet uses IP and the user datagram protocol (UDP). The real-time transport protocol (RTP) can also optionally be used. Dedicated hardware performs the encapsulation, which maximizes the throughput of the reference design and minimizes latency. Frames can be processed, transmitted, and received at the Ethernet line rate, which supports an aggregate TS bandwidth of over 900 Mbps for a gigabit Ethernet link. For multiple TS interfaces, the reference design individually maps each one to a specific UDP/IP socket (combination of IP address and UDP port). All other encapsulation parameters can also be individually configured per TS. The reference design supports IP multicast. The reference design includes a Nios® II processor. Software running on the processor configures the operation of the reference design and handles any Ethernet management traffic.

Altera Corporation AN-374-1.3

1 Preliminary

Video Over IP Reference Design

Specifications & Standards

Many standards and industry specifications have been referenced in creating this reference design. These standards are summarized in this section.

DVB-ASI
The DVB Project defined an ASI for the transmission of MPEG-2 TS data. It is specified by European Standard EN 50083-9. ASI is a 270-Mbps serial link that carries 188 or 204 byte MPEG-2 TS packets over a physical and signalling interface layer based on fibre channel. One or more programs can be carried over a single ASI. 8B/10B coding maintains a DC balance and supports self checking and byte synchronization of the link. Comma characters match the bit rate of the MPEG-2 packets to the fixed serial bit rate of the link. Altera has a reference design for ASI.

f

For more information on the Asynchronous Serial Interface (ASI) Reference Design, see AN344: Asynchronous Serial Interface (ASI) Reference Design.

Real-Time Transport Protocol
The Internet Engineering Task Force (IETF) has an Audio/Video transport (avt) Working Group that has defined a protocol for real-time transmission of audio and video over IP. This protocol is the real-time transport protocol (RTP). RTP is primarily aimed at the distribution of audio and video over the internet for applications such as video conferencing and video streaming. However, this protocol is also useful for the distribution of video over Ethernet in the more controlled environment of a broadcast facility. RTP offers features for time stamping and detection of packet loss or reordering. RTP is defined in the request for comments (RFC) document RFC3350. It was approved as a full standard by the IETF Internet Engineering Steering Group (IESG) in May 2004. The avt Working Group are also developing a number of supporting standards for payload formats, error correction, security etc.

2 Preliminary

Altera Corporation

Specifications & Standards

RTP Payload Format for MPEG1/MPEG2 Video
RTP is a generic protocol suitable for a wide variety of transport applications. It is extended by a number of additional specifications targeted at more specific applications. RFC2250 defines an RTP payload format for MPEG-1 and MPEG-2 video. It includes details for the encapsulation of MPEG-2 TS data, and is referenced by the Pro-MPEG code of practice #3 and the DVB-IP Handbook.

UDP/IP
RTP is a transport protocol. Most commonly, it uses UDP as the host-tohost layer and IP as the internet layer. Unlike the transmission control protocol (TCP), UDP is not connection oriented and offers no facilities for sequencing data or guaranteeing reliable packet delivery. This feature makes it faster, simpler and more efficient than TCP, and therefore more suitable for high bandwidth video distribution when combined with RTP. It is defined by IETF RFC768. IP is the standard internet layer. It is defined by IETF RFC791.

Pro-MPEG Code of Practice #3
The Pro-MPEG Forum is an association of broadcasters and program makers, equipment manufacturers and component suppliers with interests in realizing interoperability of professional television equipment, according to the implementation requirements of broadcasters and other end-users. The Pro-MPEG Wide Area Network (WAN) working group is focused on establishing interoperability practices for systems that provide for the exchange of high-quality programme material over wide area networks using IP. This group has produced a code of practice for the transmission of professional MPEG-2 TS data over IP networks. The code of practice recommends the transmission protocol (e.g., RTP/UDP/IP mapping), a forward error correction (FEC) scheme, and also discusses issues such as timing recovery, jitter tolerance and latency. The recommendations for the transmission protocol have been followed for this reference design, although the use of RTP has been made optional to support legacy standards based just on UDP/IP.

Altera Corporation

3 Preliminary

Video Over IP Reference Design

DVB-IPI
There is a DVB IP Infrastructure (IPI) group that is defining technology for the distribution of DVB services over IP. This is primarily targeted at direct-to-home (DTH) content delivery, but some of the work is also applicable to contribution and primary distribution applications. Phase 1 of the DVB-IP Handbook is complete and includes a chapter on the transport of MPEG-2 over IP. The content was taken from IPI2001-016. The standard specifies the use of RTP/UDP/IP encapsulation. FEC is optional.

Overview

The reference design accepts TS data and encapsulates it for transmission over Ethernet. This function is a TS-to-Ethernet bridge (see Figure 1).

Figure 1. TS-to-Ethernet Bridge
TS Input FIFO Buffer FIFO Buffer TS Input DMA

Frame Buffer Transmit Channel Info

FIFO Buffer

Transmit Queue Host Transmit Queue Host Receive Queue

Transmit DMA Receive DMA

Encapsulate MII/ GMII PHY

4 Preliminary

Altera Corporation

Overview

The design can also receive frames from Ethernet and generate TS data. This function is an Ethernet-to-TS Bridge (see Figure 2). Figure 2. Ethernet-to-TS Bridge
TS Output FIFO Buffer FIFO Buffer TS Output DMA

Frame Buffer Receive Channel Info

FIFO Buffer

Receive Queue Host Receive Queue Host Transmit Queue

Receive DMA Transmit DMA

De-encapsulate MII/ PHY GMII

Typically the reference design is configured as either a TS-to-Ethernet bridge, or as an Ethernet-to-TS bridge. However, the reference design can perform both operations simultaneously. The reference design performs the following four main functions:
■ ■ ■ ■

Encapsulation of TS input and transmission to Ethernet; Reception of encapsulated data from Ethernet and generation of TS output Host packet transmission to Ethernet Host packet reception from Ethernet

Each of these functions is now described.

f

For a detailed description of each reference design element, see “Functional Description” on page 16.

Altera Corporation

5 Preliminary

Video Over IP Reference Design

TS-to-Ethernet
Figure 3 shows the data flow for TS-to-Ethernet. Figure 3. Data Flow for TS-to-Ethernet
TS Inputs FIFO Buffer FIFO Buffer TS Input DMA Payload Frame Buffer Pointer Payload Transmit Queue Free List Pointer Transmit DMA Encapsulate Transmit Channel Info MII/ GMII PHY

FIFO Buffer

The reference design accepts TS data from a configurable number of input ports. Each port accepts parallel 8-bit data and supports both 188 and 204 byte packets. The received TS packets are accumulated to create the payload for the Ethernet frames. Typically seven packets from an individual input port are combined to make the payload for a single Ethernet frame, although this number is configurable. Data from separate ports is always treated separately so any individual Ethernet frame only contains packets from one individual input port. The Ethernet frame always contains an integer number of TS packets. The frame buffer module provides storage for the Ethernet frame payload for multiple input ports. A pointer identifies an individual frame storage location within the frame buffer. Pointer value 0 identifies the first location, pointer value 1 identifies the second location, etc. A list of pointers to free locations is maintained by a stack. This stack is referred to as the buffer free list. Before an input port can accept data, it requests a pointer from the buffer free list. Data is then received, retimed through a FIFO buffer, and written to the frame store location in the frame buffer that corresponds to the allocated pointer.

6 Preliminary

Altera Corporation

Overview

When enough TS data has been accumulated to fill an Ethernet frame, the payload length and input port identifier (channel number) are written to a special location (parameter word) in the frame buffer. An entry is then made to the transmit queue to indicate that the payload is ready for encapsulation and transmission to Ethernet. The only data required by the queue is the allocated pointer. Figure 4 shows the TS input logic flow diagram. Figure 4. TS Input Logic Flow Diagram

Fetch Pointer from Buffer Free List

Accumulate Data for Ethernet Frame & Store in Allocated Location in Frame Buffer

Store Payload Length and Channel Number

Load Pointer to Transmit Queue

If there are multiple TS input ports, each one performs the operations. At any point in time, multiple inputs may be simultaneously writing to the frame buffer and queuing transmit requests. The reference design includes arbitration to handle this situation. 1 There is only one transmit queue, which is shared by all the TS input ports.

The transmit queue is monitored to detect when there is an entry. This indicates a transmit request is pending. The transmit queue is a FIFO buffer so the first entry loaded to the queue is always the first entry processed. When there is an entry in the transmit queue, the first pointer is read. This provides the location in the frame buffer where the Ethernet frame payload is stored. Next, the parameter word for the location is read to

Altera Corporation

7 Preliminary

Video Over IP Reference Design

determine which input port the data came from, and what the payload length is. The frame payload is then read and forwarded to the Ethernet encapsulator. The encapsulator adds the required Ethernet frame headers to the payload to correctly format the data for output. The encapsulation type and header parameters are read from the transmit channel information block. Each individual TS input has its own set of encapsulation parameters. This situation ensures that all data from a single TS input port is always encapsulated in the same way, and also allows for each separate TS input to be routed to its own individual IP destination. Figure 5 shows the encapsulated frame for Ethernet. Figure 5. Encapsulated Frame for Ethernet
MAC IP UDP RTP (optional) Inserted by Encapsulator Read from Frame Buffer Inserted by Encapsulator Payload FCS

The complete Ethernet frame is passed to the physical layer (PHY) device using a media independent interface (MII) or Gigabit MII (GMII). When transmission of the frame is complete, the pointer is released back to the buffer free list. This action releases the location in the frame buffer for use by another frame. Figure 6 shows the Ethernet output flow diagram.

8 Preliminary

Altera Corporation

Overview

Figure 6. Ethernet Output Flow Diagram

Fetch Pointer from Transmit Queue

Read Payload Length & Channel Number from Parameter Word

Read Payload Data from Frame Buffer & Forward to Encapsulator

Add Appropriate Header Using Data from Transmit Channel Info Block

Send Ethernet Frame to PHY for Transmission

Release Pointer to Buffer Free List

Altera Corporation

9 Preliminary

Video Over IP Reference Design

Ethernet-to-TS
Figure 7 shows data flow for Ethernet-to-TS. Figure 7. Data Flow for Ethernet-to-TS
TS Output FIFO Buffer FIFO Buffer TS Output DMA

Frame Buffer Receive Channel Info

FIFO Buffer

Receive Queue Free List

Receive DMA

MII/ GMII De-encapsulate PHY

Ethernet frames are received from the PHY device using MII or GMII. All frames forwarded by the PHY are parsed by the de-encapsulator. This block identifies key parameters such as IP destination address and UDP source and destination ports. It also identifies frames that contain correctly encapsulated video data. The time that the start of frame was received is also noted (timestamp). The receive channel information block analyzes the parameters extracted by the de-encapsulator and decides where to route the data from the received frame. If the frame contains video data, the receive channel information block determines the output to where it routes the video data. Typically, this routing is achieved by matching the IP address and UDP destination port. Each receive channel can have its own IP address and UDP destination port. IP multicast is supported. The receive DMA block requests a pointer from the buffer free list. The received Ethernet frame data is then written to the allocated location in the frame buffer. When storage of the frame is complete, the receive DMA stores the frame length, start of payload offset (for video frames) and timestamp. It then loads the appropriate receive queue (for video frames), host receive queue (for frames being routed to the host), or discards the frame by releasing the allocated pointer. Figure 8 shows the Ethernet input flow diagram.

10 Preliminary

Altera Corporation

Overview

Figure 8. Ethernet Input Flow Diagram

Fetch Pointer from Buffer Free List

Receive Data from Ethernet & Store in Allocated Location in Frame Buffer

When Receiving the Frame, Parse to Extract Critical Parameters (e.g., IP Address, UDP Port)

Match the Extracted Parameters to Identify Destination (TS Output, Host, or Discard)

At End of Frame, Store Length & Timestamp in Frame Buffer

Queue Pointer to Appropriate Receive Queue (TS Output or Host) or Discard by Releasing to Free List

Each TS output port has its own receive queue. Whenever there is an entry in the related queue, the port fetches the head entry to get the pointer to the related data in the frame buffer. It then reads the frame parameters (length and start of payload offset) for that pointer from the frame buffer. The frame payload for the received frame is read from the frame buffer and written to a FIFO buffer. The TS output reads from this FIFO buffer and generates the output data. A minimum inter-packet gap is inserted between individual packets in the output. A more complex mechanism for averaging the output rate of the packets, or for correcting errors in the PCR packet locations or timestamp, is possible but is not implemented in this reference design. When all the data for the received frame has been read from the frame buffer, the pointer is released to the buffer free list. Figure 9 shows the TS output flow diagram.
Altera Corporation 11 Preliminary

Video Over IP Reference Design

Figure 9. TS Output Flow Diagram

Fetch Pointer from Receive Queue

Read Payload Length & Offset from Parameter Word

Read Payload Data from Frame Buffer & Forward to Output FIFO Buffer

Read Data from FIFO Buffer & Output as Transport Stream

Release Pointer to Buffer Free List

12 Preliminary

Altera Corporation

Overview

Host Packet Transmission
Figure 10 shows the data flow for host transmit. Figure 10. Data Flow for Host Transmit
Configure 1 Payload 3 Host Interface Payload Pointer Transmit DMA Encapsulate Frame Buffer Transmit Channel Info MII/ GMII PHY

Pointer 4

Host Transmit Queue Free List

2 Pointer 6 5 Done Flag

The host processor uses the same mechanism to transmit frames to Ethernet as it uses for data from the TS inputs. A pointer is requested from the buffer free list. The frame data is then written to the allocated location in the frame buffer. The length and channel number are written to the parameter word for the buffer location. Finally a transmit request is loaded to the host transmit queue. The host has its own transmit queue to prevent its requests being stuck behind those from the input ports. However the data path from the frame buffer to the Ethernet output is the same as that used for TS data. Packets sent by the host can be treated in the same way as those from the TS input ports, with an Ethernet frame header being added by the encapsulator, or the packets can just be sent out directly without any modification. By using the encapsulator, the host can off load to hardware operations such as the IP header checksum calculation. If the encapsulator is used, the host has to configure a specific channel in the transmit channel information block, thereby setting the encapsulation parameters, before sending the frame. When the host frame has been sent, the related pointer can either be automatically released to the buffer free list, or the host can be informed that the transmission is complete and then it can release (or reuse) the pointer. Figure 11 shows the host transmit flow diagram.

Altera Corporation

13 Preliminary

Video Over IP Reference Design

Figure 11. Host Transmit Flow Diagram
Initialize the host Transmit Channel

Fetch pointer from Buffer Free List

Write frame data to allocated location in Frame Buffer

Write frame length to Parameter Word

Optionally configure the host Transmit Channel encapsulation parameters

Load pointer to Host Transmit Queue

Yes

AutoRelease No

Wait for transmit to complete

Another Frame No

Yes

Return pointer to Buffer Free List

14 Preliminary

Altera Corporation

Overview

Host Packet Reception
Figure 12 shows the data flow for host receive. Figure 12. Data Flow for Host Receive
Payload Frame Buffer Receive Channel Info Host Interface Interrupt/ Flag 1 2 Pointer Pointer 4 Receive DMA De-encapsulate MII/ GMII PHY

3

Host Receive Queue Free List

Ethernet frames that are received and address matched but not matched for forwarding to a TS output are routed to the host processor. There is a dedicated host receive queue that is loaded with an entry when one of these frames is received. The host can poll the host receive queue to see if there is an entry, or it can receive an interrupt. The receive frame is processed by reading the entry from the host receive queue to get the pointer to the frame location in the frame buffer. The frame length and content are then read from the frame buffer. When the frame has been processed, the pointer is released to the buffer free list. Alternatively the pointer can be used for a host transmit, such as when a reply to a received message might be required. Figure 13 shows the host receive flow diagram.

Altera Corporation

15 Preliminary

Video Over IP Reference Design

Figure 13. Host Receive Flow Diagram

Poll Host Receive Queue or wait for Interrupt

Read Pointer from Host Receive Queue

Read Payload Length from Paramter Word of Allocated Location in Frame Buffer

Read Payload Data from Frame Buffer & Process

Release Pointer to Buffer Free List or Reuse for Host Transmit

Functional Description

This section provides a detailed functional description of the main components of the reference design. The reference design is partitioned in to the following three top-level elements:
■ ■ ■

Nios II processor system Ethernet-PHY interface TS-to-Ethernet bridge

16 Preliminary

Altera Corporation

Functional Description

Figure 14 shows the top-level partitioning. Figure 14. Top-Level Partitioning
Nios Processor System

MII/ GMII TS Interfaces TS-to-Ethernet Bridge Ethernet-PHY Interface

Altera supplies an example Nios II processor system as part of the reference design. You may replace this system by a different system, or an external processor interface. The TS-to-Ethernet bridge provides the interface between the TS ports and the Ethernet-PHY interface.

Clock
The reference design has the following three main clock domains:
■ ■ ■

TS interface clock Host processor clock Main system clock

The TS interface clock is typically 27 MHz, but can be any rate required and does not have to be synchronous to other clocks in the design. The host processor clock is constrained by the speed of the processor and its system. It does not have to be synchronous to other clocks in the design. The reference design uses a frequency of 50 MHz for Cyclone devices and 85 MHz for Cyclone II devices. The speed of the main system clock is constrained by the Ethernet data rate and the bandwidth required by the TS interfaces. For gigabit Ethernet operation, the system clock must be 125 MHz.

Altera Corporation

17 Preliminary

Video Over IP Reference Design

For 100 MHz Ethernet operation, a lower frequency system clock can be used. The exact frequency required depends upon the number of TS interfaces implemented by the design, and the data bandwidth used by each port. For simplicity, this reference design uses 125 MHz for the system clock regardless of the Ethernet rate that is supported.

Processor System
The reference design uses an SOPC Builder-generated processor system. It consists of a Nios II processor and the following associated peripherals and memory interfaces:
■ ■ ■ ■ ■ ■ ■

Flash interface SDRAM controller and interface SRAM interface Timer peripheral JTAG UART peripheral LCD controller Various parallel IOs for LED control and switch inputs

The TS-to-Ethernet bridge and Ethernet-PHY interface are not instantiated in the SOPC Builder-generated system. They are implemented as external components using the Interface to User Logic option.

f

For details on how to configure and generate this processor system using SOPC Builder, see “Getting Started” on page 34.

Ethernet-PHY Interface
The Ethernet-PHY interface provides the interface between the TS-toEthernet bridge and an external Ethernet PHY device. It provides an MII and GMII connection to the PHY device, plus MDIO for control purposes. It uses a FIFO interface to the TS-to-Ethernet bridge, which is based on the Altera Atlantic™ interface. The reference design requires the Ethernet connection to operate in full-duplex mode; half-duplex operation is not supported.

f

For more information on the Atlantic interface, see FS13: The Atlantic Interface. You can implement the Ethernet-PHY interface using a MorethanIP 10/100/1000 Ethernet MAC core, or using the reference design-provided modules. 1 If you use the reference design modules, the MAC functionality is implemented as part of the TS-to-Ethernet bridge.

18 Preliminary

Altera Corporation

Functional Description

The reference design MAC functionality provides a limited subset of the MorethanIP core MAC implementation and has the following restrictions:
■ ■ ■ ■

Full duplex 100 megabit and gigabit operation only No pause frame support No hardware padding for short frames Limited statistics counters

f

For details on how to configure the MorethanIP MAC core for use in this design, see “Getting Started” on page 34.

TS-to-Ethernet Bridge
The TS-to-Ethernet bridge instantiates the following modules to provide the main functionality of the design:
■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■ ■

Host processor interface TS input logic TS output logic Frame buffer Queue system Ethernet transmit DMA Ethernet receive DMA Encapsulator De-encapsulator Transmit channel information Receive channel information Timestamp

It has the following external interfaces:
■ ■ ■ ■

TS input interface TS output interface MAC interface Host processor interface

TS Input Interface
The TS input interface supports a configurable number of TS inputs. Each of these inputs accepts either 188 or 204 byte TS packets. Data from the interface is encapsulated and sent to an IP destination specified for that interface. The Atlantic-based TS input interface consists of an 8-bit data bus, data valid strobe, start of packet flag, end of packet flag, and lock status indication.

Altera Corporation

19 Preliminary

Video Over IP Reference Design

f

For more information on the Altera Atlantic™ interface, see FS 13: Atlantic Interface. There is a bus for each signal. Table 1 shows the TS input interface.

Table 1. TS Input Interface Signal
ts_in_clk ts_in_dav[i] ts_in_ena[i] ts_in_dat[(i×8)+7:i×8] ts_in_sop[i] ts_in_eop[i]

Note (1) Direction
Input Output Input Input Input Input Clock, common to all inputs. Data input enable. Data valid. Assert for one clock cycle for each valid data byte, provided ts_in_dav[i] is high. Data. Start of packet. Assert to accompany first byte of packet. End of packet. Assert to accompany last byte of packet. Lock status (00 = unlocked, 11 = 188-byte packets, and 01 = 204-byte packets).

Use

ts_in_lock[(i×2)+1:i×2] Input
Note to Table 1:
(1)

i is the port number, e.g., ts_in_ena[1] is data valid signal for port 1 and ts_in_dat[15:8] is its associated data.

The design does not handle packet errors. Only provide complete, legal packets to the interface. If errors are likely to occur, implement an external buffer to discard any errors packets. If the TS input is not required, tie the input signals identified above to logic 0.

TS Output Interface
The TS output interface supports a configurable number of TS outputs. TS data received from Ethernet is output on this interface, and the output selection is determined by the encapsulation parameters of the received frame. The data is output in 188 or 204 byte packet format, depending on the size of packet received. Typically, seven consecutive packets are output, with a minimum interpacket gap between them. For this design, no attempt is made to smooth the rate of the output, or to correct any jitter introduced by the IP network. The Atlantic-based TS output interface consists of an enable, 8-bit data bus, data valid strobe, start of packet flag, and end of packet flag.

20 Preliminary

Altera Corporation

Functional Description

f

For more information on the Altera Atlantic™ interface, see FS 13: Atlantic Interface. There is a bus for each signal. Table 2 shows the TS output interface.

Table 2. TS Output Interface Signal
ts_out_clk ts_out_dav[i] ts_out_ena[i]

Note (1) Direction
Input Input Output Clock. Enable. Data is not output when low. Data valid. Asserted for one clock cycle for each valid data byte. Data. Start of packet. Asserted to accompany first byte of packet. End of packet. Asserted to accompany last byte of packet.

Use

ts_out_dat[(i*8)+7:i*8] Output ts_out_sop[i] ts_out_eop[i]
Note to Table 2:
(1)

Output Output

i is the port number, e.g., ts_out_ena[1] is data valid signal for port 1 and ts_out_dat[15:8] is its associated data.

If the TS output is not required, tie the input signals identified above to logic 0.

MAC Interface
The MAC transmit interface sends encapsulated TS data or frames generated by the host processor to the Ethernet-PHY interface. Received Ethernet frames are input on the MAC receive port.

Altera Corporation

21 Preliminary

Video Over IP Reference Design

Both ports run synchronous to the main system clock. The Ethernet-PHY interface retimes these signals to the appropriate PHY clock domains if necessary. Table 3 shows the MAC interface.

Table 3. MAC Interface Signal
mac_tx_dav mac_tx_ena mac_tx_dat[7:0] mac_tx_sop mac_tx_eop mac_rx_ena mac_rx_dat[7:0] mac_rx_sop mac_rx_eop mac_rx_err mac_rx_err_stat[3:0]

Direction
Input Output Output Output Output Input Input Input Input Input Input

Use
Transmit data enable from the Ethernet-PHY interface. Transmit data valid. Transmit data. Transmit start of packet flag. Transmit end of packet flag. Receive data valid. Receive data. Receive start of packet flag. Receive end of packet flag. Receive error flag. Receive error code.

Host Processor Interface
Each design element has its own Avalon™ slave interface for register access. These Avalon slave interfaces are connected to the host processor interface by the Avalon system module.

22 Preliminary

Altera Corporation

Functional Description

TS Input Logic
The base address offset is 0x1140. Table 4 shows the TS input logic registers.

Table 4. TS Input Logic Registers Address
0 1 2 3

Access
R/W R/W R/W R W Port select.

Register Use
Enable for selected port (1 to enable). Channel number for selected port. [1:0] lock status for selected port. [2:0] the number of TS packets per Ethernet frame. [19:0] Estimated bits per second for selected port. [2:0] Number of TS packets encapsulated per Ethernet frame (between 1 and 7). Reserved.

4 5 7:6

R R/W –

The channel number identifies the encapsulation parameters that will be associated with the input port. Altera suggests that input port 0 is allocated channel number 1, input port 1 is allocated channel number 2, etc. You can then use channel number 0 for host transmit purposes.

TS Output Logic
The base address offset is 0x1160. Table 5 shows the TS output logic registers.

Table 5. TS Output Logic Registers Address
0 1 2 7:3

Access
R/W R R – Port select.

Register Use
[1:0] lock status for selected port. [19:0] Estimated bits per second for selected port. Reserved.

Altera Corporation

23 Preliminary

Video Over IP Reference Design

Frame Buffer
The base address offset is 0x0000. Table 6 shows the frame buffer registers

Table 6. Frame Buffer Registers Address
381:0 382 383 511 893:512 894 895 1023

Access
R/W R R/W W R/W R R/W W

Register Use
Frame data for first pointer. Timestamp (for received frames only). Frame parameters (length, receive error flags). Pointer selection (first pointer). Frame data for second pointer. Timestamp (for received frames only). Frame parameters (length, receive error flags). Pointer selection (second pointer).

To access the data relating to a specific frame, write the buffer pointer value to the pointer selection register. The frame content is then directly addressable from the associated frame data locations. The register provides two separate pointer selection and frame data locations to allow re-entrancy issues to be avoided when processing receive traffic and transmit traffic in different software threads.

24 Preliminary

Altera Corporation

Functional Description

Queue System
The base address offset is 0x1100. Table 7 shows the queue system registers.

Table 7. Queue System Registers Address
0 1

Access
R/W R/W R

Register Use
Queue select (0 = free list; 1 = host receive; 2 = host transmit). [n:0] pointer. [31] set if the pointer is read from an empty queue. Queue level for selected queue. [0] host release mode (0 = buffer automatically released after transmit; 1 = buffer not released after transmit [default]). [1] Host override mode (1 to allow host to use TS queues, 0 by default). [31] host transmit status (1 = transmit in progress). [0] Interrupt enable for host receive (1 to enable, 0 by default)

2 3

R R/W

R/W R 10 R/W

Table 8 shows additional registers that are defined to give direct access to specific queues without having to first select the queue using the queue select register. 1 Accessing any of these registers changes the value stored in the queue select register.

Table 8. Additional Queue System Registers (Part 1 of 2) Address
4

Access
W R R

Register Use
[n:0] Pointer for writing to the free list queue. [n:0] pointer read from the free list queue. [31] set if pointer read when the queue is empty. Queue level for the free list queue. [n:0] pointer read from the host receive queue. [31] Set if the pointer read when the queue is empty. Queue level for the host receive queue.

5 6

R R R

7

R

Altera Corporation

25 Preliminary

Video Over IP Reference Design

Table 8. Additional Queue System Registers (Part 2 of 2) Address
8 9

Access
W R

Register Use
[n:0] pointer for writing to the host transmit queue. Queue level (number of entries) for the host transmit queue.

Free List Initialization The host processor initializes the queue system by writing buffer pointers to the free list. To initialize the queue system, write incrementing buffer pointer values to the free list queue. When done, read the free list queue level to check the number of entries in the free list. Host Transmit To transmit an Ethernet frame, request a buffer pointer from the free list by reading from the free list queue. A negative value is returned if no pointers are available. When the frame payload and length have been written to the frame buffer, generate a transmit request by writing the buffer pointer to the host transmit queue. You may read the host transmit status bit to determine when the transmission has completed. If the host release mode is not set to auto release, manually return the buffer pointer to the free list when the transmission is complete. If the host release mode is set to auto release, the design automatically releases the pointer to the free list when the transmission is complete. In this mode, the host does not need to poll the transmission status flag. Host Receive The host processor can either poll the host receive queue level to determine when an Ethernet frame has been received for processing, or it can receive an interrupt. To use the interrupt, clear the interrupt mask bit. The queue system interrupt flag to the processor is then asserted whenever the host receive queue is not empty. If the mask bit is set, the interrupt flag is negated regardless of the level of the host receive queue. When there is an entry in the host receive queue, read the buffer pointer value from the queue. After the received frame has been processed, release the buffer pointer to the free list.

26 Preliminary

Altera Corporation

Functional Description

De-Encapsulator
The base address offset is 0x11B0. Table 9 shows the de-encapsulator registers.

Table 9. De-encapsulator Registers Address
0 3:1

Access
R/W – Reserved.

Register Use
[0] assert to enable RTP support.

Transmit Channel Information
The base address offset is 0x1000. Table 10 shows the transmit channel registers.

Table 10. Transmit Channel Registers Address
0 1 2 3 4 9:4 10 11 15:12 19:16 21:20 23:22 27:24 31:28 32

Access
R/W R/W – – R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W R/W

Register Use
[2:0] encapsulation type (000 = none, 001 = IP only, 011 = UDP/IP, 111 = RTP/UDP/IP). Fixed value of 0x11 required for IP encapsulation Reserved. Reserved. Virtual LAN (VLAN) field enable. MAC destination address. IP type of service (TOS) field. IP time To live (TTL) field. IP source address. IP destination address. UDP source port. UDP destination port. MAC VLAN field. RTP synchronization source (SSRC) field. Channel select.

To set the encapsulation parameters for a specific channel, select the channel by writing to the channel select register, then write the parameters using offsets 0 to 31.

Altera Corporation

27 Preliminary

Video Over IP Reference Design

Receive Channel Information
The base address offset is 0x1180. Table 11 shows the receive channel registers.

Table 11. Receive Channel Registers Address
0 1 2 3 4

Access
R/W R/W R/W R/W R/W R/W MAC address [31:0]. MAC address [47:32]. IP address. IP subnet mask.

Register Use

[0] set to check IP address for host receive frames [1] set to match MAC multicast frames for host. Port select. [15:0] UDP destination port for selected channel. [31:0] IP destination address for selected channel.

5 6 7

R/W R/W R/W

To set the UDP destination port for a specific TS output, write the port number of the TS output to the port select register, then write the UDP destination port number to the UDP destination port register. Write the enable bit to enable the matcher.

Statistics
The base address offset is 0x1200. All read only. Table 12 shows the statistics registers.

Table 12. Statistics Registers Address
0 1 2 3 4 5 6 7

Access
R R R R R R R R

Register Use
Frames received and matched for host. Errored frames received. Frames received with format not recognized by the deencapsulator. Frames discarded due to lack of buffers. Host frames discarded due to lack of buffers. Frames received and discarded. Frames sent by the host. Frames transmitted from TS input 0.

28 Preliminary

Altera Corporation

Functional Description

Table 12. Statistics Registers Address
8 9 10

Access
R R R

Register Use
Frames transmitted from TS input 1. Frames received and sent to TS output 0. Frames received and sent to TS output 1.

Design Configuration
The base address offset is 0x11A0. Table 11 shows the design configuration registers.

Table 13. Design Configuration Registers Address
0

Access
R/W

Register Use
[0] device (0 = Cyclone; 1 = Stratix). [1] encapsulator logic present. [2] de-encapsulator logic present. [3] RTP support present. [4] 1 = MAC functionality implemented by reference design; 0 = MAC IP core.

1 2 3

R/W R/W R/W

Number of TS outputs. Number of TS inputs. Maximum number of frame buffer pointers.

These registers provide information on the hardware configuration.

Parameters
A number of features of the reference design can be parameterized to customize it for the desired operation. Table 14 shows the parameters

Table 14. Parameters (Part 1 of 2) Parameter
P_TARGET_DEVICE P_BUFFER_RAM_TYPE P_POINTERS P_TS_OUTPUT_PORTS

Definition
The target device, e.g., Cyclone or Stratix. Frame buffer RAM internal memory type, e.g., M4K or M-RAM. Total number of pointers (frame buffer locations). The number of TS outputs (set to 1 if no outputs are implemented).

Altera Corporation

29 Preliminary

Video Over IP Reference Design

Table 14. Parameters (Part 2 of 2) Parameter
P_TS_INPUT_PORTS P_IMPLEMENT_MAC

Definition
The number of TS inputs (set to 1 if no input ports are implemented). Set to 1 to use reference design MAC implementation. Set to 0 to use the MorethanIP 10/100/1000 MAC core.

To set the parameters use the Verilog HDL include file, video_over_ip.h. A template include file is provided in source/cyclone_demo. An important parameter is the number of pointers (frame buffer locations) that the design supports. There must be enough buffers available for the video transmit and/or receive operations to work without loss of data, whilse also ensuring that sufficient buffers are also available for any host processor traffic. Determining factors when deciding on the minimum number of buffers required include the number of inputs and outputs, and the rate and profile of the Ethernet connection.

Demonstration Description

The reference design includes the following demonstrations:
■ ■

Basic demonstration Web server demonstration

Basic Demonstration
The reference design includes a basic demonstration.

f

For details on how to run the basic demonstration, “Run the Basic Demonstration” on page 40. The basic demonstration uses the Nios II Development Kit, Cyclone Edition (or the Nios II Development Kit, Cyclone II Edition), the DBGIG1 Gigabit Ethernet PHY module, and Cyclone Video Development Board to show the reference design’s functionality (see Figure 15). 1 The DBGIG1 Gigabit Ethernet PHY module is available from Richter Industrie Elektronik (www.devboards.de).

30 Preliminary

Altera Corporation

Demonstration Description

Figure 15. Nios II Development Kit, Cyclone Edition & Cyclone Video Development Board
Nios Development Board, Cyclone Edition

DBGIG1 PHY Board

Ethernet CAT5e Cable

Parallel Transport Stream Interface Cable

Cyclone Video Demonstration Board ASI Input Cable

ASI Output Cable

The demonstration bridges between 100-Mbps or 1-Gbps Ethernet and ASI. The Cyclone Video Demonstration Board provides ASI connectivity for the TS data. The basic demonstration uses one set of boards (see Figure 15) to receive TS and generate encapsulated Ethernet frames. A second set of boards receives these Ethernet frames and regenerates the TS data. Software running on the Nios II processor responds to basic network messages such as ARP (Address Resolution Protocol) and Internet Control Message Protocol (ICMP) echo (ping) to show the design handling a combination of video and network management traffic. The software is for demonstration purposes only. The reference design includes a TS generator and checker. These items provide a second channel of video traffic to show the design supporting multiple TS data transfers simultaneously over the Ethernet connection.

Altera Corporation

31 Preliminary

Video Over IP Reference Design

Figure 16 shows the connector pinout for the TS interface to the Cyclone Video Demonstration Board. Figure 16. TS Interface Connector (J11)
Pin 1 TX_DAT[1] TX_DAT[3] TX_DAT[5] TX_DAT[7] TX_ENA RX_EOP RX_ENA RX_DAT[1] GND RX_DAT[2] RX_DAT[3] RX_DAT[4] RX_DAT[5] RX_DAT[7] CLK GND TX_DAT[0] TX_DAT[2] TX_DAT[4] TX_DAT[6] RX_LOCK[0] RX_SOP RX_DAT[0] GND GND GND RX_DAT[6] GND RX_LOCK[1] RX: Transport Stream Input to Cyclone device TX: Transport Stream Output from Cyclone device No Connection

Web Server Demonstration
f
For details on how to run the web server demonstration, “Run the Web Server Demonstration” on page 45. This eCos based web server demonstration provides a graphical interface for the Altera Video over IP reference design. It highlights the use of the NIOS-II processor for design configuration, network management and statistics gathering purposes. An eCos driver has been created for the Video over IP reference design. This provides the functions required by the eCos operating system to initialise the network interface and transmit and receive network traffic. A series of functions have also been created to generate the HTML code served by the eCos web server. These pages can be viewed by any web browser attached to the network.

32 Preliminary

Altera Corporation

Resource Requirements

Resource Requirements

The device resource requirement for the reference design depends upon the design parameterization. It is affected by the number of pointers that the frame buffer uses, the number of TS input and output channels, and the type of encapsulation/de-encapsulation required. Table 15 shows the demonstration (two channels TS-to-Ethernet, two channels Ethernet-to-TS) resources using the MorethanIP 10/100/1000 MAC.

Table 15. Demonstration Resources (with MorethanIP MAC) Module
Nios II system MorethanIP 100/1000 MAC Bridge

LEs
3,000 3,300 3,700

Memory (M4K RAM Blocks)
15 9 33

Table 16 shows the demonstration (two channels TS-to-Ethernet, two channels Ethernet-to-TS) resources using the reference design MAC.

Table 16. Demonstration Resources (with reference design MAC) Module
Nios II system MAC Bridge

LEs
3,000 400 3,900

Memory (M4K RAM Blocks)
15 2 33

Table 17 shows the one channel TS-to-Ethernet resources. This design uses four buffers and the reference design MAC.

Table 17. One Channel TS-to-Ethernet Resources Module
Nios II system MAC TS-to-Ethernet Bridge logic

LEs
3,000 335 1,700

Memory (M4K RAM Blocks)
15 2 17

Altera Corporation

33 Preliminary

Video Over IP Reference Design

Table 18 shows the one channel Ethernet-to-TS resources. This design uses eight buffers and the reference design MAC.

Table 18. One Channel Ethernet-to-TS Resources Module
Nios II system MAC Ethernet-toTS Bridge logic

LEs
3,000 375 2,300

Memory (M4K RAM Blocks)
15 2 30

Getting Started

This section includes the following sections:
■ ■ ■ ■ ■ ■ ■ ■ ■

“System Requirements” on page 34 “Install the Reference Design” on page 35 “Build the Nios II System” on page 36 “Parameterize the MorethanIP MAC Core (Optional)” on page 37 “Simulate the Design” on page 37 “Compile the Demonstration Project” on page 38 “Build the Basic Demonstration Software” on page 38 “Run the Basic Demonstration” on page 40 “Run the Web Server Demonstration” on page 45

System Requirements
Table 19 shows the demonstration hardware requirements.

Table 19. Hardware Requirements Hardware Manufacturer

Nios II Development Kit, Cyclone Edition (or Nios II Altera Corporation Development Kit, Cyclone II Edition) DBGIG1 Gigabit Ethernet PHY Module Richter Industrie Elektronik, www.devboards.de Altera Corporation Supplied with Cyclone Video Development Board Altera Corporation

Cyclone Video Development Board (1) Parallel cable (for TS connection) USB-Blaster™ download cable Note to Table 19:
(1) Available from Altera for evaluation use only.

34 Preliminary

Altera Corporation

Getting Started

The demonstrations requires the following software:
■ ■ ■ ■ ■

A PC running the Windows 2000/XP operating system Quartus II version 5.1 ModelSim-Altera simulator version 6.0c (Optional) MorethanIP 10/100/1000 Ethernet MAC version 3.5 Nios II processor version 5.1 If required, you should purchase the MorethanIP 10/100/1000 MAC core from MorethanIP. Altera do not provide this core as part of the Altera Video Over IP Reference Design.

1

The reference design requires a license for product ID BC01 and vendor ID 6A7B. Contact Altera for a license. 1 If you compile the design without a license, it uses OpenCore Plus hardware evaluation.

f

For more information on OpenCore Plus hardware evaluation, see AN 320: OpenCore Plus Evaluation of Megafunctions.

Install the Reference Design
To install the reference design, run the an374-v1.2.exe file and follow the installation instructions. Figure 17 shows the directory structure. 1 The default installation directory is c:\altera\reference_designs. You can change the default directory during the installation. The design files for the encapsulation, deencapsulation and PHY interface functions are supplied in encrypted form.

1

Altera Corporation

35 Preliminary

Video Over IP Reference Design

Figure 17. Directory Structure
auk_video_over_ip demo Contains the precompiled demonstration files. doc Contains the documentation. ecos_demo Contains the Nios II software for the web server demonstration. lib Contains the Quartus II models for encypted components. quartus Contains the Quartus II project files. cyclone_demo Contains the Quartus II project for the Cyclone demonstration. cycloneii_demo Contains the Quartus II project for the Cyclone II demonstration. sim_lib Contains the functional simulation models for encrypted components. simulation Contains the simulation scripts and waveforms. software Contains the Nios II project for the Cyclone demonstration. source Contains the source files. avalon_system Contains the SOPC Builder system for register access. channel_info Contains the transmit and receive channel information blocks. cyclone_demo Contains the top-level design files for the Cyclone demonstration. ethernet_system Contains the encapsulation and de-encapsulation functions. frame_buffer Contains the frame buffer and transmit and receive DMAs. mac_wrapper Contains the Ethernet MAC design files. port_logic Contains the TS interface logic. queue_system Contains the queue system files. ts_ethernet_bridge Contains the top level design files for TS-to-Ethernet bridge. tb Contains the testbench.

Build the Nios II System
To build the Nios II system supplied with the reference design, follow these steps: 1. Open the Quartus II software, Programs > Altera > Quartus II (Windows Start menu).

36 Preliminary

Altera Corporation

Getting Started

2.

Choose Open Project (File menu) and open the Quartus II project in the quartus\cyclone_demo or quartus\cycloneii_demo directory. Choose SOPC Builder (Tools menu). In SOPC Builder, click Generate.

3. 4.

Parameterize the MorethanIP MAC Core (Optional)
To parameterize the MorethanIP MAC core, follow these steps: 1. Run the MorethanIP installer to create the required MAC function and set the following values:
● ● ● ● ●

Include asynchronous FIFO buffers Include host interface with registers Include MDIO module Do not enable 10/100 half duplex support MII/GMII loopback and supplemental MAC unicast addresses are optional and should be set according to your system requirements Set ingress and egress FIFO buffer depths to 64, with 8-bit width

2.

Generate a VQM file—the Quartus II project for the basic demonstration design requires a VQM netlist (top_gen_host.vqm) for the generated MAC core.

f

For details on how to generate the VQM file, see the MorethanIP 10/100/1000 Ethernet MAC Reference Guide. 3. Place the VQM file in the quartus\cyclone_demo or quartus\cycloneii_demo directory.

Simulate the Design
The reference design includes a testbench that allows simulation of the design operation. A test fixture replaces the processor system and emulates the operation of software running on the processor. This fixture configures the design to transmit TS data to Ethernet and receive TS data from Ethernet. It also emulates host transmit and receive operations. Scripts to compile the design and run the simulation in the ModelSim-Altera simulator version 6.0c are in the simulation\tb_cyclone_demo directory.

Altera Corporation

37 Preliminary

Video Over IP Reference Design

Compile the Demonstration Project
The reference design includes a Quartus II project for the demonstrations. Before compiling, ensure you have performed the following actions:
■ ■

Generated the Nios II processor system using SOPC Builder (see “Build the Nios II System” on page 36) Generated the VQM netlist for the MorethanIP MAC (if required) and placed it in the quartus\cyclone_demo or quartus\cycloneii_demo directory Obtained licenses for the reference design MAC core and Nios II processor, as appropriate

To compile the demonstration, follow these steps: 1. 2. Open the demonstration project in the Quartus II software. Choose Start Compilation (Processing menu).

Build the Basic Demonstration Software
The basic demonstration includes some software designs and Nios II IDE project files. To start a Nios II project, follow these steps: 1. Start the Nios II IDE by choosing Programs > Altera > Nios II 5.1 > Nios II IDE (Windows Start menu). Choose New > Project (File menu). Choose C/C++ Application and click Next. Enter video_over_ip_demo for the Name (see Figure 18).

2. 3. 4.

38 Preliminary

Altera Corporation

Getting Started

Figure 18. Start a Nios II Project

5.

Turn off Use default location and browse to <install directory>\altera\reference_designs\an374-v1.2\software. For the SOPC Builder System browse to <install directory>\altera\reference_designs\an374v1.2\quartus\cyclone_demo\nios_system_cyclone.ptf. or For the SOPC Builder System browse to <install directory>\altera\reference_designs\an374v1.2\quartus\cycloneii_demo\nios_system_cycloneii.ptf.

6.

7. 8.

In CPU choose cpu. In Select Project Template choose Blank Project.

Altera Corporation

39 Preliminary

Video Over IP Reference Design

9.

Click Finish.

f

For details on how to build and run the project, see the Nios II Development Kit Getting Started User Guide.

Run the Basic Demonstration
f
For more information on the basic demonstration, see “Basic Demonstration” on page 30. Figure 19 shows the basic demonstration with a Nios II Development Board, Cyclone Edition. Figure 19. Demonstration
Ethernet CAT5e Cable

DBGIG1 Board

DBGIG1 Board

Nios II Development Board, Cyclone Edition

Cyclone Video Demonstration Board

Nios II Development Board, Cyclone Edition

Cyclone Video Demonstration Board

ASI Source

ASI Analyzer

Running the demonstration involves the following steps:
■ ■ ■ ■

“Set Up the Hardware” on page 41 “Program the Boards” on page 41 “Test the Connection” on page 42 “Connect the TS Data” on page 43

40 Preliminary

Altera Corporation

Getting Started

Set Up the Hardware
To set up the hardware, follow these steps: 1 Any references to the Nios II Development Board, Cyclone Edition apply to the Nios II Development Board, Cyclone II Edition. Connect a DBGIG1 Gigabit Ethernet PHY module to the PROTO2 connector on each Nios II Development Board, Cyclone Edition. Connect a Cyclone Video Demonstration Board (connector JP5) to each Nios II Development Board, Cyclone Edition (connector J11) using the parallel ribbon cable supplied with the Cyclone Video Demonstration Board. Ensure that DIP switch 8 on the Cyclone Video Demonstration Board is in the closed position. All other switches should be in the open position. Connect the LCD display provided with the Nios II Development Kit to connector J12 of the Nios II Development Board, Cyclone Edition. Connect the two Ethernet ports on the PHY boards using CAT5E cable. The ports can either be connected directly or through a gigabit Ethernet switch. Provide power to all four boards.

1.

2.

3.

4.

5.

6.

Program the Boards
To program the boards, follow these steps: 1. Program the Cyclone Video Demonstration Boards with the cvdb_demo.sof image in the \demo directory. Program the Nios II Development Board, Cyclone Edition, with the cyclone_demo.sof image in the \demo directory. or Program the Nios II Development Board, Cyclone II Edition, with the cycloneii_demo.sof image in the \demo directory.

2.

Altera Corporation

41 Preliminary

Video Over IP Reference Design

1

The cyclone_demo.sof or cycloneii_demo.sof image use the reference design MAC. To use the MorethanIP core, acquire a license, change the P_IMPLEMENT_MAC parameter to 0 in video_over_ip.h and recompile the design. Download the demonstration software executable (demo\video_over_ip_demo.elf) to the first Nios II Development Board, Cyclone Edition, using either the Nios II IDE or the following nios2-download command:

3.

nios2-download -g -c USB-Blaster video_over_ip_demo.elf 4. When programmed, the first board indicates 00 on its 7-segment display. If the LCD display is connected, it shows 123.123.123.32, which is the assigned IP address for the board. Hold down button SW0 on the second Nios II Development Board, Cyclone Edition, while downloading the demonstration software executable video_over_ip_demo.elf (see step 3). When programmed, the second board indicates 01 on its 7-segment display. If the LCD display is connected, it shows 123.123.123.33, which is the assigned IP address for the board. If the 7-segment display shows 00, repeat the previous step, and ensure that button SW0 is held down until the software has been fully downloaded. Check that LEDs D0, D1, and D2 on both Nios II Development Boards, Cyclone Edition, are all flashing. Each LED flashes at a different rate. If LED D2 is not flashing, ensure that the Cyclone Video Demonstration Board is connected properly and that its 27 MHz oscillator is fitted to U7. Monitor the output from the software using the following nios2terminal command:

5.

6.

7.

8.

nios2-terminal -c USB-Blaster This monitor output shows that the device initialization process. If the PHY auto-negotiation does not complete, check the Ethernet connection on both boards.

Test the Connection
To test the connection, follow these steps:

42 Preliminary

Altera Corporation

Getting Started

1.

Press button SW0 on the first Nios II Development Board, Cyclone Edition. This operation sends an ICMP echo (ping) to the second Nios II Development Board, Cyclone Edition. The software monitor output displays the ICMP reply. On the first Cyclone Video Demonstration Board, connect the SDI_TX BNC (J9) output to the ASI_RX0 BNC (J1) input. This action sends a test pattern to the design input. Check that LED D0 on the first Cyclone Video Demonstration Board is illuminated. Check that LED D3 on the first Nios II Development Board, Cyclone Edition is also illuminated. Check that LED D3 on the second Cyclone Video Demonstration Board is illuminated. The LED D3 indicates that the second board is generating a TS recovered from the Ethernet frames sent by the first board. On the second Cyclone Video Demonstration Board, connect the ASI_TX BNC (J8) output to the SDI_RX BNC (J3) input. LED D2 illuminates constantly to indicate that the TS being generated by the second board matches the expected test pattern. If there are any bit errors, LED D2 does not illuminate. Repeat the test in the other direction to check that both sides are capable of receiving and transmitting data.

2.

3.

4.

5.

6.

1

Ping messages can be sent at any time by pressing button SW0 on either Nios II Development Board, Cyclone Edition.

Connect the TS Data
1. Connect a TS generator to the ASI_RX0 BNC (J1) of one Cyclone Video Demonstration Board. Connect a TS analyzer to the ASI_TX BNC (J8) of the other Cyclone Video Demonstration Board.

2.

The TS data received by the first board is output by the second board. You can connect a second TS generator and analyzer to the other pair of TS inputs and outputs to show traffic being sent in both directions. You can generate a test stream containing null packets by briefly pressing button SW1 on one of the Nios II Development Board, Cyclone Edition. LED D5 illuminates on the board. This test stream is routed to the second

Altera Corporation

43 Preliminary

Video Over IP Reference Design

board using a different UDP/IP socket so does not interfere with the first stream. LED D6 illuminates on the second board to indicate that the TS data is being received. Press the button again to stop the test generator. Table 20 shows the Nios II Development Board, Cyclone Edition LEDs.

Table 20. LEDs—Nios II Development Board, Cyclone Edition LED
D0 D1 D2 D3 D4 D5 D6

Use
Flashes to indicate the 125-MHz system clock is running. Flashes to indicate the 50-MHz processor clock is running. Flashes to indicate the 27-MHz TS clock is running. Illuminates when TS input from Cyclone Video Demonstration Board is valid. Illuminates when TS output to Cyclone Video Demonstration Board is valid. Illuminates when the second test TS data is being generated. Illuminates when received the test TS data is valid.

Table 21 shows the Nios II Development Board, Cyclone Edition buttons.

Table 21. Buttons—Nios II Development Board, Cyclone Edition Button
SW0

Use
Hold down during the download of the software executable to set the board number to 01 instead of 00. Press during the demonstration to initiate a ping request to the other board.

SW1

Press during the demonstration to toggle the enable for the TS test generator.

Table 22 shows the Cyclone Video Demonstration Board connectors.

Table 22. Connectors—Cyclone Video Demonstration Board Connector
ASI_RX0 ASI_RX1 ASI_TX
TS input. TS input (can be used instead of ASI_RX0 if cable equalizer is required). TS output.

Use

44 Preliminary

Altera Corporation

Getting Started

Table 22. Connectors—Cyclone Video Demonstration Board Connector
SDI_TX SDI_RX
TS output from test generator. TS input for test checker. LED D2 Illuminates when valid packets are detected.

Use

Table 23 shows the Cyclone Video Demonstration Board LEDs.

Table 23. LEDs—Cyclone Video Demonstration Board LED
D0 D1 D2 D3

Use
Illuminates when valid packets are detected on ASI_RX0. Illuminates when valid packets are detected on ASI_RX1. Illuminates when valid packets are detected on SDI_RX. Illuminates when valid packets are output on ASI_TX.

Table 24 shows the Cyclone Video Demonstration Board switches.

Table 24. Switches—Cyclone Video Demonstration Board DIP Switch S5
8 7 5

Use
Closed (default): ASI output taken from parallel cable; open: ASI output taken from ASI input. Open (default): pattern generator creates 188 byte packets; closed: 204 byte packets. Open (default): pattern generator creates ~33 Mbps; closed: pattern generator creates ~204 Mbps

Run the Web Server Demonstration
f
For more information on the web server demonstration, see “Web Server Demonstration” on page 32. Running the web server demonstration involves the following steps:
■ ■ ■ ■

“Set Up the Hardware” on page 46 “Program the Boards” on page 46 “Acquire an IP Address” on page 46 “Connect to the Web Server” on page 47

Altera Corporation

45 Preliminary

Video Over IP Reference Design

■ ■ ■ ■ ■

“Configure Basic Operation” on page 47 “Change Global & Per-Port Settings” on page 48 “Display Network & Port Statistics” on page 48 “Display Host Traffic Statistics” on page 48 “Demonstrate Transport Of Video Traffic” on page 49

Set Up the Hardware
To set up the hardware, see “Set Up the Hardware” on page 41.

Program the Boards
To program the boards, follow these steps: 1. Program the Cyclone Video Demonstration Boards with the cvdb_demo.sof image in the \demo directory. Program the Nios II Development Board, Cyclone Edition, with the cyclone_demo.sof image in the \demo directory. or Program the Nios II Development Board, Cyclone II Edition, with the cycloneii_demo.sof image in the \demo directory. 1 The cyclone_demo.sof or cycloneii_demo.sof image use the reference design MAC. To use the MorethanIP core, acquire a license, change the P_IMPLEMENT_MAC parameter to 0 in video_over_ip.h and recompile the design. Download the demonstration software executable (demo\http.elf) to the first Nios II Development Board, Cyclone Edition, using either the Nios II IDE or the following nios2-download command:

2.

3.

nios2-download -g -c USB-Blaster http.elf

Acquire an IP Address
By default, the design attempts to acquire an IP address using the dynamic host configuration protocol DHCP. If a DHCP server is not present on the network, an IP address is created for the demonstration that is based on the least significant byte of the board's MAC address, using the reserved 169.254.197 subnet. When the board has acquired an IP address, you can ping it from a PC attached to the demonstration network.

46 Preliminary

Altera Corporation

Getting Started

1

Do not attach the design to your corporate network as it can generate a high bandwidth of data, which, especially in IP multicast mode, may have undesirable consequences. You can create a suitable DHCP server for demonstration purposes by running the freeware version of Weird Solutions' DHCP Turbo software on a PC attached to the demonstration network. Do not leave this DHCP server running, if the PC is reconnected to your corporate network

Connect to the Web Server
Run a web browser application on a PC attached to the demonstration network. Enter the IP address of the Nios II Development Board, Cyclone Edition, as indicated on the LCD display, to view the home page of the web server. Open a separate browser window for each demonstration platform attached to the network. 1 Unless you include a router in the demonstration network, the PC that you use to view the web pages should be on the same IP subnet as the Nios II Development Board, Cyclone Edition.

Configure Basic Operation
A page is provided for configuring the design for the demonstration. To get to this page, click the link at the bottom of the home page. The demonstration uses two systems to show the transfer of video traffic over the network. To establish communication between the boards, the first board needs to know the IP address of the second. Enter this address information in to the Destination IP box and click Submit. The demonstration software uses ARP to determine the MAC address associated with the IP address supplied. If the device associated with the supplied IP address does not reply to this ARP, an error is reported. If an IP multicast is used for the demonstration, a multicast address can be entered in the box. IP multicast addresses use the range 224.0.0.0 to 239.255.255.255. The software calculates the MAC multicast address that is used for the IP multicast. As an example, the MAC address for IP multicast address 225.10.20.30 is 01005E0A141E. When the destination IP address has been entered and accepted, click on the link to go to the main configuration page.

Altera Corporation

47 Preliminary

Video Over IP Reference Design

Change Global & Per-Port Settings
The main configuration page provides various links that you can use to change some of the global and per-port settings. The global parameters that you can change are the encapsulation type (UDP or RTP) and the number of transport stream packets per frame. 1 Ensure that the encapsulation type is set to the same value on all boards in the demonstration system. The number of transport stream packets per frame value only has to be set for boards that are transmitting TS data to Ethernet.

For the TS to Ethernet ports, you can modify the target IP address, UDP source and destination ports, IP type of service (TOS), and IP time to live (TTL) fields. Each port can also be enabled or disabled. 1 The IP address should be set to the address of a second board for unicast traffic, or to an IP multicast address for multicast traffic.

For the Ethernet-to-TS ports, the target IP address and UDP port can be modified. Each port can also be enabled or disabled. 1 The IP address should match the address of the board for unicast traffic, or be set to an IP multicast address for multicast traffic.

There is a test pattern generator in the demonstration design, which is connected to the second TS input. You can enable the generator by following a link on the main configuration page.

Display Network & Port Statistics
To display network and port statistics, click on the Stats link in the main banner at the top of the web page, which opens the main statistics page. The statistics displayed include the total number of transmitted and received Ethernet frames and the lock state and estimated bit rate for each Transport Stream interface port. Click Refresh in the browser window to update the values displayed.

Display Host Traffic Statistics
To display host traffic statistics, click on the Host link in the main banner at the top of the web page, which opens the host network monitor page. A variety of information gathered by the software network stack is displayed. Click Refresh in the browser window to update the values displayed.

48 Preliminary

Altera Corporation

Getting Started

Demonstrate Transport Of Video Traffic
To demonstrate the transport of video traffic from one system to a second, follow these steps: 1. Configure two systems (see “Set Up the Hardware” on page 46, “Program the Boards” on page 46, “Acquire an IP Address” on page 46, and “Configure Basic Operation” on page 47). You should have two web browser windows open, one for each system. When you configure the basic operation, each system is informed of the IP address of the other system. This action initializes the basic unicast demonstration. TS-to-Ethernet port 0 of the first system is configured to send traffic to Ethernet-to-TS port 0 of the second system; port 0 of the second system is configured to send traffic to port 0 of the first. Connect a TS source to the ASI input of the first system (ASI_RX0 connector on the Cyclone Video Demonstration Board). Connect a TS analyzer to the ASI output of the second system (ASI_TX connector). On the Configuration web page for the first system, click on the TSto-Ethernet port 0 link to open the state editor for the port. Select Yes for the enabled property. Click Submit. The TS data is now transferred from the first system to the second and output to the analyzer. View the Stats page for both boards to see the reported statistics.

2.

3.

4.

5. 6. 7.

8.

To demonstrate the transport of video traffic using an IP multicast session, use the same steps, but before enabling the port, change the destination IP address of TS-to-Ethernet port 0 to an IP multicast address and change the IP address of Ethernet-to-TS port 0 to the same value. IP class D addresses 224.0.0.0 to 239.255.255.255 are reserved for IP multicast. 1 This demonstration shows the principle of using IP multicast for the video transport. However, Internet group management protocol (IGMP) has not been implemented so the network switch must be configured to broadcast the multicast data to all attached nodes. Simple unmanaged layer two switches typically operate in this way by default.

Altera Corporation

49 Preliminary

Video Over IP Reference Design

101 Innovation Drive San Jose, CA 95134 (408) 544-7000 www.altera.com Applications Hotline: (800) 800-EPLD Literature Services: literature@altera.com

Copyright © 2005 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device designations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services.

50 Preliminary

Altera Corporation

Sign up to vote on this title
UsefulNot useful