An 374

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 1
AN-374-1.3 Preliminary
Video Over IP Reference Design
Specifications & Many standards and industry specifications have been referenced in
creating this reference design. These standards are summarized in this
Standards 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 re-
ordering.
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 Altera Corporation
Preliminary
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-to-
host 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.
Preliminary
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 FIFO Buffer
Input
FIFO Buffer TS Input

DMA Frame Buffer
Transmit
FIFO Buffer Channel
Info
Transmit
Queue
Transmit
DMA Encapsulate
Host
MII/ PHY
Transmit
GMII
Queue Receive
DMA
Host
Receive
Queue
Preliminary
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 FIFO Buffer
Output
FIFO Buffer TS Output

DMA Frame Buffer
Receive
FIFO Buffer Channel
Info
Receive
Queue
Receive
DMA De-encapsulate
Host
MII/ PHY
Receive
GMII
Queue Transmit
DMA
Host
Transmit
Queue
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.
Preliminary
TS-to-Ethernet
Figure 3 shows the data flow for TS-to-Ethernet.
Figure 3. Data Flow for TS-to-Ethernet

TS FIFO Buffer
Inputs
FIFO Buffer TS Input Payload

DMA Frame Buffer
Transmit
FIFO Buffer Pointer Channel
Info
Payload
Transmit MII/
Pointer
Queue GMII
Transmit
DMA Encapsulate PHY
Free
List
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.
Preliminary
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
Preliminary
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 Payload FCS
(optional)
Inserted by Encapsulator Read from Frame Buffer Inserted by Encapsulator
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.
Preliminary
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
Preliminary
Ethernet-to-TS
Figure 7 shows data flow for Ethernet-to-TS.
Figure 7. Data Flow for Ethernet-to-TS

TS FIFO Buffer
Output
FIFO Buffer TS Output

DMA Frame Buffer
Receive
FIFO Buffer Channel
Info
Receive
MII/
Queue
Receive GMII
DMA De-encapsulate PHY
Free
List
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.
Preliminary
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.
Preliminary
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
Preliminary
Overview
Host Packet Transmission

Figure 10 shows the data flow for host transmit.
Figure 10. Data Flow for Host Transmit

Configure
1
Payload
3
Frame Buffer
Host Interface Transmit
Channel
Info
Payload
Pointer Host
4 Transmit
Pointer MII/
Queue
GMII
Transmit
DMA Encapsulate PHY
2 Free
Pointer
List
6
Done Flag
5
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.
Preliminary
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 Auto-
Release
No
Wait for transmit to complete
Another Yes
Frame
No
Return pointer to Buffer Free List
Preliminary
Overview
Host Packet Reception

Figure 12 shows the data flow for host receive.
Figure 12. Data Flow for Host Receive
Payload
3 Frame Buffer
Receive
Channel
Info
Host Interface
MII/
Interrupt/ Receive GMII
Flag DMA De-encapsulate PHY
1 Host
2 Pointer Receive
Queue
Pointer Free
4
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.
Preliminary
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 This section provides a detailed functional description of the main

components of the reference design.
Description
The reference design is partitioned in to the following three top-level
elements:
■ Nios II processor system

■ Ethernet-PHY interface
■ TS-to-Ethernet bridge
Preliminary
Functional Description
Figure 14 shows the top-level partitioning.
Figure 14. Top-Level Partitioning
Nios Processor
System
MII/
GMII
TS TS-to-Ethernet Ethernet-PHY
Interfaces Bridge 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.
Preliminary
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-to-
Ethernet 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.
Preliminary
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.
Preliminary
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 Note (1)
Signal Direction Use

ts_in_clk Input Clock, common to all inputs.
ts_in_dav[i] Output Data input enable.
ts_in_ena[i] Input Data valid. Assert for one clock cycle for each valid data byte,
provided ts_in_dav[i] is high.
ts_in_dat[(i×8)+7:i×8] Input Data.
ts_in_sop[i] Input Start of packet. Assert to accompany first byte of packet.
ts_in_eop[i] Input End of packet. Assert to accompany last byte of packet.
ts_in_lock[(i×2)+1:i×2] Input Lock status (00 = unlocked, 11 = 188-byte packets, and
01 = 204-byte packets).
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.
Preliminary
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 Note (1)

