Excelfore Ethernet AVB Software Architecture on ARM Cortex SOCs (White Paper)

AVB software architecture
on ARM Cortex SOCs
Document Number:
990901-FR-60-0108-1

December12, 2012

Shrikant Acharya
CTO

Excelfore Corporation
43255 Mission Boulevard
Fremont, California 94539 USA

Copyright Notice: © 2012 Excelfore Corporation
This document contains proprietary information of Excelfore Corporation. No part of this document may be
reproduced, stored, copied, or transmitted in any form or by means of electronic, mechanical, photocopying or
otherwise, without the express consent of Excelfore Corporation. This document is intended for the recipient only
and not meant for distribution.

© Excelfore Confidential

Excellence in Connected Automotive Systems

Table of Contents
1 Introduction ........................................................................................................................... 1
2 Need for AVB in Industry .................................................................................................... 1
3 AVB System Glossary ........................................................................................................... 2
4 Basic System Setup ............................................................................................................... 3
5 Multi-display Projection System under AVB Components .............................................. 4
5.1 Linux Ethernet Driver ..................................................................................................... 4
5.2 Gstreamer ........................................................................................................................ 4
5.3 Media Clock/Vsync Phase Synchronization ................................................................... 5
5.3.1 gPTP (Precision Time Protocol) ................................................................................. 6
6 AVB System Block Diagram ................................................................................................ 7

© 2012, Excelfore Corporation


1 Introduction
This document is a white paper that describes an AVB S/W Architecture implemented
on ARM Cortex A8 Silicon with an integrated Ethernet 1588 MAC.

More specifically the AVB implementation is created on a Texas instruments Centaurus
Platform (TI‐814X).

2 Need for AVB in the Industry
Traditional clocking synchronization in networked A/V systems is elaborate means.  In
the automotive sector, the clock synchronization of displays and multi‐channel audio in
an infotainment platform is implemented using the MOST.  MOST Bus is an isochronous
environment.  In the Pro‐A/V area the displays are synchronized through a combination
of separate master clock control link and fixed delay compensation depending on the
length of the control link.  Synchronization thus has been a tedious and time consuming
exercise.  Standard Ethernet does not provide QoS and it is an asynchronous
environment, although topologies exist to provide it today.

The Ethernet AVB Protocol (IEEE1722+IEEE1588 or 802.1AS) in one such standard that o
formally brings a QoS and synchronization implementation to the Ethernet.  By
providing global time synchronization mechanism combined with a protocol of
prioritization of streams as they pass through switches, makes the Ethernet Isochronous
like the MOST bus. Ethernet AVB protocol will allow the widespread proliferation of
Ethernet in Automotive, Pro‐AV and Pro‐Audio systems.

Examples of Ethernet AVB application are:
1) Automotive ADAS in surround camera architecture
2) Automotive Infotainment End points
3) Pro A/V video wall projection system and
4) Multichannel Sound system for Automotive, Studio Environments.

© 2012, Excelfore Corporation Page 1


Automotive ADAS Surround Cameras need to bring the video snap shots at the same
time to the driver from various points on the car, Pro AV Video Walls applications need
to have synchronization across all screens so as to project images that are spread over
multiple screens. Ethernet AVB Automotive Infotainment Endpoints have to synchronize
the displays and the separate multichannel amplifier sound system and the Wireless
Multichannel Audio that needs to synchronize the delays amongst spatially arranged
speaker systems.

This document presumes the reader has a working knowledge of the standards such as
IEEE 1722, IEEE 1588 and IEEL 802.AS standards that encompass Ethernet AVB.

3 AVB system glossary
ADAS: Advanced Driver Assistance System
A/V:    Audio Video System
AVB Switch:  Ethernet Switch or Hub that is compliant with IEEE1722 and 802.1AS
specifications.
Infotainment Systems: Center Stack in a car that houses the Media playback of audio
and video, system, navigation, phone connectivity using BT etc.
BT: Blue tooth hands free technology
Listener:  System that received a/v packets and synchronization signals. The a/v packets
are decoded and presented to a screen.
MOST: Media Oriented Systems Transport
PST: Presentation time stamp. These accompany the image payload header.
Pro A/V: Professional Audio Video
QoS: Quality of Service
Sync Packets:  Timing synchronization packets that providing timing signals for all slave
nodes to be in sync.
Talker: Typically a camera system or a stream encoder that encodes video signals and
formats them as IEEE1722 envelope.



