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