The M-PHY specification is designed to allow mobile devices to have a low power, high performance interface. Several higher level protocols use the M-PHY physical layer for storage, I/O and memory in mobile devices. In this presentation, Gordon Getty of Teledyne LeCroy discusses how higher layer protocols, including UniPro and UFS, use the M-PHY physical layer to provide an efficient, low power storage protocol to be enabled on mobile platforms. It also covers debug and analysis techniques for UFS and UniPro technologies to allow root-cause analysis to be performed in an efficient and effective manner.
Serial Peripheral Interface (SPI) is an interface bus commonly used to send data between microcontrollers and small peripherals such as shift registers, sensors, and SD cards.
its only for learning purpose for beginners who wants to understand this protocol.
Life is all about learning, hope u will enjoy in this my PPT.
for any suggestion your always welcome .
SPI is a serial bus standard established by Motorola and supported in silicon products from various manufacturers.
It is a synchronous serial data link that operates in full duplex (signals carrying data go in both directions simultaneously).
Devices communicate using a master/slave relationship, in which the master initiates the data frame. When the master generates a clock and selects a slave device, data may be transferred in either or both directions simultaneously.
Serial Peripheral Interface (SPI) is an interface bus commonly used to send data between microcontrollers and small peripherals such as shift registers, sensors, and SD cards.
its only for learning purpose for beginners who wants to understand this protocol.
Life is all about learning, hope u will enjoy in this my PPT.
for any suggestion your always welcome .
SPI is a serial bus standard established by Motorola and supported in silicon products from various manufacturers.
It is a synchronous serial data link that operates in full duplex (signals carrying data go in both directions simultaneously).
Devices communicate using a master/slave relationship, in which the master initiates the data frame. When the master generates a clock and selects a slave device, data may be transferred in either or both directions simultaneously.
I²C (Inter-Integrated Circuit), pronounced I-squared-C, is a multi-master, multi-slave, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors). It is typically used for attaching lower-speed peripheral ICs to processors and microcontrollers. Alternatively I²C is spelled I2C (pronounced I-two-C) or IIC (pronounced I-I-C).
Since October 10, 2006, no licensing fees are required to implement the I²C protocol. However, fees are still required to obtain I²C slave addresses allocated by NXP.[1]
Several competitors, such as Siemens AG (later Infineon Technologies AG, now Intel mobile communications), NEC, Texas Instruments, STMicroelectronics (formerly SGS-Thomson), Motorola (later Freescale), and Intersil, have introduced compatible I²C products to the market since the mid-1990s.
SMBus, defined by Intel in 1995, is a subset of I²C that defines the protocols more strictly. One purpose of SMBus is to promote robustness and interoperability. Accordingly, modern I²C systems incorporate policies and rules from SMBus, sometimes supporting both I²C and SMBus, requiring only minimal reconfiguration.
The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola and has become a de facto standard. Typical applications include sensors, Secure Digital cards, and liquid crystal displays.
SPI devices communicate in full duplex mode using a master-slave architecture with a single master. The master device originates the frame for reading and writing. Multiple slave devices are supported through selection with individual slave select (SS) lines.
Sometimes SPI is called a four-wire serial bus, contrasting with three-, two-, and one-wire serial buses. The SPI may be accurately described as a synchronous serial interface,[1] but it is different from the Synchronous Serial Interface (SSI) protocol, which is also a four-wire synchronous serial communication protocol, but employs differential signaling and provides only a single simplex communication channel.
MPI DevCon Hsinchu City 2017: MIPI M-PHY Gear4 and Its Impact on UniPort/UFSMIPI Alliance
Roy Chestnut of Teledyne LeCroy reviews the features of MIPI M-PHY Gear 4 and their impact and implementation within UniPort/UFS Protocol. He discusses how UniPort and UFS will implement the higher speeds of Gear 4 and introduce the changes between UniPort Version 1.61 and Version 1.80. In addition, the presentation includes changes from UFS 2.1 to UFS 3.0 and changes that should be noted in the Protocol between host and device.
Universal Serial Bus (USB) is an industry standard developed in the mid-1990s that defines the cables, connectors and communications protocols used in a bus for connection, communication, and power supply between computers and electronic devices
Advance Microcontroller Bus Architecture(AMBA).
this is a advance bus architecture. it is defined by ARM.
all the content is taken from http://infocenter.arm.com/ website.
SCSI Express is the robust and proven SCSI protocol combined with PCIe that creates an industry-standard path to PCIe-based storage. SCSI Express combined with SAS-based solutions provides unprecedented performance and low latency that enterprises demand.
The Advanced Peripheral Bus (APB) is part of the Advanced Microcontroller Bus Architecture (AMBA) protocol family. It defines a low-cost interface that is optimized for minimal power consumption and reduced interface complexity.
Presentation discusses Issues in modeling bidirectional buses such as USB 2.0. Solutions for common issues are shown through pictures and verilog code.
MIPI DevCon 2016: Verification of Mobile SOC Design (UFS)MIPI Alliance
Verification of mobile SoC designs is extremely challenging due to the size of the designs, complexity of software and diversity of protocols. For example, protocols like MIPI CSI and DSI require long simulation runs to stream even a small number of video frames.
Utilizing HW/SW co-design methodology, MIPI CSI-3 and JEDEC UFS2 were developed where the UFS2/CSI-3 and UniPro (TL/NL/DME) layers are implemented in software while the UniPro (DL/PAL) and M-PHY layers are implemented in synthesizable Verilog RTL. The communication layer between the software and hardware parts of the UniPro solution is implemented using a transaction-based methodology based on SCE-MI 2.0.
The presentation by Mohamed Samy of Mentor Graphics will cover the co-design methodology and how the software and hardware were integrated together. It will also speak about the testing environment and the advanced debug capabilities enabled by the use of protocol analyzer.
MIPI DevCon 2016: Testing of MIPI High Speed PHY Standard ImplementationsMIPI Alliance
Interoperability in mobile devices shall be achieved through a variety of protocol standards such as MIPI CSI, DSI, UniPro or JEDEC UFS and their underlying physical layer standards MIPI M-PHY, D-PHY or C-PHY. Integration of different vendors' designs into a working system is simplified using standard conformant parts. Testing them according to the procedures outlined in the applicable Conformance Test Suite guarantees their conformance. However, increasing data rates, lower power dissipation and modularity of mobile devices create challenges for debugging and conformance verification of the affected components. In this presentation, Joel Birch of Keysight Technologies discusses these challenges and offers possible solutions to address them.
I²C (Inter-Integrated Circuit), pronounced I-squared-C, is a multi-master, multi-slave, single-ended, serial computer bus invented by Philips Semiconductor (now NXP Semiconductors). It is typically used for attaching lower-speed peripheral ICs to processors and microcontrollers. Alternatively I²C is spelled I2C (pronounced I-two-C) or IIC (pronounced I-I-C).
Since October 10, 2006, no licensing fees are required to implement the I²C protocol. However, fees are still required to obtain I²C slave addresses allocated by NXP.[1]
Several competitors, such as Siemens AG (later Infineon Technologies AG, now Intel mobile communications), NEC, Texas Instruments, STMicroelectronics (formerly SGS-Thomson), Motorola (later Freescale), and Intersil, have introduced compatible I²C products to the market since the mid-1990s.
SMBus, defined by Intel in 1995, is a subset of I²C that defines the protocols more strictly. One purpose of SMBus is to promote robustness and interoperability. Accordingly, modern I²C systems incorporate policies and rules from SMBus, sometimes supporting both I²C and SMBus, requiring only minimal reconfiguration.
The Serial Peripheral Interface (SPI) bus is a synchronous serial communication interface specification used for short distance communication, primarily in embedded systems. The interface was developed by Motorola and has become a de facto standard. Typical applications include sensors, Secure Digital cards, and liquid crystal displays.
SPI devices communicate in full duplex mode using a master-slave architecture with a single master. The master device originates the frame for reading and writing. Multiple slave devices are supported through selection with individual slave select (SS) lines.
Sometimes SPI is called a four-wire serial bus, contrasting with three-, two-, and one-wire serial buses. The SPI may be accurately described as a synchronous serial interface,[1] but it is different from the Synchronous Serial Interface (SSI) protocol, which is also a four-wire synchronous serial communication protocol, but employs differential signaling and provides only a single simplex communication channel.
MPI DevCon Hsinchu City 2017: MIPI M-PHY Gear4 and Its Impact on UniPort/UFSMIPI Alliance
Roy Chestnut of Teledyne LeCroy reviews the features of MIPI M-PHY Gear 4 and their impact and implementation within UniPort/UFS Protocol. He discusses how UniPort and UFS will implement the higher speeds of Gear 4 and introduce the changes between UniPort Version 1.61 and Version 1.80. In addition, the presentation includes changes from UFS 2.1 to UFS 3.0 and changes that should be noted in the Protocol between host and device.
Universal Serial Bus (USB) is an industry standard developed in the mid-1990s that defines the cables, connectors and communications protocols used in a bus for connection, communication, and power supply between computers and electronic devices
Advance Microcontroller Bus Architecture(AMBA).
this is a advance bus architecture. it is defined by ARM.
all the content is taken from http://infocenter.arm.com/ website.
SCSI Express is the robust and proven SCSI protocol combined with PCIe that creates an industry-standard path to PCIe-based storage. SCSI Express combined with SAS-based solutions provides unprecedented performance and low latency that enterprises demand.
The Advanced Peripheral Bus (APB) is part of the Advanced Microcontroller Bus Architecture (AMBA) protocol family. It defines a low-cost interface that is optimized for minimal power consumption and reduced interface complexity.
Presentation discusses Issues in modeling bidirectional buses such as USB 2.0. Solutions for common issues are shown through pictures and verilog code.
MIPI DevCon 2016: Verification of Mobile SOC Design (UFS)MIPI Alliance
Verification of mobile SoC designs is extremely challenging due to the size of the designs, complexity of software and diversity of protocols. For example, protocols like MIPI CSI and DSI require long simulation runs to stream even a small number of video frames.
Utilizing HW/SW co-design methodology, MIPI CSI-3 and JEDEC UFS2 were developed where the UFS2/CSI-3 and UniPro (TL/NL/DME) layers are implemented in software while the UniPro (DL/PAL) and M-PHY layers are implemented in synthesizable Verilog RTL. The communication layer between the software and hardware parts of the UniPro solution is implemented using a transaction-based methodology based on SCE-MI 2.0.
The presentation by Mohamed Samy of Mentor Graphics will cover the co-design methodology and how the software and hardware were integrated together. It will also speak about the testing environment and the advanced debug capabilities enabled by the use of protocol analyzer.
MIPI DevCon 2016: Testing of MIPI High Speed PHY Standard ImplementationsMIPI Alliance
Interoperability in mobile devices shall be achieved through a variety of protocol standards such as MIPI CSI, DSI, UniPro or JEDEC UFS and their underlying physical layer standards MIPI M-PHY, D-PHY or C-PHY. Integration of different vendors' designs into a working system is simplified using standard conformant parts. Testing them according to the procedures outlined in the applicable Conformance Test Suite guarantees their conformance. However, increasing data rates, lower power dissipation and modularity of mobile devices create challenges for debugging and conformance verification of the affected components. In this presentation, Joel Birch of Keysight Technologies discusses these challenges and offers possible solutions to address them.
MIPI DevCon 2016: MIPI C-PHY - Introduction From Basic Theory to Practical Im...MIPI Alliance
In this presentation, Mohamed Hafed of Introspect Technology will introduce the fundamental principles of three-phase encoding and then describe the evolutionary process involved in going from a D-PHY circuit topology to a C-PHY one. Also discussed are protocol implementation properties and guidelines for both CSI-2 and DSI-2 applications running over C-PHY links, all the while highlighting unique bandwidth, power, and encoding properties for this new SerDes standard. Practical implementation experiences that were gained when creating the world's first interoparable C-PHY systems will also be presented.
The D-PHY specification, since the release of its first version more than a decade ago, continues to evolve and push the envelope of throughput to support current and future needs of mobile interfaces – camera and display in particular. In this process, PHY layer test and measurement solutions are posed with newer challenges to provide for the feature additions to the specification. This presentation by Parthasarathy Raju and Suryakant Kumar of Tektronix discusses an introduction to both transmitter and receiver characteristics of D-PHY, and highlights the importance of test modes. Also discussed are test/measurement solutions to overcome these challenges and simplify the testing of devices to accomplish conformance.
C-PHY has emerged as an interface alternative to D-PHY in MIPI camera applications. By decreasing toggle rate and increasing bandwidth, C-PHY offers systems designers more options for controlling EMI and power within a system, while maintaining high performance. However, testing C-PHY presents unique challenges, due to the need to monitor 3 lines simultaneously, as well as unique encoding and decoding methods. To address these challenges, UNH-IOL has created the C-PHY GUI tool. Similar to the widely used D-PHY GUI tool, C-PHY-GUI interfaces with oscilloscopes from various vendors. In this presentation, Paul Willis of UNH-IOL discusses the methodology behind C-PHY GUI, the challenges of building and testing it, and how to use it to easily test a C-PHY implementation.
In this presentation, George Wiley of Qualcomm Technologies discusses the unique properties of the MIPI C-PHY physical layer, as well as system-level benefits and values for camera and display interfaces.
MIPI DevCon 2016: Specifications Roadmap - The Wires for WirelessMIPI Alliance
Rick Wietfeldt, chairman of MIPI Alliance's technical steering group, provides a look at the body of mobile interface specifications introduced to date, as well as a look at what's in development now.
MIPI DevCon 2016: Effective Verification of Stacked and Layered ProtocolsMIPI Alliance
Pre-silicon verification of UniPro devices is challenging, demanding and may require significant effort. The layered structure of the specification and the rapid pace of new revisions and features require a flexible, modular and advanced test bench that is well beyond the ability of the traditional directed testing verification schemes that most designers employ. This presentation by Ofir Michaeli of Cadence Design Systems will discuss practical guidelines for defining a proper verification plan; how to design a verification test bench, a scoreboard and a reference model; the pros and cons of standalone verification vs. full stack verification; and a review of real-world verification environments used in actual verification of UFS/UniPro/M-PHY devices.
The use of embedded and removable card universal flash storage (UFS) in the fast-moving mobile market is growing, and designers are looking for ways to accelerate their design development and verification process. In this presentation, Rui Terra of Synopsys describes how using FPGA-based prototyping systems with pre-verified UFS and UniPro IP reference designs enable designers to easily develop their required software, test their device’s interoperability and ensure compliance.
MIPI DevCon 2016: Key Learnings in Creating the UFS Compliance Test ProgramMIPI Alliance
Of the many reasons driving development of standards, two of the most important are: 1) Enabling development of distinct yet "plug compatible" implementations; and 2) Encapsulating functionality to create a "building block" that can be used in a wide variety of systems. These two goals can conflict with each other in unexpected ways as the types of systems using the standard evolve. In this presentation, Perry Keller of the UFSA examines the UFSA's learnings in preparing to support logo certification testing of the recently adopted UFS card standard.
Adoption of MIPI standards is accelerating, making design verification and interoperability critically important. In this presentation, Ross Nelson of Protocol Insight discusses effective verification processes to test the physical, link and application layers and the complete system, focusing on debug, stress/corner case testing and conformance/interoperability verification. This presentation also covers effective verification processes and the new MIPI Product Registry model.
MIPI DevCon 2016: Using MIPI Conformance Test Suites for Pre-Silicon Verifica...MIPI Alliance
MIPI Alliance conformance test suites provide a valuable set of tools improving interoperability of MIPI specification-based products. While the main purpose of conformance test suites is to verify conformance of these products at post-silicon stages, a significant number of these tests can be used in pre-silicon verification of MIPI-based designs in order to improve the product quality and increase confidence for being spec-conformant in very early design stage. This presentation by Ofir Michaeli of Cadence Design Systems focuses on the following topics: selection of appropriate CTS tests for pre-silicon verification, integrating CTS tests into the verification plan, and modification of the verification test bench to accommodate CTS tests. These topics are explained by the examples of integration of DSI, D-PHY and C-PHY conformance test suites into verification plans and would be relevant for every engineer who designs or verifies MIPI-based interfaces.
MIPI DevCon 2016: Mobile Technology Expands to New HorizonsMIPI Alliance
Smartphones are perhaps the most technically demanding semiconductor-based products, requiring high CPU and graphics performance within tight power, size and cost constraints. Processors forged in this crucible can also serve in emerging markets such as IoT, wearables and automotive. Linley Gwennap, founder and principal analyst of the
Linley Group, discusses the latest market and technology trends in the mobile market, including 5G, heterogeneous computing and sensor fusion. It also covers how these and other mobile technologies are impacting adjacent markets.
MIPI DevCon 2016: MIPI Mobile Touch SpecificationMIPI Alliance
David Johnson of Qualcomm Technologies presents an overview of the forthcoming MIPI Touch specification, which will provide a comprehensive touch interface for use in mobile phones, tablets, automotive dashboards and infotainment displays, and other devices and applications.
MIPI DevCon 2016: MIPI I3C High Data Rate ModesMIPI Alliance
The MIPI I3C standardized sensor interface provides a number of significant advantages over existing digital sensor interfaces. One of the most advanced features is the ability to operate in I3C high data rate modes, HDR-DDR, HDR-TSP and HDR-TSL, which provides the best performance in both speed and power. Alex Passi of Cadence Design Systems presents I3C interface basics and focuses on various verification aspects of I3C HDR modes through an advanced verification methodology based on coverage driven verification and real-life scenarios.
MIPI DevCon 2016: Meeting Demands for Camera and Sensor Interfaces in IoT and...MIPI Alliance
Enhanced IoT and automotive applications are driving demand for multiple camera interfaces to enable embedded vision use cases. In this presentation, Synopsys' Hezi Saar outlines typical camera and display use cases for automotive and IoT applications, and how multiple Rx and Tx image streams can be integrated into an SoC to create a flexible and reusable architecture. The presentation will also provide a quick overview of the MIPI CSI-2 and I3C specifications and their key features that are important to meeting the required functionality, performance and power targets.
The transformation of the car into a connected mobile device is occurring from the inside out, and is a perfect setting for leveraging the work done in the MIPI Alliance. The intimate (vendor controlled) system interfaces of a smartphone supplier mirror those developing to serve the auto industry. Mixel Inc.'s Ashraf Takla discusses this transformation, and how MIPI Alliance and its member companies are helping to make it happen.
MIPI DevCon Seoul 2018: Troubleshooting MIPI M-PHY Link and Protocol IssuesMIPI Alliance
Gordon Getty and Juhyun Yang, both of Teledyne LeCroy, discuss how higher-layer protocols, including UniPro® and UFS, use MIPI M-PHY® to provide an efficient, low-power storage protocol to be enabled on mobile platforms.
These slides present various communications and measurement technology applied for smart grid. Later of the class I will present the same at advance level.
Hyper Transport technology is a very fast, low latency, point-to-point link used for inter-connecting integrated circuits on board. Hyper Transport, previously codenamed as Lightning Data Transport (LDT), provides the bandwidth and flexibility critical for today's networking and computing platforms while retaining the fundamental programming model of PCI. Hyper Transport was invented by AMD and perfected with the help of several partners throughout the industry.
3GPP Standards for the Internet-of-ThingsEiko Seidel
Presenation by 3GPP RAN3 Chairman - Philippe Reininger - at the IoT Business & Technologies Congress (November 30, in Singapore). Main topics are eMTC, NB-IOT and EC-GSM-IoT as completed in 3GPP Release 13 and enhanced in Release 14
ptical Networks have been dominated by closed and vendor specific network solutions. The need for greater interoperability, efficiency and simplicity in optical networks are the drivers for the open optical network architecture. We will invite speakers from the industry and vendor communities to discuss and share their views on Open Optical Network architecture. Some of the key issues to discuss are:
- How Open Line Systems and optical white boxes could play a role in building NREN networks.
- Are these technologies mature enough to rely on?
- What are the key issues it is going to solve?
- What are the operational consequences of such dramatic network architecture changes?
- What have standardizations bodies done in the area of Open Optical Network?
- Do we have clear demarcation points between different functional blocks and boxes?
MIPI DevCon 2021: MIPI I3C Under the Spotlight: A Fireside Chat with the I3C ...MIPI Alliance
Panel discussion with Tim McKee, MIPI I3C Working Group chair; Matthew Schnoor; Eyuel Zewdu Teferi, MIPI I3C Basic Ad-hoc Working Group vice chair; and Radu Pitigoi-Aron
This session puts MIPI I3C® "under the spotlight" by assembling a panel of experts to talk about the latest developments in the world of I3C. The panel discusses the latest I3C specifications (including the latest HCI specification), how to address conformance in the absence of face-to-face plug fests, and how the MIPI I3C interface is being leveraged by other standards organizations.
MIPI DevCon 2021: MIPI I3C Application and Validation Models for IoT Sensor N...MIPI Alliance
Presented by Eyuel Zewdu Teferi, David Schumacher and Souha Kouki, STMicroelectronics
This presentation provides a global overview of using MIPI I3C® protocol for on-board communication among subsystems of an IoT sensor node. It includes adoption of MIPI CTS by using SysML models of requirements and test cases as an approach to manage I3C application use cases requirement validation.
MIPI DevCon 2021: MIPI I3C Signal Integrity Challenges on DDR5-based Server P...MIPI Alliance
Presented by Azusena Lupercio Ramirez, Juan Orozco and Nestor Hernandez Cruz, Intel Corporation
The MIPI I3C® protocol is first used in a server application for the DDR5 DIMM SPD function. MIPI I3C was defined for low capacitance applications, while DDR5 SPD exceeds by far the bus capacitance specification. This presentation covers the interoperability challenges of the dynamic push-pull and open-drain operating modes, on server applications with an in-depth analysis of the implications of long PCB traces, multiple DIMM routing branches, and multiple loads to the electrical and timing parameters.
MIPI DevCon 2021: MIPI I3C interface for the ETSI Smart Secure PlatformMIPI Alliance
Presented by Gulio Follero, ETSI
The ETSI Technical Committee Smart Card Platform (TC SCP) is developing the specification of the next generation secure element, the Smart Secure Platform (SSP). SCP is standardizing the MIPI I3C interface for SSP. This presentation describes the SSP architecture and its main use cases, followed by a discussion of how the MIPI I3C interface is adapted to the SSP and the main benefits in terms of speed, power and efficiency.
MIPI DevCon 2021: MIPI Security for Automotive and IoT – Initial Focus on MASSMIPI Alliance
Presented by Philip Hawkes and Rick Wietfeldt, co-chairs of the MIPI Security Working Group
MIPI Automotive SerDes Solutions (MASS) allows transmission of sensor and display data between sensors, electronic control units (ECUs) and displays distributed around a vehicle. The MIPI Security Working Group is developing a MASS security framework for protecting this data against malicious attacks.
This session covers the objectives of the security framework and explains how the framework achieves those objectives.
MIPI DevCon 2021: MIPI HTI, PTI and STP: The Bases for Next-Generation Online...MIPI Alliance
Presented by Thomas B. Preußer and Alexander Weiss, Accemic Technologies GmbH
The key challenge for testing and debugging embedded multicore systems is their limited observability. MIPI trace protocols provide essential operational insights non-intrusively, and this presentation advocates for the continuous online analysis of these trace data. It also contrasts the challenges posed by the vigorously compressed MIPI trace protocols with the enormous benefits that can be gained by online processing.
MIPI DevCon 2021: Meeting the Needs of Next-Generation Displays with a High-P...MIPI Alliance
Presented by Alain Legault, Hardent Inc.; Joe Rodriguez, Rambus Inc.; and Justin Endo, Mixel, Inc.
Next-generation display applications have an insatiable appetite for bandwidth. Using a combination of VESA Display Stream Compression (DSC) and MIPI DSI-2℠ technology, designers can achieve display resolutions up to 8K without compromise to video quality, battery life or cost. This presentation discusses a fully integrated, off-the-shelf display IP subsystem solution, consisting of Mixel (MIPI C-PHY℠/D-PHY℠ combo), Rambus (MIPI DSI-2® controller) and Hardent (VESA DSC) IP, that can deliver this state-of-the-art performance in a power-efficient and compact footprint.
MIPI DevCon 2021: MIPI CSI-2 v4.0 Panel Discussion with the MIPI Camera Worki...MIPI Alliance
Panel discussion with Haran Thanigasalam, Intel Corporation, MIPI Camera Working Group chair; Natsuko Ibuki, Google, LLC;
Yuichi Mizutani, Sony Corporation; and Wonseok Lee, Samsung Electronics, Co.
MIPI DevCon 2021: MIPI D-PHY and MIPI CSI-2 for IoT: AI Edge DevicesMIPI Alliance
Presented by Ashraf Takla, Mixel Inc.
This presentation covers the deployment of MIPI D-PHY℠ and MIPI CSI-2® in IoT and edge devices. While many mobile-influenced applications benefit from the low-power, small-form factor of MIPI specifications, AI edge processors in particular are seeing a surge in the use of MIPI specifications for their sensors as market trends shift from processing in the cloud or central location, to processing at the edge.
This presentation includes a high-level system overview of a specific use case, Perceive Ergo edge inference processor, and how Mixel was able to meet Perceive’s stringent requirements with its MIPI D-PHY CSI-2 TX and D-PHY CSI-2 RX IPs.
Presented by Licinio Sousa, Synopsys, Inc., and Edo Cohen, Valens Semiconductor
Synopsys and Valens Semiconductor outline how MIPI automotive solutions can enable safe and robust long-reach connectivity for cameras and sensors. The ability for high volumes of data to travel at a fast rate over a long reach infrastructure is now mandatory in automotive vision applications. In addition, maintaining a reliable link can be the difference between successful operation and system failure in a car. In this presentation, Synopsys and Valens present a Valens MIPI A-PHY℠ design for in-vehicle connectivity using Synopsys’ ISO 26262-ready MIPI CSI-2® and MIPI C-PHY℠/D-PHY℠ IP in the FinFET process to meet their latency and bandwidth requirements. The presentation also previews examples of display applications that can benefit from the same architecture.
Presented by James Goel, MIPI Technical Steering Group chair, and Rick Wietfeldt, Security Working Group co-chair
This session brings you up to speed on all the latest developments within MIPI Automotive SerDes Solutions (MASS) – a framework that provides a full-stack, end-to-end sensor/display-to-ECU solution for autonomous driving and ADAS systems that leverage existing MIPI CSI-2®, DSI-2℠ and VESA eDP/DP protocols running over MIPI A-PHY℠. The presentation also explains how recent developments make it easier for you to integrate MIPI A-PHY into your next automotive E/E architecture and how, through A-PHY's adoption as an IEEE standard, it can be accessed for evaluation without MIPI membership.
In addition, the presenters discuss how recently released MIPI Camera and Display Service Extensions (CSE and DSE) and their associated protocol adaptation layers (PALs) work together to embed functional safety and security enablers natively at the "edge" – ultimately within the sensor, display and ECU components themselves.
MIPI DevCon 2021: The MIPI Specification Roadmap: Driving Advancements in Mob...MIPI Alliance
Presented by James Goel, MIPI Technical Steering Group Chair
Despite the many challenges over the past year, MIPI Alliance is on track to release more specifications in 2021 than in any other year in the organization's history. This packed schedule covers updates to many of MIPI's most popular specifications, including all physical layer specifications, MIPI I3C® and I3C Basic℠, and those for camera and display, in addition to introducing several new specifications. James Goel, chair of the MIPI Technical Steering Group, highlights some of the key specifications released over the past year and then provides a look at what's still to come. He' also provides an overview of MIPI's development activity in particular focus areas, such as automotive, IoT, 5G and security.
MIPI DevCon 2021: State of the AllianceMIPI Alliance
Get an update on MIPI Alliance priority initiatives in mobile and in the beyond-mobile focus areas of automotive, IoT and 5G. Peter Lefkin, MIPI managing director, discusses collaborative efforts within the Alliance and industry, as well as progress toward strategic priorities, including the development of key specifications and resources, education opportunities, outreach and other activities to support the MIPI member ecosystem.
MIPI DevCon 2020 | Snapshot of MIPI RFFE v3.0 from a System-Architecture Per...MIPI Alliance
Lalan Mishra, vice-chair of the MIPI RFFE Working Group, presents the new features of MIPI RFFE v3.0 to help architecture and design engineers understand how the triggering features in the latest version work together to improve performance and to switch quickly among the various bands and band combinations in a 5G system.
MIPI DevCon 2020 | The Story Behind the MIPI I3C HCI Driver for LinuxMIPI Alliance
Nicolas Pitre of BayLibre covers the work that has been done to date to plan Linux support when new technology is developed and a quick overview of future development.
MIPI DevCon 2020 | Interoperability Challenges and Solutions for MIPI I3CMIPI Alliance
This presentation from Geoffrey Duerden of Introspect Technology features a case study of several specific interoperability challenges and solutions in terms of circuit and layout guidelines, protocol implementations and target applications.
MIPI DevCon 2020 | Why an Integrated MIPI C-PHY/D-PHY IP is EssentialMIPI Alliance
Licinio Sousa of Synopsys describes the key advantages of the latest MIPI C-PHY℠ and D-PHY℠ specifications and how designers are implementing them in multipixel cameras and high-resolution displays targeting mobile, drone and automotive applications.
MIPI DevCon 2020 | MIPI to Bluetooth LE: Leveraging Mobile Technology for Wir...MIPI Alliance
Grant Jennings of GOWIN Semiconductor shares use case examples in the wireless IoT space found while helping customers develop new types of solutions with the first SoC FPGA with built in Bluetooth Low Energy (LE) transceiver.
Kevin Yee, chair of MIPI Marketing Steering Group, and Ian Smith, MIPI technical content manager and author of the MIPI Alliance IoT White Paper, explain the advantages of using MIPI specifications within IoT devices and provide an overview of the MIPI specifications that are most relevant to the IoT market.
This presentation, from Gregor Sievers, Ph.D., of dSPACE GmbH, addresses how the MIPI CSI-2℠, D-PHY℠, CCS, and A-PHY℠ specifications simplify validation and testing and help bring autonomous driving to the streets.
2. Objective
2
A major component of the "Internet of Things" is mobile device support. The
MIPI M-PHY specification is designed to allow mobile devices to have a low
power, high performance interface. Several higher level protocols use the M-
PHY physical layer for storage, I/O and memory in mobile devices. This
paper will discuss how higher layer protocols such as MIPI UniPro, and UFS
use the M-PHY physical layer to allow traditional PC type protocols to be
enabled on mobile platforms.
5. New Markets Reaching 1 Billion Milestone
Quickly
• Cell phones sold 1 Billion units in 7.5 years, PCs took
21 years.
• Mobile shipped 4 Billion units in 12.5 years, PC market
will take over 33 years.
• Tablets will hit 1 Billion in 6 years.
5
6. Mobility Driving Growth
6
• Mobile market will be
>8 times the size of the
PC market
• Notebook PCs evolving
into large tablets
7. Market Trends
• Smartphone market driving innovation
• Large volumes, fast design cycles
• Personal, always at hand
• Other markets will leverage smartphone designs
• • Increasing number of MEMS per system
• Eroding ASPs
• Sensor Hub will become more specialized
• 32-bit MCU will be challenged
7
10. MIPI M-PHY Protocols
• MIPI M-PHY protocols are used based on interface
used in each application.
• Multiple protocols can be used in a single device.
10
12. Why MIPI M-PHY?
From the M-PHY Specification V4.0:
“Mobile devices face increasing bandwidth demands for
each of its functions as well as an increase of the
number of functions integrated into the system. This
requires wide bandwidth, low-pin count (serial) and
highly power-efficient (network) interfaces that provides
sufficient flexibility to be attractive for multiple
applications, but which can also be covered with one
physical layer technology. M-PHY is the successor of D-
PHY, requiring less pins and providing more bandwidth
per pin (pair) with improved power efficiency.”
12
14. Line States
• M-PHY technology exploits only differential signaling. a LINE can show the
following states:
• A positive differential voltage, driven by the M-TX, which is denoted by LINE state DIF-P
• A negative differential voltage, driven by the M-TX, which is denoted by LINE state DIF-N
• A weak zero differential voltage, maintained by M-RX, which is denoted by LINE state DIF-Z
• An unknown, floating LINE voltage, or no LINE drive, which is denoted by LINE state DIF-Q
14
15. Signal Amplitudes
• All communication is based on low-swing, DC-coupled,
differential signaling
• The LINE driver in an M-TX may support two drive
strengths, resulting in different signal amplitudes.
• Large Amplitude (LA) is about 400 mVPK_NT (and roughly 200
mVPK_RT)
• Small Amplitude (SA) is about 240 mVPK_NT (and roughly 120
mVPK_RT)
15
16. Signaling Schemes
• LS and HS Speed (Optional)
• May use a shared clock or different reference clocks
• Uses NRZ signaling
16
17. Data Rates
• LS-MODE
• Gears 0-7
• HS-MODE
• Gears 1-3
• All Modules (Host and Device) must support LS
• Default for PWM is Gear1 3-9Mbs
• Each Gear supports 2x higher speeds
• one GEAR below the default speed range (PWM-G0)
• HS-Mode is Optional
• HS-MODE includes a default GEAR (HS-G1)
• Two optional GEARs (HS-G2 and HS-G3) at incremental 2x higher rates
• Each GEAR includes two data rates for EMI mitigation reasons
• HS-G1 supports 1.25 Gbps and 1.45 Gbps
• These two data rates are known as A & B
• Support for a LS or a HS GEAR requires support for all GEARs
below
17
20. State Machine
20
• Two operating modes,
• HS-MODE
• LS-MODE
• A data transmission (BURST) state and
a MODE-specific power saving (SAVE)
state
• STALL is the SAVE state of HS-MODE
• SLEEP is the SAVE state of LS-MODE
• HS-MODE: STALL, HS-BURST
• LS-MODE (Type-I MODULE): SLEEP, PWM-
BURST, LINE-CFG
• LS-MODE (Type-II MODULE): SLEEP, SYS-
BURST
21. Data Bursts
• Data transmission occurs in
BURSTs with power saving
states between BURSTs
• BURST starts from the SAVE
state
• Transition from DIF-N to DIF-P
for period called PREPARE
• Generate SYNC Pattern
• Send Marker0 followed by mix of
DATA0 - 255, Markers, FILLER
• Marker0 used for receiver
alignment, similar to SKIP
ordered sets in PCIe
• Burst ends with TAIL-OF-Burst
Symbol
21
22. HIBERN8
• HIBERN8 state enables ultra-low power consumption, while
maintaining the configuration settings.
• A MODULE shall support HIBERN8.
• The M-TX shall be high-impedance in HIBERN8,
• M-RX shall hold the LINE at DIF-Z.
• Under these conditions, the M-RX is considered to be in squelch.
• When entering HIBERN8 from LS-MODE or HS-MODE, the
Protocol Layer shall not request a MODULE exit HIBERN8
before a minimum period in HIBERN8 of THIBERN8,
• THIBERN8, is the larger of local
TX_Hibern8Time_Capability and remote
RX_Hibern8Time_Capability.
• Optional calculations of HIBERN8 based on the implementation
• (see the spec for additional details)
22
24. MIPI UniPro
• MIPI specification to the define protocol
used to transfer data between Devices
that implement the UniPro Specification.
• This includes definitions of data
structures, such as Packets and Frames,
used to convey information across the
Network.
• Flow control, error handling, power and
state management, and connection
services are also defined in this
specification
• UniPro version 1.61, the use of M-PHY is
mandated for chip-to-chip
interconnections
24
25. Phy Adapter Layer - L1.5
• PHY Adapter Layer is responsible for
abstracting the details of the PHY technology,
thus providing a PHY-independent interface
(PA_SAP) to higher protocol layers.
• The PHY Adapter Layer provides bandwidth
scalability by supporting up to four PHY Data
Lanes per direction.
• Supports Asymmetrical Data Lanes
• When multiple Data Lanes are available, they
are assumed to have identical capabilities.
• Lanes are assumed to be in the same state,
and L1.5 handles all details of how the Lanes
are used autonomously.
25
26. L1.5 Protocol
• The L1.5 for M-PHY automates a significant part
of the required steps used for Power Modes
control, utilizing an L1.5-to-L1.5 communication
protocol known as PACP (PHY Adapter Control
Protocol).
• PDUs (“PACP frames”) generated by L1.5 are
multiplexed with the symbol stream received from
L2 and can be recognized by a unique header
pattern.
26
27. L1.5 Power States and Power Modes
• The difference between Power States and Power
Modes are as follows:
• An Application can set only a Power Mode, but
cannot set a Power State
• An Application can get a Power Mode and get a
Power State
• the gettable value of a Power Mode simply reflects the value
that was set
• the gettable value of a Power State may change
spontaneously when in FastAuto_Mode or SlowAuto_Mode
27
30. Data Link Layer – L2
• The Data Link Layer provides reliable Links between a transmitter
and a directly attached receiver
• Multiplexes and arbitrates multiple types of data traffic (priorities)
• Data Link Layer clusters the 17-bit PA_PDU symbols into Data
Frames
• Every Data Frame consists of a 1-symbol header, a payload of up
to 144 symbols and a 2-symbol trailer including a 16-bit CRC.
30
31. • Network Layer is to allow data to be routed to the proper
destination in a networked environment.
• Network Layer introduces a new PDU known as a Packet
• When a Packet is passed down to L2, the Packet is
encapsulated between an L2 header and an L2 trailer to form a
single L2 Frame
• UniPro supports Networks of up to 128 Devices
31
Network Layer – L3
32. Transport Layer L4
• Transport Layer is the highest UniPro protocol layer
• Transport Layer mechanisms allow a single physical Packet stream
between two Devices to support multiple, independent, logical
Packet streams or “Connections”.
• Transport Layer supports multiple bidirectional Connections
• Connections can span a single hop or multiple hops using Switches
• Switches not yet defined by the UniPro spec
• UniPro guarantees that data sent over a single Connection arrives
in the order in which it was sent
32
33. Preemption (UniPro)
• In order to reduce delays in the transmission of high
priority Frames and to improve QoS in conjunction with
upper layers, the DL Layer can insert high priority
Frames within a low-priority Data Frame if the latter one
is already in transmission.
• This functionality is known as preemption of a Frame.
Support of preemption functionality is optional for the
transmitter, whereas the receiver shall always be able
to receive preempted and non-preempted Frames.
33
34. Preemption (UniPro)
• Uses COF – Continuation of Frame header
34
This Frame consists of 2 fragments, the second fragment star0ng with COF
36. UFS – Universal Flash Storage
• Universal Flash Storage – JEDEC Standard JESD220C
• Universal Flash Storage (UFS) is a simple, high performance,
mass storage device with a serial interface.
• It is primarily used in mobile systems, between host
processing and mass storage memory devices.
• M-PHY and UniPro make up the interconnect for UFS
• UFS is architected on SCSI SAM
• UFS uses the command layers from SCSI SPC and SBC
36
37. Why UFS?
1. Be5er User Experience:
• Higher performance, efficiency & responsiveness - Leading to Instant ON, Mul0-Tasking, Fast app loading
and swapping
• Low Power – Longer BaQery life even with larger screens and mul0-tasking
• Security and Reliability – Enterprise applica0on support and Secure Mobile shopping
• Small and Scalable – Thinner and lighter devices
2. Easier technological integra>on:
• SoTware compa0bility with the wide spread SCSI framework - UFS 2.0 Specifica0on follows the SCSI
programming model enabling soTware reuse
• Simpler Host design due to the well-defined UFS Host controller interface (UFSHCI) specifica0on
• Apart from these UFS 2.0 requires only single UniPro Transport layer CPort and does not use the built in
end-to-end flow control capabili0es of UniPro. It does not require the low latency TC1 support or Pre-
emp0on. This leads to simplifica0on of the MIPI UniPro controller design as well.
3. Be5er u>liza>on of bandwidth:
• JEDEC UFS is able to fully u0lize the duplex bandwidth provided by the MIPI UniPro transport.
37
39. Physical Layer
• UFS interface can support multiple lanes.
• Each lane consists of a differential pair.
• Basic configuration is based on one transmit lane and
one receive lane.
• Optionally, a UFS device may support two downstream
lanes and two upstream lanes. An equal number of
downstream and upstream lanes shall be provided in
each link.
• Links must be symmetrical
39
40. Application Layer
• The application layer consists of the UFS Command
Set layer (UCS), the device manager and the Task
Manager
• The UCS will handle the normal commands like read,
write, and so on.
• UFS may support multiple command sets.
• UFS is designed to be protocol agnostic. This version
UFS standard uses SCSI as the baseline protocol
layer.
• A simplified SCSI command set was selected for UFS.
• UFS Native command set can be supported when it is
needed to extend the UFS functionalities.
• The Task Manager handles commands meant for
command queue control.
• The Device Manager will provide device level control
like Query Request and lower level link-layer control.
40
44. Debug process for Serial Protocols
44
Analyze
and find
root cause
Pick the
correct
tool
Iden0fy
the Layer
45. Debugging M-PHY problems
• Typically M-PHY production systems are chip to chip, no
connector
• Development systems may have SMA connections
between devices
• First challenge is to access link
• Probing Type:
• SMA
• Multi Lead
• Midbus
• Check electrical first before debugging protocol problem
45
46. Probing Options
• Identify the appropriate probing solution
• SMA
• Multi-Lead – Solder Down
46
Mul0-Lead Solder Down SMA
47. Using the correct tool
• Is problem related to Signal Integrity?
• Are devices physically connected?
• Are both devices providing M-PHY compliant
signaling?
• Use an Oscilloscope to verify
• Is problem related to Connectivity
• Is a link established between the 2 devices?
• Is the data rate as expected?
• Can software see the devices –
• for UFS, can the storage be seen?
• Use a Protocol analyzer to verify
47
48. Which Layer is causing the problem?
• Same principle applies regardless
of MIPI M-PHY upper layer
protocol
• Identify the layer
• Performance?
• Reliability?
• Errors?
48
49. Protocol Analyzer sees nothing?
• Is there a signal present?
• Connect the analyzer probe output to an Oscilloscope to verify.
49
50. • Is there a signal present?
• Connect the analyzer probe output to an Oscilloscope to verify.
Protocol Analyzer sees nothing?
50
DUT
51. • Is there a signal present?
• Connect the analyzer probe output to an Oscilloscope to verify.
Protocol Analyzer sees nothing?
51
DUT
52. Set Up Trigger
• What to trigger on?
• Depending on layer, trigger condition may vary
• Look for PACP on Boot to see initialization
• Higher level SCSI trigger for looking at software problem
52
SCSI Op Code