ts_out_clk Input Clock.
ts_out_dav[i] Input Enable. Data is not output when low.
ts_out_ena[i] Output Data valid. Asserted for one clock cycle for each valid data
byte.
ts_out_dat[(i*8)+7:i*8] Output Data.
ts_out_sop[i] Output Start of packet. Asserted to accompany first byte of packet.
ts_out_eop[i] Output End of packet. Asserted to accompany last byte of packet.
Note to Table 2:
(1) 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.
Preliminary
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

mac_tx_dav Input Transmit data enable from the
Ethernet-PHY interface.
mac_tx_ena Output Transmit data valid.
mac_tx_dat[7:0] Output Transmit data.
mac_tx_sop Output Transmit start of packet flag.
mac_tx_eop Output Transmit end of packet flag.
mac_rx_ena Input Receive data valid.
mac_rx_dat[7:0] Input Receive data.
mac_rx_sop Input Receive start of packet flag.
mac_rx_eop Input Receive end of packet flag.
mac_rx_err Input Receive error flag.
mac_rx_err_stat[3:0] Input 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.
Preliminary
TS Input Logic
The base address offset is 0x1140. Table 4 shows the TS input logic
registers.
Table 4. TS Input Logic Registers
Address Access Register Use

0 R/W Port select.
1 R/W Enable for selected port (1 to enable).
2 R/W Channel number for selected port.
3 R [1:0] lock status for selected port.
W [2:0] the number of TS packets per Ethernet frame.
4 R [19:0] Estimated bits per second for selected port.
5 R/W [2:0] Number of TS packets encapsulated per Ethernet
frame (between 1 and 7).
7:6 – Reserved.
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

0 R/W Port select.
1 R [1:0] lock status for selected port.
2 R [19:0] Estimated bits per second for selected port.
7:3 – Reserved.
Preliminary
Frame Buffer
The base address offset is 0x0000. Table 6 shows the frame buffer
registers
Table 6. Frame Buffer Registers

381:0 R/W Frame data for first pointer.
382 R Timestamp (for received frames only).
383 R/W Frame parameters (length, receive error flags).
511 W Pointer selection (first pointer).
893:512 R/W Frame data for second pointer.
894 R Timestamp (for received frames only).
895 R/W Frame parameters (length, receive error flags).
1023 W 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.
Preliminary
Queue System
The base address offset is 0x1100. Table 7 shows the queue system
registers.
Table 7. Queue System Registers

0 R/W Queue select (0 = free list; 1 = host receive; 2 = host
transmit).
1 R/W [n:0] pointer.
R [31] set if the pointer is read from an empty queue.
2 R Queue level for selected queue.
3 R/W [0] host release mode (0 = buffer automatically released
after transmit; 1 = buffer not released after transmit
[default]).
R/W [1] Host override mode (1 to allow host to use TS queues,
0 by default).
R [31] host transmit status (1 = transmit in progress).
10 R/W [0] Interrupt enable for host receive (1 to enable, 0 by
default)
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)

4 W [n:0] Pointer for writing to the free list queue.
R [n:0] pointer read from the free list queue.
R [31] set if pointer read when the queue is empty.
5 R Queue level for the free list queue.
6 R [n:0] pointer read from the host receive queue.
R [31] Set if the pointer read when the queue is empty.
7 R Queue level for the host receive queue.
Preliminary
Table 8. Additional Queue System Registers (Part 2 of 2)

8 W [n:0] pointer for writing to the host transmit queue.
9 R 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.
Preliminary
De-Encapsulator
The base address offset is 0x11B0. Table 9 shows the de-encapsulator
registers.
Table 9. De-encapsulator Registers

0 R/W [0] assert to enable RTP support.
3:1 – Reserved.
Transmit Channel Information

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

