HardwareCalypsoDSP » History » Version 3
laforge, 02/19/2016 10:48 PM
add distinction dsp / arm tasks
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 | 3 | laforge | Please don't confuse DSP tasks with Layer1 tasks. They are both called ''tasks'' and even use one namespace, |
64 | but are distinctively different. Each layer1 task (on the ARM) is using a sequence of one or multiple DSP tasks. |
||
65 | |||
66 | 1 | laforge | ==== CHECKSUM ==== |
67 | This task computes a checksum over the program code inside the DSP. It is used to ensure that patches in combination with |
||
68 | the ROM code have the desired overall result. |
||
69 | |||
70 | The checksum task finishes after 1 frame. |
||
71 | |||
72 | ==== Measurement / AGC Task ==== |
||
73 | This task measures the received power level to control the gain of the analog Rx path. |
||
74 | |||
75 | The ARM can specify how many measurements are to be taken (1,2 or 3). |
||
76 | |||
77 | The number of measurements determines the execution time. |
||
78 | |||
79 | ==== FB (Frequency Burst) ==== |
||
80 | This task performs Frequency Burst detection/decoding in idle mode. |
||
81 | |||
82 | This task finishes after a maximum of 13 frames. |
||
83 | |||
84 | The first frame is "idle", and all further 12 frames are checked for frequency burst detection results in the NDB page. |
||
85 | |||
86 | ==== SB (Synchronization Burst) ==== |
||
87 | This task performs Synchronization Burst detection/decoding in idle mode. |
||
88 | |||
89 | It has two wait-states ({{{C W W R}}}) |
||
90 | |||
91 | ==== TCH_FB (Frequency Burst) ==== |
||
92 | This task performs Frequency Burst reading in dedicated mode. |
||
93 | |||
94 | ==== TCH_SB (Synchronization Burst) ==== |
||
95 | This task performs Synchronization Burst reading in dedicated mode. |
||
96 | 2 | laforge | |
97 | |||
98 | === Data Formats === |
||
99 | |||
100 | ==== Angle ==== |
||
101 | |||
102 | This angle indicates how far the received carrier clock deviates from our synthesized LO-based clock. |
||
103 | It's measured in radians and coded in fx1.15 notation (fixed-point 16bit data type with 1 bit integral and 15bit fractional) |
||
104 | |||
105 | ==== SNR (Signal/Noise Ratio) ==== |
||
106 | |||
107 | The SNR as measured by the DSP is maesured in dB and coded in fx6.10 notation. |
||
108 | |||
109 | ==== Power ==== |
||
110 | |||
111 | The Power of a signal present at the ADC baseband input, coded in 1/64dBm |