Automotive packet data switch utilizing line diversity

Abstract

Embodiments of a method and apparatus are disclosed. In an embodiment, a vehicle onboard network interface device includes a data port to send and receive data packets, a plurality of packet processing pipelines coupled to the data port, the packet processing pipelines each to inspect an individual data packet to determine an action to be performed on the individual data packet, and a security module to receive the determined actions from each packet processing pipeline, to select one of the determined actions to be performed on the individual data packet, and to cause a selected one of the packet processing pipelines to perform the selected action.

Description

TECHNICAL FIELD

[0001] The present invention relates to a packet data switch for automotive applications utilizing pipeline diversity. BACKGROUND

[0002] In motor vehicles, the features and capabilities of advanced driver assistance systems (ADAS) are steadily increasing and are creating conditions for autonomous driving beyond level 3. Associated with this is the increasing demand for functional safety, as standardized in, for example, ISO 26262. This applies to almost every subsystem of a vehicle and to vehicle communication systems. For next-generation systems, a packet data switch is a key element of automotive in-vehicle communication. The packet data switch will support more functional safety mechanisms and will be part of the overall vehicle functional safety architecture.

[0003] The safety requirements for automotive communication applications are therefore also increasing. The steadily increasing safety requirements have already been applied to automotive Ethernet and can be applied to future controller area network (CAN) switch communication in the vehicle network architecture area and to network systems that are being developed or will be developed. SUMMARY

[0004] Embodiments of a method and apparatus are disclosed. In embodiments, a packet data switch utilizing pipeline diversity is disclosed. In embodiments, an in-vehicle network interface apparatus includes a data port to send and receive data packets, a plurality of packet processing pipelines coupled to the data port, the packet processing pipelines each to inspect a single data packet to determine an action to be performed on the single data packet, and a safety module to receive the determined actions from each packet processing pipeline, to select one of the determined actions to be performed on the single data packet, and to cause a selected one of the packet processing pipelines to perform the selected action.

[0005] In further embodiments, the safety module selects one of the determined actions by selecting the action determined by a majority of the packet processing pipelines. In further embodiments, the safety module generates an error flag in response to different determined actions from the plurality of packet processing pipelines. In further embodiments, the safety module includes a functional safety interface to a connected external apparatus, and wherein the safety module sends the error flag to a diagnostic application of the connected external apparatus in a safety mode.

[0006] In further embodiments, a first packet processing pipeline of the plurality of packet processing pipelines includes a first type of action determination mechanism, and a second packet processing pipeline of the plurality of packet processing pipelines includes a second type of action determination mechanism. In further embodiments, the first action determination mechanism includes a content addressable memory (CAM) and the second action determination mechanism includes a random access memory (RAM).

[0007] Further embodiments include a frame counter connected to each packet processing pipeline and to the safety module, wherein the frame counter reports a frame count to the safety module, and wherein the safety module uses the frame count, in part, to select an action.

[0008] In further embodiments, a first packet processing pipeline of the plurality of packet processing pipelines includes a first voltage source from a first power rail, and a second packet processing pipeline of the plurality of packet processing pipelines includes a second voltage source from a second power rail. In further embodiments, a first packet processing pipeline of the plurality of packet processing pipelines includes a first oscillator, and a second packet processing pipeline of the plurality of packet processing pipelines includes a second oscillator.

[0009] In further embodiments, the determined action includes lookup and forward.

[0010] One embodiment is a method of operating an in-vehicle network interface device, the in-vehicle network interface device comprising: receiving a data packet at a data port; inspecting a single data packet at each packet processing pipeline of a plurality of packet processing pipelines coupled to the data port; determining, at each packet processing pipeline of the plurality of packet processing pipelines, an action to be performed on the single data packet; receiving, at a safety module, the determined actions from each packet processing pipeline; selecting one of the determined actions to be performed on the single data packet; and causing a selected packet processing pipeline of the packet processing pipelines to perform the selected action.

