Building One Interface Subsystem For Multiple IoT SoCs

When designing SoCs for Internet of Things (IoT) applications, designers quickly realize that their most efficient use of resources will result in chips that can address multiple end applications. Consumer products require connectivity or edge devices, and networking or enterprise companies are broadening their reach to home networking and cloud services, like remote processing, that complement the other layer devices. Designers often need to address several of these applications at once, with a single ASIC. With the cost of ASIC tape-outs increasing, and designs being constrained by pin counts, designers are looking for ways to support more of the solution space with a single chip.

To address this need, designers are adding flexibility to their SoCs by integrating interface IP subsystems. Interface IP subsystems support several different configurations or products with similar functionalities, or the same chip used in products for different price ranges. For example, home or networking devices may support PCIe and Ethernet in one product, but in a smaller product, the SoC will support USB and DisplayPort or HDMI. This article will talk about the challenges and benefits of building and integrating interface subsystems that support multiple protocols for flexible IoT SoCs.

Figure 1: Grouping IoT devices into related application types shows the similarities in interface requirements

Is your SoC for a home router, a wireless hub or a car?
A single SoC may support different wireless or wired solutions based on the configurations or price range. One of the best ways to build-in SoC flexibility is to add a PCI Express (PCIe) interface. PCIe 3.0 can support 8 Gbps of data throughput and connect to many modular wireless systems. A PCIe interface not only supports different storage devices but also can connect to many wireless interfaces as well. Since 10G Ethernet support requires similar performance, and is also useful for IoT devices, designers often choose to offer it within the same PHY as the PCIe interface. This combination can save area and power by using a two-port SerDes PHY and bifurcating with PCIe (Figure 2). Architecting a device in this way can support 1 or 2 lanes of PCIe to connect multiple devices, or different configurations can support 10G Ethernet or one instance of each. Flexible PHYs give the end product designer options when implementing wired or wireless connectivity, or connecting to additional storage.

Figure 2: Use of a two-port SerDes PHY to implement both 10G Ethernet and PCIe 3.0

For storage applications, designers often need to support USB for some devices and SATA for others. In this scenario, a single PHY supporting both protocols can be used and the burden shared for more flexibility in the end product.

Figure 3: Use of a flexible PHY to support both SATA and USB for storage applications

Although these diagrams look simple, the details can be complex depending on the throughput supported, features required, and which two interfaces are in the same PHY. The Figure 2 example, with PCIe and Ethernet, must support at least three different speeds each. In addition, they require different PHY interfaces, as PCIe requires PIPE and Ethernet has several, including GMII. Connecting address and data are not so hard, but clocking, resets, DFT, SRAMs, and sideband signals take considerable time to learn and integrate. Also, additional specific logic is often needed to overcome all the differences in the protocols and the design work of combining them, which requires deep knowledge and experience for success.

USB is the first protocol to actually plan for the connection of multiple protocols with the new Type-C connector. The thinking is that since the new USB Type-C connector has additional pins, why not conquer one the of biggest problems of most IoT devices and add some display functionality? These new functions are called Alt modes and support DisplayPort, HDMI and potentially more (Table 1).

Table 1: Orientations of the USB Type-C connector supporting USB, DisplayPort and HDMI

Implementing a combination of USB Type-C, DisplayPort and HDMI requires in-depth knowledge of the protocols, including HDCP for security (Figure 4). The complexity is in understanding the implementation details to connect the different blocks and still support all the modes and combinations for the design to support the functionality needed.

Figure 4: Implementation of USB 3.1, DisplayPort, HDMI and HDCP 2.2

Designing it right is just the beginning
The complexity of these subsystems starts with the design, and continues. The verification of different clocks and combinations can be very challenging as well as CDC checking, linting, and synthesis timing checks. But all this complexity is required to maximize the value compared to the cost of making a modern-day ASIC. With time-to-market pressure looming, consulting with a trusted IP supplier, who has deep knowledge and experience in these protocols, allows SoC integrators to achieve first-pass silicon success.

Synopsys knows how to implement these complex designs and has created teams to work with our customers’ design experts. These teams not only know the IP but also know the system implementation details to customize these DesignWare Interface IP Subsystems for the customer. Typically, customers have special requirements such as performance monitors for high speed applications, redundancy, or fail safe modules for automotive or medical equipment. These special blocks can also be modified to support all the SoC requirements to allow the design to more easily drop in to the full SoC. Interface IP subsystems can be completed quickly as the Synopsys teams specialize in the IP as well as custom integration. Using Interface IP Subsystems can reduce the project schedule for integrating complex designs from months to weeks. Synopsys’ Interface IP Subsystem teams can support projects with complex I/O designs that address these issues, allowing SoC teams to focus on differentiating their products.