PCI Express Passes Other Standards Found in Automobile Entertainment Systems
Move over CANbus, PCI Express is the latest communications technology found in automotive infotainment.
Regarding “car tech,” we take for granted that every window motor, headlamp and trunk release has its own MCU; there might be a hundred MCUs and sensors interconnected via networks in the modern car (Figure 1). Yet the hotter topic for automotive designers now is the car’s “connectedness” to the Internet, advanced safety features like lane departure or self-parking, and in-vehicle infotainment (IVI).
The center console IVI system is a consumer must-have item and differentiates car brands. High-end auto manufacturers offer more features—such as front-mounted radar or 360-degree camera vision—but even the lower tier brands include back-up cameras, smartphone integration (and Google’s Android Auto or Apple’s CarPlay) along with Bluetooth and smart device charging (Figure 2).
The IVI system block diagram reveals sensors and graphics, media processors, packet-based networks, and PCI Express peripherals. The IVI console is actually a collection of many embedded systems that rely on the efficiency of the PCIe interface.
Yet cars are also unique. Designers need to account for 10-year life cycle requirements, wicked EMI mitigation and “dirty” power, plus all manner of temperature extremes in a moist and corrosive environment. Architecting—and spec’ing components for today’s connected car—are a designer’s challenge.
Connected Cars Modify IVI Architecture
Within just a few years, the majority of automobiles will be “connected”—to the Internet, to the occupants’ mobile devices, and to each other and the road’s infrastructure. Data by BI Intelligence shows about 75% of the cars sold by 2020 will be connected (Figure 3). This trend has forced a rethinking of the car’s architecture by separating the “telematics” processing from the IVI system, requiring a more complex IVI design.
While it was once thought the IVI processor would be the car’s primary CPU controlling all the other MCUs via CANbus network—the telematics with 4G LTE cellular modem block will instead connect to the IVI system via automotive-grade high-speed Ethernet AVB. This frees the IVI system to have more local processing, interface to a variety of sensors, and be a connected yet sophisticated embedded system of systems (Figure 4). Key technologies needed in this architecture are packet switches and bridges, along with timing devices. Let’s examine each briefly.
Life in the Fast Lane: Packet Switches
Switches are increasingly common in embedded systems for one key reason: the limited number of I/O options available on high-density SoCs. When pins are at a premium, either because they are needed for other I/O or to keep costs down, something’s got to give.
The packet switch is differentiated by moving data between the ports while maintaining the original source packet formatting. Figure 5 shows this put to practice in our notional IVI system.
Figure 5: Packet switches used in an IVI system; the switches for PCIe and USB increase fanout from processors with limited I/O and/or pins.
Shown in Figure 5 is a notional IVI system with center console (instrument panel can also be included), and USB entertainment and storage peripherals. Shown is a 4-port PCIe (packet) switch, which is used to increase the SoC’s PCIe fanout from a single port to three downstream PCIe ports. Without this switch, no additional PCIe devices could attach to the IVI’s SoC processor.
The packet switch in the telematics module is always “on” as it is used for entry, remote start and other functions utilizing wireless protocols. Therefore, having a packet switch with very low standby power is critical, especially for the telematics module, and is a power-saving feature for the infotainment module. Pericom’s small 3 (PI7C9X2G304SL) and 4 port PCIe GEN2 packet switches (PI7C9X2G404EL) can provide very low standby power to specifically address these applications.
One PCIe switch example from industry is the Pericom PI7C9X2G404EL 4-port, 4-lane PCIe 2.0 packet switch. A single x1 PCIe lane connects to the host controller, while three x1 Gen 2 ports connect to endpoints. More than a simple switch, the device has a low 150ns “non-blocking” latency between ports but also allows “store and forward” capabilities to buffer packets. Link power management per the PCI Express spec assures interoperability, and the device is available from -40 ºC to +85 ºC and in automotive versions starting 3QCy16. Pericom will have AECQ qualified small packet switches available in 3QCY16.
Intelligence Right at the PCI Express Switch
One other interesting feature about the Pericom PI7C9X2G404EL 4-port, 4-lane packet switch is that it supports Single Root I/O Virtualization (SR-IOV) address translation. This is part of the PCI Express specification that defines a standardized mechanism to create natively shared devices when virtual machines (VM) are employed. Although Figure 5 doesn’t reflect a VM architecture, it is quite possible that such an architecture would be employed in an IVI system if the IVI processor was also responsible for some of the car’s telematics functions. In that case, partitioned virtual environments would be used for security and safety critical operations.
Figure 6 shows that PCI Express packet switches are also needed for the IVI system but outside of it for dealing with remote sensors. In this diagram, the advanced driver assistance system (ADAS) sub-system connects with IP-based cameras using Gigabit Ethernet. The GigE controller is bridged to PCIe, which is then packet switched to the ADAS processor through a Pericom (the Q meaning AECQ qualified); the other port connects to a PCIe Wi-Fi controller.
This PCIe packet switch is similar to the one shown in Figure 5; however, it has 3 ports (typically one in and two out) but one port can be configured as a PCIe x2 lane port. This provides twice the data throughput on this port—useful to service two data-hungry downstream ports like Wi-Fi and GigE. To save power, downstream ports are set to idle.
Plenty of Time
Figure 7 highlights the timing blocks typical in an IVI system, which is a bit more detail than was shown earlier in our notional IVI system in Figure 5. Even though the IVI embedded system is in a car, it still requires precision clocks and timing sources for the digital components. Here, the emphasis is on accuracy over a wide temperature along with the ability to clock multiple controllers with one clock source.
The concept of “one to many” is made clear by referring back to Figure 6 where a single clock generator is capable of meeting the timing for both the SoC and the PCI Express packet switch. The device shown, PI6C557-03AQ PCIe 2.0 clock generator by Pericom, runs on 3.3VDC and operates over a wide AEC-Q100 qualified industrial/automotive temperature range—probably the most critical requirement for a timing device.
In this application, output frequencies of 25MHz, 100MHz, 125MHz and 200MHz provide flexibility to drive many kinds of PCIe peripherals and controllers. The onboard PLL remains steady over temperature and merely requires an equally steady 25MHz crystal oscillator as shown.
In an automotive environment that is sensitive to electromagnetic interference, Pericom’s PCIe clock generators are capable of providing spread spectrum output clock signals to help lower EMI from the high frequency clocks. The various spread spectrum settings of 0%, +0.25%, -0.5%, and -0.75% are available for system designers to select and change to ensure that their design passes the strict EMI requirements of the automotive industry without sacrificing the performance of the PCIe link.
On the Move
The world has always loved the automobile as a way to get places quickly, a means of independence, and increasingly as a personal space to escape. But in today’s connected world where the Internet is the backbone of modern commerce, the connected car demands more sophistication from the center console IVI system.
Yet even with enhanced graphics, smartphone connectivity, and high-density SoC processors, the IVI system fundamentally remains an embedded system. And, as with all high-speed embedded systems, engineers must be aware of packet switches and bridges and timing solutions, and remain vigilant in dealing with high-speed signal integrity challenges.