[0011] In further embodiments, selecting one of the determined actions includes selecting an action determined by a majority of the packet processing pipelines.

[0012] Further embodiments include generating an error flag at the safety module in response to different determined actions from the plurality of packet processing pipelines. Further embodiments include sending the error flag to a diagnostic application of a connected external device in a safety mode using a functional safety interface of the safety module.

[0013] In further embodiments, determining actions at a first packet processing pipeline of the plurality of packet processing pipelines comprises using a first type of action determination mechanism, and wherein determining actions at a second packet processing pipeline of the plurality of packet processing pipelines comprises using a second type of action determination mechanism.

[0014] In further embodiments, the first action determination mechanism comprises a content addressable memory (CAM) and the second action determination mechanism comprises a random access memory (RAM).

[0015] Further embodiments include counting frames at each packet processing pipeline of a frame counter and reporting frame counts to the safety module, and wherein selecting one of the determined actions comprises using the frame counts, in part, to select.

[0016] Another implementation is a vehicle data network switch, comprising: a data port to send and receive data packets; a plurality of packet processing pipelines coupled to the data port, each to inspect a data packet to determine an action to perform on the data packet, a first action determination mechanism comprising a content addressable memory (CAM) to look up actions and a second action determination mechanism comprising a random access memory (RAM) to look up actions; and a safety module to receive determined actions from each packet processing pipeline, to select one of the determined actions to perform on a respective data packet, and to cause a selected one of the packet processing pipelines to perform the selected action.

[0017] In further embodiments, the first action determination mechanism comprises a first voltage source from a first power rail and the second action determination mechanism comprises a second voltage source from a second power rail. In further embodiments, the safety module comprises a functional safety interface to a connected external device, and wherein the safety module sends an error flag to a diagnostic application of the connected external device in a safety mode. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 A vehicle communication system with multiple switches and nodes is depicted.

[0019] Figure 2 An automotive packet data switch utilizing pipeline diversity is depicted.

[0020] Figure 3 An alternative automotive packet data switch utilizing pipeline diversity is depicted.

[0021] Figure 4is a process flow diagram for operating a cellular packet data switch. DETAILED DESCRIPTION

[0022] It will be readily understood that the components of the embodiments, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following more detailed description of the various embodiments, as represented in the figures, is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments are presented in the drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

[0023] The present application can be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the application is, therefore, indicated by the appended claims, rather than by this detailed description. All changes coming within the meaning and equivalency range of the claims are intended to be embraced in the scope of the claims.

[0024] Reference throughout this specification to a feature, advantage, or similar language does not imply that all of the features and advantages that can be achieved with the present application should be or are in any single embodiment of the application. Rather, languages referring to a feature or an advantage are understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the application. Thus, appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0025] Furthermore, the described features, advantages, and characteristics of the application can be combined in any suitable manner in one or more embodiments. One skilled in the art will recognize that the application can be practiced without one or more of the specific features or advantages of a particular embodiment, in this case an embodiment. In other cases, additional features and advantages can be recognized in a certain embodiment that can not be present in all embodiments of the application.

[0026] Reference throughout this specification to "one embodiment," "an embodiment," or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the application. Accordingly, appearances of the phrases "in one embodiment," "in an embodiment," and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0027] Figure 1An example of an in-vehicle electronic communication system suitable for use with the present application and in conjunction with a packet data switch as described herein is depicted. The switch can be based on Ethernet or another packet data protocol. The automotive system includes packet data switches integrated into electronic control units (ECUs) distributed throughout the vehicle. Alternatively, one or more of the switches can be independent of the ECUs. As shown, a central processor 107 includes a main gateway switch 101 coupled to other devices 129, 133, 145 and controllers 135, 137, 139. The central processor 107 is further coupled to an on-board diagnostic (OBD) port 111 for external maintenance, control, and monitoring.

[0028] In this example, the central processor is coupled through a packet data gateway to a power domain controller 135, a body domain controller 137, and an advanced driver assistance system (ADAS) controller 139. These controllers each include another integrated packet data switch for connection to other components. For example, the power domain controller 135 is coupled through its switch to ECUs 113, such as an engine management unit and a tire pressure monitoring system (TPMS) module 115. The body domain controller 137 is coupled to two other body control ECUs 117, 119, such as for steering and braking. The ADAS domain controller 139 is coupled to a variety of sensors, such as a camera 121, radar 123, LIDAR 125, and a vehicle cellular radio 127 for communication with other vehicles and roadside objects.

[0029] A navigation and in-vehicle infotainment system 129 can also be coupled to the central gateway 101. This system can include connection through its own packet data switch to a telematics control unit (TCU) 143 that can include inertial sensors and a satellite positioning receiver, a radio 141 and other entertainment signal sources, an audio amplifier 145 and a speaker system 147. One or more displays 133 are coupled to the central gateway and can also provide user input through touchscreens and physical buttons as well as switch interfaces.

[0030] As shown, the packet data switches can be configured as part of a system on a chip (SoC), a system in a package (SiP), or in any other suitable manner. The packet data switches connect processors and memory to a number of nodes, several examples of which are shown. However, more or different types of more or fewer nodes can be used in the system.

[0031] The packet data switch allows each node to communicate with each processor, each sensor, each input, and each output device. Some connections are direct, while some connections are indirect. Data storage devices can be incorporated into the processors, on the die or package, or into other nodes, and each node can include data storage devices.

[0032] More and more automotive sensors and other nodes are being proposed, and with this increase in complexity and the increasing demand for autonomous driving, it is increasingly difficult to ensure fast and reliable operation. Certain reliability can be ensured by the way the different nodes are connected, so that for example braking is based on a dedicated connection, while entertainment channel selection can be implemented more indirectly. New reliability standards - in network switches referred to as functional safety mechanisms - target certain reliability. The focus is on improving the use of memory resources to achieve redundancy and proper interaction with other functions of the functional safety architecture, thereby reducing the risk of system performance degradation. While current versions of automotive switches feature a certain degree of functional safety, this is not enough to enable future generations of these devices to meet the needs of future semi- and fully autonomous driving.

[0033] Figure 2 is a block diagram of an Ethernet system on chip (SoC) 202, such as a packet data switch suitable for use with an in-vehicle communication system such as the central gateway 101, or Figure 1 other switches coupled to or integrated with vehicle ECUs. While an Ethernet switch is shown and described, the Ethernet SoC 202 can be adapted to accommodate other packet data protocols. Other packet data types can also be handled, including CAN and Local Interconnect Network (LIN) data, as well as other data using the same or similar structure. The system includes a switch fabric 212, a microcontroller 218, a reference block 220, and physical input interfaces PHY 222, 226, all on a single die and packaged as an integrated unit. Alternatively, the switch can be configured as a system in a package (SIP), in which multiple dies together perform all of the described functions, and possibly more. All of the dies are then mounted in a single package as a single unit.

[0034] The switch has multiple input / output (I / O) ports, such as (n) Ethernet ports 224-1, 224-2,..., 224-n and (m) other additional ports 228-1,..., 228-m, which in this example are indicated as x Media Independent Interfaces (xMII, such as Reduced MII and Gigabit MII) or serial ports, such as Serial GMII or other protocols. More or other ports can be used to accommodate specific implementations. In this embodiment, the ports are primarily used to provide packet data with metadata that facilitates packet inspection, such as headers and footers. Even with serial ports, if these are connected directly to another node, the connection can be used to provide source and destination information.

