FreeCalypso > hg > fc-sim-sniff

comparison doc/Sniffer-FPGA-design @ 4:b275c69c1b80

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc: describe proposed FPGA design
author Mychaela Falconia <falcon@freecalypso.org>
date Sat, 29 Jul 2023 07:06:54 +0000
parents
children 41e6026e5d1a
comparison
equal deleted inserted replaced
3:0c321f1ce085 4:b275c69c1b80
1 The first FPGA gateware function to be implemented in the SIMtrace-ice project
2 is the passive sniffer: receiving level-shifted SIM RST, CLK and I/O signals
3 from the 74LVC4T3144 buffer and capturing all exchanges that happen on the SIM
4 interface between a DUS and a SIM.
5
6 The sniffer FPGA logic function will be implemented on the inexpensive off-the-
7 shelf Icestick board, featuring an iCE40HX1K FPGA and an FT2232H-based USB host
8 interface. This FPGA logic function will operate principally as a byte
9 forwarder from the ISO 7816-3 sniffer block to the FT2232H UART: every time the
10 bus sniffer block captures a character (in ISO 7816-3 terminology) being passed
11 on the SIM electrical interface in either direction (the two directions of
12 transmission are indistinguishable to a tap sniffer that does not actively
13 participate in the protocol), the FPGA will forward this character to the
14 connected host computer (by way of FT2232H UART) for further processing in
15 software. The UART data line going from the FPGA to the FT2232H will be the
16 sole functional output from this FPGA, beyond debug outputs being added during
17 logic development and troubleshooting. The other UART data line going the
18 opposite direction (output from FT2232H) will remain unused, i.e., the host
19 software application will only read/receive from the ttyUSBx FPGA device and
20 won't send anything to it. All modem control lines on this UART interface will
21 likewise remain unused.
22
23 Serial interface format
24 =======================
25
26 For every ISO 7816-3 character captured by the sniffer, two back-to-back UART
27 bytes will be transferred from the FPGA to the host computer; more generally,
28 the FPGA will only transmit pairs of back-to-back bytes on this UART and no
29 singletons or other arrangements - thus the host receiver can always recover
30 synchronization by dropping any partially received two-byte message (the first
31 byte of an expected pair) during prolonged pauses. The FPGA will transmit the
32 two back-to-back UART bytes as a single shift-out of 20 bits, conveying two
33 bytes in 8N1 framing.
34
35 Why are we turning every captured ISO 7816-3 character into a pair of bytes on
36 our internal UART interface, why not simply forward it as a single byte? The
37 reason is that we need to pass some additional bits beyond the 8 that comprise
38 the ISO 7816-3 character payload; the additional bits which we need to pass are
39 as follows:
40
41 - the received parity bit;
42 - a flag indicating whether or not an error signal (ISO 7816-3 section 7.3)
43 was seen;
44 - additional flag bits communicating SIM RST assertion and negation events,
45 as distinct from ISO 7816-3 characters;
46 - an additional flag indicating an action of the integrated PPS catcher state
47 machine, to be described later in this document.
48
49 Assertion or negation of SIM RST is the only other possible event (besides ISO
50 7816-3 character capture, with or without attendant PPS catcher state machine
51 action) that can cause the FPGA to send a byte-pair UART message to the host
52 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
54 event (new RST for transitions, 1 for characters), and all other bits are
55 meaningful only for characters.
56
57 Clocking design
58 ===============
59
60 The FPGA on the Icestick board receives a 12 MHz clock input; the on-chip PLL
61 will be used to multiply this clock by 4, producing a 48 MHz system clock.
62 This 48 MHz SYSCLK will be used for the entirety of the present logic design -
63 a single-clock fully synchronous design is the best current practice.
64
65 The 3 inputs to the FPGA coming from the SIM electrical sniffer (buffered and
66 level-shifted SIM RST, CLK and I/O lines) will pass through two cascaded DFFs,
67 bringing them into our internal clock domain. The delay added by these cascaded
68 DFFs is not a concern: we are a passive sniffer without any output back to the
69 SIM interface, and all 3 signal inputs will be subject to the same delay.
70
71 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
73 divider from SYSCLK to time its output bits; future derivative designs that will
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
79 * 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
81 non-standard.
82
83 * No cables of any kind are used, instead the UART interface is confined to
84 short PCB traces running between the FPGA and the FTDI chip on the same board
85 - hence high baud rates are not a problem.
86
87 * Our UART baud rate needs to be high enough to provide good margin, despite
88 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
90 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
92 3 Mbps provides sufficient margin.
93
94 ISO 7816-3 sniffer block
95 ========================
96
97 Our ISO 7816-3 receiver will trigger on the falling edge of the I/O line. Once
98 it detects a high-to-low transition on the SYSCLK-synchronized SIM_IO input, it
99 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
101 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
103 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
105 to get from the initial falling edge on the I/O line to the mid-etu data
106 sampling point. Following the session-opening low-to-high transition on the RST
107 line, our half-etu register will be set to 8'd186, corresponding to F/D=372.
108 Our PPS catcher state machine will then overwrite this register with a smaller
109 value based on the captured PPS exchange.
110
111 Direct and inverse coding conventions
112 =====================================
113
114 Only the card and not the DUS (interface device in ISO 7816-3 terminology)
115 determines which coding convention is used, direct or inverse. So far we
116 (FreeCalypso) have not yet encountered a real-life SIM that uses the inverse
117 convention, only the direct convention kind. In the sniffer function of
118 SIMtrace-ice, we are going to keep our FPGA gateware simple in this regard and
119 punt all inverse convention handling to the software application on the host
120 computer: the FPGA will pass the 9 received bits (8 data bits and 1 parity bit)
121 to the 16-bit UART message as-is, without inverting or reordering them.
122
123 Integrated PPS catcher
124 ======================
125
126 The logic described so far will be sufficient to capture all exchanges on the
127 SIM interface between a DUS and a SIM *if* the etu-defining F/D ratio is never
128 switched from the basic default of 372. However, given that most SIM cards of
129 interest to us (our own FCSIM1, as well as SIMs issued by various commercial
130 operators) support Fi=512 Di=8 or higher, and given that even very classic
131 implementations of GSM ME (including our dear Calypso) support this F=512 D=8
132 speed enhancement mode endorsed by GSM 11.11 spec, many real-life DUS-to-SIM
133 sessions (which we would like to sniff and trace) will include a PPS exchange
134 switching to a smaller number of SIM CLK cycles per etu.
135
136 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,
138 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
140 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
142 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
144 other direction, or a modem control line) to switch the half-etu counter, we
145 stand very little chance of getting this command to the FPGA in time, before
146 the DUS starts transmitting its next command to the SIM using the new etu
147 definition.
148
149 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
151 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
153 step through the following states between this starting point and the final
154 action of changing the half-etu count register:
155
156 * As the ATR bytes are transferred, the state machine will need to understand
157 enough of ATR format to know which byte constitutes the end of ATR. A fatal
158 error in ATR real-time parsing (if the first byte is anything other than
159 8'h3B) will put the machine into its inactive state for the remainder of the
160 session until next reset.
161
162 * If the byte following ATR is 8'hFF, the machine will proceed into PPS request
163 real-time parsing state. If this byte equals any other value, go to the
164 inactive state for the remainder of the session.
165
166 * In the PPS request real-time parsing series of states, the state machine will
167 need to catch the PPS0 byte and based on this byte, figure out how many bytes
168 it needs to skip.
169
170 * Following the PPS request, the machine will need to real-time-parse the PPS
171 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
173 and then step through states until the final PCK byte of the PPS response.
174
175 * 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
177 is entered at this point, and the state machine will take no further action
178 for the remainder of the session.
179
180 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
182 sniffer FPGA will omit 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
184 configuration would be to use a FreeCalypso GSM ME as DUS, with SIM speed
185 enhancement disabled via AT@SPENH=0. Then we shall embark on implementing this
186 proposed PPS catcher state machine.
187
188 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
190 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.