HardwareCalypsoDSP » History » Version 11
nion, 02/19/2016 10:49 PM
Name changed from CalypsoDSP to Hardware/CalypsoDSP
1 | 11 | nion | {{>toc}} |
---|---|---|---|
2 | 1 | laforge | |
3 | 11 | nion | h1. The Calypso DSP |
4 | |||
5 | |||
6 | 1 | laforge | The DSP inside the Calypso is a TMS320c5x LEAD2 DSP core. |
7 | |||
8 | The software inside the DSP is mainly mask-ROM implementing the signal processing related part of GSM (mostly Rx side). |
||
9 | |||
10 | |||
11 | 11 | nion | h2. DSP Hardware |
12 | |||
13 | |||
14 | |||
15 | h3. Bus |
||
16 | |||
17 | 1 | laforge | The DSP has its own address adress and data bus, independent of the ARM bus. |
18 | |||
19 | There is a bridge (called RHEA bridge) interfacing the DSP with its peripherals. |
||
20 | |||
21 | 11 | nion | |
22 | h3. Clock |
||
23 | |||
24 | 1 | laforge | The Clock is fed from the DPLL of the Calypso chip. |
25 | |||
26 | 11 | nion | |
27 | h3. Reset |
||
28 | |||
29 | 1 | laforge | The Reset line of the DSP is controlled by the ARM. |
30 | |||
31 | 11 | nion | |
32 | h3. API RAM |
||
33 | |||
34 | 1 | laforge | There's a shared memory window (8kWords, i.e. 16kByte) between the DSP and the ARM used for inter-CPU-communication |
35 | |||
36 | |||
37 | 11 | nion | h2. DSP Software |
38 | |||
39 | |||
40 | |||
41 | h3. Patches |
||
42 | |||
43 | 1 | laforge | The normal phone firmware downloads patches into the DSP RAM, using the API memory. |
44 | The DSP ROM code seems to contain some patch download program that is executed after reset. |
||
45 | |||
46 | Patches are likely used to fix bugs and to extend features in the DSP |
||
47 | |||
48 | |||
49 | |||
50 | 11 | nion | h3. API |
51 | |||
52 | |||
53 | 1 | laforge | The API is the programming interface implemented via the API RAM. |
54 | |||
55 | It consists of |
||
56 | 11 | nion | * A double buffered (DB) Read Page (DSP->ARM direction, mostly response values) |
57 | * A double buffered (DB) Write Page (ARM->DSP direction, mostly commands) |
||
58 | * A non double-buffered (NDB) Page |
||
59 | * A parameter area |
||
60 | 1 | laforge | |
61 | 5 | laforge | Some parameters details: |
62 | 11 | nion | * @ndb.d_tch_mode@ |
63 | *** bit 11: ABB model selection. @1@ selects IOTA, @0@ selects ???. This changes the address at which @BULDATA@ register is expected. |
||
64 | *** bit ![10:7] : Number of guard bits inserted before actual data when TXing burst. (actual value - 4). Max value seems to be 8 guard bit. After that the DSP code will do strange things. So setting a value of 4 will TX 4+4=8 guard bits and so will be @11111111000xxxxx...@. The @1@ are guard bits, then 3 x @0@ of tail, then the data. |
||
65 | 1 | laforge | |
66 | |||
67 | |||
68 | |||
69 | 11 | nion | h3. Timing |
70 | |||
71 | |||
72 | 5 | laforge | The timing we know so far is for single-slot operation (i.e. only one of the 8 timeslots is used) |
73 | 1 | laforge | |
74 | The flow of events is as follows: |
||
75 | 11 | nion | * The ARM utilizeds the DB Write page to define the set of actions (tasks) to be performed by the DSP |
76 | ** It indicates which tasks (GSM and/or MISC) are to be executed by a field in the NDB page |
||
77 | ** It indicates which of the two double buffered write pages was used in the NDB page |
||
78 | * The ARM tells the TPU to issue a FRAME interrupt at the next GSM frame |
||
79 | * When the first FRAME interrupt executes, the DSP starts to process the tasks as indicated by the ARM |
||
80 | ** The DSP seems to need a setup time of 66 Quarter-bits before it receives RF samples via TSP (DSP_SETUP_TIME) |
||
81 | ** The DSP receives and processes the sample data |
||
82 | ** Results are stored as they are ready, using the DB Read page |
||
83 | * When the next FRAME interrupt executes, the ARM can read the results from the DB Read page. |
||
84 | 1 | laforge | |
85 | Those flows normally happen overlapping, i.e. after the first FRAME interrupt above, the ARM can already write |
||
86 | 11 | nion | the next set of commands to the _other_ DB Write page. |
87 | 3 | laforge | |
88 | Of course, some more complex DSP tasks take more than one frame to complete. The ARM code needs to know how |
||
89 | 1 | laforge | many frame interrupts to wait before reading the results from the DB Read page. |
90 | |||
91 | |||
92 | 11 | nion | h3. Tasks |
93 | 1 | laforge | |
94 | 11 | nion | |
95 | The DSP has a number of tasks that it can execute on behalf of the ARM. A full list is available at [[TSM30Layer1#DSPTasks]] |
||
96 | |||
97 | Please don't confuse DSP tasks with Layer1 tasks. They are both called _tasks_ and even use one namespace, |
||
98 | 1 | laforge | but are distinctively different. Each layer1 task (on the ARM) is using a sequence of one or multiple DSP tasks. |
99 | |||
100 | 11 | nion | |
101 | h4. CHECKSUM |
||
102 | |||
103 | 1 | laforge | This task computes a checksum over the program code inside the DSP. It is used to ensure that patches in combination with |
104 | the ROM code have the desired overall result. |
||
105 | |||
106 | The checksum task finishes after 1 frame. |
||
107 | 5 | laforge | |
108 | 11 | nion | |
109 | h4. PM (Power Measurement) / AGC Task |
||
110 | |||
111 | 1 | laforge | This task measures the received power level to control the gain of the analog Rx path. |
112 | |||
113 | The ARM can specify how many measurements are to be taken (1,2 or 3). |
||
114 | |||
115 | The number of measurements determines the execution time. |
||
116 | |||
117 | 11 | nion | |
118 | h4. FB (Frequency Burst) |
||
119 | |||
120 | 1 | laforge | This task performs Frequency Burst detection/decoding in idle mode. |
121 | |||
122 | This task finishes after a maximum of 13 frames. |
||
123 | |||
124 | The first frame is "idle", and all further 12 frames are checked for frequency burst detection results in the NDB page. |
||
125 | |||
126 | 11 | nion | |
127 | h4. SB (Synchronisation Burst) |
||
128 | |||
129 | 1 | laforge | This task performs Synchronisation Burst detection/decoding in idle mode. |
130 | |||
131 | 11 | nion | <pre> |
132 | 1 | laforge | |
133 | 11 | nion | It processes 190 IQ samples and has a 50 bits training sequence search window starting at sample!r39 and correlating the full 64 bits. |
134 | 1 | laforge | (See PROM0:7C2C in DSP code for more details about demodulation) |
135 | |||
136 | 11 | nion | |
137 | h4. RX NB (Normal Burst - Reception) |
||
138 | |||
139 | 9 | ahuemer | This task performs reception of Normal Bursts in both idle mode & dedicated mode. It should be called four times (for the 4 bursts) and the final data can be retrieved on the fourth call response. |
140 | |||
141 | 11 | nion | It processes 150 IQ samples and has a 10 bits training sequence search window starting at sample!r68 and correlating only 16 bits (TSC![10..25]). |
142 | 6 | laforge | (See PROM0:7C27 in DSP code for more details about demodulation) |
143 | 1 | laforge | |
144 | 11 | nion | |
145 | h4. TCH_FB (Frequency Burst) |
||
146 | |||
147 | 6 | laforge | This task performs Frequency Burst reading in dedicated mode. |
148 | 9 | ahuemer | |
149 | 11 | nion | |
150 | h4. TCH_SB (Synchronisation Burst) |
||
151 | |||
152 | 6 | laforge | This task performs Synchronisation Burst reading in dedicated mode. |
153 | 1 | laforge | |
154 | |||
155 | |||
156 | 11 | nion | h3. Data Formats |
157 | 9 | ahuemer | |
158 | 11 | nion | |
159 | |||
160 | h4. Angle |
||
161 | |||
162 | |||
163 | 2 | laforge | This angle indicates how far the received carrier clock deviates from our synthesised LO-based clock. |
164 | 9 | ahuemer | It's measured in radians and coded in fx1.15 notation (fixed-point 16bit data type with 1 bit integral and 15bit fractional) |
165 | 2 | laforge | |
166 | |||
167 | 11 | nion | h4. SNR (Signal/Noise Ratio) |
168 | |||
169 | |||
170 | 2 | laforge | The SNR as measured by the DSP is measured in dB and coded in fx6.10 notation. |
171 | |||
172 | |||
173 | 11 | nion | h4. Power |
174 | |||
175 | |||
176 | 6 | laforge | The Power of a signal present at the ADC baseband input, coded in 1/64dBm |
177 | |||
178 | 11 | nion | |
179 | h4. TOA (Time Of Arrival) |
||
180 | |||
181 | 1 | laforge | |
182 | When reading NB, this is expressed as full bits and seems to be only positive. |