[0035] The ports are each coupled to a respective physical interface. The (n) Ethernet ports can be connected to (n) respective physical Ethernet interfaces, such as Ethernet PHYs 222-1, 222-2, 222-n. The Ethernet PHYs can be a dedicated chip in a SiP implementation, or part of a die in a SOC implementation, for example. The PHY portion can be dedicated to support a specific protocol, such as 100BASE-T1 for automotive Ethernet, or any other protocol for IEEE 802.3 or another communication system. The xMII ports are also coupled to respective physical interfaces, such as SerDes PHYs 226-1,..., 226-m.

[0036] The SERDES physical interfaces (PHYs) 222, 226 are coupled to a switch fabric 212, which in this example provides a media access control (MAC) interface 230-1, 230-2,..., 230-n for each Ethernet PHY 222, and a MAC interface 232-1,..., 232-m for each SERDES PHY 226. The MAC interfaces are each coupled to a packet processing pipeline 213, also referred to as a switch core, which has a lookup portion 214 for packet inspection and analysis, and an action portion 216 that takes action based on the lookup results. The action can include forwarding, adding a timestamp, or changing a header field, such as for a VLAN tag. The lookup portion 214 uses at least two different types of memory access systems. In this instance, there are two ternary content addressable memory (TCAM) lookup mechanisms 242, 244. These can be different memories or other CAM types, as well as one static random access memory (SRAM) lookup mechanism 246 or other memory type. The action portion 216 uses only one type of memory access system and has three SRAMs 248, 250, 251, but can instead use different memory types and diverse memory types.

[0037] In the lookup portion 214, decisions are made based on several parameters. The decisions can be affected by the configuration of the lookup memory and various issues in the received packet. If there is a TCAM or a packet with errors or any other common cause error or failure, such as a single point failure, the overall safety of the system can be compromised. If the error or failure pattern is severe enough, the functional safety can be violated.

[0038] In Figure 2 In the example shown, the lookup portion and action determination can operate in a redundant manner. Three identical packet processing pipelines are used to provide a first level of redundancy. In some embodiments, this is sufficient to ensure that some errors are eliminated. Another way to achieve this redundancy is to apply diversification of the memory. As shown, two different memory technologies are used: TCAM and random access memory, although other alternative types of memory can be used instead. As shown, MAC interfaces 230, 232 are connected to the same lookup portion. Typically, there is a unique packet processing pipeline in the lookup portion for each MAC interface. After lookup, each pipeline performs a unique subsequent action. In the embodiment shown, there are three pipelines that independently process the same packet. A single packet is received in the lookup portion, for example from MAC 1 232-1, and is processed by each of the three independent lookup processing mechanisms 242, 244, 246. Similarly, the next packet, for example from MAC 2 232-2, is also processed by each of the three independent lookup processing mechanisms 242, 244, 246. Two of the lookup processing mechanisms use TCAM and one of the lookup processing mechanisms uses SRAM. However, this configuration of redundancy and multiple mechanisms can be modified to suit a particular application.

[0039] Each of the three independent lookup processing mechanisms 242, 244, 246 is coupled to a respective independent SRAM 248, 250, 251 action determination mechanism. They each produce independent results that are partially dependent on the input from the respective connected lookup processing mechanism 242, 244, 246. Although the action determination mechanisms are each shown as using SRAM in the physical implementation, other configurations can be used and the diversity of memory can also be used as in the lookup portion.

[0040] The three independent action determinations from each of the three independent packet processing pipelines are monitored by a security module 204 of the Ethernet SoC 202, which is coupled to each pipeline to receive the three determined actions. The security module 204 provides real-time monitoring of the decisions implemented by the individual packet processing pipelines. The security module determines whether the determined actions are consistent among all three pipelines for the same packet. When the determined actions are consistent, then any of the packet processing pipelines can take action to process the single packet. In some embodiments, one of the pipelines is configured to be primary and will always perform the determined action when the pipelines are consistent. In some embodiments, the other two pipelines are primarily used as a security check to ensure the accuracy and reliability of the primary pipeline.

[0041] Each pipeline is represented by a table in the lookup section 214 and a table in the action section 216. The first packet processing pipeline is a first TCAM 242 and connected SRAM 248, and the connections therebetween. The packet is received from any of the MAC interfaces through the determined action in the action section of the SRAM 248, and then returned to the same MAC interface to exit the appropriate Ethernet PHY 222. The second packet processing pipeline includes a second TCAM 244 and connected SRAM 250. The third packet processing pipeline includes a third table, in this example a SRAM 246 and connected action determination SRAM 251. This allows each pipeline to independently process a single packet through the lookup section 214 and the action section 216. Each pipeline independently determines the action for a single packet. Although three packet processing pipelines are shown, more or fewer pipelines can be used. With three pipelines, majority voting is simplified, especially when only one pipeline produces a different action determination.

[0042] If the determined actions are not consistent, one of the determined actions is selected. The selection of which pipeline takes precedence can be a configuration parameter or a hardware setting. Alternatively, a majority voting mechanism can be used in the case where the primary pipeline produces a different action than the other two pipelines. When all of the determined actions are received at the security module 204, the security module can select the determined action and generate an error flag 210 when there is a conflict between the pipelines. The error flag is sent to an external management program, such as the appropriate one of the connected processors 107, 109 or a dedicated maintenance device.

[0043] In addition to triggering a fail-safe state through the error flag 210, the safety module 204 can also include a data and control interface 206 to an external supervisor. Using the data and control interface 206, the safety module 204 is able to transfer functional safety data to the supervisor. The functional safety data can include additional data such as the cause of the error. The communication with the supervisor can be connected to an application or higher instance within the functional safety architecture. The application can perform additional diagnostics and defect analysis for the vehicle.

[0044] The Ethernet SoC 202 can additionally include a microcontroller 218 having a microprocessor 260 connected to working and cache memory such as SRAM 262 and instruction and configuration storage such as boot read-only memory (ROM) 264. The microcontroller 218, as well as the processors 107, 109, can be a central processing unit (CPU), a digital signal processor (DSP), a microcontroller, or any other digital system having multiple processors and multiple memories. The processors can be of different types as tasks differ and power distribution differs. Some processors can work together on a single combined task to increase total throughput. The memories can be volatile or non-volatile and can take any of a variety of different physical forms, including static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, magnetic memory, optical memory, or another memory.

[0045] In some embodiments, the microcontroller 218 performs the higher instance application functions in place of or in cooperation with an external device coupled to the functional safety data and control interface 206. In some embodiments, the microcontroller 218 performs the selection of the determined action when the results of the diverse packet processing pipelines are inconsistent. In some embodiments, the safety module 204 is implemented as a function of the microcontroller 218. In some embodiments, the safety module 204 is a separate circuit coupled to the microcontroller 218.

[0046] In some embodiments, the safety module 204 is configured such that resolution actions are taken in a self-responsible manner. In such embodiments, the error flag is sent to the external device, but the safety module resolves the error independently. The resolution action can include logging the event that caused the error flag in a predefined memory space for later inspection. Packet processing continues operation. The error flag is still sent. In some embodiments, the safety module indicates the event via the error flag and prepares a set of additional information to send to a higher instance at the external device, such as the processor 107, 109 that manages the network and communication availability and is responsible for further actions. In some embodiments, the communication between the safety module 204 and the higher instance is in a safety mode, which can be a handshake or mechanism that guarantees a higher safety. Particular safety implementations can be adapted to accommodate different safety requirements of the vehicle.

[0047] The Ethernet SoC 202 can additionally include various different reference blocks 220. The reference blocks can include an oscillator 266, a voltage source 268, and a reference current 270. The blocks are shown as being in a single physical location on the die, however, this is for ease of understanding and the blocks can have many instances distributed through the Ethernet SoC 202. The voltage source is coupled to the switch fabric 212 as a first Vcc 252 and a second Vcc 254. The oscillator is coupled to the switch fabric 212 as a first Osc 256 and a second Osc 258. In some embodiments, the two Vccs 252, 254 are each provided from a different voltage source 268. The two Vccs 252, 254 can also each be coupled to a different reference current 270. In some embodiments, the voltage sources are each fed from a different power supply rail that externally powers the Ethernet SoC 202, each voltage source having a different reference voltage and reference current source. A first power supply rail powers the first Vcc and a second power supply rail powers the second Vcc. In some embodiments, different circuitry for the voltage source 268 and the reference current 270 are coupled to the same external power supply rail. Similarly, the two Oscs 256, 258 can be powered by the oscillator 266, the Oscs 256, 258 each being generated independently of a common reference master oscillator or each being sourced from a different reference oscillator.

[0048] Two different Vcc and OSC are coupled to two different packet processing pipelines. In some embodiments, the TCAM242, 244 packet processing pipelines receive a first Vcc 252 and OSC 256, while the SRAM 246 packet processing pipeline receives a second Vcc 254 and OSC 258. Although two are shown, each pipeline can have different Vcc and OSC. This diversification significantly improves functional safety levels because different memory technologies involve different voltage sources and different clock systems. Different memory technologies may also involve different self-tests and different self-healing mechanisms. This diversification reduces many possible common-cause failures. Similar to reference block 220, physical interface (PHY) 222, 226, and MAC interfaces 230, 232, different memory entities can be located on a microchip, as different dies within a microchip package, or as separate components on a printed circuit board.

[0049] Figure 3 Depicting Figure 2 A block diagram of an alternative configuration of a portion of the Ethernet SoC 202. This switch architecture includes multiple MAC interfaces 330-1, 330-2, ..., 330-n coupled to a switch core 312. The switch core 312 includes three packet processing pipelines, partially shown in this diagram. The first packet processing pipeline includes a TCAM 342 coupled to a first voltage source Vcc 352 and a first oscillator Osc 356. The second packet processing pipeline includes a second TCAM 344 ​​coupled to the same Vcc 352 and Osc 356. The third packet processing pipeline includes an SRAM 346 coupled to a second Vcc 354 and a second Osc 358. This provides the information provided above regarding... Figure 2 The discussed memory diversity and voltage, current and oscillator diversity are designed to reduce common-cause failures and enhance functional safety.

[0050] Each pipeline is coupled to a respective counter. A first pipeline, denoted as first TCAM 342, is coupled to a first counter 370-1. A second pipeline, denoted as second TCAM 344, is coupled to a second counter 370-2. A third pipeline, denoted as SRAM 346, is coupled to a third counter 370-3. Additional counters can be present for additional pipelines. Although the counters are shown as separate entities for ease of understanding, a single circuit or module can implement all of the counters. The counters are coupled to a safety module 304 of the switch, which can be implemented as a separate circuit or as part of an internal or external processor (not shown). The counters are used for frame counting for each respective packet processing pipeline. The frame counters 370 report the frame counts to the safety module 304. The safety module 304 compares the frame counts from each counter. In some embodiments, the safety module determines whether there is a discrepancy in the frame counts of the packets and sends an error flag in response to the discrepancy. In some embodiments, the safety module compares the frame counts and selects a determined action in response to the frame counts. For example, if a packet processing pipeline uses an excessive number of frames to determine an action, the safety module can ignore the action and select a different action for the respective packet.

[0051] The Ethernet switch described herein can be utilized in many different applications, such as automotive body domain controllers, gateway controllers, or zone controllers, among others. The switch can also be used in other non-automotive applications to enhance safety or reliability. As described herein, the diversity of memory types enhances the functional safety level. The diversity of voltage sources further enhances the functional safety level, and the diversity of oscillators yet further enhances the functional safety level. Additionally, the diversity can be extended to include diversity of reference currents. As shown, each of these elements can be used independently or together. These diversity measures each reduce the switch's susceptibility to common cause failures.

[0052] Faults can be detected by observing the determined actions from each of the different packet processing pipelines. Additional fault detection can be performed using the frame counters to compare the operation of each packet processing pipeline. The described embodiments have flexibility and can be reconfigured to accommodate different purposes. For example, without the need for functional safety, a regular memory (e.g., SRAM) can not be configured as a redundant entity to the TCAM, but rather biased as an independent memory entity. In cases where speed is more important than safety, the three packet processing pipelines can be configured to operate independently to triple the output of the switch.

[0053] The safety module is configured to observe the operation of the packet processing pipelines and collect information about any fault events. The safety module can operate independently to correct any observed events and can share any events with higher instances. In some embodiments, the safety module takes the decision on how to resolve discrepancies detected in the redundancy mode between TCAM and regular memory. In some embodiments, the safety module can leave the action decision to the host controller or higher instances in the functional safety architecture to ensure network and communication availability. The described configuration can be in one microchip, in a multi-die system in a microchip package, in a standalone component on a printed circuit board, or in other physical implementations.

[0054] Figure 4 is a process flow diagram of the operation of the Ethernet SoC 202 and Figure 3 modifications in the operation of the Ethernet SoC 202. At block 402, a data packet is received at a data port of the switch. The packet can come from any node in the system and be directed to any other node. The data packet can be in the 100BASE-T1 format or the xMII format for automotive Ethernet. However, any other packet data format can be used to accommodate the needs of the particular nodes and network.

[0055] At block 404, the packet is passed through the physical interface and MAC interface to a plurality of packet processing pipelines, and the packet is inspected at each pipeline. The plurality of pipelines can be identical or use various types of diversification, including memory diversification, Vcc diversification, Osc diversification, reference current diversification, and other types of diversification.

[0056] After packet inspection, then at block 406, an action is determined at each packet processing pipeline to determine an action for the packet. The action can be to forward the packet to another node based on source or destination information in the packet or both. Other actions can also be supported, including lookup, etc.

[0057] At block 408, the determined action for each pipeline is sent from each pipeline to the safety module. The safety module receives these determined actions and at block 410 selects one of the actions to perform on the corresponding packet. When the system is operating properly, then the three determined actions will be identical. However, when there is a fault, there will be more than one determined action. The safety module can select the action based on a preferred pipeline, a majority vote, or another process.

[0058] At block 412, the selected action is performed by the pipeline that determined the action. In many cases, the packet is forwarded by the selected pipeline to another node through the MAC interface and PHY interface.

[0059] When the packet processing pipelines determine different actions for the respective packet, then the safety module generates an error flag that can be sent to a diagnostic application of the connected external device in the safety mode. In some embodiments, a counter counts the frames used by each packet processing pipeline and sends the frame count to the safety module for selecting the determined action.

[0060] It should be noted that at least some of the operations of the methods described herein can be implemented using software instructions stored in a computer-usable storage medium for execution by a computer. For example, an embodiment of a computer program product includes a computer-usable storage medium to store a computer readable program.

[0061] The computer-usable or computer-readable storage media can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Examples of a non-transitory computer-usable and computer-readable storage media include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read / write (CD-R / W) and digital video disk (DVD).

[0062] Alternatively, embodiments of the present application can be implemented entirely in hardware or in an implementation that includes both hardware and software elements. In embodiments that use software, the software can include, but is not limited to, firmware, resident software, microcode, etc.

[0063] Although specific embodiments of the present application have been described and illustrated, the present application is not to be limited to the specific forms or arrangements of parts so described and illustrated. The scope of the present application is to be defined by the claims appended hereto and their equivalents.

Claims