0 R/W [2:0] encapsulation type (000 = none, 001 = IP only,
011 = UDP/IP, 111 = RTP/UDP/IP).
1 R/W Fixed value of 0x11 required for IP encapsulation
2 – Reserved.
3 – Reserved.
4 R/W Virtual LAN (VLAN) field enable.
9:4 R/W MAC destination address.
10 R/W IP type of service (TOS) field.
11 R/W IP time To live (TTL) field.
15:12 R/W IP source address.
19:16 R/W IP destination address.
21:20 R/W UDP source port.
23:22 R/W UDP destination port.
27:24 R/W MAC VLAN field.
31:28 R/W RTP synchronization source (SSRC) field.
32 R/W 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.
Preliminary
Receive Channel Information

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

0 R/W MAC address [31:0].
1 R/W MAC address [47:32].
2 R/W IP address.
3 R/W IP subnet mask.
4 R/W [0] set to check IP address for host receive frames
R/W [1] set to match MAC multicast frames for host.
5 R/W Port select.
6 R/W [15:0] UDP destination port for selected channel.
7 R/W [31:0] IP destination address for selected channel.
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

0 R Frames received and matched for host.
1 R Errored frames received.
2 R Frames received with format not recognized by the
deencapsulator.
3 R Frames discarded due to lack of buffers.
4 R Host frames discarded due to lack of buffers.
5 R Frames received and discarded.
6 R Frames sent by the host.
7 R Frames transmitted from TS input 0.
Preliminary
Table 12. Statistics Registers

8 R Frames transmitted from TS input 1.
9 R Frames received and sent to TS output 0.
10 R 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

0 R/W [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 R/W Number of TS outputs.
2 R/W Number of TS inputs.
3 R/W 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 Definition
P_TARGET_DEVICE The target device, e.g., Cyclone or Stratix.
P_BUFFER_RAM_TYPE Frame buffer RAM internal memory type, e.g., M4K or M-RAM.
P_POINTERS Total number of pointers (frame buffer locations).
P_TS_OUTPUT_PORTS The number of TS outputs (set to 1 if no outputs are implemented).
Preliminary
Table 14. Parameters (Part 2 of 2)
Parameter Definition
P_TS_INPUT_PORTS The number of TS inputs (set to 1 if no input ports are implemented).
P_IMPLEMENT_MAC 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 The reference design includes the following demonstrations:
Description ■ 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).
Preliminary
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 ASI Output Cable
Demonstration Board
ASI Input 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.
Preliminary
Figure 16 shows the connector pinout for the TS interface to the Cyclone
Video Demonstration Board.
Figure 16. TS Interface Connector (J11)
Pin 1 GND
TX_DAT[1] TX_DAT[0]
TX_DAT[3] TX_DAT[2]
TX_DAT[5] TX_DAT[4]
TX_DAT[7] TX_DAT[6]
TX_ENA
RX_EOP RX_LOCK[0]
RX_ENA RX_SOP
RX_DAT[1] RX_DAT[0]
GND
RX_DAT[2] GND
RX_DAT[3] GND
RX_DAT[4] GND
RX_DAT[5] RX_DAT[6]
RX_DAT[7] GND
CLK 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.
Preliminary
Resource Requirements
Resource The device resource requirement for the reference design depends upon
the design parameterization. It is affected by the number of pointers that
Requirements 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)
Memory
Module LEs
(M4K RAM Blocks)
Nios II system 3,000 15
MorethanIP 100/1000 MAC 3,300 9
Bridge 3,700 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)
Memory
Module LEs
(M4K RAM Blocks)
MAC 400 2
Bridge 3,900 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
Memory
Module LEs
(M4K RAM Blocks)
MAC 335 2
TS-to-Ethernet Bridge logic 1,700 17
Preliminary
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
Memory
Module LEs
(M4K RAM Blocks)
MAC 375 2
Ethernet-toTS Bridge logic 2,300 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
Cyclone Video Development Board (1) Altera Corporation
Parallel cable (for TS connection) Supplied with Cyclone
Video Development Board
USB-Blaster™ download cable Altera Corporation
Note to Table 19:

(1) Available from Altera for evaluation use only.
Preliminary
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
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.
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.
1 The design files for the encapsulation, deencapsulation and

PHY interface functions are supplied in encrypted form.
Preliminary
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).
Preliminary
Getting Started
2. Choose Open Project (File menu) and open the Quartus II project in
the quartus\cyclone_demo or quartus\cycloneii_demo directory.
3. Choose SOPC Builder (Tools menu).
4. In SOPC Builder, click Generate.
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.
Preliminary
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. Open the demonstration project in the Quartus II software.
2. 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).
2. Choose New > Project (File menu).
3. Choose C/C++ Application and click Next.
4. Enter video_over_ip_demo for the Name (see Figure 18).
Preliminary
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.
6. For the SOPC Builder System browse to <install

directory>\altera\reference_designs\an374-
v1.2\quartus\cyclone_demo\nios_system_cyclone.ptf.
or
For the SOPC Builder System browse to <install

directory>\altera\reference_designs\an374-
v1.2\quartus\cycloneii_demo\nios_system_cycloneii.ptf.
7. In CPU choose cpu.
8. In Select Project Template choose Blank Project.
Preliminary
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
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 Cyclone Video Nios II Development Cyclone Video

Board, Demonstration Board, Demonstration
Cyclone Edition Board Cyclone Edition 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
Preliminary
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.
1. Connect a DBGIG1 Gigabit Ethernet PHY module to the PROTO2

connector on each Nios II Development Board, Cyclone Edition.
2. 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.
3. 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.
4. Connect the LCD display provided with the Nios II Development

Kit to connector J12 of the Nios II Development Board, Cyclone
Edition.
5. 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.
6. Provide power to all four boards.
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.
2. 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.
Preliminary
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.
3. 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:
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.
5. 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).
6. 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.
7. 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.
8. Monitor the output from the software using the following nios2-
terminal command:
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:
Preliminary
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.
2. 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.
3. 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.
4. 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.
5. 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.
6. Repeat the test in the other direction to check that both sides are
capable of receiving and transmitting data.
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
2. Connect a TS analyzer to the ASI_TX BNC (J8) of the other Cyclone

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
Preliminary
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 Use
D0 Flashes to indicate the 125-MHz system clock is running.
D1 Flashes to indicate the 50-MHz processor clock is running.
D2 Flashes to indicate the 27-MHz TS clock is running.
D3 Illuminates when TS input from Cyclone Video Demonstration Board is
valid.
D4 Illuminates when TS output to Cyclone Video Demonstration Board is
valid.
D5 Illuminates when the second test TS data is being generated.
D6 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 Use
SW0 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 Use
ASI_RX0 TS input.
ASI_RX1 TS input (can be used instead of ASI_RX0 if cable equalizer is
required).
ASI_TX TS output.
Preliminary
Getting Started
Table 22. Connectors—Cyclone Video Demonstration Board
Connector Use
SDI_TX TS output from test generator.
SDI_RX TS input for test checker. LED D2 Illuminates when valid packets
are detected.
Table 23 shows the Cyclone Video Demonstration Board LEDs.
Table 23. LEDs—Cyclone Video Demonstration Board
LED Use
D0 Illuminates when valid packets are detected on ASI_RX0.
D1 Illuminates when valid packets are detected on ASI_RX1.
D2 Illuminates when valid packets are detected on SDI_RX.
D3 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 Use
S5
8 Closed (default): ASI output taken from parallel cable; open: ASI output
taken from ASI input.
7 Open (default): pattern generator creates 188 byte packets; closed:
204 byte packets.
5 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
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
Preliminary
■ “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.
2. 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.
3. 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:
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.
Preliminary
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.
Preliminary
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.
Preliminary
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.
2. 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.
3. 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).
4. On the Configuration web page for the first system, click on the TS-
to-Ethernet port 0 link to open the state editor for the port.
5. Select Yes for the enabled property.
6. Click Submit.
7. The TS data is now transferred from the first system to the second
and output to the analyzer.
8. View the Stats page for both boards to see the reported statistics.
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.
Preliminary
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 re-
spective holders. Altera products are protected under numerous U.S. and foreign patents and pending
101 Innovation Drive applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products
San Jose, CA 95134 to current specifications in accordance with Altera's standard warranty, but reserves the right to make chang-
(408) 544-7000 es 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
www.altera.com herein except as expressly agreed to in writing by Altera Corporation. Altera customers
Applications Hotline: are advised to obtain the latest version of device specifications before relying on any pub-
(800) 800-EPLD lished information and before placing orders for products or services.
Literature Services:
literature@altera.com
Preliminary

