435 lines
15 KiB
TeX
435 lines
15 KiB
TeX
% $Header: /cvsroot/latex-beamer/latex-beamer/solutions/conference-talks/conference-ornate-20min.en.tex,v 1.7 2007/01/28 20:48:23 tantau Exp $
|
|
|
|
\documentclass{beamer}
|
|
|
|
\usepackage{url}
|
|
\makeatletter
|
|
\def\url@leostyle{%
|
|
\@ifundefined{selectfont}{\def\UrlFont{\sf}}{\def\UrlFont{\tiny\ttfamily}}}
|
|
\makeatother
|
|
%% Now actually use the newly defined style.
|
|
\urlstyle{leo}
|
|
|
|
|
|
% This file is a solution template for:
|
|
|
|
% - Talk at a conference/colloquium.
|
|
% - Talk length is about 20min.
|
|
% - Style is ornate.
|
|
|
|
|
|
|
|
% Copyright 2004 by Till Tantau <tantau@users.sourceforge.net>.
|
|
%
|
|
% In principle, this file can be redistributed and/or modified under
|
|
% the terms of the GNU Public License, version 2.
|
|
%
|
|
% However, this file is supposed to be a template to be modified
|
|
% for your own needs. For this reason, if you use this file as a
|
|
% template and not specifically distribute it as part of a another
|
|
% package/program, I grant the extra permission to freely copy and
|
|
% modify this file as you see fit and even to delete this copyright
|
|
% notice.
|
|
|
|
|
|
\mode<presentation>
|
|
{
|
|
\usetheme{Warsaw}
|
|
% or ...
|
|
|
|
\setbeamercovered{transparent}
|
|
% or whatever (possibly just delete it)
|
|
}
|
|
|
|
|
|
\usepackage[english]{babel}
|
|
% or whatever
|
|
|
|
\usepackage[latin1]{inputenc}
|
|
% or whatever
|
|
|
|
\usepackage{times}
|
|
\usepackage[T1]{fontenc}
|
|
% Or whatever. Note that the encoding and the font should match. If T1
|
|
% does not look nice, try deleting the line with the fontenc.
|
|
|
|
|
|
\title{Anatomy of modern cell phones}
|
|
|
|
\subtitle
|
|
{the 2012 update of the 2010 paper about 2005 phones ;)}
|
|
|
|
\author{Harald Welte <laforge@gnumonks.org>}
|
|
|
|
\institute
|
|
{gnumonks.org\\hmw-consulting.de\\sysmocom GmbH}
|
|
% - Use the \inst command only if there are several affiliations.
|
|
% - Keep it simple, no one is interested in your street address.
|
|
|
|
\date[] % (optional, should be abbreviation of conference name)
|
|
{August 8, 2012 / OSmocom Berlin User Group}
|
|
% - Either use conference name or its abbreviation.
|
|
% - Not really informative to the audience, more for people (including
|
|
% yourself) who are reading the slides online
|
|
|
|
\subject{Communications}
|
|
% This is only inserted into the PDF information catalog. Can be left
|
|
% out.
|
|
|
|
|
|
|
|
% If you have a file called "university-logo-filename.xxx", where xxx
|
|
% is a graphic format that can be processed by latex or pdflatex,
|
|
% resp., then you can add a logo as follows:
|
|
|
|
% \pgfdeclareimage[height=0.5cm]{university-logo}{university-logo-filename}
|
|
% \logo{\pgfuseimage{university-logo}}
|
|
|
|
|
|
|
|
% Delete this, if you do not want the table of contents to pop up at
|
|
% the beginning of each subsection:
|
|
%\AtBeginSubsection[]
|
|
%{
|
|
% \begin{frame}<beamer>{Outline}
|
|
% \tableofcontents[currentsection,currentsubsection]
|
|
% \end{frame}
|
|
%}
|
|
|
|
|
|
% If you wish to uncover everything in a step-wise fashion, uncomment
|
|
% the following command:
|
|
|
|
%\beamerdefaultoverlayspecification{<+->}
|
|
|
|
|
|
\begin{document}
|
|
|
|
\begin{frame}
|
|
\titlepage
|
|
\end{frame}
|
|
|
|
\begin{frame}{Outline}
|
|
\tableofcontents[hideallsubsections]
|
|
% You might wish to add the option [pausesections]
|
|
\end{frame}
|
|
|
|
|
|
% Structuring a talk is a difficult task and the following structure
|
|
% may not be suitable. Here are some rules that apply for this
|
|
% solution:
|
|
|
|
% - Exactly two or three sections (other than the summary).
|
|
% - At *most* three subsections per section.
|
|
% - Talk about 30s to 2min per frame. So there should be between about
|
|
% 15 and 30 frames, all told.
|
|
|
|
% - A conference audience is likely to know very little of what you
|
|
% are going to talk about. So *simplify*!
|
|
% - In a 20min talk, getting the main ideas across is hard
|
|
% enough. Leave out details, even if it means being less precise than
|
|
% you think necessary.
|
|
% - If you omit details that are vital to the proof/implementation,
|
|
% just say so once. Everybody will be happy with that.
|
|
|
|
\begin{frame}{About the speaker}
|
|
\begin{itemize}
|
|
\item Using + toying with Linux since 1994
|
|
\item Kernel / bootloader / driver / firmware development since 1999
|
|
\item IT security expert, focus on network protocol security
|
|
\item Former core developer of Linux packet filter netfilter/iptables
|
|
\item Board-level Electrical Engineering
|
|
\item Always looking for interesting protocols (RFID, DECT, GSM)
|
|
\item OpenEXZ, OpenPCD, Openmoko, OpenBSC, OsmocomBB, OsmoSGSN
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\section{Classic GSM phone architecture}
|
|
|
|
\begin{frame}{The classic GSM phone design}
|
|
\begin{itemize}
|
|
\item Classic GSM mobile phones didn't really change much for 10 years from 1992 to 2002
|
|
\item RF circuitry for analog RX and TX (mixers, filters, PA)
|
|
\item DSP for radio modem, mostly Rx side, hardware modulator
|
|
\item Microcontroller (often ARM7TDMI) for protocol stack + UI
|
|
\item VCTCXO for clock generation
|
|
\item Serial Port with AT-commands over RS-232
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
% picture of calypso based phone
|
|
|
|
\begin{frame}{Improvements in classic GSM phone design}
|
|
\begin{itemize}
|
|
\item DSP was becoming faster, permitted better voice codecs
|
|
\item DPS and controller merged in one chip/component to simply PCB design
|
|
\item Improvements on analog side from IF to zero-IF to low-IF designs
|
|
\item Smaller silicon processes for power and space savings
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Evolution to Smart Phones}
|
|
|
|
\begin{frame}{Personal Digital Assistants}
|
|
\begin{itemize}
|
|
\item In the late 1990ies, PDAs became popular (Palm, Sharp, Compaq, ...)
|
|
\item A PDA was a mostly pen-operated embedded device with large screen
|
|
\item PDAs only had RS-232 to sync with desktop PCs but no wireless interfaces
|
|
\item Some people connect your PDA over RS-232 to the mobile phone
|
|
\item But: Until 2000, SMS and CSD was the only data transport medium
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{From classic phone to smart phone}
|
|
\begin{itemize}
|
|
\item Companies started to put a phone and a PDA in one case
|
|
\item Interconnection between still a normal UART with AT commands
|
|
\item Phone part had keyboard and display removed, AT commands are only interface
|
|
\item OS on PDA side much more powerful than OS on phones at that time (PalmOS, Windows CE / PocketPC, ...)
|
|
\item PDA-side CPU called {\em Application Processor} (AP)
|
|
\item Phone-side CPU called {\em Baseband Processor} (BP)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{smart phone evolution}
|
|
\begin{itemize}
|
|
\item GSM phone (now called "modem") gets GPRS, later EDGE support
|
|
\item AP gets faster (from m68k/arm7tdmi to ARM920, ARM926, ARM11....)
|
|
\item Color displays, higher resolutions
|
|
\item Mobile GPUs for video encoding/decoding, cameras, ...
|
|
\item Resistive touch screens replaced by capacitive touch
|
|
\item AP OS more full-blown (Linux, iOS, ...)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Baseband processors: An abuse of feature phone SoCs!}
|
|
Until almost the end of the 2000's,
|
|
\begin{itemize}
|
|
\item BPs continue to be made primarily for feature phones
|
|
\item BPs thus still contain keypad scan matrix, display interface, etc.
|
|
\item BPs external interfaces are primarily developed for connecting
|
|
the feature phone to a computer, i.e. USB.
|
|
\end{itemize}
|
|
Only recently, smart phones have been so popular that BPs are designed with them as
|
|
a primary user!
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP / BP memories}
|
|
\begin{itemize}
|
|
\item AP and BP are separate SoCs
|
|
\item they each have their own address/memory bus and flash memories
|
|
\item those memories traditionally are in separate components for AP and BP
|
|
\begin{itemize}
|
|
\item often an integrated NOR+SRAM (later NAND+SDRAM) for the BP
|
|
\item SDRAM + NAND (later mDDR + eMMC) on the the AP
|
|
\end{itemize}
|
|
\item You can still see the 'two brain syndrome' from the DPA +
|
|
featurephone legacy
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Current situation and trends}
|
|
|
|
\begin{frame}{2012 smart phones}
|
|
\begin{itemize}
|
|
\item Has AP with two or four cores (Exynos 4412, Tegra 3, ...)
|
|
\item Has BP with ARM1176 core (better than AP some years ago!)
|
|
\item Still have the separation of AP and BP processor
|
|
\item Often still use AT commands to control the BP
|
|
\item Normally don't use UART physical interface anymore, as it's too slow for HSPA speeds
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\subsection{AP/BP interface technologies}
|
|
|
|
\begin{frame}{AP/BP interfaces}
|
|
Many different variants exist today:
|
|
\begin{description}[MIPI HSI]
|
|
\item[USB] e.g. used around 2005/2006 by Motorola EZX
|
|
\item[MIPI HSI] High-Speed serial interface designed specifically for phones
|
|
\item[HSIC] A different USB physical layer (from usb.org)
|
|
\item[DPRAM] Dual-Ported RAM
|
|
\end{description}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP-BP IF: Universal Serial Bus}
|
|
\begin{itemize}
|
|
\item full-speed USB significantly better than UART speeds
|
|
\item AP SoC often contained USB host controller anyway
|
|
\item BP (made for feature phones) also had USB instead of UART for PC connection
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP-BP IF: MIPI HSI}
|
|
\begin{itemize}
|
|
\item HSI: High-Speed Synchronous Serial Interface
|
|
\item MIPI Alliance is a vendor consortium in the mobile space
|
|
\item They specify a variety of other interfaces, e.g. for display, battery, camera, ABB/DBB, ...
|
|
\item Adoption of MIPI HSI not very big (yet?) today
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP-BP IF: HSIC}
|
|
\begin{itemize}
|
|
\item High-Speed Inter-Circuit specification from USB forum
|
|
\item removes USB phy for transmission over long wires
|
|
\item can transport high-speed USB (480 Mbits)
|
|
\item regular USB protocol stack on AP and BP
|
|
\item primarily used by Samsung for Infineon XGold BP
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP-BP IF: Dual-Ported RAM}
|
|
\begin{itemize}
|
|
\item A RAM component with two separate Address and Data busses
|
|
\item Shared-Memory mailbox protocol between AP and BP
|
|
\item Lots of bus routing on PCB
|
|
\item Some AP have DPRAM internal and connect one side internally to the AP CPU core on the die
|
|
\item Very good match for SPoC (Smart Phone on a Chip) like Qualcomm MSM
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\section{Smart Phone on a Chip}
|
|
|
|
\subsection{Introducing the SPoC}
|
|
|
|
\begin{frame}{Smart Phone on a Chip (SPoC)}
|
|
Around the time the Google G1 came out
|
|
\begin{itemize}
|
|
\item Qualcomm was offering the first integrated SPoC (MSM7200)
|
|
\item Integrate AP and BP CPU core + their peripherals on one chip/die
|
|
\item Important for reducing required PCB footprint in devices
|
|
\item Important for reducing PCB routing requirements
|
|
\item Enables deeper integration between AP and BP
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SPoC AP-BP integration}
|
|
\begin{itemize}
|
|
\item So far, AP and BP had their own SoCs, address/memory bus, memories, etc.
|
|
\item With SPoC, you can simply use the same RAM and flash chips, and somehow divide them between AP and BP
|
|
\begin{itemize}
|
|
\item part of the physical RAM is mapped into AP, another part into BP
|
|
\item part of the flash is accessed by the AP, another part by the BP
|
|
\item added benefit: you can map some RAM into both, and get a DPRAM-like shared memory mailbox interface for the AP-BP interface
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Industry Politics}
|
|
|
|
\begin{frame}{SPoC industry politics, 1/2}
|
|
\begin{itemize}
|
|
\item For years, ST-Ericsson only alternative to QC with integrated AP+BP (U8500)
|
|
\begin{itemize}
|
|
\item Infineon never had an AP business, only BP
|
|
\item Samsung System LSI never had a BP business, only AP
|
|
\item Nokia has been sleeping too long, then sold off their BP to Reensas
|
|
\item TI had a GSM/GPRS/EDGE BP business until 2008, then closed it down
|
|
\item NXP sold off their BP business and merged it with ST, later Ericsson Mobile Platforms (EMP) joined to create ST-Ericsson. They all lack a BP business
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{SPoC industry politics, 2/2}
|
|
\begin{itemize}
|
|
\item Industry politics, continued
|
|
\begin{itemize}
|
|
\item Broadcom has APs, but never been very successful in the BP market
|
|
\item Intel once had an AP business (X-Scale, PXA25x,26x,27x), but sold it to Marvell
|
|
\item Marvell had integrated AP + GSM/GPRS/EDGE BP, but no WCDMA
|
|
\end{itemize}
|
|
\item Do you understand why Intel bought the Infineon BP business?
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{Routing around the problem}
|
|
|
|
\begin{frame}{Industry finds SPoC alternatives}{Samsung}
|
|
If you cannot get AP+BP in one package, you have to be innovative
|
|
\begin{itemize}
|
|
\item Samsung has long successful AP line (s3c24xx, s3c6410, Exynos)
|
|
\begin{itemize}
|
|
\item They also build mDDR and NAND flash as well as SD card controllers
|
|
\item They build MCP (Multi Chip Package) with multiple dies in one package
|
|
\item Reduces need for external memory components, simplifies PCB routing
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Industry finds SPoC alternatives}{Texas Instruments}
|
|
If you cannot get AP+BP in one package, you have to be innovative
|
|
\begin{itemize}
|
|
\item TI has successful OMAP3/OMAP4 AP business
|
|
\begin{itemize}
|
|
\item They have no RAM/flash business, thus cannot do MCP
|
|
\item They start with PoP (Package on Package)
|
|
\item Idea: expose memory interface on top of SoC, then solder memory BGa on top of SoC
|
|
\item Saves PCB footprint and simplifies routing, but adds height!
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{The odd SPoC alternatives}
|
|
|
|
\begin{frame}{Have it the Mediatek way}{The MTK GSM/GPRS/EDGE chipsets}
|
|
\begin{itemize}
|
|
\item Users want features, they don't care about separate AP/BP
|
|
\item So instead of adding an AP to a feature phone, just add all the peripherals and software to the BP
|
|
\item Result: ARM7TDMI, later ARM920-EJS BP with hardware codec, GPU, lots of memory, JAVA, ...
|
|
\item Lots of applications like web browser, mail, games to make it look like a real smartphone
|
|
\item You save a lot in silicon footprint and ARM core licensing
|
|
\item Shipped up to 90 Million units / quarter !
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{Mediatek 3G Evolution}
|
|
\begin{itemize}
|
|
\item Mediatek buys BP business from ADI (Analog Digital)
|
|
\item This most likely included Blackfin-based 3G baseband
|
|
\item Modern MTK chipsets are SPoC, with ARM9/ARM11 on AP side and ARM9 on BP
|
|
\item Shared memory components akin to Qualcomm solution
|
|
\item How can MTK become successful once they sell outside China (WCDMA patent licenses to QC?)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{The ST-Ericsson low-cost solution}
|
|
\begin{itemize}
|
|
\item Use a single CPU core for AP and BP
|
|
\item Run a hypervisor on it to virtualize the hardware
|
|
\item Run BP OS in one guest compartment, AP in another
|
|
\item Save on silicon cost/size and ARM core licensing like MTK
|
|
\item Used in very few phones
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}{AP/BP chipset market distribution}
|
|
Out of ~ 70 phone models available on German market today,
|
|
\begin{itemize}
|
|
\item Distribution by vendor
|
|
\begin{itemize}
|
|
\item 47 are Qualcomm BP based (mostly SPoC)
|
|
\item 17 are Infineon BP based (BP-only)
|
|
\item 5 are ST-Ericsson based (SPoC / 2 core)
|
|
\end{itemize}
|
|
\item Distribution by AP/BP interface
|
|
\begin{itemize}
|
|
\item 54 use shared memory interface
|
|
\item 8 use HSIC or USB
|
|
\item 4 use MIPI HSI
|
|
\end{itemize}
|
|
\end{itemize}
|
|
Careful: This is per models. Some models sell more units than 10 other models together ;)
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}{Thanks}
|
|
Thanks for your attention. I hope we have time for Q\&A.
|
|
\end{frame}
|
|
|
|
|
|
\end{document}
|