AN298 provides a description of the operation of firmware
for the CS485xx family of DSPs. This document gives a
general overview to the family of CS485xx Firmware
User’s Manuals designated by the general name
AN298[X][Y]; where [X] = MPM (Matrix Processing
Module), VPM (Virtual Processing Module), PPM (Post
Processing Module), and [Y] = A,B,C, etc. Note that the
CS485xx family of DSPs does not contain a compressed
data decoder.
More specifically, the purpose of this document is to serve
as an introduction to the various DSP Firmware designed
specifically to run on the CS485xx DSP. This document will
attempt to explain frequently used term in olog y and, at the
same time, systematically explain the OS operation and
communication for the CS485xx.
http://www.cirrus.com
CS485xx Block Diagram
Copyright Cirrus Logic, Inc. 2013
(All Rights Reserved)
AN298RC14
MAR '13
1 Document Strategy
1Document Strategy
The CS485xx has been designed with an inherent flexibility in terms of firmware usage. Each instance of operation of the
CS485xx can potentially use a different mix of DSP firmware depending on the need of the end user. As such, the strategy
adopted to document the various DSP firmware is based on a single General Overview coupled with an individual
Firmware User’s Manual for each DSP firmware module offered by Cirrus Logic. AN298 is the General Overview to the
family of CS485xx Firmware User’s Manuals.
The individual Firmware User’s Manuals, mentioned in the abov e paragraph, each follow as an extension of AN298. These
manuals have been named in such a way so as to classify them into one of the following categories:
•Operating System and General Overview
•Matrix Processing Module (MPM)
•Virtual Processing Module (VPM)
•Post Processing Module (PPM)
Furthermore, since each classification (e.g., Post Processing Module) may contain several associated DSP firmware, an
incremental letter assignment (e.g., A, B, C etc.) was given to index each DSP firmware within a given category. As an
example, the table below outlines the general naming conventions for several firmware modules.
Table 1-1. Naming Conventions
DSP Firmware ModuleBase NameOverlay TypeIndexReference Number
For a further breakdown of the available CS485xx firmware modules and their respective Firmware User’s Guide
document number, see Section 2.4. For the latest code updates and availability, contact your local field applications
engineer (FAE).
2AN298RC14
Mid-Processor Overlay
PCM Output s
Post-Processor O ver l ay (wit h APP loaded)
ID =0x83
ID =0xD9
ID =0xD5ID =0xD4
Tone
Control
Module
Re-Eq
Module
Bass
Management
Module
Parametric
EQ
Module
Delay
Module
Audio Manager
Module
Includes:
Ga in (mas ter)
Mute (mas ter )
Channel Trim
Channel Remap
Up-sampler
Mid-Processor Module
e.g. P L II, PLIIx, N e o6, Cros s b a r,
Viva+, COMS2, Neur al Sur r ound,
Circl e Surr ound 2
Virtualizer-Processor
Module
e.g. DVS2, DH2, SRS TSXT,
Audistry
Virtual izer-Processor Overlay
Mid-Processor O ve rlay
PCM input s
Down-
sampler
2 Overview
2Overview
The firmware that runs on this device expects a stereo or multi-channel PCM input source. This section describes the
different overlays as well as the functionality of the various processor module overlays.
Figure 2-1. CS485xx Firmware Block Diagram
2.1 Firmware Overlays
The data flows through a series of four firmware overlays that contain one or more firmware modules. A firmware module
provides the specific application affectionately and is controlled by the host via a Firmware Mana ger that defines the
control interface. The overlays segment the firmware module functionality into four independent groups depending on
function:
OS Overlay
•Manages the overall operation of the DSP. Also handles host communication, data inputs and outputs and various
other critical internal tasks.
Matrix Processing Module Overlay
•Performs additional channel generation, upmixing, downmixing. This segment is where algorithms such as Pro
®
Logic
Virtual Processing Module Overlay
•Performs stereo virtualizing to simulate multi-channel systems, such as Dolby
Dolby Virtual Surround
Post Processing Module Overlay
•This segment specifically caters to firmware that performs post-processing tasks. It allows the system designer
flexibility in “tweaking” the system for optimal audio performance and effects. This is also the segment in which
firmware modules such as the Audio Manager, Bass Manager, Tone Control, Delay, THX
Module will reside.
AN298RC143
IIx, Neo6™, and COMS2 reside.
®
.
®
Audistry®, Dolby Headphone®, and
®
, and Parametric-EQ
2.2 Code Image (.uld) Files
2.2 Code Image (.uld) Files
Each overlay is a separate code image file (.uld) that is loaded individually into the DSP. To ch ange the functionality of the
application, only the overlay of interest needs to be loaded. For example the Post Pro cessin g overlay can be exch anged
from SPP to APP by reloading only the Post Processing overlay. This reduces the system response time to user changes
as well as the code image storage requirements.
Note:There are 4 different memory configurations pertaining to the program RAM size (most code is in ROM). The
different memory configurations are denoted by p2, p4, p6, a nd p8 (p for prog ram memory, 2, 4, 6, a nd 8 are the
number of kilo-words, 1 word = 32 bits). Increasing P RAM decreases Y RAM. Each overlay is denoted with the
p2, p4, p6, or p8 in the .uld file name to indicate which memory configuration is used.
WARNING: Memory configuration must be consistent across all overlays (OS, MPM, VPM, and PPM).
2.2.1.uld File Naming Conventions
A generic template for representing .uld file can be represented by the following file name:
AA_48BBB_pC_DD_EE_rcFF.uld
2.2.1.1.uld File Name Variables
•
AA = Technology name (os, mb, app, spp, …)
•BBB = minimum chip required to run the firmware loaded by the .uld file (520, 560, dv2, au2)
•520 means this will run on a 520, 540, & 560
•540 means this will run on a 540 & 560 (Not on a 520)
•560 means this will run on a 560 (Not on a 520 or 540)
•dv2 means this will run on a CS48DV2x DSP only
•au2 mean this will run on a CS48AU2B only
•C = memory configuration (2, 4, 6, or 8)
This is the amount of PRAM in Kilowords (1 word = 32-bits). More PRAM means less YRAM.
The memory configurations can be broken down into the following categories:
•P2
•X Memory - 8kx32 SRAM, 8kx32 DROM
•Y Memory - 14kx32 SRAM, 8kx32 DROM
• P Memory - 2kx32 SRAM, 32kx32 DROM
•P4
•X Memory - 8kx32 SRAM, 8kx32 DROM
•Y Memory - 12kx32 SRAM, 8kx32 DROM
•P Memory - 4kx32 SRAM, 32kx32 DROM
•P6
•X Memory - 8kx32 SRAM, 8kx32 DROM
•Y Memory - 10kx32 SRAM, 8kx32 DROM
•P Memory - 6kx32 SRAM, 32kx32 DROM
•P8
•X Memory - 8kx32 SRAM, 8kx32 DROM
•Y Memory - 8kx32 SRAM, 8kx32 DROM
•P Memory - 8kx32 SRAM, 32kx32 DROM
•DD = Firmware version
4AN298RC14
2.3 Download Sequence
This variable is the specific memory map for the various overlays and can be specific to a particular version of ROM
Current Firmware versions are:
•01 = CS485xx
•02 =CS48DV2A
•03 = CS48DV2B
•04 = CS485xx
•05 = CS485xx
•06 = CS48AU2B
•09 = CS485xx
•EE = This variable indicates a major revision, increments when rc99 -> rc1
•FF = This Variable indicates a minor revision, increments by one for each new .uld build
2.2.1.2 Example of .uld file name
An example of a .uld file name:
os_48520_p2_48520_01_01_rc5.uld
•AA = os (DSPP operating system)
•BBB = CS48520 (this .uld will run on CS48520, CS48540, and CS48560)
•C = p2
•DD = 01 (all other overlays that are loaded on the DSP must be 01 overlays)
•EE = 01 (have not made over 100 of these)
•FF = rc5
2.3 Download Sequence
A standard procedure to download firmware to the DSP follows the following structure at system power-up: