HardwareCalypsoDSP » History » Version 1
laforge, 02/19/2016 10:48 PM
some documentation on how the DSP works
1 | 1 | laforge | = The Calypso DSP = |
---|---|---|---|
2 | |||
3 | The DSP inside the Calypso is a TMS320c5x LEAD2 DSP core. |
||
4 | |||
5 | The software inside the DSP is mainly mask-ROM implementing the signal processing related pary of GSM (mostly Rx side). |
||
6 | |||
7 | == DSP Hardware == |
||
8 | |||
9 | === Bus === |
||
10 | The DSP has its own address adress and data bus, independent of the ARM bus. |
||
11 | |||
12 | There is a bridge (called RHEA bridge) interfacing the DSP with its peripherals. |
||
13 | |||
14 | === Clock === |
||
15 | The Clock is fed from the DPLL of the Calypso chip. |
||
16 | |||
17 | === Reset === |
||
18 | The Reset line of the DSP is controlled by the ARM. |
||
19 | |||
20 | === API RAM === |
||
21 | There's a shared memory window (8kWords, i.e. 16kByte) between the DSP and the ARM used for inter-CPU-communication |
||
22 | |||
23 | == DSP Software == |
||
24 | |||
25 | === Patches === |
||
26 | The normal phone firmware downloads patches into the DSP RAM, using the API memory. |
||
27 | The DSP ROM code seems to contain some patch download program that is executed after reset. |
||
28 | |||
29 | Patches are likely used to fix bugs and to extend features in the DSP |
||
30 | |||
31 | |||
32 | === API === |
||
33 | |||
34 | The API is the programming interface implemented via the API RAM. |
||
35 | |||
36 | It consists of |
||
37 | * A double buffered (DB) Read Page (DSP->ARM direction, mostly response values) |
||
38 | * A double buffered (DB) Write Page (ARM->DSP direction, mostly commands) |
||
39 | * A non double-buffered (NDB) Page |
||
40 | * A parameter area |
||
41 | |||
42 | === Timing === |
||
43 | |||
44 | The flow of events is as follows: |
||
45 | * The ARM utilizeds the DB Write page to define the set of actions (tasks) to be performed by the DSP |
||
46 | * It indicates which tasks (GSM and/or MISC) are to be executed by a field in the NDB page |
||
47 | * It indicates which of the two double buffered write pages was used in the NDB page |
||
48 | * The ARM tells the TPU to issue a FRAME interrupt at the next GSM frame |
||
49 | * When the first FRAME interrupt executes, the DSP starts to process the tasks as indicated by the ARM |
||
50 | * Results are stored as they are ready, using the DB Read page |
||
51 | * When the next FRAME interrupt executes, the ARM can read the results from the DB Read page. |
||
52 | |||
53 | Those flows normally happen overlapping, i.e. after the first FRAME interrupt above, the ARM can already write |
||
54 | the next set of commands to the ''other'' DB Write page. |
||
55 | |||
56 | Of course, some more complex DSP tasks take more than one frame to complete. The ARM code needs to know how |
||
57 | many frame interrupts to wait before reading the results from the DB Read page. |
||
58 | |||
59 | === Tasks === |
||
60 | |||
61 | The DSP has a number of tasks that it can execute on behalf of the ARM. |
||
62 | |||
63 | ==== CHECKSUM ==== |
||
64 | This task computes a checksum over the program code inside the DSP. It is used to ensure that patches in combination with |
||
65 | the ROM code have the desired overall result. |
||
66 | |||
67 | The checksum task finishes after 1 frame. |
||
68 | |||
69 | ==== Measurement / AGC Task ==== |
||
70 | This task measures the received power level to control the gain of the analog Rx path. |
||
71 | |||
72 | The ARM can specify how many measurements are to be taken (1,2 or 3). |
||
73 | |||
74 | The number of measurements determines the execution time. |
||
75 | |||
76 | ==== FB (Frequency Burst) ==== |
||
77 | This task performs Frequency Burst detection/decoding in idle mode. |
||
78 | |||
79 | This task finishes after a maximum of 13 frames. |
||
80 | |||
81 | The first frame is "idle", and all further 12 frames are checked for frequency burst detection results in the NDB page. |
||
82 | |||
83 | ==== SB (Synchronization Burst) ==== |
||
84 | This task performs Synchronization Burst detection/decoding in idle mode. |
||
85 | |||
86 | It has two wait-states ({{{C W W R}}}) |
||
87 | |||
88 | ==== TCH_FB (Frequency Burst) ==== |
||
89 | This task performs Frequency Burst reading in dedicated mode. |
||
90 | |||
91 | ==== TCH_SB (Synchronization Burst) ==== |
||
92 | This task performs Synchronization Burst reading in dedicated mode. |