comparison doc/Sniffer-FPGA-design @ 48:1068f9fd41d5

doc: project rename
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 21 Sep 2023 06:31:34 +0000
parents 695ca51e1564
children
comparison
equal deleted inserted replaced
47:7c9bf72d460f 48:1068f9fd41d5
1 FPGA component of SIMtrace3 sniffer 1 FPGA component of FreeCalypso SIMsniff
2 =================================== 2 ======================================
3 3
4 The SIM interface sniffing apparatus of SIMtrace3 consists of a sniffer pod 4 The present FreeCalypso solution for SIM interface sniffing consists of a
5 (hardware adapter with level shifters) and a Lattice Icestick FPGA board, loaded 5 sniffer pod (hardware adapter with level shifters) and a Lattice Icestick FPGA
6 with the appropriate gateware image from the present project. This document 6 board, loaded with the appropriate gateware image from the present project.
7 describes the design and operation of the FPGA component of this SIMtrace3 7 This document describes the design and operation of the FPGA component of
8 sniffing solution. 8 FC SIMsniff.
9 9
10 Hardware architecture and FPGA design principle 10 Hardware architecture and FPGA design principle
11 =============================================== 11 ===============================================
12 12
13 The two principal components of the Icestick board are an iCE40HX1K FPGA and an 13 The two principal components of the Icestick board are an iCE40HX1K FPGA and an
176 ===================================== 176 =====================================
177 177
178 Only the card and not the interface device (ISO 7816-3 terminology) determines 178 Only the card and not the interface device (ISO 7816-3 terminology) determines
179 which coding convention is used, direct or inverse. So far we (FreeCalypso) 179 which coding convention is used, direct or inverse. So far we (FreeCalypso)
180 have not yet encountered a real-life SIM that uses the inverse convention, only 180 have not yet encountered a real-life SIM that uses the inverse convention, only
181 the direct convention kind. In the sniffer function of SIMtrace-ice, we are 181 the direct convention kind. The approach taken in FC SIMsniff is that the FPGA
182 going to keep our FPGA gateware simple in this regard and punt all inverse 182 is mostly (except for the integrated PPS catcher) oblivious to the coding
183 convention handling to the software application on the host computer: the FPGA 183 convention: it passes the 9 received bits (8 data bits and 1 parity bit) to the
184 passes the 9 received bits (8 data bits and 1 parity bit) to the 16-bit UART 184 16-bit UART message as-is, without inverting or reordering them. The coding
185 message as-is, without inverting or reordering them. 185 convention and the parity check are then handled in simsniff-dec host
186 application.
186 187
187 Integrated PPS catcher 188 Integrated PPS catcher
188 ====================== 189 ======================
189 190
190 Our sniffer FPGA logic was developed incrementally. The first version, 191 Our sniffer FPGA logic was developed incrementally. The first version,
227 228
228 Designs that incorporate a local CPU core immediately adjacent to the ISO 7816-3 229 Designs that incorporate a local CPU core immediately adjacent to the ISO 7816-3
229 receiver block, such as original Osmocom SIMtrace in which the local CPU core 230 receiver block, such as original Osmocom SIMtrace in which the local CPU core
230 and the ISO 7816-3 receiver sit in the same AT91SAMx chip, don't suffer from 231 and the ISO 7816-3 receiver sit in the same AT91SAMx chip, don't suffer from
231 this problem: with a local (dedicated, embedded) CPU so close, the firmware can 232 this problem: with a local (dedicated, embedded) CPU so close, the firmware can
232 react and intervene in time. However, in the case of our SIMtrace3, the nearest 233 react and intervene in time. However, in the case of FC SIMsniff, the nearest
233 CPU is the host computer separated by UART and USB links - not closely coupled 234 CPU is the host computer separated by UART and USB links - not closely coupled
234 enough to provide the degree of real-time response that is needed here. Someone 235 enough to provide the degree of real-time response that is needed here. Someone
235 could say that we should stick a soft CPU core with firmware into our FPGA - but 236 could say that we should stick a soft CPU core with firmware into our FPGA - but
236 we've implemented a different solution: we have a specialized PPS catcher state 237 we've implemented a different solution: we have a specialized PPS catcher state
237 machine instead. This gateware FSM follows the spec-defined structure of ATR, 238 machine instead. This gateware FSM follows the spec-defined structure of ATR,