1. An in-vehicle network interface device, characterized by comprising: comprises: a data port to send and receive data packets; a plurality of packet processing pipelines coupled to the data port, each to inspect a single data packet to determine an action to be performed on the single data packet; a safety module to receive the determined actions from each packet processing pipeline, wherein the safety module is configured to determine if the determined actions are consistent, the determined actions being consistent if a majority of the plurality of packet processing pipelines select the same determined action; if the determined actions are consistent, the safety module is configured to select the consistent determined action to be performed on the single data packet, and the safety module is configured to cause any of the plurality of packet processing pipelines to perform the selected action; if the determined actions are inconsistent, the safety module is configured to select one of the determined actions to be performed on the single data packet, and to cause a selected packet processing pipeline of the plurality of packet processing pipelines to perform the selected action.

2. The apparatus of claim 1, wherein, The safety module generates an error flag in response to different determined actions from the plurality of packet processing pipelines.

3. The apparatus of claim 2, wherein, The safety module comprises a functional safety interface to a connected external device, and wherein the safety module sends the error flag to a diagnostic application of the connected external device in a safety mode.

4. The apparatus of claim 1, wherein, A first packet processing pipeline of the plurality of packet processing pipelines comprises a first type of action determination mechanism, and a second packet processing pipeline of the plurality of packet processing pipelines comprises a second type of action determination mechanism.

5. The apparatus of claim 4, wherein, The first type of action determination mechanism comprises a content addressable memory, CAM, and the second type of action determination mechanism comprises a random access memory, RAM.

6. The apparatus of claim 1, wherein, Further comprising a frame counter connected to each packet processing pipeline and to the safety module, wherein the frame counter reports a frame count to the safety module, and wherein the safety module uses the frame count, in part, to select an action.

7. The apparatus of claim 1, wherein, A first packet processing pipeline of the plurality of packet processing pipelines comprises a first voltage source from a first power supply rail, and a second packet processing pipeline of the plurality of packet processing pipelines comprises a second voltage source from a second power supply rail.

8. A method of operating a vehicle network interface device, characterized by, comprises: receiving a data packet at a data port; inspecting a single data packet at each of a plurality of packet processing pipelines coupled to the data port; determining an action to be performed on the single data packet at each of the plurality of packet processing pipelines; receiving the determined actions from each packet processing pipeline at a safety module; wherein the safety module is configured to determine if the determined actions are consistent, the determined actions being consistent if a majority of the plurality of packet processing pipelines select the same determined action; if the determined actions are consistent, the safety module is configured to select the consistent determined action to be performed on the single data packet, and the safety module is configured to cause any of the plurality of packet processing pipelines to perform the selected action; if the determined actions are inconsistent, the safety module is configured to select one of the determined actions to be performed on the single data packet, and to cause a selected packet processing pipeline of the plurality of packet processing pipelines to perform the selected action. if the determined actions are consistent, then the safety module is configured to select the consistent determined action to perform on the single data packet, and the safety module is configured to cause any of the plurality of packet processing pipelines to perform the selected action; if the determined actions are inconsistent, then the safety module is configured to select one of the determined actions to perform on the respective data packet, and to cause the selected packet processing pipeline of the plurality of packet processing pipelines to perform the selected action. and cause the selected packet processing pipeline of the plurality of packet processing pipelines to perform the selected action.

9. An in-vehicle data network switch, comprising: Comprise: a data port to send and receive data packets; a plurality of packet processing pipelines coupled to the data port, each of the plurality of packet processing pipelines to inspect a data packet to determine an action to perform on the data packet, a first action determination mechanism comprising a content addressable memory (CAM) to look up actions and a second action determination mechanism comprising a random access memory (RAM) to look up actions; and a safety module to receive the determined actions from each packet processing pipeline, wherein the safety module is configured to determine whether the determined actions are consistent, the determined actions being consistent if a majority of the plurality of packet processing pipelines select the same determined action; if the determined actions are consistent, then the safety module is configured to select the consistent determined action to perform on the single data packet, and the safety module is configured to cause any of the plurality of packet processing pipelines to perform the selected action; if the determined actions are inconsistent, then the safety module is configured to select one of the determined actions to perform on the respective data packet, and to cause the selected packet processing pipeline of the plurality of packet processing pipelines to perform the selected action.

Images