Sienda Time Sensitive Network Stack - Architecture Guide

_{^{Updated March 2023. Content subject to change. Copyright (c) 2023 Sienda Multimedia Ltd. All rights reserved.}}

🢀 Back to main documentation page

Introduction

AVB systems are complex embedded realtime systems, with a number of separate components that must interact in specific and time-critical ways to ensure correct functioning of the whole system.

This architecture guide attempts to give an overview of a typical AVB Audio device and describes some of the components and their (sometimes complex) interactions. It assumes that the Sienda TSN stack will be used as the core of the system and aims to detail the system and hardware requirements of an AVB audio device.

In the guide the terms AVB, TSN and Milan are used interchangeably. Where any reference is made to one, each applies equally, unless explicitly stated otherwise.

The Stack Library

The Sienda TSN stack is a monolithic networking library that incorporates all the required protocol handling to support AVB/TSN/Milan in an endpoint device. The stack provides the ‘brains’ of the endpoint, but to interface with the outside world it requires embodiment in an endpoint application that provides it with various services, and interfaces with the hardware.

A programming guide for the Sienda TSN Stack can be found here.

The library API reference can be found here.

^{stack embodiment in endpoint application and hardware}

Endpoint hardware

To provide the required services, an endpoint application requires certain hardware capabilities. The hardware platform must therefore have:

• An ethernet peripheral supporting:
  • gPTP timestamping
  • tx priority queues supporting the credit based shaper
  • rx priority queues
• A hardware timer/counter peripheral supporting:
  • capture of audio FSCLK edges for clock recovery
  • synchronisation with ethernet peripheral timestamp clock
• Finely adjustable clock generator for media clock recovery
• An audio interface

ⓘ for devices with no audio interface (network only devices), the clock generator is not required, and in some instances the timer/counter may be downgraded to a system/software timer.

The following sections will address each hardware requirement in more detail.

Ethernet peripheral

An ethernet peripheral is obviously required for ethernet connectivity. AVB can run over various types and speeds of ethernet, but the minimum requirements are:

• 100base-tx
• Full duplex
• No jumbo frames
• No flow control

• gPTP timestamping

  The ethernet peripheral must (either by itself or in collaboration with a timer/counter) provide the ability to capture accurate timestamps of the arrival and departure of layer 2 PTP messages. Different manufacturer’s datasheets report this capability in different ways, but any of the following claims usually suggest the required timestamping is supported:

  • IEEE 1588-2008
  • 1588v2
  • PTPv2
  • 802.1AS

  ⓘ If the ethernet peripheral includes its own timer/counter for generating timestamps then it is also required that this timer/counter can either also capture an audio FSCLK, or be synchronised with another timer/counter in the system. This generally means that the ethernet timer and the system timer must run from the same clock, and that a synchronisation pulse can be sent from one to the other during system initialisation to calculate the difference between the two timers.

  ⓘ Do not assume that just because the datasheet states support for PTP, that it will work for AVB! AVB requires two-step layer-2 PTP functionality, which is not supported by all ‘PTP’ capable hardware.

• Tx priority queues supporting the credit based shaper.

  The ethernet peripheral must provide at least two transmit queues, and at least one must support the Credit Based Shaper traffic shaper specified in 802.1Q. Different manufacturer’s datasheets report this capability in different ways, but any of the following claims usually suggest the required traffic queues are supported:

  • Transmit queues with traffic shaper (Credit Based Shaper)
  • 802.1Qav
  • 802.1Q clause 35
  • FQTSS
  • ‘AVB’

  ⓘ Please be aware that traffic shapers other than the ‘Credit Based Shaper’ are NOT AVB capable, and so ‘leaky bucket’, ‘fixed priority’, ‘egress rate limiting’ and several other types of traffic shaping will NOT provide adequate traffic shaping for a compliant AVB system.

• Rx priority queues.

  Receive priority queues are required to ensure that high priority data arriving from the network can be processed before lower priority data. AVB audio packets would use the high priority rx queue, ensuring that if any ethernet packets are dropped due to processing or memory constraints, it will be ‘best effort’ traffic that is dropped and not AVB traffic. To ensure that there are no interruptions to flowing streams when an endpoint drops packets, a high priority queue should also be used for PTP and MRP traffic. Please not that it is NOT required that the rx queues support traffic shaping. Fixed priority rx queues are sufficient to implement a fully compliant AVB device.

  ⓘ In some scenarios rx priority queues can be replaced with software priority handling. In this case the device must have enough processing power to be able to receive and partially process ALL received packets at LINE RATE. For 100mbps devices this is around 150,000 packets per second (18 packets per 125uS ‘tick’ interval), while at gigabit speeds this is around 1.5 million packets per second (180 packets per 125uS ‘tick’ interval).

Hardware timer/counter

A hardware timer/counter peripheral is required:

• To maintain the system (device) time
• To measure the rate (and phase) of the audio clock

In some implementations it is also used to provide a 8kHz system ‘tick’ for driving the stack so it can send talker packets at regular intervals. In other implementation this is not required, as a 8kHz ‘tick’ may also be driven from an audio DMA interrupt or other source.

In some implementations the timer/counter may also be used for capturing PTP timestamps. If the system includes a PHY (or MAC) with a dedicated output signal that is triggered when a PTP packet is sent or received, then this signal may be fed into the timer/counter to capture the PTP packet timestamp. In systems where the ethernet peripheral maintains its own timer/counter for capturing PTP timestamps, it is important that the system timer/counter can be synchronised with the ethernet timer/counter. This generally means that the ethernet timer and the system timer must run from the same clock, and that a synchronisation pulse can be sent from one to the other during system initialisation to calculate the difference between the two timers.

_{the sync pulse can go in either direction. The ethernet peripheral and the timer need not run at the same rate, but they must be sourced from the same clock}

Depending on the type of clock generator chosen for the system, a timer/counter may also be required to generate a reference clock (a 1kHz clock for example) to drive a PLL. This timer/counter may be the same as the system timer/counter, or may be a separate instance. (Some timer/counter peripherals support multiple channels, where ‘capture’ and ‘compare’ features may be used simultaneously, others do not).

Timer/counter general requirements

To maintain the system/device time, a 32 bit or 64 bit timer/counter is recommended. If a 32 bit timer is used, a further ‘upper’ 32 bits must be maintained in software. The timer is required to have a minimum resolution of 40ns, so must be driven by a clock of at least 25MHz. The timer may maintain a nanosecond count, or a ‘tick’ count.

If the endpoint uses an ethernet peripheral with an embedded timer, there must be a way to synchronise the ethernet timer and the system timer. The two timers must be running from the same source clock, although they need not be running at the same rate. (see fig 4).

FSCLK rate/phase measurement

The timer must be able to accurately capture the FSCLK (or preferably a divided FSCLK), or some other signal synchronised to the FSCLK, for clock recovery. If a 32 bit timer is being used (with the upper 32 bits maintained in software) then the timer and its software driver must be able to determine accurate timestamps for an FSCLK capture even if a timer rollover event has occurred just before (or just after) the FSCLK capture. Support for this is sometimes provided by the hardware, but if not, it can usually be provided by software polling the timer occasionally. The captured FSCLK timestamps are passed to the stack and used for media clock recovery.

_{divided FSCLK captured by timer}

_{audio DMA completion interrupt captured by timer}

Adjustable clock generator for media clock recovery

As most AVB audio endpoints have an audio interface, an audio (media) clock must be generated to drive the interface, and to drive any ADC/DAC or digital transceivers connected to the interface. The rate of this clock must be finely adjustable so that the clock can be synchronised with the AVB network clock. The adjustable clock generator forms half of the clock recovery circuit, while the FSCLK rate/phase measurement forms the other half.

There are several different types of adjustable clock generator, but two methods that have been used successfully by Sienda are to use an i2c controlled crystal oscillator, such as the Si570, or to use a PLL driven from a reference clock from a timer.

An example clock recovery circuit using a PLL driven from a timer is shown below.

_{complete clock recovery circuit using refclk, PLL, and FSCLK divider feedback}

Audio interface

AVB doesn’t really place any requirements on the audio interface, and in fact a ‘network only’ AVB device doesn’t require a separate audio interface at all. It is worth noting however that most AVB devices are expected to operate in tight sync with each other, and so the recovered media clock (see clock recovery section) is required to drive the audio interface. This usually implies that the audio interface operates in ‘leader’ mode, outputting the MCLK, SCLK and FSCLK signals. In rare circumstances it may be preferably to have the audio interface operating in ‘follower’ mode (receiving MCLK, SCLK and FSCLK), but from the AVB perspective this would only be possible if the device was the AVB media clock leader, or if sample-rate conversion was used.

If the system does not require a ‘leader’ clock (MCLK) signal from the audio interface then the clock recovery circuit may generate the serial clock (SCLK) instead.

Endpoint Application

The endpoint application is generally an embedded application based on an RTOS kernel, although it may also be a desktop or any other type of application that can provide the stack with the services it requires. The services required by the stack are:

• Ethernet packet handling with gPTP timestamping support
• Timer services
• Audio IO services

As AVB systems have strict realtime requirements, the application will also be required to support multiple threads/tasks with realtime scheduling, and synchronisation primitives such as mutexes and semaphores. (Note that the stack itself does not use mutexes/semaphores or perform thread handling internally, but the application will require these services to ensure timely handling of high priority tasks, and to serialise access to the stack from the application.)

^{interaction of application services with stack}

For more information on developing an AVB application (firmware) please see the programming guide.

🢀 Back to main documentation page