l Boot Procedures f or Host Boot and Auto boot
l Resetting the CS492x
l Connecting External Memory (Using Paged
and Non-Paged Memory)
l Understanding Configuration Messages
l Input & Output Hardware Configuration
l Pseudocode examples for SPI and I2C
Communication with the CS492x
l Pseudocode Outlining a Typical Download
Session with the CS492X
l Pseudocode Outlining a Typical Reset
Sequence with the CS492X
DIGIT ALSOUND
Description
The CS4923/4/5/6/7/8/9 is a system on a chip
solution for multi-channel audio decompression
and digital signal processing. Because the
device is RAM-based, a download of
application software is required each time the
CS4923/4/5/6/7/8/9 is powered up. This
document focuses on hardware control of the
chip from a functional perspective.
This document takes more of a functional
approach to the hardware of the chip. An indepth description of communication, boot
procedure, extern al memory and the hardwa re
configuration are given in this document. This
document will be valuable to both the
hardware designer and the system
programmer.
C Communication ............................................................................................. 12
2.1.2.1 W riting in I
2.1.2.2 Reading in I
2.2.1.1 Writing a Byte in Intel Mode ................................................................ 19
2.2.1.2 Reading a Byte in Intel Mode ..............................................................19
2.2.2.1 Writing a Byte in Motorola Mode .........................................................20
2.2.2.2 Reading a Byte in Motorola Mode .......................................................21
2.2.3.1 Control Write in a Parallel Host Mode .................................................22
2.2.3.2 Control Read in a Parallel Host Mode .................................................23
2
C ....................................................................................... 12
2
C .................................... ................................................. 13
Contacting Cirrus Logic Support
For a complete listing of Direct Sales, Distributor, and Sales Representative contacts, visit the Cirrus Logic web site at:
http://www.cirrus.com/corporate/contacts/
Preliminary product info rmation describes products which are i n production, but for whi ch ful l characterization data is not yet available. Advance produ ct i nfor mation describes products which are in development and subject to development changes. Cirrus Logic, Inc. has made best efforts to ensure that the information
contained in this document is accurate and reliable. However, the information is subject to change without notice and is provided “AS IS” without warranty of any
kind (express o r i mplie d). No re spon sibilit y is as sume d b y Cirru s Logic, Inc. for the use of this information, nor for infringements of patents or other rights of third
parties. This document is the property of Cirrus Logic, Inc. and implies no license under patents, copyrights, trademarks, or trade secrets. No part of this publication may be copied, reproduced, stored in a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photographic, or otherwise)
without the prior wri tten consent of Ci rrus Lo gic, Inc. Items fr om any Cir rus Logi c websit e or disk may be p rinte d for use by t he user . However , no part of the
printout or electronic files may be copied, reproduced, stored in a retrieval system, or transmitted, in any form or by any means (electronic, mechanical, photographic, or otherwise) wi thout the prior writ ten consent of Cirrus Log ic, I nc.F urt h erm ore, no part of this p ubl i c ati on may be used as a basis for manufacture or
sale of any items without the prior written consent of Cirrus Logic, Inc. The names of products of Cirrus Logic, Inc. or other vendors and suppliers appearing in
this document may be trademarks or service marks of their respect ive owner s which may be registered in some jurisdi ctions. A li st of Ci rru s Logic, Inc. trademarks and service marks can be found at http://www.cirrus.com.
Table 26. Example Values to be Sent to CS492X After Download or Soft Reset.........................57
2
C Communication Signals .... ...... ....... .......................................................................... 1 2
4AN115REV2
1.OVERVIEW
The CS4923/4/5/6/7/8/9 is a family of system on a
chip solutions for multi-channel audio
decompression and digital signal processing. Since
the part is RAM-based, a download of application
software is required each time the
CS4923/4/5/6/7/8/9 is powered up.
Digital bitstream); used primarily in broadcast environments.
PES - a Packetized Elementary Stream (PES) bitstream contains the elementary compressed audio
stream and additional header information which
can be used for A/V synchronization; used primarily in broadcast environments.
These parts are generally ta rgeted at two differ ent
market segments. The broadcast market where
audio/video (A/V) synchronization is required, and
the outboard decoder markets where audio/video
synchronization is not required. The important
differentiation is the format in which the data will
be received by the CS4923/4/5/6/7/8/9. In systems
where A/V synchronization is required from the
CS4923/4/5/6/7/8/9, the incoming data is typically
PES encoded. In an outboard decoder application
the data typically comes in the IEC61937 format
(as specified by the DVD consortium). An
important point to remember is that the
CS4923/4/5/6/7/8/9 will support both
environments, but different downloads are required
depending on the input data type.
Broadcast applications include (but are not limited
to) set top box applications, DVDs and digital TVs.
Outboard decoder applications include standalone
decoders and audio/video receivers. Often times a
system may be a hybrid between an outboard
decoder and a broadcast system depending on its
functionality.
As discussed above, compressed audio can be
packed in IEC61937, PES, or elementary formats
depending on the decoder environment. Each format is supported by a separate download of application code. Consult the relevant Application Code
User’s Guide to determine which format s are supported by a particular application. A brief description of each format is presented below.
Elementary - an elementary bitstream consists only
of compressed audio data (e.g., strictly the Dolby
IEC61937 - a method of packing compressed audio
such that it can be delivered using a bi-phase encoded signal (e.g., S/PDIF output signal from DVD
player); used primarily for outboard decoders
where A/V synchronization is not required.
1.1 Multi-Channel Decoder Family of Parts
CS4923 - Dolby Digital
CS4923 is the original member of the family and is
intended to be used if only Dolby Digital decoding
is required. For Dolby Digital, post processing
includes bass management, delays and Dolby Pro
Logic decoding. Separate downloads can also be
used to support stereo to 5.1 channel effects
processing and stereo MPEG decoding.
CS4924 - Dolby Digital
Decoder. The CS4924 is the stereo version of the
CS4923 designed for source products such as
DVD, HDTV, and set-top boxes. Separate
downloads are available for stereo decode of Dolby
Digital and MPEG audio.
CS4925 - International Multi-Channel DVD
Audio Decoder. The CS4925 supports both Dolby
Digital and MPEG-2 multi-channel formats. For
both Dolby Digital and MPEG-2 multi-channel,
post processing includes bass management and
Dolby Pro Logic decoding. Separate downloads are
available for decode of Dolby Digital and MPEG
audio. Another code load can be used to support
stereo to 5.1 channel effects processing.
CS4926 - DTS/Dolby® Multi-Channel Audio
Decoder. The CS4926 supports both Dolby Digital
and DTS, or Digital Theater Surround. For Dolby
Digital, post processing includes bass management
TM
Audio Decoder. The
TM
Source Product
AN115REV25
and Dolby Pro Logic. The Dolby Digital code and
DTS code take separate code downloads. Separate
downloads can also be used to support stereo to 5.1
channel effects processing and stereo MPEG
decoding.
CS4927 - MPEG-2 Multi-Channel Decoder. The
CS4927 supports MPEG-2 multi-channel decoding
and should be used in applications where Dolby
Digital decoding is not necessary. For MPEG-2
multi-channel decoding, post processing includes
bass management and Dolby Pro Logic decoding.
Another code load can be used to support stereo to
5.1 channel effects processing.
CS4928 - DTS Multi-Channel Decoder. The
CS4928 supports DTS multi-channel decoding and
should be used in applications where Dolby Digital
decoding is not necessary. For DTS multi-channel
decoding, post processing includes bass
management. Separate downloads can also be used
to support stereo to 5.1 channel effects processing
and stereo MPEG decoding.
CS4929 - AAC 2-Channel, (Low Complexity) and
MPEG-2 Stereo Decoder. The CS4929 is capable
of decoding both 2-channel AAC and MPEG-2
audio. The CS4929 supports elementary and PES
formats.
1.2 Document Strategy
Multiple documents are needed to fully define,
understand and implement the functionality of the
CS4923/4/5/6/7/8/9. They can be split up into two
basic groups: hardware and application code
documentation. It should be noted that hardware
and application code are co-dependent and one can
not successfully use the part without an
understanding of both. The ‘ANXXX’ notation
denotes the application note number under which
the respective user’s guide was released.
1.2.1 Hardware Documentation
CS4923/4/5/6/7/8/9 Family Data Sheet - This
document describes the el ec tric al char acte ristic s of
the device from timing to base functionality. This is
the hardware designers tool to learn the part’s
electrical and systems requirements.
AN115 - CS4923/4/5/6/7/8/9 Hardware User’s
Guide - describes the functional aspects of the
device. An in depth description of communication,
boot procedure, external memory and hardware
configuration are given in this document. This
document will be valuable to both the hardware
designer and the system programmer.
1.2.2 CS4923/4/5/6/7/8/9 Application Code
User’s Guides
The following application notes describe the
application codes used with the
CS4923/4/5/6/7/8/9. Whenever an application code
user’s guide is referred to, it should be assumed that
one or more of the below documents are being
referenced. The following list covers currently
released application notes. This list will grow with
each new application released. For a current list of
released user’s guides please see www.crystal.com
and search for the part number.
AN120 - Dolby Digital User’s Guide for the
CS4923/4/5/6. This document covers the features
available in the Dolby Digital code including
delays, pink noise, bass management, Pro Logic,
PCM pass through and Dolby Digital processing
features. Optional appendices are available that
document code for Dolby Virtual, Q-Surround and
VMAx.
AN121 - MPEG User’s Guide for the CS4925.
This document covers the features available in the
MPEG Multi-Channel code including delays, bass
management, Pro Logic, and MPEG processing
features.
AN122 - DTS User’s Guide for the CS4926,
CS4928. This document covers the features
available in the DTS code including bass
management and DTS processing features.
6AN115REV2
AN123 - Surround User’s Guide for the
CS4923/4/5/6/7/8. This code covers the different
Stereo PCM to surround effects processing code.
Optional appendices are available that document
Crystal Original Surround, Circle Surround and
Logic 7.
AN140 - Broadcast Systems Guide for the
CS4923/4/5/6/7/8/9. This guide describes all
application code (e.g. Dolby Digital, MPEG, AAC)
designed for broadcast systems such as HDTV and
set-top box receivers. This document also provides
a discussion of broadcast system considerations
and dependencies such as A/V synchronization and
channel change procedures.
1.3 Using the CS4923/4/5/6/7/8/9
No matter what application is being used on the
chip, the following four steps are always followed
to use the CS4923/4/5/6/7/8/9 in system.
1) Reset and/or Download Code - Detailed
information in AN115
2) Hardware Configuration - Detailed information
in AN115
3) Application configuration - Detailed
information in the appropriate Application
Code User’s guide
4) Kickstart - This is the “Go” command to the
CS492X once the system is properly
configured. Information can be found in the
appropriate Application Code User’s guide.
For this document, CS4923/4/5/6/7/8/9 has been
replaced in certain places with CS492X for
readability. Unless otherwise specified CS492X
should be interpreted as applying to the CS4923,
CS4924, CS4925 and CS4926.
AN115REV27
2.HOST COMMUNICATION
The host communication port of the
CS4923/4/5/6/7/8/9 is used for downloading
application code to the DSP and it is used for
communicating with the DSP during run-time. The
CS492X supports two parallel host communication
modes (Intel mode and Motorola mode) and two
serial host communication modes (I2C and SPI).
Please note that when a parallel host
communication mode has been selected, the
external memory interface cannot be used. This
constraint has two significant implications:
•Autoboot cannot be used in a system using
parallel host communication
•Parallel host communication modes cannot be
used when processing DTS (CS4926 or CS4928)
Each of the host communication modes supported
by the CS492X family will be discussed in
subsequent sections. The following information
will be provided for each mode:
•How to configure the CS492X for each host
communication mode
•Which pins of the CS492X must be used
•The protocol used for writing to the CS492X
•The protocol used for reading from the CS492X
2.1Serial Communication
The CS4923/4/5/6/7/8/9 has a serial control port
that supports both SPI and I2C forms of
communication. The mode of communication is
determined by the states of the RD (pin 5) and WR
(pin 4) pins at the rising edge of RESET (pin 36).
Table 1 below shows the two possible mode
configurations:
Other modes are not supported at this time and
should not be used. If the mode pins are driven
dynamically by the host, then set up (t
) and hold
rstsu
RDWRMODE
01
10SPI
Table 1. Serial Host Mode Configurations
(t
) times must be satisfied around the rising
rsthld
2
C
I
edge of reset as specified in the RESET Switching
characteristics portion of the CS492X Family
Datasheet.
The following sections will explain each
communication mode in more detail. Flow
diagrams will illustrate read and write cycles.
Pseudocode is presented in “Appendix A Pseudocode For The CS4923/4/5/6/7/8/9 Family”
58 to demonstrate communication with the chip
from a programming perspective.
Timing diagrams will be shown to demonstrate
relative edge positions of signal transitions for read
and write operations.
Only the subsection describing the communication
mode being used needs to be read by the system
designer.
2.1.1SPI Communication
SPI communication with the CS4923/4/5/6/ 7/8/9 is
accomplished with 5 communication lines: chip
select, serial control clock, serial data in, serial data
out and an interrupt request line to signal that the
DSP has data to transmit to the host. Table 2 shows
the mnemonic, pin name and pin number of each of
these signals on the CS4923/4/5/6/7/8/9.
MnemonicPin NamePin Number
Chip SelectCS
Serial ClockSCCLK7
Serial Data InSCDIN6
Serial Data OutSCDOUT19
Interrupt RequestINTREQ
Table 2. SPI Communication Signals
18
20
8AN115REV2
2.1.1.1Writing in SPI
Figure 1. SPI Write Flow Diagram
SPI START: CS (LOW)
WRITE ADDRESS BYTE
SET TO 0 FOR WRITE
SEND DATABYTE
MORE DATA?
CS
(HIGH)
WITH MODE BIT
N
Y
When writing to the device in SPI the same
protocol will be used whether writing a byte, a
message or even an entire executable download
image. The examples shown in this document can
be expanded to fit any write situation. Figure 1
shows a typical write sequence:
3) The host should then clock data into the device
most significant bit first, one byte at a time. The
data byte is transferred to the DSP on the falling
edge of the eighth serial clock. For this reason,
the serial clock should be default low so that
eight transitions from low to high to low will
occur for each byte.
4) When all of the bytes have been transferred,
chip select should be raised to signify an end of
write. Once again it is crucial that the serial
clock transitions from high to low on the last bit
of the last byte before chip select is raised, or a
loss of data will occur.
The pseudocode in Section 6.1.1 “SPI Write
Operation” -- page 58 demonstrates a write
operation for the SPI mode of communication.
The same write routine could be used to send a
single byte, message or an entire application code
image. From a hardware perspective, it makes no
difference whether communication is by byte or
multiple bytes of any length as long as the correct
hardware protocol is followed.
The following is a detailed description of an SPI
write sequence with the CS492X.
1) An SPI transfer is initiated when chip select
(CS) is driven low.
2) This is followed by a 7-bit address and the
read/write bit set low for a write. The address
for the CS492X defaults to 0000000b. It is
necessa ry to clo ck this address in prior to any
transfer in order for the CS492X to accept the
write. In other words a byte of 0x00 should be
clocked into the device preceding any write. The
0x00 byte represents the 7 bit address 0000000b,
and the least significant bit set to 0 to designate
a write.
2.1.1.2Reading in SPI
A read operation is necessary when the
CS4923/4/5/6/7/8/9 signals that it has data to be
read. The CS492X does this by dropping its
interrupt request line (INTREQ) low. When
reading from the device in SPI, the same protocol
will be used whether reading a single byte or
multiple bytes. The examples shown in this
document can be expanded to fit any read situation.
Figure 2 shows a typical read sequence:
The following is a detailed description of an SPI
read sequence with the CS492X.
1) An SPI read transaction is initiated by the
CS492X dropping INTREQ, signaling that it
has data to be read.
2) The host responds by driving chip select (CS)
low.
AN115REV29
Figure 2. SPI Read Flow Diagram
CS (LOW)
WRITE ADDRESS BYTE
SET TO 1 FOR READ
READ DATA BYTE
INTREQ STILL LOW?
CS (HIGH)
WITH MODE BIT
NO
YES
INTREQ LOW?
YES
NO
3) This is followed by a 7-bit address and the
read/write bit set high for a read. The address
for the CS492X defaults to 0000000b. It is
necessary to clock this address in prior to any
transfer in order for the CS492X to
acknowledge the read. In other words a byte of
0x01 should be clocked into the device
preceding any read. The 0x01 byte represents
the 7 bit address 0000000b, and the least
significant bit set to 1 to designate a read.
4) After the falling edge of the serial control clock
(SCCLK) for the read/write bit, the data is
ready to be clocked out on the control data out
pin (CDOUT). Data clocked out by the host is
valid on the rising edge of SCCLK and data
transitions occur on the falling edge of S CCLK.
The serial clock should be default low so that
eight transitions from low to high to low will
occur for each byte.
5) If INTREQ is still low, another byte should be
clocked out of the CS492X. Please see the
discussion below for a complete description of
INTREQ behavior.
6) When INTREQ has risen, the chip select line of
the CS492X should be raised to end the read
transaction.
Understanding the role of INTREQ is important for
successful communication. INTREQ is guaranteed
to remain low (once it has gone low) until the
second to last rising edge of SCCLK of the last byte
to be transferred out of the CS492X. If there is no
more data to be transferred, INTREQ will go high
at this point. For SPI this is the rising edge for the
second to last bit of the last byte to be transferred.
After going high, INTREQ is guaranteed to stay
high until the next rising edge o f SCC LK. This end
of transfer condition signals the host to end the read
transaction by clocking the last data bit out and
raising CS. If INTREQ is still low after the second
to last rising edge of SCCLK, the host should
continue reading data from the serial control port.
It should be noted that all data should be read out of
the serial control port during one cycle or a loss of
data will occur. In other words, all data should be
read out of the chip until INTREQ signals the last
byte by going high as described above. Please see
Section 2.1.3 “INTREQ Behavior: A Special Case”
-- page 10 for a more detailed description of
INTREQ behavior.
The pseudocode in Section 6.1.2 “SPI Read
Operation” -- page 59 demonstrates a read
operation for the SPI mode of communication.
The Figure 3 timing diagram shows the relative
edges of the control lines for an SPI read and write.
2. INTREQ
may go LOW again if there is new data to be read. The condition of INTREQ
point should be treated as a new read condition. After a stop condition, a new start condition
and an address byte should be sent
SP I R ead F unc tional Tim ing
Note1
is guaranteed to stay LOW until the rising edge of SCCLK for bit D1 of the last byte
is guaranteed to remain HIGH until the next rising edge of SCCLK at which point it
going LOW at this
Figure 3. SPI Timing
Note 2
2.1.2I2C Communication
I2C communication with the CS4923/4/5/6/7/8/9 is
accomplished with 3 communication lines: serial
control clock, a bi-directional serial data
input/output line and an interrupt request line to
signal that the DSP has data to t ransmi t to the host.
Table 3 shows the mnemonic, pin name and pin
number of each of these signals on the CS492X.
MnemonicPin NamePin Number
Serial ClockSCCLK7
Bi-Directional DataSCDIO19
Interrupt RequestINTREQ
Table 3. I
2
C Communication Signals
Typically in I2C communication SCDIO is an open
drain line with a pull-up. A logic one is placed on
the line by tri-stating the output and allowing the
pull-up to raise the line. At this point another
device can drive the line low if necessary. Tristating SCDIO can have two effects: 1. To send out
a one when writing data or sending a “no
acknowledge”; 2. release the line when another
chip is writing data.
For our pseudocode examples, driving SCDIO high
effectively tri-states this signal since it is open
drain and SCDIO (HIGH) should be interpreted as
such.
20
SEND I2C START:
DROP SCDIO LOW
WHILE SCCLK IS HIGH
WRITE ADDRESS BYTE
WITH MODE BIT
SET TO 0 FOR WRITE
GET ACK
SEND DATABYTE
GET ACK
MORE DATA?
N
2
C STOP:
I
RAISE SCDIO HIGH
WHILE SCCLK IS HIGH
Figure 4. I2C Write Flow Diagram
Y
2.1.2.1Writing in I2C
2) Next a 7-bit address with the read/write bit set
When writing to the device in I2C the same
protocol will be used whether writing a byte, a
message or even an application code image. The
examples shown in this document can be expanded
to fit any write situation. Figure 4 shows a typical
write sequence:
The following is a detailed description of an I2C
write sequence with the CS492X.
1) An I2C transfer is initiated with an I2C start
condition which is defined as the data (SCDIO)
line falling while the clock (SCCLK) is held
high.
12AN115REV2
low for a write should be sent to the CS492X.
The address for the CS492X defaults to
0000000b. It is necessary to clock this address
in prior to any transfer in order for the CS492X
to accept the write. In other words a byte of
0x00 should be clocked into the device
preceding any write. The 0x00 byte represents
the 7 bit of address (0000000b) and the
read/write bit set to 0 to designate a write.
3) After each byte (including the address and each
data byte) the host must release the data line
and provide a ninth clock for the CS492X to
acknowledge. The CS492X will drive the data
line low during the ninth clock to acknowledge.
If for some reason the CS492X does not
acknowledge, it means that the last byte sent
was not received and should be resent. If the
resent byte fails to produce an acknowledge, a
stop condition should be sent and the device
should be reset.
4) The host should then clock data into the device
most significant bit first, one byte at a time. The
CS492X will (and must) acknowledge each
byte that it receives which means that after each
byte the host must provide an acknowledge
clock pulse on SCCLK and release the data
line, SCDIO.
5) At the end of a data transfer a stop condition
must be sent. The stop condition is defined as
the rising edge of SCDIO while SCCLK is
high.
INTREQ LOW?
NO
YES
SEND I2C START:
DROP SCDIO LOW
WHILE SCCLK IS HIGH
WRITE ADDRESS BYTE
WITH MODE BIT
SET TO 1 FOR READ
GET ACK
READ DATABYTE
The pseudocode in Section 6.2.1 “I2C Write
Operation” -- page 60 demonstrates a write
operation for the I2C mode of communication.
2.1.2.2Reading in I2C
A read operation is necessary when the
CS4923/4/5/6/7/8/9 signals that it has data to be
read. It does this by dropping its interrupt request
line (INTREQ) low. When reading from the device
in I2C, the same protocol will be used whether
reading a single byte or multiple bytes. The
examples shown in this document can be expanded
to fit any read situation. Figure 5 shows a typical
I2C read sequence
1) An I2C read transaction is initiated by the
CS492X dropping INTREQ, signaling that it
has data to be read.
YES
INTREQ STILL LOW?
NO
SEND NACK
SEND I2C STOP:
RISING EDGE OF SCDIO
WHILE SCLK IS HIGH
Figure 5. I2C Read Flow Diagram
SEND ACK
2) The host responds by sending an I2C start
condition which is SCDIO dropping while
SCCLK is held high.
AN115REV213
3) The start condition is followed by a 7-bit
address and the read/write bit set high for a
read. The address for the CS492X defaults to
0000000b. It is necessary to clock this address
in prior to any transfer in order for the CS492X
to acknowledge the read. In other words a byte
of 0x01 should be clocked into the device
preceding any read. The 0x01 byte represents
the 7 bit address 0000000b and a read/write bit
set to 1 to designate a read.
4) After the falling edge of the serial control clock
(SCCLK) for the read/write bit of the address
byte, an acknowledge must be read in by the
host. The CS492X will drive SCDIO low to
acknowledge the address byte and to indicate
that it is ready for a read operation. If an
acknowledge is not sent by the CS492X, a stop
condition should be issued and the read
sequence should be restarted.
5) The data is ready to be clocked out on the
SCDIO line at this point. Data clocked out by
the host is valid on the rising edge of SCCLK
and data transitions occur on the falling edg e of
SCCLK.
6) If INTREQ is still low after a byte transfer, an
acknowledge (SCDIO clocked low by SCCLK)
must be sent by the host to the CS492X and
another byte should be clocked out of the
CS492X. Please see the discussion below for a
complete description of INTREQ’s behavior.
7) When INTREQ has risen, a no acknowledge
should be sent by the host (SCDIO clocked
high by the host) to the CS492X. This, followed
by an I2C stop condition (SCDIO raised, while
SCCLK is high) signals an end of read to the
CS492X.
Understanding the role of INTREQ is important for
successful communication. INTREQ is guaranteed
to remain low (once it has gone low), until the
rising edge of SCCLK for the last bit of the last byte
to be transferred out of the CS492X (i.e . the rising
edge of SCCLK before the ACK SCCLK). If there
is no more data to be transferred, INTREQ will go
high at this point. After going high, INTREQ is
guaranteed to stay high until the next rising edge of
SCCLK (i.e. it will stay high until the rising edge
of SCCLK for the ACK/NACK bit). This end of
transfer condition signals the host to end the read
transaction by clocking the last data bit out of the
CS492X and then sending a no acknowledge to the
CS492X to signal that the read sequence is over. At
this point the host should send an I2C stop
condition to complete the read sequence. If
INTREQ is still low after the rising edge of
SCCLK on the last data bit of the current byte, the
host should send an acknowledge and continue
reading data from the serial control port.
It should be noted that all data should be read out of
the serial control port during one cycle or a loss of
data will occur. In other words, all data should be
read out of the chip until INTREQ signals the last
byte by going high as described above. Please see
Section 2.1.3 “INTREQ Behavior: A Special Case”
-- page 10 for a more detailed description of
INTREQ behavior.
The pseudocode in Section 6.2.2 “I2C Read
Operation” -- page 62 demonstrates a read
operation for the I2C mode of communication.
The timing diagram in Figure 6 shows the relative
edges of the control lines for an I2C read and write.
2.1.3INTREQ Behavior: A Special Case
When communicating with the CS4923/4/5/6/7/8/9
there are two types of messages which force
INTREQ to go low. These messages are known as
solicited messages and unsolicited messages. For
more information on the specific types of messages
that require a read from the host, one of the
application code user’s guides should be
referenced.
In general, when communicating with the CS492X,
INTREQ will not go low unless the host first sends
Notes: 1. The ACK for the address byte is driven by the CS4923/4/5/6/7/8/9.
2. The ACKs for the data bytes being read from the CS4923/4/5/6/7/8/9 should be driven by the
host.
3. INTREQ
is guaranteed to stay LOW until the rising edge of SCCLK for bit D0 of the last byte
to be transferred out of the CS4923/4/5/6/7/8/9.
4. A NACK should be sent by the host after the last byte to indicate the end of the read cycle.
5. INTREQ
is guaranteed to stay HIGH until the next rising edge of SCCLK (for the ACK/NACK
bit) at which point it may go LOW again if there is new data to be read. The condition of
INTREQ
going LOW at this point should be treated as a new read condition. After a stop
condition, a new start condition followed by an address byte should be sent.
Figure 6. I2C Timing
Note 4
Note 5
a read request command message. In other words
the host must solicit a response from the DSP. In
this environment, the host must read from the
CS492X until INTREQ goes high again. Once the
INTREQ pin has gone high it will not be driven low
until the host sends another read request.
When unsolicited messages, such as those used for
Autodetect, have been enabled, the behavior of
INTREQ is noticeably different. The CS492X will
drop the INTREQ pin whenever the DSP has an
outgoing message, even though the host may not
have requested data.
There are three ways in which INTREQ can be
affected by an unsolicited message:
1) During normal operation, while INTREQ is
high, the DSP could drop INTREQ to indicate an
outgoing message, without a prior read request.
2) The host is in the process of reading from the
CS492X, meaning that INTREQ is already low. An
unsolicited message arrives which forces INTREQ
to remain low after the solicited message is read.
3) The host is reading from the CS492X when the
unsolicited message is queued, but INTREQ goes
high for one period of SCCLK and then goes low
again before the end of the read cycle.
In case (1) the host should perform a read operation
as discussed in the previous sections.
In case (2) an unsolicited message arrives before
the second to last SCCLK of the final byte transfer
of a read, forcing the INTREQ pin to remain low.
In this scenario the host should continue to read
from the CS492X without a stop/start condition or
data will be lost.
In case (3) an unsolicited message arrives between
the second to last SCCLK and the last SCCLK of
the final byte transfer of a read. In this scenario,
INTREQ will transition high for one clock (as if the
read transaction has ended), and then back low
(indicating that more data has queued). This final
case is the most com plicated and shall be expl ained
in detail.
There are two constraints which completely
characterize the behavior of the INTREQ pin
during a read. The first constraint is that the
INTREQ pin is guaranteed to remain low until the
second to last SCCLK (SCCLK number N-1) of the
final byte being transferred from the CS492X (not
necessarily the second to last bit of the data byte).
The second constraint is that once the INTREQ pin
has gone high it is guaranteed to remain high until
the rising edge of the last SCCLK (SCCLK number
N) of the final byte being transferred from the
CS492X (not necessarily the last bit of the data
byte). If an unsolicited message arrives in the
window of time between the rising edge of the
second to last SCCLK and the final SCCLK,
INTREQ will drop low on the rising edge of the
final SCCLK as illustrated in the functional timing
diagrams shown for I2C and SPI read cycles.
INTREQ behavior for I2C communication is
illustrated in figure 6. When using I2C
communication the INTREQ pin will remain low
until the rising edge of SCCLK for the data bit D0
(SCCLK N-1), but it can go low at the rising edge
of SCCLK for the NACK bit (SCCLK N) if an
unsolicited message has arrived. If no unsolicited
messages arrive, the INTREQ pin will remain high
after rising.
INTREQ behavior for SPI communication is
illustrated in figure 3. When using SPI
communication, the INTREQ pin will remain low
until the rising edge of SCCLK for the data bit D1
(SCCLK N-1), but it can go low at the rising edge
of SCCLK for data bit D0 (SCCLK N) if an
unsolicited message has arrived. If no unsolicited
messages arrive, the INTREQ pin will remain high
after rising.
Ideally, the host will sample INTREQ on the
falling edge of SCCLK number N-1 of the final
byte of each read response message. If INTREQ is
16AN115REV2
sampled high, the host should conclude the current
read cycle using the stop condition defined for the
communication mode chosen. The host should then
begin a new read cycle complete with the
appropriate start condition and the chip address. If
INTREQ is sampled low, the host should continue
reading the next message from the CS492X
without ending the current read cycle.
When using automated communication ports,
however, the host is often limited to sampling the
status of INTREQ after an entire byte has been
transferred. In this situation a low-high-low
transition (case 3) would be missed and the host
will see a constantly low INTREQ pin. Since the
host should read from the CS492X until it detects
that INTREQ has gone high, this condition will be
treated as a multiple-message read (more than one
read response is provided by the CS492X). Under
these conditions a single byte of 0x00 will be read
out before the unsolicited message.
The length of every read response is defined in the
user’s manual for each piece of application code.
Thus, the host should know how many bytes to expect
based on the first byte (the OPCODE) of a read
response message. It is guaranteed that no read
responses will begin with 0x00, which means that a
NULL byte (0x00) detected in the OPCODE position
of a read response message should be discarded.
Please see an Application Code User’s Guide for an
explanation of the OPCODE.
It is important that the host be aware of the
presence of NULL bytes, or the communication
channel could become corrupted.
When case (3) occurs and the host issues a stop
condition before starting a new read cycle, the first
byte of the unsolicited message is loaded directly
into the shift register and 0x00 is never seen.
Alternatively, if case (3) occurs and the host continues to read from the CS492X without a stop condition (a multiple message read), the 0x00 byte
must be shifted out of the CS492X before the first
byte of the unsolicited message can be read.
In other words, if a system can only sample
INTREQ after an entire byte transfer the following
routine should be used if INTREQ is low after the
last byte of the message being read:
1) Read one byte
2) If the byte == 0x00 discard it and skip to step 3.
If the byte != 0x00 then it is the OPCODE for
the next message. For this case skip to step 4.
3) Read one more byte. This is the OPCODE for
the next message.
4) Read the rest of the messag e as indicat ed in the
previous sections.
2.2Parallel Host Communication
The parallel host communication modes of the
CS4923/4/5/6/7/8/9 provide an 8-bit interface to
the DSP. An Intel-style parallel mode and a
Motorola-style parallel mode are supported. The
mode of communication is determined by the states
of the RD (pin 5), WR (pin 4), and PSEL (pin 19)
pins at the rising edge of RESET (pin 36). Each
time the CS492X is reset, the RD, WR, and PSEL
pins are sampled to determine how the host
interface port will be configured. Table 4 shows the
necessary pin configurations for selecting a parallel
configuration mode.
RDWRPSELMODE
110Intel Mode
111Motorola Mode
Table 4. Parallel Host Mode Configurations
The host interface is implemented using four
communication registers within the CS492X:
•The Host Message register (A[1:0]==00b):
receives incoming control data bytes and
provides outgoing response data bytes.
AN115REV217
•The Host Control register (A[1:0]=01b):
provides information about the state of the
communication interface.
•The PCM Data Input register (A[1:0]=10b):
accepts bytes of linear PCM audio data
(WRITE ONLY).
•The Compressed Data Input register
(A[1:0]=11b): accepts bytes of compressed
audio data (WRITE ONLY).
When the host is downloading code to the CS492X
or configuring the application code, control
messages will be written to (and read from) the
Host Message register. The Host Control register is
used during messaging sessions to determine when
the CS492X can accept another byte of control
data, and when the CS492X has an outgoing byte
that may be read.
The PCM Data and Compressed Data registers are
used strictly for the transfer of audio data. The host
cannot read from these two registers. Audio data
written to registers 11b and 10b are transferred
directly to the internal FIFOs of the CS492X. When
the level of the PCM FIFO reaches the FIFO
threshold level, the MFC bit of the Host Control
register will be set. When the leve l of the Compressed
Data FIFO reaches the FIFO threshold level, the MFB
bit of the Host Control register will be set.
It is important to remember that the parallel host
interface requires the DATA[7:0] pins of the
CS492X. The external memory interface also
requires the DATA[7:0] pins. This conflict results
in the following constraint:
•Parallel host communication modes cannot be used
when processing DTS (CS4926 and CS4928)
Systems that require DTS capability and systems
utilizing the autoboot capabilities of the CS492X
must use a serial host communication protocol.
A detailed description for each parallel host mode
will now be given. The following information will
be provided for the Intel mode and Motorola mode:
•The pins of the CS492X which must be used for
proper communication
•Flow diagram and description for a parallel
byte write
•Flow diagram and description for a parallel
byte read
The four registers of the CS492X’s parallel host
mode are not used identically. The algorithm used
for communicating with each register will be given
as a functional description, building upon the basic
read and write protocols defined in the Motorola
and Intel sections. The following will be covered:
•Flow diagram and description for a control write
•Flow diagram and description for a control read
2.2.1Intel Parallel Host Communication
Mode
The Intel parallel host communication mode is
implemented using the pins given in Table 5.
The INTREQ pin is controlled by the application code
when a parallel host communication mode has been
selected. When the code supports INTREQ
notification, the INTREQ pin is asserted whenever
the DSP has an outgoing message for the host. This
18
4
5
19
18AN115REV2
same information is reflected by the HOUTRDY bit
Figure 7. Intel Mode, One-Byte Write Flow Diagram
ADDRESS A PARALLEL I/O REGISTER
CS (LOW)
WRITE BYTE TO
CS (HIGH)
WR (LOW)
(A[1:0] SET APPROPRIATELY
DATA [7:0]
WR (HIGH)
of the Host Control Register (A[1:0] = 01b).
INTREQ is useful for informing the host of
unsolicited messages. An unsolicited message is
defined as a message generated by the DSP without
an associated host read request. Unsolicited
messages can be used to notify the host of
conditions such as a change in the incoming audio
data type (e.g. PCM --> AC-3).
2.2.1.1Writing a Byte in Intel Mode
Information provided in this section is intended as
a functional description of how to write control
information to the CS492X. The system designer
must insure that all of the timing constraints of the
Intel Parallel Host Mode Write Cycle are met. The
timing specifications for the Intel Parallel Host
Mode can be found in the CS4923/4/5/6/7/8/9
Family Datasheet.
The flow diagram shown in Figure 7 illustrates the
sequence of events that define a one-byte write in
Intel mode.
1) The host must first drive the A1 and A0 register
address pins of the CS492X with the address of
the desired Parallel I/O Register.
2) The host then indica tes that the selected r egister
will be written. The host initiates a write cycle
by driving the CS and WR pins low.
3) The host drives the data byte to the DATA[7:0]
pins of the CS492X.
4) Once the setup time for the write has bee n me t,
the host ends the write cycle by driving the CS
and WR pins high.
2.2.1.2Reading a Byte in Intel Mode
Information provided in this section is intended as
a functional description of how to write control
information to the CS492X. The system designer
must insure that all of the timing constraints of the
Intel Parallel Host Mode Read Cycle are met. The
timing specifications for the Intel Parallel Host
Mode can be found in the CS4923/4/5/6/7/8/9
Family Datasheet
The protocol presented in Figure 7 will now be
described in detail.
AN115REV219
The flow diagram shown in Figure 8 illustrates the
sequence of events that define a one-byte read in
Intel mode.
The protocol presented in Figure 8 will now be
described in detail.
1) The host must first drive the A1 and A0 register
address pins of the CS492X with the address of
the desired Parallel I/O Register. Note that only
the Host Message register and the Host Control
register can be read.
2) The host now indicates that the selected regis ter
Figure 8. Intel Mode, One-Byte Read Flow Diagram
ADDRESS A PARALLEL I/O REGISTER
CS (LOW)
READ BYTE FROM
CS
(HIGH)
RD (LOW)
(A[1:0] SET APPROPRIATELY
DATA [7:0]
RD (HIGH)
will be read. The host initiates a read cycle by
driving the CS and RD pins low.
3) Once the data is valid, the host can read the
value of the selected register from the
DATA[7:0] pins of the CS492X.
4) The host should now terminate the read cycle
by driving the CS and RD pins high.
2.2.2Motorola Parallel Host
Communication Mode
The Motorola parallel host communication mode is
implemented using the pins given in Table 6.The
INTREQ pin is controlled by the application code
when a parallel host communication mode has been
selected. When the code supports INTREQ
notification, the INTREQ pin is asserted whenever
the DSP has an outgoing message for the host. This
same information is reflected by the HOUTRDY
bit of the Host Control Register (A[1:0] = 01b).
INTREQ is useful for informing the host of
unsolicited messages. An unsolicited message is
defined as a message generated by the DSP without
an associated host read request. Unsolicited
messages can be used to notify the host of
conditions such as a change in the incoming audio
data type (e.g. PCM --> AC-3).
MnemonicPin NamePin Number
Chip SelectCS
Data StrobeDS
Read or Write SelectR/W
Register Address Bit 1A16
Register Address Bit 0A07
Interrupt RequestINTREQ
DATA7DATA78
DATA6DATA69
DATA5DAT A510
DATA4DATA411
DATA3DAT A314
DATA2DAT A215
DATA1DAT A116
DATA0DAT A017
Table 6. Motorola Mode Communication Signals
18
4
5
19
2.2.2.1Writing a Byte in Motorola Mode
Information provided in this section is intended as
a functional description of how to write control
information to the CS492X. The system designer
must insure that all of the timing constraints of the
Motorola Parallel Host Mode Write Cycle are met.
The timing specifications for the Motorola Parallel
Host Mode can be found in the CS4923/4/5/6/7/8/9
Family Datasheet.
The flow diagram shown in Figure 9 illustrates the
sequence of events that define a one-byte write in
Motorola mode.
The protocol presented in figure 9 will now be
described in detail.
20AN115REV2
Figure 9. Motorola Mode, One-Byte Write Flow
Diagram
R/W (LOW)
CS (LOW)
WRITE BYTE TO
CS (HIGH)
DS (LOW)
ADDRESS A PARALLEL I/O REGISTER
DATA [7:0]
DS
(HIGH)
(A[1:0] SET APPROPRIATELY
R/W (HIGH)
ADDRESS A PARALLEL I/O REGISTER
(A[1:0] SET APPROPRIATELY
CS (LOW)
DS (LOW)
READ BYTE FROM
DATA [7:0]
CS
(HIGH)
DS (HIGH)
Figure 10. Motorola Mode, One-Byte Read Flow
Diagram
1) The host must drive the A1 and A0 register
address pins of the CS492X with the address of
the address of the desired Parallel I/O Register.
Host Message: A[1:0]==00b.
Host Control: A[1:0]==01b.
PCMDATA: A[1:0]==10b.
CMPDATA: A[1:0]==11b.
The host indicates that this is a write cycle by
driving the R/W pin low.
2) The host initiates a write cycle by driving the
CS and DS pins low.
3) The host drives the data byte to the DATA[7:0]
pins of the CS492X.
4) Once the setup time for the write ha s been me t,
the host ends the write cycle by driving the CS
and DS pins high.
2.2.2.2Reading a Byte in Motorola Mode
The flow diagram shown in Figure 10 illustrates the
sequence of events that define a one-byte read in
Motorola mode.
The protocol presented Figure 10 will now be
described in detail.
1) The host must drive the A1 and A0 register
address pins of the CS492X with the address of
the desired Parallel I/O Register. Note that only
the Host Message register and the Host Control
register can be read.
Host Message: A[1:0]==00b.
Host Control: A[1:0]==01b.
The host indicates that this is a read cycle by
driving the R/W pin high.
2) The host initiates the read cycle by driving the
CS and DS pins low.
3) Once the data is valid, the host can read the
value of the selected register from the
DATA[7:0] pins of the CS492X.
4) The host should now terminate the read cycle
by driving the CS and DS pins high.
AN115REV221
Loading...
+ 46 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.