An 374

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

An 374

Diunggah oleh

Hak Cipta:

Format Tersedia

Video Over IP Reference

Version 1.3, October 2005 Application Note 374

Introduction The Altera® video over IP reference design demonstrates transmission of

The reference design accepts TS data and encapsulates it for transmission

The Altera Asynchronous Serial Interface (ASI) Reference Design can

f For more information on the Asynchronous Serial Interface (ASI)

For multiple TS interfaces, the reference design individually maps each

The reference design includes a Nios® II processor. Software running on

8B/10B coding maintains a DC balance and supports self checking and

Altera has a reference design for ASI.

f For more information on the Asynchronous Serial Interface (ASI)

Real-Time Transport Protocol

RTP is defined in the request for comments (RFC) document RFC3350. It

RTP Payload Format for MPEG1/MPEG2 Video

Unlike the transmission control protocol (TCP), UDP is not connection

IP is the standard internet layer. It is defined by IETF RFC791.

Pro-MPEG Code of Practice #3

The Pro-MPEG Wide Area Network (WAN) working group is focused on

The code of practice recommends the transmission protocol (e.g.,

Phase 1 of the DVB-IP Handbook is complete and includes a chapter on

The standard specifies the use of RTP/UDP/IP encapsulation. FEC is

Figure 1. TS-to-Ethernet Bridge

FIFO Buffer TS Input

Figure 2. Ethernet-to-TS Bridge

FIFO Buffer TS Output

Typically the reference design is configured as either a TS-to-Ethernet

The reference design performs the following four main functions:

■ Encapsulation of TS input and transmission to Ethernet;

Each of these functions is now described.

f For a detailed description of each reference design element, see

Figure 3. Data Flow for TS-to-Ethernet

FIFO Buffer TS Input Payload

The reference design accepts TS data from a configurable number of input

Data from separate ports is always treated separately so any individual

Figure 4. TS Input Logic Flow Diagram

Fetch Pointer from Buffer Free List

Accumulate Data for Ethernet Frame & Store

Store Payload Length and Channel Number

Load Pointer to Transmit Queue

1 There is only one transmit queue, which is shared by all the TS

The transmit queue is monitored to detect when there is an entry. This

The encapsulator adds the required Ethernet frame headers to the

Figure 5. Encapsulated Frame for Ethernet

MAC IP UDP RTP Payload FCS

Inserted by Encapsulator Read from Frame Buffer Inserted by Encapsulator

When transmission of the frame is complete, the pointer is released back

Figure 6. Ethernet Output Flow Diagram

Fetch Pointer from Transmit Queue

Read Payload Length & Channel Number from

Read Payload Data from Frame Buffer &

Add Appropriate Header Using Data from

Send Ethernet Frame to PHY for Transmission

Release Pointer to Buffer Free List

Figure 7. Data Flow for Ethernet-to-TS

FIFO Buffer TS Output

The receive channel information block analyzes the parameters extracted

Figure 8. Ethernet Input Flow Diagram

Fetch Pointer from Buffer Free List

Receive Data from Ethernet & Store in Allocated

When Receiving the Frame, Parse to Extract

Match the Extracted Parameters to Identify

At End of Frame, Store Length & Timestamp in

Queue Pointer to Appropriate Receive Queue (TS