An374-V2 3

Video Over IP Reference
Design
March 2007, Version 2.3 Application Note 374
Introduction The Altera® Video Over IP Reference Design implements a system that
bridges between MPEG transport stream (TS) data and Ethernet-based
internet protocol (IP) networks.
The reference design can accept TS data from several inputs and
encapsulate it for transmission over an Ethernet network. The design uses
industry standard user datagram protocol (UDP)/IP network
encapsulation, with real-time transport protocol (RTP) encapsulation and
Pro-MPEG Code of Practice #3 (CoP3) forward error correction (FEC)
available as an option. The design supports both 100-megabits per second
(Mbps) (full-duplex) and 1-gigabit per second (Gbps) Ethernet
connections and can process up to 256 individual streams. By using
hardware encapsulation, the design can achieve line-rate gigabit Ethernet
performance with minimal transmission latency.
The design can also accept up to 256 individual streams from an Ethernet
network and recover the TS data. For RTP encapsulated data, the design
includes a receiver buffer to absorb network jitter and correct for packet
reordering and duplication. CoP3 FEC-based lost packet recovery is
available as an option.
The reference design includes a demonstration for the Nios® II

Development Board, Cyclone® II Edition and one for the Audio Video
Development Kit, Stratix® II GX Edition.
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 asynchronous serial interface (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.
Altera Corporation 1
AN-374-2.3 Preliminary
Video Over IP Reference Design
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 an ASI MegaCore function.
f For more information on the ASI MegaCore function, see the ASI
MegaCore Function User Guide.
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, and security.
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 CoP3 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.
2 Altera Corporation
Preliminary
Functional Description
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 (for example,

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.
Functional Figure 1 shows reference design block diagram.
Description
Preliminary
Figure 1. Block Diagram
DDR Flash SSRAM

SDRAM Memory
DDR SDRAM Nios II

Controller Processor
TS 100/1000
Input RTP PHY Ethernet Ethernet
TS
Input Transmitter Interface PHY
UDP/IP or
TS Ethernet
Output RTP- MAC
RTP Receiver
to-TS (Optional)
SOPC Builder System
TS Ethernet
Altera provides two demonstrations: a Cyclone II demonstration, which

supports two data channels for TS-to-Ethernet, and two channels for
Ethernet-to-TS; and a Stratix II GX demonstration, which supports four
data channels for TS-to-Ethernet, and four channels for Ethernet-to-TS.
The demonstrations use external SDRAM for the transmitter FEC packet
buffering and for the receiver payload and FEC packet buffering. A
Nios II processor allows you to write software to control and monitor the
design operation. For hardware demonstration and evaluation purposes,
the Cyclone II demonstration is mapped to the Nios II Development Kit,
Cyclone II Edition; the Stratix II GX demonstration is mapped to the
Audio Video Development Kit, Stratix® II GX Edition.
Reference Design System

The reference design is based on an SOPC Builder system, which
provides the following components:
■ The main design elements:

● RTP transmitter
● RTP receiver
● UDP/IP function
● PHY interface
Preliminary
■ A Nios II processor for control of the design

■ Arbitration logic and memory controller for the FEC generator and
receiver buffer external RAM.
The SOPC Builder system is instantiated in a top-level design

(ts_ethernet_bridge.v), which adds top-level connectivity and TS
interface logic.
Figure 3 shows the SOPC Builder system.
Figure 2. SOPC Builder System
The Nios II processor uses the flash memory and SSRAM on the
development board for its code and data. The FEC generator and receiver
buffer use DDR SDRAM, for packet storage. The data width, operating
frequency, and capacity of the SDRAM vary according to the application.
Preliminary
If you want to use a different processor or external memory for your

application, modify the example SOPC Builder system to instantiate the
desired components. For an external processor, you should create an
Avalon® Memory-Mapped (Avalon-MM) interface master that the
processor can control to access the on-chip peripherals.
UDP/IP Function
The UDP/IP function provides the following features:
■ Hardware UDP, IP, and (optional) Ethernet MAC encapsulation for

transmitting MPEG TS data
■ Hardware UDP, IP and (optional) Ethernet MAC de-encapsulation
and socket matching for receiving MPEG TS data
■ Transmitter and receiver path for host processor traffic
Figure 3 shows the UDP/IP function block diagram.
Figure 3. UDP/IP Function Block Diagram
Host Transmitter Transmit Socket

& Receiver Information
Payload UDP/IP MAC

To PHY Interface
Input Encapsulator
Frame Buffer
& Queues
Payload UDP/IP MAC From PHY Interface
Output De-encapsulator
Statistics Receive Socket

Counter Match
The transmitter path receives MPEG TS data from the transmitter

payload input interface. UDP and IP headers are added to the payload.
Optionally an Ethernet MAC header and FCS field are also added. The
resulting encapsulated packet is output on the transmitter packet output
interface. The reference design supports a number of individual
transmitter channels, each of which is assigned its own set of UDP, IP, and
Ethernet MAC encapsulation parameters (for example, destination IP
address and UDP port).
Preliminary
The receiver path receives packets from the receiver packet input
interface. The UDP, IP, and (optionally) Ethernet MAC header fields are
parsed to determine how the packet should be processed. For packets
matched for hardware processing, the extracted MPEG TS data is
presented on the receiver payload output interface. Packets matched for
processing by software are made available to the host processor via the
host interface. All remaining packets are discarded.
A register mapped interface is provided to allow the host processor to

control the module operation and to transmit and receive network
packets.
Buffering, queuing, and arbitration is provided to allow the simultaneous

processing of transmitter, receiver, and host traffic. The design can
processing full-duplex line rate gigabit traffic.
UDP/IP Network Encapsulation

Table 1 shows the Ethernet MAC layer.
Table 1. Ethernet MAC Layer
Field Width (Bits) Value

Interframe gap 96 (minimum) 0
Preamble 56 0x55
Start of frame delimiter 8 0xd5
Destination address 48 Configurable per channel
Source address 48 Configurable
VLAN (optional) 32 Configurable per channel
Type/length 16 0x0800 (IP)
Client data 368 to 12,000 MAC payload
Frame check sequence 32 Calculated
Table 2 shows the IP layer.
Table 2. IP Layer (Part 1 of 2)

Version 4 4
Internet header length 4 20
(IHL)
Type of service (TOS) 8 Configurable per channel
Preliminary
Table 2. IP Layer (Part 2 of 2)

Total length 16 Calculated
Identification 16 Calculated
Fragmentation 16 0x4000 (do not fragment)
Time to live (TTL) 8 Configurable per channel
Protocol 8 17 (UDP)
Header checksum 16 Calculated
Source address 32 Configurable
Destination address 32 Configurable per channel
Data 11,840 maximum IP payload
Table 3 shows the UDP layer.
Table 3. UDP Layer

Source port 16 Configurable per channel
Destination port 16 Configurable per channel
Message length 16 Calculated
Checksum 16 0 (field not calculated)
Data 11,776 maximum UDP payload
Receiver Socket Matching

The reference design allocates each hardware receiver channel an IP
address and a UDP destination port. The combination of these two values
is called a socket. If the IP address and UDP port of a received packet
matches one of the hardware sockets, the reference design forwards the
packet for processing.
If the packet is not matched for hardware processing, the reference design
checks it to see if it should forward it to the host processor. By default, any
unprocessed packets that match the Ethernet MAC address of the design
or the broadcast MAC address go to the host processor. Optionally, you
can also forward all unprocessed multicast packets to the host processor
or filter the unprocessed packets using their IP address.
Preliminary
If you want to implement a different algorithm for the receiver packet

processing, turn on Enable external address matching when
parameterizing the design in IP Toolbench. This options provides
additional interface signals from the custom variation that you can use to
monitor the received packets and control their destination.
Host Packet Transmission

Figure 4 shows the data flow for host transmission.
Figure 4. Data Flow for Host Transmission

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
To transmit frames to Ethernet, the host processor first requests a pointer

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 transmission
request is loaded to the host transmitter queue.
The host has its own transmitter 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.
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 5 shows the host transmitter flow diagram.
f For more information on how to write software for the UDP/IP host
transmission, refer to the UDP/IP software instructions in the UDP/IP
package.
Preliminary
Figure 5. Host Transmitter 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
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
Host Packet Reception

Figure 6 shows the data flow for host reception.
Preliminary
Figure 6. Data Flow for Host Reception
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 receiver queue that is loaded with an entry when one of
these frames is received.
The host can poll the host receiver queue to see if there is an entry, or it
can receive an interrupt.
The receiver frame is processed by reading the entry from the host
receiver 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 transmitter, such as when
a reply to a received message might be required. Figure 7 shows the host
receiver flow diagram.
f For more information on how to write software for the UDP/IP host
reception, refer to the UDP/IP software instructions in the UDP/IP
package.
Preliminary
Figure 7. Host Receiver 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
Parameters
Figure 8 shows the UDP/IP function IP Toolbench.
Preliminary
Figure 8. UDP/IP Function IP Toolbench
Signals
Unless otherwise indicated, all signals are active high and synchronous to
their related clock.
Table 4 shows the system signals.
Table 4. System Signals
Name Direction Width Description

system_clk Input 1 125-MHz system clock
system_rst Input 1 System reset
payload_clk Input 1 Payload clock. (1)
payload_rst Input 1 Payload reset. (1)
timestamp Input 32 90-kHz timestamp (tie to 0 if not required), which records
packet reception time.
Note to Table 4:
(1) The payload_clk and payload_rst signals are not available if P_SINGLE_CLOCK_MODE is set to 1.
Preliminary
Table 5 shows the transmitter payload input signals.
Table 5. Transmitter Payload Input Signals Note (1)

payload_in_ready Output 1 Ready to payload source. Payload source must respond to
negation of payload_in_ready in one cycle.
payload_in_valid Input 1 Data valid.
payload_in_data Input 32 Payload data (little endian).
payload_in_channel Input 16 Transmitter channel identifier. Transmitter channels are
numbered from 0 to (P_INPUT_CHANNELS – 1). Tie
unused bits to 0. Bits [15:14] are a subchannel indication
for CoP3 FEC encapsulation. Use 00 for data packets, 01
for row FEC, and 10 for column FEC.
payload_in_length Input 11 Payload length in bytes.
payload_in_start Input 1 Start of payload flag.
payload_in_end Input 1 End of payload flag.
payload_in_error Input 1 Payload error flag.
Note to Table 5:
(1) Signals are not available if P_INPUT_CHANNELS is 0.
Table 6 shows the transmitter packet output signals.
Table 6. Transmitter Packet Output Signals

mac_tx_ready Input 1 Ready from MAC/PHY.
mac_tx_valid Output 1 Data valid.
mac_tx_data Output 8 Data byte.
mac_tx_start Output 1 Start of packet flag.
mac_tx_end Output 1 End of packet flag.
Table 7 shows the receiver packet input signals.
Table 7. Receiver Packet Interface Signals (Part 1 of 2)

mac_rx_valid Input 1 Data valid.
mac_rx_data Input 8 Data byte.
Preliminary
Table 7. Receiver Packet Interface Signals (Part 2 of 2)

mac_rx_start Input 1 Start of packet flag.
mac_rx_end Input 1 End of packet flag.
mac_rx_error Input 1 Error flag.
Table 8 shows the receiver payload output signals.
Table 8. Receiver Payload Output Signals Note (1)

payload_out_ready Input 1 Ready from payload sink. Payload output responds to
negation of payload_out_ready in one cycle.
payload_out_valid Output 1 Data valid.
payload_out_data Output 32 Payload data (little endian).
payload_out_channel Output 16 Receiver channel identifier.
payload_out_length Output 11 Payload length in bytes.
payload_out_start Output 1 Start of payload flag.
payload_out_end Output 1 End of payload flag.
Note to Table 8:
(1) Signals are not available if P_OUTPUT_CHANNELS is 0.
Table 9 shows the register access signals.
Table 9. Register Access Signals (Part 1 of 2)

avalon_clk Input 1 Clock.
avalon_rst Input 1 Reset.
avalon_address Input 11 Address.
avalon_byteenable Input 4 Byte enable.
avalon_write Input 1 Write.
avalon_writedata Input 32 Write data. (1)
avalon_read Input 1 Read.
avalon_readdata Output 32 Read data. (1)
avalon_waitrequest Output 1 Wait request.
Preliminary
Table 9. Register Access Signals (Part 2 of 2)

irq_hostrx Output 1 Interrupt.
Note to Table 8:
(1) Registers are 32-bit and therefore endian neutral. The frame buffer RAM is byte addressable, with the endianness
controlled by P_BIG_ENDIAN (little endian by default—the first packet byte corresponds to data bits [7:0]).
Table 10 shows the external address matcher signals.
1 Only available when you turn on Enable external address

matching.
Table 10. External Address Matcher Signals

ext_rx_channel Input 16 Hardware channel identifier.
ext_rx_match Input – Assert if frame is matched for hardware or software,
negate to discard.
ext_rx_send_to_ Input – Assert to send frame to the host processor, negate to
host forward for hardware processing.
denc_out_dat Output 8 Received frame data byte.
denc_out_ena Output – Data valid.
denc_out_eop Output – End of packet.
denc_out_id Output 4 Field identifier. The denc_out_id signal identifies the
encapsulation fields in the received frame. Individual
bytes within the field are identified by the
denc_out_id_count signal (first byte for the field is 0,
next is 1, and so on). The denc_out_id signal has the
following coding:
● 0: null
● 1: MAC VLAN
● 2: IP source address
● 3: IP destination address
● 4: UDP source port
● 5: UDP destination port
● 6: IP payload
● 7: Exception (packet not a supported UDP/IP format)
● 10: MAC destination address
denc_out_id_count Output 3 Field identifier byte count.
denc_out_sop Output – Start of packet.
Preliminary
f For more information on how to write software to access the UDP/IP

registers, refer to the UDP/IP software instructions in the UDP/IP
package.
PHY Interface
The PHY interface is an Atlantic interface to MII or GMII bridge plus
MDIO controller. If MAC layer encapsulation is performed by the
UDP/IP function, you can use the PHY Interface to connect to an external
100/1000 Ethernet PHY.
For fully featured MAC layer functionality, replace the PHY interface
with an Ethernet MAC IP core The UDP/IP function includes a top-level
design for the Altera Triple-Speed Ethernet MAC MegaCore function.
Signals

clk Input 1 125-MHz system clock.
rst Input 1 System reset.
Table 12. Register Access Signals

avalon_writedata Input 32 Write data.
avalon_readdata Output 32 Read data.
Preliminary
Table 13 shows the transmitter data input signals.
Table 13. Transmitter Data Input Signals

mac_tx_dav Output 1 Enable to data source.
mac_tx_dat Input 8 Data.
mac_tx_sop Input 1 Start of packet flag.
mac_tx_eop Input 1 End of packet flag.
mac_tx_ena Input 1 Data valid.
Table 14 shows the receiver data output signals.
Table 14. Receiver Data Output Signals

mac_rx_dat Output 8 Data.
mac_rx_sop Output 1 Start of packet flag.
mac_rx_eop Output 1 End of packet flag.
mac_rx_err Output 1 Error flag.
mac_rx_err_stat Output 23 Error status.
mac_rx_ena Input Output 1 Data valid.
Table 15 shows the PHY interface signals.
Table 15. PHY Interface Signals (Part 1 of 2)

phy_rst_n Output 1 Active low reset to the PHY.
phy_tx_clk Input 1 PHY transmitter clock (125 MHz for GMII or 25 MHz for
MII).
phy_rx_clk Input 1 PHY receiver clock (25 MHz for GMII and MII).
phy_gtx_clk Output 1 125-MHz GMII transmitter clock to PHY. The
phy_gtx_clk is an inverted version of the 125-MHz
system clock. If this signal does produce acceptable timing
results for the interface, use an alternative method to
generate phy_gtx_clk (for example, phase shift the
output from a PLL).
phy_tx_d Output 8 Transmitter data (use bits [3:0] for MII).
Preliminary
Table 15. PHY Interface Signals (Part 2 of 2)

phy_tx_en Output 1 Transmitter data valid.
phy_tx_err Output 1 Transmitter error flag.
phy_rx_d Input 8 Receiver data (use bits [3:0] for MII).
phy_rx_dv Input 1 Receiver data valid.
phy_rx_crs Input 1 Receiver carrier sense, not used.
phy_rx_col Input 1 Receiver collision detect, not used.
phy_rx_err Input 1 Receiver error flag.
phy_mdc Output 1 MDIO clock, which runs at 1/32 of the avalon_clk
frequency.
phy_mdio Input/output 1 MDIO data.
f For more information on how to write software to access the PHY

interface, refer to the UDP/IP software instructions in the UDP/IP
package.
RTP Transmitter
The RTP transmitter provides RTP encapsulation for TS packets. It can
encapsulate from one to seven TS packets per RTP packet. The
encapsulation logic can be bypassed if the input data is already RTP
encapsulated.
The RTP transmitter also generates CoP3 FEC packets for RTP
encapsulated TS. It supports one dimensional (column only) and two-
dimensional (row and column) FEC. You can interleave the generated
FEC packets with the original data stream according to COP#3 Annex A
or B.
TS data is received on the payload input. It is temporarily stored in

external RAM while the RTP packet is generated and the row and column
FEC data are updated. The encapsulated data is then transmitted on the
payload output with the interleaved FEC packets. Transmitter latency
through the generator is minimal. Figure 9 shows the RTP transmitter.
Preliminary
Figure 9. RTP Transmitter
RAM
RTP FEC Transmit Output

TS Payload
Encapsulator Generator Queue DMA
(Optional)
The design has an Avalon-MM master port for access to the storage RAM.
This can be connected to an internal RAM or external memory controller
with SOPC Builder.
RTP Encapsulation & FEC Generation

f For more information on RTP encapsulation and FEC generation, refer to
the Pro-MPEG CoP3 specification.
Parameters
Figure 10 shows the RTP transmitter IP Toolbench.
Preliminary
Figure 10. RTP Transmitter
Signals
Table 16. Signals

payload_clk Input 1 System clock for payload input and output.
payload_rst Input 1 System reset.
Preliminary
Table 17 shows the payload input signal.
Table 17. Payload Input Signals

payload_in_ready Output 1 Ready to payload source.
payload_in_channel Input 16 Channel identifier.
payload_in_data Input 32 Data (little endian).
payload_in_start Input 1 Start of packet flag.
payload_in_end Input 1 End of packet flag.
payload_in_error Input 1 Error flag.
payload_in_count Input 9 Word count. First word is 0, second is 1... This input is not
used if P_ADD_RTP is 1
payload_in_length Input 11 Payload length in bytes. For example, 188 for a single TS
packet or 1,328 for 7 TS packets plus RTP header.
payload_in_ Input 32 Timestamp for RTP header. This input is not used if
timestamp P_ADD_RTP is 0.
Table 18 shows the frame buffer RAM signals.
Table 18. Frame Buffer RAM Signals

fb_clk Input 1 RAM clock.
fb_rst Input 1 Reset for fb_clk domain.
gen_fb_* Input/Output – Avalon master for FEC generator (read/write).
dma_fb_* Input/Output – Avalon master for output DMA (read only).
Table 19 shows the payload output signals.
Table 19. Payload Output Signals (Part 1 of 2)

payload_out_ready Input 1 Ready from payload sink.
payload_out_ Output 16 Channel identifier. Bits [15:14] are a subchannel indication
channel for CoP3 FEC encapsulation. Use 00 for data packets, 01
for row FEC, and 10 for column FEC.
payload_out_data Output 32 Data (little endian).
Preliminary
Table 19. Payload Output Signals (Part 2 of 2)

payload_out_start Output 1 Start of packet flag.
payload_out_end Output 1 End of packet flag.
payload_out_error Output 1 Error flag.
payload_out_count Output 9 Word count.

f For more information on how to write software to access the RTP

transmitter registers, refer to the RTP software instructions in the RTP
package.
RTP Receiver
The RTP receiver provides the following features:
■ Large packet buffer for storage of received RTP or UDP payload

■ Packet reordering and duplicate removal based on RTP sequence
number
■ Optional Pro-MPEG FEC-based lost packet recovery
■ Buffer status information and payload output interfaces that support
external jitter control function
■ Receiver packet statistics
Figure 11 shows the RTP receiver block diagram.
Preliminary
Figure 11. RTP Receiver Block Diagram
RAM
RTP Input Input DMA Output DMA RTP Output
Channel Status
Status Output
FEC Decoder
RTP payload is accepted by the input DMA data sink interface and then
loaded to the buffer RAM. This RAM can either be on-chip or, more
typically, off-chip, depending on the amount of storage that you require.
FEC packets are stored separately to data packets in this RAM. Data
packets are stored in order of RTP sequence number. Reordered packets
are inserted at the appropriate place, and duplicated packets are
discarded. The buffer attempts to correct for missing packets using the
received FEC data. In UDP mode, packets are just stored in receive order.
Reordering, duplicate packet removal, and lost packet correction are not
supported.
Receiver event information and the level of the receiver buffer (number of
RTP or UDP packets) are presented on a status interface. An external
controller can use this information to decide when to request data from
the buffer, perhaps based on the current level.
When the video output requires data, the external controller requests a
payload packet from the receiver buffer. It is then presented with the
earliest packet received (from the bottom of the buffer). If the packet is not
available, an error indication is asserted. You can use this indication to
allow the external controller to pad the output stream with null data
when packets are missing.
The reference design has an Avalon-MM master interfaces for access to

the storage RAM. You can connect this interface to an internal RAM or
external memory controller using SOPC Builder.
The receiver buffer handles multiple independent receiver channels.
Preliminary
Parameters
Figure 12 shows the RTP receiver IP Toolbench.
Figure 12. RTP Receiver IP Toolbench
The receiver buffer has the following two main purposes:
■ Temporary storage of received packets for jitter removal;

■ Storage of data and FEC packets as required for lost packet recovery.
To choose the receiver buffer depth, typically allocate 2 × (L × D) to 3 × (L

× D) entries per channel to support the FEC decoder function (300 entries
for L × D = 100). You can then allocate additional entries per channel to
implement the jitter buffer. The number of additional entries depends on
the expected jitter profile and the received bit rate (for example, 4 Mbps
TS, 7 TS per RTP packet equates to 46 locations for 120-ms jitter buffer).
Preliminary
The RTP receiver stores FEC data separately to the received data payload.
There is a common pool of FEC storage locations that is shared by all
channels. The size of this pool depends on the receiver error profile.
Under normal conditions, only 2 to 3 entries are required per channel.
However, in the presence of burst error conditions on multiple channels,
a much larger number of entries (approximately (L + D) may be required.
Typically you make a trade off between the instantaneous error correction
capability of the design and the number of FEC entries that are allocated.
Each storage location (data and FEC) requires 1,536 bytes of RAM.
Interfaces
Signals

clk Input 1 System clock (typically 125 MHz).
Table 22 shows the receiver payload input signals.
Table 22. Receiver Payload Input Signals (Part 1 of 2)

payload_in_ready Output 1 Ready to payload source. The payload source should
respond to the negation of payload_in_ready in one
cycle.
payload_in_data Input 32 Payload data (little endian). The payload data consists of
the RTP header and RTP payload with any additional
encapsulation headers (for example, UDP/IP headers) and
footers (for example, MAC FCS) removed.
payload_in_start Input 1 Start of payload flag (assert to accompany first data word).
payload_in_end Input 1 End of payload flag (assert to accompany last data word).
Preliminary
Table 22. Receiver Payload Input Signals (Part 2 of 2)

payload_in_channel Input 16 Receiver channel identifier. The receiver channel numbers
are between 0 and P_CHANNELS - 1. Data and FEC
packets should use the same identifier.
payload_in_length Input 11 Payload length in bytes.
payload_in_ Input 32 Timestamp value to use if P_USE_LOCAL_TIMESTAMP is
timestamp 1.
Table 23 shows the buffer status signals.
Table 23. Buffer Status Signals (Part 1 of 2)

status_req Input 1 Status request. Assert and hold the status_req and
status_req_channel signals until status_ack is
seen. The status_ack signal is asserted for a single
cycle to accompany the status data.
status_req_channel Input 16 Channel identifier for status request.
status_ack Output 1 Acknowledge flag.
status_ack_depth Output 16 Current number of buffer entries for selected channel.
status_ack_depth_ Output 18 Difference between 90-kHz timestamp values of top and
time bottom entries in the buffer.
flush_req Output 1 Flush request. The flush request output is asserted in the
event of an exception in the receiver buffer, for example,
underflow, overflow, or large discontinuity in the received
RTP timestamps.
flush_req_channel Output 16 Channel identifier for flush request.
event_fifo_not_ Output 1 A 1 if the event FIFO buffer contains a message.
empty
event_fifo_fetch_ Input 1 Assert to request message from the event FIFO buffer.
req
event_fifo_fetch_ Output 1 Acknowledge flag for the request.
ack
event_fifo_fetch_ Output 16 Channel identifier for the read message.
channel
event_fifo_fetch_ Output 32 Depth for the read message.
depth
event_fifo_fetch_ Output 32 Depth (in time) for the read message.
depth_time
Preliminary
Table 23. Buffer Status Signals (Part 2 of 2)

event_fifo_fetch_ Output 32 Timestamp for the read message.
timestamp
event_fifo_fetch_ Output 5 FEC L for the read message.
fec_l
event_fifo_fetch_ Output 5 FEC D for the read message.
fec_d
event_fifo_fetch_ Output 5 FEC 1D for the read message.
fec_1d
debug_message_req Output 1 Asserted when there is a debug message.
debug_message_ Output 16 Channel identifier for the debug message.
channel
debug_message_ Output 32 Debug message data.
data
Table 24 shows the payload request interface.
Table 24. Payload Request Interface

payload_req Input 1 Payload request. Assert and hold the payload_req and
payload_req_channel signals until payload_ack
is seen. The payload_ack is asserted for a single cycle
to acknowledge the request.
payload_req_ Input 16 Channel identifier for payload request.
channel
payload_req_ack Output 1 Acknowledge flag.
payload_req_ack_ Output 1 Payload missing indication. If the requested payload is
error missing (RTP packet was not received),
payload_req_ack_error is asserted to accompany
payload_req_ack. No data will be provided on the
payload output interface for this case
Preliminary
Table 25 shows the payload output interface.
Table 25. Payload Output Interface

payload_out_valid Output 1 Data valid. Data is presented on the payload output
interface some time after the payload request has
completed, except when payload_req_ack_error is
asserted. All data must be accepted when it is presented
as it is not possible to flow control the data output.
payload_out_start Output 1 Start of payload flag (assert to accompany first data word).
payload_out_end Output 1 End of payload flag (assert to accompany last data word).
payload_out_ Output 16 Receiver channel identifier.
channel
Table 26 shows the RAM signals.
Table 26. RAM Signals

ram_clk Input 1 RAM clock. RAM access is synchronous to ram_clk,
which can be a different frequency to the main system
clock and should match the rate required by the memory
controller.
ram_rst Input 1 Reset for ram_clk domain.
input_dma_ram_* Input/output – Avalon master for input DMA RAM write access.
output_dma_ram_* Input/output – Avalon master for output DMA RAM read access.
fec_dma_ram_* Input/output – Avalon master for FEC DMA RAM read/write access.

Preliminary

f For more information on how to write software to access the RTP

receiver registers, refer to the RTP software instructions in the RTP
package.
TS Input
The TS input block takes TS input on a number of TS ports, and converts
this data into frames suitable for use by the RTP transmitter. These frames
are 32-bit little-endian packed versions of the TS data. Each TS port has its
own clock; the TS input block retimes the TS data onto its local system
clock.
Altera supplies the TS input block as an open source Verilog HDL

example. You can modify it to suit your system requirements or replace it
with your own implementation.
Figure 13 shows the TS input block diagram.
Figure 13. TS-to-RTP Block Diagram
TS
TS
Multichannel Output
Buffer
Input Frames
TS State
TS
Multichannel Machine
Buffer
Input
TS
TS Output
Multichannel
Buffer FIFO Buffer
Input
[
Preliminary
Up to 256 separate TS ports may be implemented, and each port can

support up to 256 separate channels. The total number of channels
supported by the system may not exceed 256, giving the following
options:
■ Up to 256 input ports with a single channel each

■ A single input port supporting up to 256 channels
■ Anything in between
This design consists of a number of input buffers and an output FIFO

buffer. One input buffer is required for each TS input, and is responsible
for conversion of TS data on its associated port into frames suitable for
use by the RTP transmitter. Each input buffer pushes pointers to its
completed frames into the output FIFO buffer. A state machine arbitrates
between the various buffers to control FIFO pushes. Items are popped
from the FIFO buffer one by one, causing requests to the corresponding
buffer to drive the output. Control of the output port is multiplexed
between the buffers based on the request signals.
Parameters
Table 28 shows the TS input parameters.
1 The product of P_NUM_INPUTS and

P_NUM_CHANNELS_PER_INPUT must be between 1 and 256.
Table 28. TS Input Parameters
Default
Name Use
Value
P_NUM_INPUTS 2 The number of TS input ports.
P_NUM_CHANNELS_PER_INPUT 1 The number of channels per TS input port.
Signals
Preliminary
Table 29 shows the TS input signals.
Table 29. TS Input Signals
Name Direction Width (1) Description

ts_channel Input N × 16 The channel associated with this packet. TS data on
port 0 must have ts_channel set to between 0 and
P_NUM_CHANNELS_PER_INPUT – 1. On port 1 it
must be between P_NUM_CHANNELS_PER_INPUT
and 2 × P_NUM_CHANNELS_PER_INPUT – 1 and so
on.
ts_clk Input N TS clock. If ts_clk is set to 1, connect the common
clock to ts_clk[0].
ts_data Input N×8 Data.
ts_timestamp Input N × 32 The timestamp for the packet.
ts_valid Input N Data valid.
ts_start Input N Start of packet.
ts_error Input N Error. Assert ts_error if a TS packet is terminated
early because of error, which forces the packet to be
discarded.
ts_ready Output N Flow control to TS source. The ts_ready signal is
negated if the input buffer is full. If the TS source
cannot be flow controlled, ensure that the input data
rate is less than the RTP packet output rate.
Note to Table 29:

(1) N represents the number of channels. For the ts_data input, the data for channel 0 is connected to
ts_data[7:0]; the data for channel 1 to ts_data[15:8]...
Table 30 shows the frame output signals.
Table 30. Frame Output Signals

payload_clk Input 1 System clock.
payload_rst Input 1 System reset.
payload_out_ready Input 1 Ready from data sink. Data is presented in a burst on
the output when payload_ready is asserted. The
source responds to the negation of payload_ready
in one cycle.
payload_out_channel Output 16 Channel identifier.
payload_out_data Output 32 Frame data (little endian).
Preliminary
Table 30. Frame Output Signals

payload_out_start Output 1 Start of packet flag.
payload_out_end Output 1 End of packet flag.
payload_out_error Output 1 Error flag.
payload_out_count Output 9 Word count (first word is 0).
payload_out_length Output 11 Packet length in bytes—188 or 204.
payload_out_ Output 32 Timestamp associated with this frame, which matches
timestamp the timestamp of the first TS packet within this output
frame.

f For more information on how to write software for this module, refer to
the software instructions that come with the reference design.
RTP-to-TS
The RTP-to-TS block generates a TS output from received RTP packets. It
connects directly to the RTP receiver.
Altera supplies the RTP-to-TS block as an open source Verilog HDL

example design. You can modify it to suit your system requirements or
replace it with your own implementation.
1 The constant bit rate output function that can be optionally

enabled is for demonstration only and is not necessarily a valid
solution for addressing network induced jitter.
Preliminary
Figure 14 shows the RTP-to-TS block diagram.
Figure 14. RTP-to-TS Block Diagram
Output TS Output 1
Buffer
Channel 1
Output TS Output 0
Payload Buffer
Channel 0
Event Ready
Status Request Output
Status Control
Payload Register Ready
Interfaces

clk Input 1 System clock.
Table 23 on page 27 describes the event, status request, and status signals.
Table 33 shows the payload request signals.
Table 33. Payload Request Signals

payload_req Output 1 Payload request to receiver buffer.
payload_req_ Output 16 Channel identifier for payload request.
channel
Preliminary
Table 33. Payload Request Signals

payload_req_ack Input 1 Acknowledge flag.
payload_req_ack_ Input 1 Payload missing indication.
error
Table 34 shows the payload input signals.
Table 34. Payload Input Signals

payload_out_start Output 1 Start of payload flag.
payload_out_end Output 1 End of payload flag.
payload_out_channe Output 16 Receiver channel identifier.
l
Table 35 shows the TS output signals.
Table 35. Output Signals
Width
Name Direction Description
(1)
ts_clk Input 1 TS clock.
ts_rst Input 1 Reset for ts_clk domain.
ts_valid Output N TS valid flag.
ts_data Output N×8 TS data. N represents P_CHANNELS. For ts_data there
are 8 bits per TS. Data for TS 0 is presented on
ts_data[7:0]; data for TS 1 on ts_data[15:8]...
ts_start Output N TS start of packet flag.
ts_end Output N TS end of packet flag.
Note to Table 35:

(1) N represents the number of channels. For the ts_data input, the data for channel 0 is connected to
ts_data[7:0]; the data for channel 1 to ts_data[15:8]...
Preliminary
Width
(1)
f For more information on how to write software for this module, refer to
the software instructions that come with the reference design.
Testbench Altera provides a test-vector based testbench. Figure 15 shows the

structure of the testbench.
Figure 15. Testbench
TS Device Split Ethernet

Inputs Under Test Channels Outputs
TS Basic Combine Ethernet

Outputs Demonstration Channels Inputs
Software
Testbench
Settings
Test
Settings
The testbench includes a single set of test vectors, which exercise the
major features of the reference design over two bidirectional channels,
and are sufficient for performing an out-of-the-box check of the reference
design.
The test vectors consist of the following items:
Preliminary
Getting Started
■ Transmit test vectors—TS input and Ethernet output vectors for each
channel, in the tb/vectors/test0 directory
■ Receive test vectors—Ethernet input and TS output vectors for each
channel, in the tb/vectors/test0 directory
■ A testbench configuration file, testbench_settings.v, in the
tb/vectors/test0 directory
■ A software configuration file for use with the basic demonstration
software, test_settings.h, in the software directory.
The device under test consists of the ts_ethernet_bridge reference

design hierarchy level, which is the highest level in the design hierarchy
that is not tied specifically to a demonstration board. However, some
parameters are specific to the demonstration board type, such as the
memory architecture. These parameters are specified when the test is run.
For more information, see “Simulate the Reference Design” on page 42.
Getting Started This section includes the following sections:
■ “System Requirements” on page 37

■ “Install the Reference Design” on page 38
■ “Setup Licensing” on page 39
■ “Compile the Reference Design” on page 40
■ “Compile the Example Software” on page 40
■ “Simulate the Reference Design” on page 42
System Requirements
Table 37 shows the demonstration hardware requirements.
1 There are two demonstrations: a Cyclone II demonstration on

the Nios II Development Kit, Cyclone II Edition; and a
Stratix II GX demonstration on the Audio Video Development
Kit, Stratix II GX Edition.
Table 37. Hardware Requirements
Hardware Manufacturer
Nios II Development Kit, Cyclone II Edition Altera Corporation
Audio Video Development Kit, Stratix II GX Edition Altera Corporation
DBGIG1 Gigabit Ethernet PHY Module (1) Richter Industrie
Elektronik,
www.devboards.de
Preliminary
Table 37. Hardware Requirements
Hardware Manufacturer
DBASI ASI Module (1) Richter Industrie
Elektronik,
www.devboards.de
TS source and analyzer –
Ethernet switch (optional) –
DHCP server (optional) –
Note to Table 37:

(1) Required only for the Nios II Development Kit, Cyclone II Edition.
The demonstrations requires the following software:
■ A PC running the Windows 2000/XP operating system

■ Quartus® II version 6.1
■ ModelSim-Altera simulator version 6.1
■ Nios II processor version 6.1
Install the Reference Design

Altera supplies the reference design as a package of executables. There
are separate executables for each of the design blocks and one for the
reference design.
Run each executable individually and follow the installation instructions.

You must accept the terms of the Altera Hardware Reference Design
License Agreement.
1 The default installation directory for the design blocks is

c:\altera\megacore. You can change the default directory
during the installation.
1 The default installation directory for the reference design is

c:\altera\reference_designs. You can change the default
directory during the installation.
Figure 16 shows the directory structure of the reference design.
Preliminary
Getting Started
Figure 16. Directory Structure

an374
demo
Contains .sof and .elf for the two demonstrations.
doc
Contains the documentation.
examples
Contains the Quartus II project for the demonstrations.
demo_2c35
Contains the Quartus II project files for the demonstration for the Nios II Development
Board, Cyclone Edition.
demo_2sgx
Contains the Quartus II project files for the demonstration for the Audio Video
Development Kit, Stratix II GX Edition.
software
Contains the software files.
source
Contains the source files.
demo
Contains the top-level source code for the demonstrations.
rtp_ts
Contains the RTP-to-TS function.
ts_input
Contains the TS input function.
tb
Contains the testbench files.
Setup Licensing
The reference design requires licenses for the following features:
■ Altera Nios II Processor

■ Altera DDR SDRAM Controller MegaCore function v6.1
■ Altera UDP/IP function—license BC02
■ FEC functions (optional)—license BC03
If you compile the design without all the licenses it uses the OpenCore
Plus evaluation feature, which generates a time-limited programming
file.
You only need to obtain licenses for the megafunctions when you are
completely satisfied with their functionality and performance, and want
to take your design to production.
f For more information on OpenCore Plus hardware evaluation, see

AN 320: OpenCore Plus Evaluation of Megafunctions.
Preliminary
Compile the Reference Design

To compile the reference design with the Quartus II software, follow these
steps:
1. To create a Quartus II project for the reference design, in a command

prompt, run the\examples\demo_<device>\make_project.bat
batch file.
2. Open the generated Quartus II project, demo_<device>.qpf.
3. Start SOPC Builder—on the Tools menu click SOPC Builder.
4. In SOPC Builder, click Generate.
5. When the generation is complete, click Exit to close SOPC Builder.
6. For the Stratix II GX demonstration only, edit the asi_rx.v and

asi_tx.v variation files and update using the MegaWizard Plug-In
Manager.
7. Compile the design, by clicking Start Compilation on the

Processing menu.
Compile the Example Software

Altera supplies some example software to support basic demonstration
and simulation of the reference design. This software initializes the
design and allocates the UDP/IP sockets for each TS.
1 This software does not provide the web interface for the
advanced demonstration.
To compile this example software, follow these steps:
1. Start the Nios II IDE (Start > Programs > Altera > Nios II EDS 6.1 >
Nios II IDE.
2. On the File menu point to New and click Nios II C/C++

Application.
a. Type basic_demo in the Name box (see Figure 17).
b. Specify the SOPC Builder System as sopc_system.ptf from

either the examples/demo_2c35 or examples/demo_2sgx
directory.
Preliminary
Getting Started
c. For CPU, select cpu.
d. Click Blank Project as the project template.
e. Click Finish.
Figure 17. New Nios II C/C++ Project
3. Right click on your new project in the projects pane of the Nios II
IDE and click System Library Properties.
a. To simulate the software only, turn on ModelSim only, no

hardware support.
b. To use the software on real hardware, turn off ModelSim only,

no hardware support.
4. Right click on your new project in the projects pane of the Nios II
IDE and click Import.
Preliminary
a. Expand General and click File System.
b. Click Next.
c. Browse to the \software directory.
d. Turn on the software checkbox and click Finish.
5. Build the basic_demo project, by clicking Build All on the Project

menu.
You may now either simulate the software or execute it in hardware on

your demonstration board.
Simulate the Reference Design

You can simulate your design using the IP Toolbench-generated IP
functional simulation models.
You can use the IP functional simulation model with any

Altera-supported VHDL or Verilog HDL simulator.
The IP Toolbench-generated IP functional simulation models, which you

generated in “Compile the Reference Design” on page 40, are Verilog
HDL models. You can specify VHDL IP functional simulation models, but
these models have not been verified.
f For more information on IP functional simulation models, refer to the

Simulating Altera in Third-Party Simulation Tools chapter in volume 3 of
the Quartus II Handbook.
The reference design includes a batch file, run_simulation.bat, in the

examples/demo_2c35/sopc_system_sim or
examples/demo_2sgx/sopc_system_sim directory. You can edit this file
to reference your installation of the ModelSim simulator, and then use it
to compile and elaborate the design and display a selection of waveforms.
The testbench stimulates the design with TS and Ethernet stimulus from
test vectors, and compares the output of the design with further test
vector sets. On completion, the testbench provides a pass/fail indication.
Use the To use the demonstration, follow these steps:
Demonstration ■ Set Up the Hardware

■ Download the Hardware & Software Images
■ Assign an IP Address
■ Control the Design With a Web Interface
Preliminary
Use the Demonstration
■ TS-to-Ethernet Demonstration
■ Ethernet-to-TS Demonstration
■ Use VLC Media Player
Set Up the Hardware

To set up the hardware, follow these steps:
1. Plug the DBGIG1 Gigabit Ethernet PHY Module in to the PROTO2

expansion connector on the Nios II development board, Cyclone
Edition.
2. For ASI connectivity, plug the DBASI module in to the PROTO1

expansion connector.
3. Connect the LCD module into the DBASI pass-through connector.
4. For TS-to-Ethernet, connect an ASI source to DBASI connector

CON3. For Ethernet-to-TS, connect an ASI analyzer to DBASI
connector CON2.
5. Connect the demonstration system to your evaluation network with

a Cat5E cable plugged in to the DBGIG1 Gigabit Ethernet PHY
Module.
1 The design supports both 100-Mbps and 1-Gbps Ethernet

and you can connect it to an Ethernet switch or directly to a
computer network interface card.
6. Power up the board.
c Do not plug a CompactFlash device in to CON3 of the Nios II

development board, Cyclone Edition when running this
demonstration.
For an end-to-end system demonstration, configure a second set of

hardware in the same manner. Use an Ethernet switch to connect the two
demonstrations systems and the control computer.
The DBASI module provides ASI connectivity for the design. For a
parallel connection to the TS test equipment, use the Nios II development
board, Cyclone Edition PROTO1 J11 connector. Figure 18 shows the
signals on the connector.
Preliminary
Figure 18. J11 Signals
N/C 1 2 GND
TS_OUT_DATA[1] 3 4 TS_OUT_DATA[0]
TS_OUT_VALID 11 12 N/C
N/C 13 14 N/C
TS_IN_VALID 15 16 TS_IN_START
TS_IN_DATA[1] 17 18 TS_IN_DATA[0]
GND 19 20 N/C
TS_IN_DATA[2] 21 22 GND
TS_IN_DATA[3} 23 24 GND
TS_IN_DATA[5] 27 28 TS_IN_DATA[6]
TS_CLK 31 32 N/C
N/C 33 34 N/C
N/C 35 36 TS_OUT_START
N/C 37 38 N/C
N/C 39 40 GND
Table 39 shows the signals.
Table 38. J11 Signals

TS_IN_DATA Input The TS source for the TS-to-Ethernet
design. Sampled on the falling edge of
TS_CLK.
TS_IN_VALID Input Must be asserted to accompany valid
bytes on TS_IN_DATA.
TS_IN_START Input Must be asserted to identify the first
byte in the TS packet. The data does
not have to be presented in packet form
(idle clocks between data bytes are
OK).
Preliminary
Table 38. J11 Signals

TS_CLK Input 27-MHz clock. You must connect a
clock to TS_CLK, otherwise the design
does not work.
TS_OUT Output Generated on the rising edge of
TS_CLK. The constant bit rate output
mode for the Ethernet-to-TS design
requires 27 MHz.
TS_OUT_DATA Output The TS recovered from Ethernet by the
Ethernet-to-TS design.
TS_OUT_VALID Output Asserted to accompany valid data
bytes on TS_OUT_DATA.
TS_OUT_START Output Asserted to accompany the first byte of
the TS packet. The data is presented in
packet form.
The PROTO1 connections are isolated from the FPGA by analog switches.
The output voltage level is 3.3 V. Input voltage levels can be between 3.3
V and 5 V.
Download the Hardware & Software Images

If the Nios II development board and Cyclone Video Demonstration
Board are not preconfigured with the demonstration design, follow these
steps to download the hardware and software images. The programming
files required can be found in the reference design demo directory.
7. Program the Nios II development board with the hardware image

demo_2c35.sof with the Quartus II Programmer
8. Program the Nios II development board with the software image

web_demo_2c35.elf by typing the following command in a Nios II
SDK Shell:
nios2-download –c USB-Blaster -r –g web_demo_2c35.elf
Assign an IP Address
The demonstration design requires an IP address, which can either be
assigned by a DHCP server connected to the demonstration network, or
by pressing a switch on the Nios II development board at boot time.
Preliminary
When the design boots, it looks for a DHCP server on the network. If a
server is found and an IP address is allocated, the design uses this
address. The LCD module displays the allocated IP address.
If no DHCP server is present, the software times out after 10 seconds. The
LCD module displays that no DHCP server has been found and the seven
segment LEDs show --. The design asks you to press a button on the
Nios II development board. The button selects a static IP address. As each
system on the demonstration network must have a unique address, press
a different button on each Nios II development board that you are using.
Table 39 shows the buttons’ fixed IP addresses.
Table 39. IP Addresses
Button IP Address
SW0 192.168.1.10
SW1 192.168.1.11
SW2 192.168.1.12
SW3 192.168.1.13
The computer that controls the design through the web interface must be
able to communicate with the IP address allocated to the board, so assign
it an address that is on the same IP subnet, for example, 192.168.1.1.
Control the Design With a Web Interface

When you assign the demonstration an IP address, you can control it
through a web interface. Enter the IP address of the board as the address
of the page you wish to view in your web browser (for example,
http://192.168.1.10). The browser display the welcome page for the
demonstration. Click on the link at the bottom of the welcome page to
access the parameters page (see Figure 19).
Preliminary
Figure 19. Parameters
The web interface has the following pages:
■ The Parameters page controls the design parameters and settings.

■ The Statistics page provides status and statistics information from
the design. The values are updated every time the page is refreshed.
Preliminary
■ The Messages page displays diagnostics messages that are produced

by the Ethernet-to-TS design. Advanced use only.
■ The Monitor page provides access to eCos monitoring functions.
TS-to-Ethernet Demonstration
The TS-to-Ethernet (transmitter) demonstration shows the design
transmitting TS data on to the IP network. The demonstration supports
two independent channels, but both are driven by the same TS source
data.
The global transmitter settings section on the parameters page controls

the parameters that are common to all the transmitter channels.
The transmitter channel settings section controls the individual

parameters for each transmitter channel. Click on the channel number to
go to the editing page for that channel. When changes are made, click
Submit then return to the parameters page. To enable a transmitter
channel, turn on the appropriate enable, then click Submit.
The force packet loss setting controls a test fixture that allows the
transmitted Ethernet packets to be corrupted to model a burst loss in the
network. This test is only applied to transmitter channel 0.
The statistics page for the transmitter demonstration just shows the
number of Ethernet frames that are generated for each channel, plus a
summary of the Ethernet and external RAM bandwidth.
Ethernet-to-TS Demonstration
The Ethernet-to-TS (receiver) demonstration shows the design receiving
TS data from the IP network. The demonstration supports two
independent channels. By default, channel 0 is connected to the TS output
connector. You can connect channel 1 instead by pressing and holding
button SW0 on the Nios II development board, Cyclone II edition.
The receiver channel settings section on the parameters page controls the
sockets that are matched for the receiver channels. You can ignore the
global transmitter settings and transmitter channel settings sections. To
change the socket for a receiver channel, click on the channel number to
go to the editing page. Once changes are made, click Submit then return
to the parameters page. To enable a receiver channel, turn on the
appropriate enable then click Submit.
The receiver has optional support for a constant bit rate output mode on
receiver channel 0. To enable this support, turn on CBR mode in the
editing page for the receiver channel. This mode only works for a
Preliminary
constant bit rate TS running at the programmed rate. If the rate you select
does not match the bit rate of the stream, buffer overflow or underflow
occurs.
The statistics page for the receiver demonstration shows the number of
Ethernet frames that are received for each channel, statistics from the
receiver buffer, and FEC decoder, plus a summary of the Ethernet and
external RAM bandwidth.
Use VLC Media Player

The VideoLAN Client (VLC) media player is a software application that
you can use to display video received from the network, and transmit
video to the network.
For the transmitter demonstration, VLC media player can display the
video being transmitted by the demonstration by setting it to match the
UDP/RTP multicast socket that it uses.
1 Sometimes the VLC decoder may report errors (for example, lost
RTP packets or TS discontinuity errors) even though the traffic
on the network is correct. These errors can be caused by load on
the processor or network interface of your computer. The errors
do not necessarily indicate that there is a problem in the
transmitter traffic. Altera recommends a professional receiver
application, such as an IP based IRD or Altera's Ethernet-to-TS
design.
For the receiver demonstration, you can use the VLC media player to
source the network traffic by streaming a TS file to the RTP multicast
socket that the demonstration uses.
1 VLC media player re-encapsulates the TS data read from the

source file. Also, it does not produce a constant bit rate output
and can introduce large amounts of jitter in the transmitted
stream. Therefore, it is not a suitable source to use when the TS
output from the demonstration is feeding a modulator or
decoder that requires a low jitter or constant bit rate TS.
Preliminary
Copyright © 2007 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

An374-V2 3

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An374-V2 3

Uploaded by

Copyright:

Available Formats

Video Over IP Reference

March 2007, Version 2.3 Application Note 374

The reference design includes a demonstration for the Nios® II

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

Altera has an ASI MegaCore function.

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 (for example,

Functional Figure 1 shows reference design block diagram.

Figure 1. Block Diagram

DDR Flash SSRAM

DDR SDRAM Nios II

SOPC Builder System

Altera provides two demonstrations: a Cyclone II demonstration, which

Reference Design System

■ The main design elements:

■ A Nios II processor for control of the design

The SOPC Builder system is instantiated in a top-level design

Figure 3 shows the SOPC Builder system.

Figure 2. SOPC Builder System

If you want to use a different processor or external memory for your

■ Hardware UDP, IP, and (optional) Ethernet MAC encapsulation for

Figure 3 shows the UDP/IP function block diagram.

Figure 3. UDP/IP Function Block Diagram

Host Transmitter Transmit Socket

Payload UDP/IP MAC

Statistics Receive Socket

The transmitter path receives MPEG TS data from the transmitter

A register mapped interface is provided to allow the host processor to

Buffering, queuing, and arbitration is provided to allow the simultaneous

UDP/IP Network Encapsulation

Table 1. Ethernet MAC Layer

Field Width (Bits) Value

Table 2 shows the IP layer.

Table 2. IP Layer (Part 1 of 2)

Field Width (Bits) Value

Table 2. IP Layer (Part 2 of 2)

Field Width (Bits) Value

Table 3 shows the UDP layer.

Table 3. UDP Layer

Field Width (Bits) Value

Receiver Socket Matching

If you want to implement a different algorithm for the receiver packet

Host Packet Transmission

Figure 4. Data Flow for Host Transmission

To transmit frames to Ethernet, the host processor first requests a pointer

Figure 5. Host Transmitter Flow Diagram

Initialize the host Transmit Channel

Fetch pointer from Buffer Free List

Write frame data to allocated location in Frame

Write frame length to Parameter Word

Load pointer to Host Transmit Queue

Wait for transmit to complete

Return pointer to Buffer Free List

Host Packet Reception

Figure 6. Data Flow for Host Reception

Figure 7. Host Receiver Flow Diagram