FreeCalypso > hg > fc-sim-sniff

comparison doc/Sniffer-FPGA-design @ 17:41e6026e5d1a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc/Sniffer-FPGA-design: update for first implementation
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 21 Aug 2023 06:50:55 +0000
parents b275c69c1b80
children c03a882cc49e
comparison
equal deleted inserted replaced
16:00229623ca81 17:41e6026e5d1a
1 The first FPGA gateware function to be implemented in the SIMtrace-ice project 1 The first FPGA logic function in the SIMtrace-ice project has been implemented
2 is the passive sniffer: receiving level-shifted SIM RST, CLK and I/O signals 2 and is now waiting to be tested: it is the basic sniffer FPGA in the
3 from the 74LVC4T3144 buffer and capturing all exchanges that happen on the SIM 3 fpga/sniffer-basic directory. It is an FPGA image for Lattice Icestick, an
4 interface between a DUS and a SIM. 4 inexpensive off-the-shelf iCE40 FPGA board, and it implements the function of
5 5 passive sniffing: receiving level-shifted SIM RST, CLK and I/O signals from the
6 The sniffer FPGA logic function will be implemented on the inexpensive off-the- 6 74LVC4T3144 buffer and capturing all exchanges that happen on the SIM interface
7 shelf Icestick board, featuring an iCE40HX1K FPGA and an FT2232H-based USB host 7 between a GSM ME or other interface device (ME/ID for short) and a SIM.
8 interface. This FPGA logic function will operate principally as a byte 8
9 forwarder from the ISO 7816-3 sniffer block to the FT2232H UART: every time the 9 This FPGA gateware function is currently waiting to be tested: some custom
10 bus sniffer block captures a character (in ISO 7816-3 terminology) being passed 10 hardware needs to be assembled before the FPGA can be tested. The PCB fab order
11 on the SIM electrical interface in either direction (the two directions of 11 for our mv-sniffer adapter board has just been placed; we will need to receive
12 transmission are indistinguishable to a tap sniffer that does not actively 12 the PCB, get it populated, and also populate the missing pin headers on the
13 participate in the protocol), the FPGA will forward this character to the 13 Icestick board before we can test our FPGA.
14 connected host computer (by way of FT2232H UART) for further processing in 14
15 software. The UART data line going from the FPGA to the FT2232H will be the 15 The two principal components of the Icestick board are an iCE40HX1K FPGA and an
16 sole functional output from this FPGA, beyond debug outputs being added during 16 FT2232H-based USB host interface. Our sniffer logic function in the FPGA
17 logic development and troubleshooting. The other UART data line going the 17 operates principally as a byte forwarder from the ISO 7816-3 sniffer block to
18 opposite direction (output from FT2232H) will remain unused, i.e., the host 18 the FT2232H UART: every time the bus sniffer block captures a character (in ISO
19 software application will only read/receive from the ttyUSBx FPGA device and 19 7816-3 terminology) being passed on the SIM electrical interface in either
20 won't send anything to it. All modem control lines on this UART interface will 20 direction (the two directions of transmission are indistinguishable to a tap
21 likewise remain unused. 21 sniffer that does not actively participate in the protocol), the FPGA will
22 forward this character to the connected host computer (by way of FT2232H UART)
23 for further processing in software. The UART data line going from the FPGA to
24 the FT2232H is the sole functional output from this FPGA, beyond debug outputs
25 being added during logic development and troubleshooting. The other UART data
26 line going the opposite direction (output from FT2232H) remains unused in this
27 application, i.e., the host software application will only read/receive from the
28 ttyUSBx FPGA device and won't send anything to it. All modem control lines on
29 this UART interface likewise remain unused.
22 30
23 Serial interface format 31 Serial interface format
24 ======================= 32 =======================
25 33
26 For every ISO 7816-3 character captured by the sniffer, two back-to-back UART 34 For every ISO 7816-3 character captured by the sniffer, two back-to-back UART
52 computer. One bit in the 16-bit message will distinguish between characters 60 computer. One bit in the 16-bit message will distinguish between characters
53 and RST events, another bit will indicate the state of RST at the time of the 61 and RST events, another bit will indicate the state of RST at the time of the
54 event (new RST for transitions, 1 for characters), and all other bits are 62 event (new RST for transitions, 1 for characters), and all other bits are
55 meaningful only for characters. 63 meaningful only for characters.
56 64
57 Clocking design 65 Detailed serial interface format
58 =============== 66 --------------------------------
59 67
60 The FPGA on the Icestick board receives a 12 MHz clock input; the on-chip PLL 68 Treating the two transmitted bytes as a single 16-bit word, with the least
61 will be used to multiply this clock by 4, producing a 48 MHz system clock. 69 significant 8 bits transmitted first (matching the transmission order of bits
62 This 48 MHz SYSCLK will be used for the entirety of the present logic design - 70 within a byte), the 16 bits of this word are assigned as follows:
63 a single-clock fully synchronous design is the best current practice. 71
64 72 Bit 15: set to 0 if this message signals ISO 7816-3 character reception or 1 if
65 The 3 inputs to the FPGA coming from the SIM electrical sniffer (buffered and 73 it signals a change of state in the RST line.
66 level-shifted SIM RST, CLK and I/O lines) will pass through two cascaded DFFs, 74
67 bringing them into our internal clock domain. The delay added by these cascaded 75 Bit 14: new state of RST in the case of RST state change messages; should always
68 DFFs is not a concern: we are a passive sniffer without any output back to the 76 be 1 in character Rx messages.
69 SIM interface, and all 3 signal inputs will be subject to the same delay. 77
78 Bits [13:11]: currently unused and set to 0.
79
80 The remaining bits are valid only in character Rx messages:
81
82 Bit 10: set to 1 if the error signal of ISO 7816-3 section 7.3 was detected,
83 0 otherwise.
84
85 Bit 9: sampled line value at the midpoint of the start bit, should be 0 in a
86 properly working system.
87
88 Bit 8: received parity bit;
89
90 Bits [7:0]: payload bits of the received character.
91
92 UART baud rate
93 ==============
70 94
71 The baud rate on the UART interface between the FPGA and the FT2232H converter 95 The baud rate on the UART interface between the FPGA and the FT2232H converter
72 will be 3000000 bps. The UART output block in the FPGA will use a simple /16 96 is 3000000 bps. This high (and very non-RS232-standard) UART baud rate was
73 divider from SYSCLK to time its output bits; future derivative designs that will 97 chosen for the following reasons:
74 use the UART interface bidirectionally (such as the planned card emulator FPGA
75 design) will use SYSCLK directly as the 16x clock for UART reception. This
76 high (and very non-RS232-standard) UART baud rate was chosen for the following
77 reasons:
78 98
79 * Our UART interface is totally private, going nowhere but the on-board FT2232H, 99 * Our UART interface is totally private, going nowhere but the on-board FT2232H,
80 thus it doesn't matter if the baud rate is standard-ish or totally 100 thus it doesn't matter if the baud rate is standard-ish or totally
81 non-standard. 101 non-standard.
82 102
88 our 2x expansion, at the highest possible effective bps rate on the SIM 108 our 2x expansion, at the highest possible effective bps rate on the SIM
89 interface, meaning the highest possible SIM CLK frequency and the most 109 interface, meaning the highest possible SIM CLK frequency and the most
90 aggressive F/D ratio. The combination of SIM CLK at 5 MHz, F=512 and D=64 110 aggressive F/D ratio. The combination of SIM CLK at 5 MHz, F=512 and D=64
91 corresponds to 625000 bps effective on the SIM interface; running our UART at 111 corresponds to 625000 bps effective on the SIM interface; running our UART at
92 3 Mbps provides sufficient margin. 112 3 Mbps provides sufficient margin.
113
114 Clocking design
115 ===============
116
117 The FPGA on the Icestick board receives a 12 MHz clock input. Our original
118 plan was to use the FPGA's on-chip PLL to multiply this clock by 4, producing a
119 48 MHz system clock - however, this plan has been shelved for now, and our
120 current sniffer-basic design uses the 12 MHz clock directly as its system clock.
121
122 The 3 inputs to the FPGA coming from the SIM electrical sniffer (buffered and
123 level-shifted SIM RST, CLK and I/O lines) pass through two cascaded DFFs,
124 bringing them into our internal clock domain. The delay added by these cascaded
125 DFFs is not a concern: we are a passive sniffer without any output back to the
126 SIM interface, and all 3 signal inputs will be subject to the same delay.
127
128 As stated in the previous section, the baud rate on the UART interface between
129 the FPGA and the FT2232H converter is 3000000 bps. The UART output block in
130 the FPGA uses a simple /4 divider from CLK12 (board-level 12 MHz clock input)
131 to time its output bits; the original intent was to use a /16 divider from
132 48 MHz SYSCLK.
93 133
94 ISO 7816-3 sniffer block 134 ISO 7816-3 sniffer block
95 ======================== 135 ========================
96 136
97 Our ISO 7816-3 receiver will trigger on the falling edge of the I/O line. Once 137 Our ISO 7816-3 receiver will trigger on the falling edge of the I/O line. Once
99 will start counting SIM CLK cycles - we are arbitrarily choosing low-to-high 139 will start counting SIM CLK cycles - we are arbitrarily choosing low-to-high
100 transition of SYSCLK-synchronized SIM_CLK input as the trigger point. (This 140 transition of SYSCLK-synchronized SIM_CLK input as the trigger point. (This
101 choice is arbitrary because per the spec there is no defined phase relation 141 choice is arbitrary because per the spec there is no defined phase relation
102 between SIM CLK and SIM I/O transitions.) Our ISO 7816-3 receiver will need to 142 between SIM CLK and SIM I/O transitions.) Our ISO 7816-3 receiver will need to
103 know how many SIM CLK cycles constitute one etu - or more precisely, our 143 know how many SIM CLK cycles constitute one etu - or more precisely, our
104 sniffing receiver will operate in half-etu counts, as we need to measure 0.5 etu 144 sniffing receiver needs to know how many SIM CLK cycles constitute 0.5 etu,
105 to get from the initial falling edge on the I/O line to the mid-etu data 145 1 etu and 1.5 etu, in order to locate various needed sampling points relative
106 sampling point. Following the session-opening low-to-high transition on the RST 146 to the instant at which SIM_IO was initially sampled low.
107 line, our half-etu register will be set to 8'd186, corresponding to F/D=372. 147
108 Our PPS catcher state machine will then overwrite this register with a smaller 148 The initial version of our sniffer gateware (the version in fpga/sniffer-basic)
109 value based on the captured PPS exchange. 149 omits the PPS catcher block, hence the just-described etu durations are
150 currently fixed to F/D=372 default values.
110 151
111 Direct and inverse coding conventions 152 Direct and inverse coding conventions
112 ===================================== 153 =====================================
113 154
114 Only the card and not the DUS (interface device in ISO 7816-3 terminology) 155 Only the card and not the interface device (ISO 7816-3 terminology) determines
115 determines which coding convention is used, direct or inverse. So far we 156 which coding convention is used, direct or inverse. So far we (FreeCalypso)
116 (FreeCalypso) have not yet encountered a real-life SIM that uses the inverse 157 have not yet encountered a real-life SIM that uses the inverse convention, only
117 convention, only the direct convention kind. In the sniffer function of 158 the direct convention kind. In the sniffer function of SIMtrace-ice, we are
118 SIMtrace-ice, we are going to keep our FPGA gateware simple in this regard and 159 going to keep our FPGA gateware simple in this regard and punt all inverse
119 punt all inverse convention handling to the software application on the host 160 convention handling to the software application on the host computer: the FPGA
120 computer: the FPGA will pass the 9 received bits (8 data bits and 1 parity bit) 161 passes the 9 received bits (8 data bits and 1 parity bit) to the 16-bit UART
121 to the 16-bit UART message as-is, without inverting or reordering them. 162 message as-is, without inverting or reordering them.
122 163
123 Integrated PPS catcher 164 Integrated PPS catcher
124 ====================== 165 ======================
125 166
126 The logic described so far will be sufficient to capture all exchanges on the 167 The logic described so far and implemented in the sniffer-basic version will be
127 SIM interface between a DUS and a SIM *if* the etu-defining F/D ratio is never 168 sufficient to capture all exchanges on the SIM interface between ME/ID and a SIM
128 switched from the basic default of 372. However, given that most SIM cards of 169 *if* the etu-defining F/D ratio is never switched from the basic default of 372.
129 interest to us (our own FCSIM1, as well as SIMs issued by various commercial 170 However, given that most SIM cards of interest to us (our own FCSIM1, as well as
130 operators) support Fi=512 Di=8 or higher, and given that even very classic 171 SIMs issued by various commercial operators) support Fi=512 Di=8 or higher, and
131 implementations of GSM ME (including our dear Calypso) support this F=512 D=8 172 given that even very classic implementations of GSM ME (including our dear
132 speed enhancement mode endorsed by GSM 11.11 spec, many real-life DUS-to-SIM 173 Calypso) support this F=512 D=8 speed enhancement mode endorsed by GSM 11.11
133 sessions (which we would like to sniff and trace) will include a PPS exchange 174 spec, many real-life ME/ID-to-SIM sessions (which we would like to sniff and
134 switching to a smaller number of SIM CLK cycles per etu. 175 trace) will include a PPS exchange switching to a smaller number of SIM CLK
176 cycles per etu.
135 177
136 The main difficulty with capturing SIM interface sessions that use speed 178 The main difficulty with capturing SIM interface sessions that use speed
137 enhancement is as follows: in order for the session capture to be complete, 179 enhancement is as follows: in order for the session capture to be complete,
138 without any lost bits, the sniffing receiver's knowledge of how many SIM CLK 180 without any lost bits, the sniffing receiver's knowledge of how many SIM CLK
139 cycles constitute a half-etu needs to change to the new value at exactly the 181 cycles constitute an etu needs to change to the new value at exactly the
140 correct moment in time, which is the moment immediately after the last byte 182 correct moment in time, which is the moment immediately after the last byte
141 (PCK) of the SIM's PPS response passes across the wire. If we were to rely on 183 (PCK) of the SIM's PPS response passes across the wire. If we were to rely on
142 host software to decode all byte exchanges up to this point (ATR from the SIM, 184 host software to decode all byte exchanges up to this point (ATR from the SIM,
143 PPS request from the DUS, then PPS response) and command the FPGA (UART in the 185 PPS request from ME/ID, then PPS response) and command the FPGA (UART in the
144 other direction, or a modem control line) to switch the half-etu counter, we 186 other direction, or a modem control line) to switch the etu counters (the
145 stand very little chance of getting this command to the FPGA in time, before 187 0.5 etu, 1 etu and 1.5 etu counters mentioned above), we stand very little
146 the DUS starts transmitting its next command to the SIM using the new etu 188 chance of getting this command to the FPGA in time, before ME/ID starts
147 definition. 189 transmitting its next command to the SIM using the new etu definition.
148 190
149 The Mother's proposed solution is to embed a PPS catcher state machine in the 191 The Mother's proposed solution is to embed a PPS catcher state machine in the
150 sniffer FPGA. This state machine will be set to its initial state upon the 192 sniffer FPGA. This state machine will be set to its initial state upon the
151 session-opening low-to-high transition on the RST line, and it will look at 193 session-opening low-to-high transition on the RST line, and it will look at
152 every ISO 7816-3 character received by the sniffer. The machine will need to 194 every ISO 7816-3 character received by the sniffer. The machine will need to
171 response. Any invalid conditions will take it to the inactive state; however, 213 response. Any invalid conditions will take it to the inactive state; however,
172 if the PPS exchange is valid, the machine will need to capture the PPS1 byte 214 if the PPS exchange is valid, the machine will need to capture the PPS1 byte
173 and then step through states until the final PCK byte of the PPS response. 215 and then step through states until the final PCK byte of the PPS response.
174 216
175 * Upon receiving that last PCK byte after all prior bytes following the expected 217 * Upon receiving that last PCK byte after all prior bytes following the expected
176 protocol, effect the half-etu count change. Either way, the inactive state 218 protocol, effect the etu counter change. Either way, the inactive state is
177 is entered at this point, and the state machine will take no further action 219 entered at this point, and the state machine will take no further action for
178 for the remainder of the session. 220 the remainder of the session.
179 221
180 This state machine is of course going to be very complicated, as evident from 222 This state machine is of course going to be very complicated, as evident from
181 the functional requirements listed above. The first version of SIMtrace-ice 223 the functional requirements listed above. The first version of SIMtrace-ice
182 sniffer FPGA will omit this block altogether, and we will get the rest of the 224 sniffer FPGA omits this block altogether, and we will get the rest of the
183 system working for DUS-to-SIM sessions that stick with F/D=372 - a good test 225 system working for ME/ID-to-SIM sessions that stick with F/D=372 - a good test
184 configuration would be to use a FreeCalypso GSM ME as DUS, with SIM speed 226 configuration would be to use a FreeCalypso GSM ME, with SIM speed enhancement
185 enhancement disabled via AT@SPENH=0. Then we shall embark on implementing this 227 disabled via AT@SPENH=0. Then we shall embark on implementing this proposed
186 proposed PPS catcher state machine. 228 PPS catcher state machine.
187 229
188 The addition of this PPS catcher state machine may increase the complexity of 230 The addition of this PPS catcher state machine may increase the complexity of
189 our logic beyond the capacity of the iCE40HX1K FPGA on the Icestick board. If 231 our logic beyond the capacity of the iCE40HX1K FPGA on the Icestick board. If
190 we run into this problem, we'll have to look for a board with a bigger FPGA - 232 we run into this problem, we'll have to look for a board with a bigger FPGA -
191 but we'll try to fit into the Icestick first. 233 but we'll try to fit into the Icestick first.