Verifying Design for In-Car Networks

Once upon a time the role of electricity in a car was pretty modest: spark plugs, alternator, lighting, some simple instrumentation and maybe heating, all supported by an equally simple wiring harness (my wife has a 1962 Morris Minor, so I know exactly what the whole wiring harness looks like). How times have changed. Now most or all drivetrain systems are controlled by wire rather than mechanical linkages, driver assistance and safety is supported through proximity detectors and AI analysis of radar, infrared and light images, the cabin has sophisticated entertainment options, navigation and other features supported by voice control. There’s no obvious end to what could be added.

Obviously, this can’t be supported with a simple wiring harness. You might assume the logical solution would be to hook it all up through some form of Ethernet with bridges to actuators and sensors where needed, but you would be wrong. Or rather you would only be partly right. Cars present a much more hostile (electromagnetic interference, temperature, and vibration) environment for electronics than you would find in a home or office environment. And an acceptable level of safety in some systems is much less tolerant to latencies in the network than for other systems. Then there’s cost – do you need an Ethernet connection to control a side mirror?

The picture is further complicated by needs for autonomous and semi-autonomous control, requiring real-time response to video, audio and data from camera, wireless and sensor interfaces. Overall there is quite a wide spectrum of communication options, some held to very high safety standards and reliability expectations given high recall costs and much longer in-service lifetimes.

Let’s start with protocols for “standard” needs. These include:

• LIN (local interconnected network) – low cost, single wire, 40kb/s, used primarily for mirrors, door locks, power seats, wiper controls, climate control and similar functions). Very simple master/slave protocol, one slave responds to each message, so no arbitration or collision detection required.
• CAN (controller area network) – middling cost, 2 wire (twisted pair), 1MB/s, used primarily for powertrain (engine timing, transmission, ABS). Protocol more like a standard bus bit multiple message types, arbitration, etc. There can be multiple CAN networks in a car.
• FlexRay – higher cost, 2 or 4 wire (twisted pair, single or dual channel), 10Mb/s, high performance powertrain and safety applications (drive-by-wire, active suspension, adaptive cruise control). Protocol offers support for static and dynamic frames with a preset communication cycle allowing an option for deterministic data arrival where needed or CAN-like dynamic event-driven delivery.
• Ethernet (no explanation needed) – this has been primarily for diagnostics
• MOST (media-oriented systems transport) – widely used for multimedia today, time-sensitive traffic support, but a protocol and architecture specialized to automotive applications. There is enthusiasm in the industry to eventually replace this (and perhaps other standards listed here) with Ethernet-based approaches.

Then we have protocols for autonomous/semi-autonomous needs:

• Ethernet-AVB (audio/video bridging) – a competing standard to MOST, also used for multimedia. Builds on the Ethernet standard to offer time-sensitive behavior where privileged data can be prioritized over non-privileged data. Important in e.g. cabin surround-sound where differing latencies to different speakers due to best effort behavior of the network may compromise listener experience.
• Time Sensitive Networking (TSN) – AVB extended to AVB TSN for application to control systems. TSN is used across the systems of an autonomous car for transmission of data ranging from ADAS and control traffic to infotainment and internet, ensuring precise, synchronized, deterministic and timely delivery of data with minimum latency.
• MIPI – there are several relevant sub-sections:

  • CSI-2 – In a typical mobile application, an application processor uses MIPI CSI-2 to provide high bandwidth, low-power, and low cost interfaces to cameras. The same architecture carries over into the automotive world for intelligent rear-view mirrors and radars for parking assist, wing mirrors, cameras for gathering information about objects around the car, and even surround-view systems.
  • DSI – MIPI DSI is aimed at reducing the cost of display controllers and commonly used for dash, infotainment, and any other display in the car. The DSI specification defines a high-speed serial interface between a peripheral, such as an active-matrix display module, and a host processor.
  • I3C – The need for a faster, lower power, scalable sensor connectivity with efficient architecture is essential for an autonomous car with myriad of sensors. The MIPI I3C standard has become the ideal solution for today’s sensor interface requirements due to its faster speeds of 12.5Mhz and fewer pin counts as compared to other existing solutions like I2C and SPI. Sensors for accelerometer, proximity, touch screen, compass, and more are used in advanced driver assistance systems (ADAS) and in-vehicle infotainment (IVI) applications, creating more opportunity to deploy the technological advantages of I3C in automobiles.

Synopsys has verification IP (VIP) for all traditional protocols used in vehicles (Ethernet/LIN/CAN/FlexRay), except for MOST. On top of this they have added Ethernet AVB/TSN and MIPI protocols for autonomous/semi-autonomous support. All of these are available in SystemVerilog/UVM.

Why not support MOST? I couldn’t get a response on this from Synopsys, but Googling around I couldn’t find any other VIP (or IP) vendor, even the small ones, providing MOST support either. I guess the design/verification eco-system doesn’t have a lot of confidence in the future of MOST or, perhaps more important, aren’t getting signals from the automotive industry that MOST is a good area to invest.

One of the nice things about protocol verification in the Synopsys suite is protocol-aware debug in Verdi. Some of us get a chance to become proficient in certain protocols but most of us have too many bases to cover to be experts at everything, so we need a little help. This is especially true in protocol debug where root-cause analysis of misbehavior and bottlenecks needs more than basic waveform analysis. Each of these automotive VIPs supports protocol-aware debug in Verdi.

Automotive VIPs come with a configurable test-suite and test plan so you don’t have to build the protocol tests from scratch; this include the test plan for complex sequences which can be quite difficult to derive from the specification.

This is complex stuff. Each standard supports many options – different network topologies, different frame-types, different modes, different rates. Building a comprehensive test-suite for each protocol can be challenging. Naturally the demands of this domain leave no room for error so you are quite likely to complement testing based on the Synopsys VIPs with your own testing. A very understandable strategy, starting with a strong out-of-the-box verification using Synopsys VIPs. You can see the Synopsys press release HERE and get more detail on the automotive VIPs HERE.

More articles by Bernard…