The Tempest Processing Engine
Power and Precision

Dr Enrique Perez Gonzalez, Chief Technology Officer
Some industry voices have suggested that CPU
technology cannot on its own deliver thestability and power required for large scaleaudio processing. The Tempest engine which
employs SSL’s patented Optimal Core
Processing proves that untrue. This document
explains SSL’s approach and why it works.
In 2011 when contemplating the future of its
digital product range, a group of SSL’s R&D
engineers spent a number of months evaluating
the requirements of a platform on which theycould base a new range of systems for a variety
of professional applications at different scales.
The platform was to be adaptable, haveindustrial strength and reliability, provide
massive processing power and be capable ofunmatched software and architectural
flexibility.
SSL C-Series consoles (C10, C100, C200 andC300) are based on SSL’s Centuri processors
and the more recent Blackrock processors. Bothemploy arrays of Sharc DSP and FPGA chips anduse an in-house operating system designed
specifically for the purpose. The advantages ofthis approach, similar to those of other manufacturers of high-end digital audio consoles,
are the deterministic behaviour of the DSP array
and absolute control over the OS. On the downside there is the complexity and cost of scaling
up the DSP resource, and for the software,
the inability to leverage standard industry resources.
During the recent decade, as the technology
of individual processors got close to somefundamental physical constraints and Moore’s
Law ran out of steam, the power of IT industry
processing hardware continued to grow largely
through the development of multi-core processors. The overall throughput of these new multi-core processors exceeded what was sensibly
achievable with discrete DSP chips but as theIT industry is not by and large as concernedwith real-time, deterministic performance as
professional audio equipment has to be, thechallenge becomes whether it is possible tomanage multi-core processors to deliver therequired performance and, if so, how much of
the maximum theoretically available power canbe utilised. We perceived that we could develop
software much more efficiently using widelyadopted programming languages and focusedon which Real Time Operating Systems (RTOS)
could best help us in our efforts to manage theprocessing resource.
Two notable approaches to using multicore
processors compete: the first uses a“supervisor” program which enables the coresto run non-real-time operating systems in somecores while independently other cores run
RTOS. The “supervisor” must give priority to thereal-time cores over the non-real-time cores andregulate the priorities of low level interrupts
and memory exchanges. The second option
is to use two separate multi-core processors,
one dedicated to processing audio the other tointerface with the controls and displays. Using
two separate multicore processors ensures that
there is no interaction between non-real-time
cores and real-time cores and secures robust
real-time performance for very large processing
systems. After lengthy experimentation andevaluation of both systems, we chose the latter
due to its deterministic behaviour and reliability, considerations which are paramount in large
scale professional audio applications.
A key constraint of multi-core processors is theway they access the available memory. Eachcore has a small amount of dedicated local(L-level) cache memory but the main external

memory is shared. There is a fundamental
trade-off between cache latency and hit rate
given that larger caches have better hit rates
but longer latency. For real-time audio signal
processing, greater levels of performance canbe achieved by managing the L-level memory
tightly. Digital consoles need to allocate
processing resource for a number of different
tasks that occur simultaneously: filters,dynamics, delays, mixing, routing, clocking,metering, displays and control interactions.
Generally it makes best use of the available
processing resource to allocate these functionsto specified cores.

anything happens to the Audio Server, the DSP
continues and so does the audio. DSP boottime is fast. The Audio Server can connect tomore than one control surface enabling
multiple front panels to control the sameengine. Standard IT industry topologies canbe used to provide full mirrored redundancy.
And in a programming language understood bymany, with industrial strength libraries of usefulcode widely available, we have been able toaccelerate our developments, accommodatechanges and special requests more easily andincrease the size of our programming team todeliver some exciting products.

After lengthy research we developed sometechnology, which we patented, to work with
the RTOS to guarantee deterministic, real-time
performance even with heavy memory
exchange loads. This is called Optimal Core
Processing and it optimises the ratio of theresource allocated to processing with that
allocated to memory exchange. It enables us
to do multiple 64-bit floating point operations
that in turn enable us to execute complex, highresolution algorithms at very low latency. The
code has also been engineered to deliver many
thousands of multiply-add-and-accumulate
instructions and doesn’t therefore need to relyon additional FPGA bus-summing or any extensive external routing hardware.

The first of these were the L500 and L300 Liveconsoles which have proved hugely popular for
their flexibility, their ease of use, their reliability and, of course, their sound quality. The
Tempest engine is now being engineered for
System T, our latest Broadcast Audio Production System. With System T the core technology
is that used in the Live consoles but, in orderto provide the high channel and bus counts
required in today’s major TV productions, has aversion of the Tempest engine that delivers 800
paths and can route over 3,000 signals in andout. With dedicated broadcast specific architecture and algorithms, the software for System T
also differs from that of the Live consoles andprovides the features that large scale broadcast
productions require with the robustness andsecurity that Broadcasters demand.

The multi-core processors we use are industrial grade units designed to operate at a wider
range of temperatures than ‘ordinary’ PC hardware. The Tempest processor uses a RTOS withour OCP software technology. The Audio Server,the name we give the controller, runs on a separate multi-core processor running an embedded
operating system. This combination confers anumber of benefits. The system is resilient; ifMore Information: The SSL Team bring decades of broadcast console design experience to the challenges of leveraging networked
technology for broadcast. Email sales@solidtsatelogic.com for help and advice.

Other Documents In This Series•

Professional AoIP for Broadcast - TheWay Forward

www.solidstatelogic.com