4 Basic system setup
The basic configuration of an AVB application system is shown in the Figure 1.   It
consists of four HD displays, each having an ARM Cortex A8, Centaurus system which
acts as listeners.  An AVB switch feeds each of the listener systems with a time
synchronized HD stream from a talker.

A full HD stream is encoded at the talker which is time stamped and sent to the AVB
switch for distribution to the listener’s destination addresses.  Each Centaurus Listener
will decode the complete image that it receives and using the video scalar crop the
image to a quarter of its size for the specific spatial quadrant.  The cropped image which
is now a quadrant will then be scaled up to the resolution of the display.

E.g., the full image represents a resolution of 1920x1080, a quadrant shall represent
960x540.  Each of the displays in the Figure 1., are HD resolution displays (1920x1080).
So a scalar will take the quadrant image of 960x540 and scale it back to the displays
resolution.
Each listener will use the time stamps and the vsync time synchronized to the gPTP
clock.



5 Multi-display projection system under AVB
components
5.1 Linux Ethernet driver
The Linux Ethernet driver services the network connection for the Ethernet AVB stack.
The driver is written with a raw Ethernet socket and not as TCP/IP socket. Excelfore has
a clock timing event (CPTS timing event) support in the TI Linux network kernel driver on
the A8.  This allows the AVB timing to be implemented.  The Kernel driver uses the
hardware assist available in the Ethernet MAC (1588 Timing Extractor) to get access to
the master network clock counter data. This data is used to synchronize all clock events
in the listener as shown in Figure 2.0.  This driver processes all “Sync” Packets coming
through the network.  Other payloads are passed to upper blocks for processing.

5.2 Gstreamer
The AVB System will use the open source Gstreamer. Gstreamer is a library for
constructing graphs of media‐handling components. The applications it supports range
from simple audio playback, audio/video streaming to complex audio (mixing) and video
(non‐linear editing) processing Multimedia streams.  Gstreamer will be used for the
video decoder, scaling and presentation.

TI supports Gstreamer through their Openmax Codec components.  Gstreamer will
provide greater flexibility than using the TI Openmax components directly.  Special
features such video cropping, video scaling etc., are better handled in Gstreamer.

Standard support for IEEE1722 packets is available as part of the AVB stack from
Excelfore. However interfaces for specialized protocols e.g. RTP can be provided as part
of the delivery.

A standard list of filters to enable multimedia components is provided with the SDK.   .
These will include all components of the filter graph using helpers e.g. play bin, decoder
bin.


The PST has to be extracted from the encoded stream received at the listener and made
available at the start of presentation while the compressed image is decoded and ready
to be displayed.  Attention has to be paid to Frame reordering for display as Frames are
compressed and ordered differently for ease of decoding.  We are unlikely to have B
frames in our h.264.  Regardless even if the decoder uses only I or both I & P frames,
there needs to be time stamps.

We recommend that the Talker multicast a single HD stream to all four listeners.  An
optional method available is to transmit four separate HD streams, one for each
listener, but this requires four times the bandwidth. There is a HD stream decoder in
each listener box.

The video renderer will time the presentation of decoded frames based on the Media
clock using PTS (Presentation time stamps).  For typical video projection applications,
only video needs to be synchronized.

For all the flexibility that is provided by gStreamer, it does come with added overhead
for processing which can become a bottleneck. If CPU processing has to be optimized
then a more compact scheme is recommended that by passes the gStreamer
framework.

5.3 Media Clock/Vsync phase synchronization
VSync synchronization will be provided in video driver.  System clock has to be
synchronized with the Ethernet clock. This system clock then synchronizes the Media
clock.

During initialization, the talker will send messages to synchronize Vsyncs for all the
listeners at a point of time in the future. All four listeners will then reset their video
controller at their prescribed time on the receipt of the sync message. Once this sync



