Project

General

Profile

Actions

HardwareCalypsoDSP » History » Revision 1

Revision 1/11 | Next »
laforge, 02/19/2016 10:48 PM
some documentation on how the DSP works


= The Calypso DSP =

The DSP inside the Calypso is a TMS320c5x LEAD2 DSP core.

The software inside the DSP is mainly mask-ROM implementing the signal processing related pary of GSM (mostly Rx side).

DSP Hardware

=== Bus ===
The DSP has its own address adress and data bus, independent of the ARM bus.

There is a bridge (called RHEA bridge) interfacing the DSP with its peripherals.

=== Clock ===
The Clock is fed from the DPLL of the Calypso chip.

=== Reset ===
The Reset line of the DSP is controlled by the ARM.

=== API RAM ===
There's a shared memory window (8kWords, i.e. 16kByte) between the DSP and the ARM used for inter-CPU-communication

DSP Software

=== Patches ===
The normal phone firmware downloads patches into the DSP RAM, using the API memory.
The DSP ROM code seems to contain some patch download program that is executed after reset.

Patches are likely used to fix bugs and to extend features in the DSP

=== API ===

The API is the programming interface implemented via the API RAM.

It consists of * A double buffered (DB) Read Page (DSP->ARM direction, mostly response values) * A double buffered (DB) Write Page (ARM->DSP direction, mostly commands) * A non double-buffered (NDB) Page * A parameter area

=== Timing ===

The flow of events is as follows: * The ARM utilizeds the DB Write page to define the set of actions (tasks) to be performed by the DSP * It indicates which tasks (GSM and/or MISC) are to be executed by a field in the NDB page * It indicates which of the two double buffered write pages was used in the NDB page * The ARM tells the TPU to issue a FRAME interrupt at the next GSM frame * When the first FRAME interrupt executes, the DSP starts to process the tasks as indicated by the ARM * Results are stored as they are ready, using the DB Read page * When the next FRAME interrupt executes, the ARM can read the results from the DB Read page.

Those flows normally happen overlapping, i.e. after the first FRAME interrupt above, the ARM can already write
the next set of commands to the ''other'' DB Write page.

Of course, some more complex DSP tasks take more than one frame to complete. The ARM code needs to know how
many frame interrupts to wait before reading the results from the DB Read page.

=== Tasks ===

The DSP has a number of tasks that it can execute on behalf of the ARM.

==== CHECKSUM ====
This task computes a checksum over the program code inside the DSP. It is used to ensure that patches in combination with
the ROM code have the desired overall result.

The checksum task finishes after 1 frame.

==== Measurement / AGC Task ====
This task measures the received power level to control the gain of the analog Rx path.

The ARM can specify how many measurements are to be taken (1,2 or 3).

The number of measurements determines the execution time.

==== FB (Frequency Burst) ====
This task performs Frequency Burst detection/decoding in idle mode.

This task finishes after a maximum of 13 frames.

The first frame is "idle", and all further 12 frames are checked for frequency burst detection results in the NDB page.

==== SB (Synchronization Burst) ====
This task performs Synchronization Burst detection/decoding in idle mode.

It has two wait-states ({{{C W W R}}})

==== TCH_FB (Frequency Burst) ====
This task performs Frequency Burst reading in dedicated mode.

==== TCH_SB (Synchronization Burst) ====
This task performs Synchronization Burst reading in dedicated mode.

Files (0)

Updated by laforge about 8 years ago · 1 revisions

Add picture from clipboard (Maximum size: 48.8 MB)