event happens, at every Vsync Interrupt the System clock is monitored to make any
adjustments to the video clock frequency, to maintain the synchronization.  This is the
phase synchronization of the Vsync.

A mechanism has to be added that will allow all systems to synchronize and start their
presentation at the same time.  The control system can decide how to move the video
during the vsync interrupt e.g. if it is slow to skip a frame and if faster, then to repeat a
frame.  A VCO controller HW clock can make things easier as it provides more precise
timing control.

All video controller system setup is the same with every Centaurus platform.  First the
video driver has to be synchronized. Then every listener has to be setup with precise
time so as to start in sync. There is some maintenance code that is running during the
vsync interrupt to make sure that clocks in the listeners are not drifting away and are
under control.

When the system boots up the video is going to be free running and there may not be a
control. However control can be exercised through the video driver and a reset can be
executed at a specified system time. Video can be disabled and then enabled on a
specified time e.g. a system message can be issued to have a reset in 1ms.  Target is to
maintain Vsync Synchronization across all four talkers at a precision better than 1ms
drift.

5.3.1 gPTP (Precision Time Protocol)
The CPTS driver is already implemented on the Centaurus using the HW time stamp in
the kernel space.  A PTP daemon can be created in user space that can access this HW
time stamp.  The Ethernet clock available through the network should sync the HW time
stamp in the listener. This will phase lock the video clock to the Ethernet clock.   Video
driver also accesses the HW time stamp as shown in the diagram. All 4 or five systems
are phase locked with some jitter but within the limits.


Although the SOW recommends using ptpdv2 approach to timing synchronization, a
more consistent approach would be to use gPTP for both the PC and the EVM.  Our
belief is that TI used the ptpdv2 approach as expedient on the PC side when they
developed the Linux code for the PC. On the EVM side TI continues to use the gPTPd.
Sirius modified ptpd code is unified for both PC Linux and TI BIOS6. It can be easily
applied for TI Linux. If the “cpsw” driver works on the EVM boards without any issues
then we can integrate the current code to work on TI Linux.

6 AVB system block diagram
The AVB Pro A/V system has six components to control the delivery of synchronized
video from talker to the listeners.
The components have already been described above. This block diagram provides the
interaction between the blocks.
The system components are

1. Linux Kernel Drivers

2. Network Driver

3. CPTS Driver

4. 802.1AS gPTP Timing

5. Video Application

6. Gstreamer

7. Video Sub System

8. Video Out HW Clock

The payload and sync timing data is received in the Network Driver.  The sync timing
messages are passed to the CPTS driver for clock synchronization to the 802.1AS block,
while the video payload is forwarded to a TCP/UDP driver which forwards the packets to
Gstreamer.



Video Application builds the filter graph and provides the higher level messages for
video presentation e.g. Play, Start, Stop, FF, RW.  The video payload gets decoded,
formatted and made available to the Video Sub System for a presentation.  A high
precision clock source which is phase locked with the Clock Driver Sync, is used to
generate the System clock and the CPTS clock.  The System clock synchronizes the video
sub‐system clock, Media clock and 802.1A gPTP layer.  The CPTS clock drives the CPTS
HW Timestamp control, which is then made available to the gPTP layer.  Synch
Messages which come as raw Ethernet packets and are presented to the gPTP layer.  Th
e802.1AS layer, phase locks the clock driver to the Ethernet clock.   The Source clock
provides triggers to the clock driver and the system clock. The System and Clock driver
serve as inputs to the CPTS system which is being synchronized with the system time
through the sync messages.
The System clock is made available to the entire system block to synchronize their
operations.


Excelfore Ethernet AVB Software Architecture on ARM Cortex SOCs (White Paper)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Excelfore Ethernet AVB Software Architecture on ARM Cortex SOCs (White Paper)

Similaire à Excelfore Ethernet AVB Software Architecture on ARM Cortex SOCs (White Paper) (20)

Dernier

Dernier (20)

Excelfore Ethernet AVB Software Architecture on ARM Cortex SOCs (White Paper)