Control Unit for Translating Between Different Bus Interfaces

The present disclosure relates to electronic control units that interface to multiple bus standards.

Compared to older vehicles, modern vehicles have an ever-growing number of sensors and control units. These sensors and control units are connected to one another by wireline busses. For example, modern automobiles may have between fifty and one-hundred control units for various subsystems. As automobiles utilize more data, finding effective ways to transport data between the sensors and control units is becoming more important.

The present disclosure will now be described with reference to the attached drawing figures, wherein like reference numerals are used to refer to like elements throughout, and wherein the illustrated structures and devices are not necessarily drawn to scale. As utilized herein, terms “component,” “system,” “interface,” and the like are intended to refer to a computer-related entity, hardware, software (e.g., in execution), and/or firmware.

1 FIG. 100 102 104 104 106 108 102 108 100 110 110 104 120 120 112 112 104 122 122 114 114 104 124 124 116 116 104 126 126 118 118 118 118 118 118 118 102 a f a c a a c a c b a c a d c a d a c d a c a b c d e f g shows an example vehiclethat includes a central control unit, a number of zone control units-, an infotainment control unit, and an Advanced Driver Assistance System control unit (ADAS). Any of these components-as well as sensors and/or other components may be referred to as a “control unit” as used herein. Sensors and/or other controllers (e.g., lighting control, sound control, and/or actuators) can be present in the vehiclefor doors, windows, drive train, brakes, steering, seats, heating and cooling, sound system, and so on. These control units are coupled together via various wireline busses. For example, a first group of sensors and/or controllers-can be coupled to a first zone control unitvia busses-, respectively; a second group of sensors and/or controllers-can be coupled to a second zone control unitvia busses-, respectively; a third group of sensors and/or controllers-can be coupled to a third zone control unitvia busses-, respectively; and a fourth group of sensors and/or controllers-can be coupled to a fourth zone control unitvia busses-, respectively. Other busses (e.g.,,,,,,, and) can also couple various control units to one another. Typically, the central control unitand/or engine control unit are the largest control units that use the largest bandwidths, with other sensors and/or controllers often using smaller bandwidths (but alternatively the sensors and/or controllers can use greater bandwidths). Some of these control units can form independent subsystems (e.g., communication is limited to only one “link” between two directly adjacent control units), while other control units can be linked to one another through a chain of multiple control units.

One network protocol for wireline busses in vehicles is Controller Area Network (CAN). CAN is a two-wire bus standard designed to enable efficient communication. Thus, CAN nodes are connected to each other through a pair of twisted copper wires having a 120Ω (nominal) characteristic impedance. CAN is a broadcast-based, message-oriented protocol that ensures data integrity and prioritization through a process called arbitration, allowing the highest priority device to continue transmitting if multiple devices attempt to send data simultaneously, while others back off. Its reliability is enhanced by differential signaling, which mitigates electrical noise. Common versions of the CAN protocol include CAN 2.0, CAN FD, and CAN XL which vary in their data rate capabilities and maximum data payload sizes. In addition to automobiles, CAN is also used in electronic bikes (ebikes), golf carts, and other control systems, such as industrial control systems and others.

Local Interconnect Network (LIN) is another network protocol used for wireline busses extending between components in modern vehicles. LIN is a low-cost single-wire, serial protocol that supports communications up to 19.2 Kbit/s with a maximum bus length of 40 meters (131.2 ft.).

1 FIG. 110 110 104 120 120 112 112 104 122 122 114 114 104 124 124 114 104 124 a c a a c a c b a c a b c a b c c c In, some of the control units may communicate with neighboring control units via CAN and/or LIN, among other network protocols. For example, each of the first group of sensors and/or controllers-can be coupled to the first zone control unitusing one or more respective pairs of twisted copper wires that make up busses-, respectively, and can communicate using the CAN protocol. In contrast, each of the second group of sensors and/or controllers-can be coupled to the second zone control unitusing one or more respective single wires that make up busses-, respectively, and can communicate using the LIN protocol. Some of the third group of sensors and/or controllers (e.g.,and) can be coupled to the third zone control unitusing respective pairs of twisted copper wires (e.g.,and) and can communicate using the CAN protocol, while others (e.g.,) of the third group of sensors and/or controllers can be coupled to the third zone control unitusing respective single wires (e.g.,) and can communicate using the LIN protocol, and so on.

CAN/LIN frames have a short frame length of 8-64 bytes, and for certain data rates this results in a high frame rate and this directly impacts processor/cpu loads. In other words, because the CAN/LIN frames are significantly shorter then Ethernet frames, the processor/cpu needs to be much faster to process CAN/LIN frames in order to keep up with the data rates. As such, CAN and/or LIN are becoming a bottleneck in vehicular communication. Therefore, vehicles are moving to Ethernet cables, which provide data speeds that are significantly faster than CAN and/or LIN. Under one approach, Ethernet cables are used exclusively throughout the entire vehicle for a unified, modern approach. However, legacy sensors/components offer still offer good value in many instances, and may communicate using CAN and/or LIN. Thus, there is a need for efficient techniques to make use of CAN/LIN and Ethernet in vehicles.

1 FIG. 1 FIG. 118 118 102 104 104 126 124 a g a f d Accordingly,'s vehicle provides a mix of CAN and/or LIN busses and as well as higher speed data busses, such as Ethernet busses. In's example, busses-that couple the Central control unitto various zone control units-can be realized as Ethernet cables, and may also couple zone control units to one another (see), and/or may couple a zone control unit to one or more sensors and/or controllers (see). Thus, when existing data speeds are sufficient, CAN/LIN busses are used to save re-design for legacy peripherals; but when higher speed data communication is required, Ethernet busses are used. This approach strikes a good balance between limiting unnecessary costs and providing good performance.

100 104 110 110 102 104 104 110 110 102 104 104 110 110 102 104 104 1 FIG. a a c b a a c b a a c b a Because multiple communication protocols are used in the vehicle, the various control units can act as “bridges” between one node that communicates with a first protocol (e.g., CAN or LIN) and another node that communicates with a second, different protocol (e.g., Ethernet). For example, in the example described in, the zone control unitcommunicates with controllers and/or sensors-using CAN, and communicates with the central control unitand/or zone control unitusing Ethernet. Therefore, when the zone control unitrelays CAN frames from controllers and/or sensors-to central control unitand/or zone control unit, the zone control unithas to “translate” incoming CAN frames from-to outgoing Ethernet frames foror(and/or vice versa). Equivalently, other nodes translate incoming LIN frames to outgoing Ethernet frames (and/or vice versa). In some other approaches, this translation from CAN/LIN to Ethernet occurs solely in software running on a microprocessor within the zone control unit. As appreciated in some aspects of the present disclosure, a single CPU in a control unit is often not sufficient to process frames quickly enough to comply with data throughput requirements. For example, some single CPU approaches where software is used to implement Ethernet IEEE1722 have a latency of 15.1 microseconds (per CAN frame data of 64 bytes). Assuming the CPU operates at a clock cycle of 500 MHz, it can take 7550 clock cycles to process each frame, and the CPU becomes 100% utilized at 66,000 frames per second, and 70% utilized at 46,000 frame per second. Therefore, a single CPU core is insufficient for control units that translate between CAN or LIN frames and 1722 Ethernet frames in future vehicles. Consequently, some aspects of the present disclosure make use of local routing engine hardware and CAN/LIN to Ethernet frame generation channels arranged within the various control units to improve data processing in the vehicle. This local routing engine hardware and CAN/LIN to Ethernet frame generation channels translate between CAN or LIN frames and 1722 Ethernet frames. The local routing engine hardware and CAN/LIN to Ethernet frame generation channels could alternatively translate other protocols, such as FLEXRAY or I2C or even wireless, to Ethernet and/or other higher speed protocols, for example as per the IEEE 1722 standard.

2 FIG. 1 FIG. 200 202 202 200 204 206 204 200 212 202 204 206 212 214 214 214 212 216 shows a control unitthat includes local routing engine hardwarein accordance with some aspects of the present disclosure. In addition to the local routing engine hardware, the control unitincludes a central processing unit (CPU), and a Data Routing Engine (e.g., DRE+), which typically is a separate hardware circuit from the CPU. The control unit(which can manifest as any of the control units, controllers, and/or sensors of) includes a housing, such as a plastic and/or metal case, that encases the local routing engine hardware, CPU, and DRE+. The housingincludes openings for n serial communication ports, wherein n can be any positive integer number (e.g., n=1, 2, 3, . . . ). The serial communication portscan, for example, be bi-directional transmission and reception ports or uni-directional transmission or reception ports. In some examples, the serial communication portscan manifest as separate DE-9 connectors that have 9 pins for the male connectors and/or 9 receptacles for female connectors, but other standard connectors or even custom connectors can also be used. The housingalso includes openings for one or more bi-directional Ethernet ports.

202 210 1 210 210 1 210 206 208 210 1 210 208 208 216 208 200 216 214 214 218 214 218 220 n n n The local routing engine hardwareincludes n serial-port-frame-to-stream-ID-frame hardware channels-through-, respectively. Each serial-port-frame-to-stream-ID-frame hardware channel has hardware that converts frame(s) or message(s) received on a given serial port to a Stream ID frame(s). Thus, the serial-port-frame-to-stream-ID-frame hardware channels-through-can take disparate frames on the various serial ports (where the serial port frames on the respective serial ports can follow the same or different network protocol frame/message formats), and convert those disparate frames to a single Stream ID frame format. Within the DRE+, a Stream-ID-frame-to-Ethernet-frame-generation logicis instantiated as a hardware circuit. Upon receiving the various Stream ID frames from the channels-through-, the Stream-ID-frame-to-Ethernet-frame-generation logicthen translates the Stream ID frames into Ethernet frames having the same Stream ID frame format as one another. The Stream-ID-frame-to-Ethernet-frame-generation logicthen transmits the Ethernet frames over the Ethernet port. In some examples,can be implemented partially in software or firmware. The control unitcan also receive incoming Ethernet frames on the Ethernet ports, internally process those Ethernet frames, and then output out-going serial port frames to the serial communication portsin response to the Ethernet frames. In some cases, incoming frames of multiple serial ports onare transmitted as Ethernet packets on a single Ethernet port (e.g., see lineleading to upper Ethernet port). In other examples, however, incoming frames of multiple serial ports ofare transmitted as Ethernet packets on respective separate Ethernet ports (see lineand optional linetransmitting Ethernet packets via upper Ethernet port and optional lower Ethernet port, respectively).

200 214 216 202 In this way, the control unitcan provide interoperability between legacy serial port devices (which make use of serial communication ports) and modern high speed devices (which make use of Ethernet ports). In particular, the local routing engine hardwareaccelerates processing/translation from serial port frames (e.g., CAN and/or LIN) to Ethernet frames, to help ensure that high data rates are achievable for system developers.

200 100 200 202 204 206 208 210 202 204 206 208 210 202 204 206 208 210 212 200 200 1 FIG. In some examples, the control unitis included in a vehicle (e.g., vehicleof), but can also be included in industrial systems or other systems. In some examples, the control unitis a single standalone chip and,,,, andare on a single die, but in other examples components,,,, andare on multiple dies stacked over one another or arranged within a single integrated circuit package in the form of a so-called 3-dimensional IC. In still other examples,,,,, andmay be formed on multiple packaged chips and/or discrete components on a printed circuit board arranged within housing. A die may include a semiconductor substrate, such as a monocrystalline silicon substrate or a silicon on insulator substrate, but can also and/or alternatively include other semiconductor materials, such as gallium arsenide (GaAs), indium gallium arsenide (InGaAs), and germanium (Ge), among others. Further, the chip(s) can include transistors arranged to specifically carry out the functions of the control unit; and/or can be programmed with software or firmware instructions to carry out functions of the control unit.

3 FIG.A 200 202 303 1 303 214 202 210 1 210 306 1 306 302 1 302 305 1 305 308 310 n n n n n shows another example of a control unitthat includes local routing engine hardwarein accordance with some aspects of the present disclosure. In this example, control unit includes n serial communication port(s)-through-, respectively, on serial interface. The local routing engine hardwareincludes channels-through-coupled to the serial ports-through-, respectively. The channels include analog transceivers-through-, respectively, and n digital channels-through-, respectively. A filter tableand a routing tableare also present. Often, the serial ports, analog transceivers, and digital channels correspond to one another in one-to-one fashion, but in other embodiments, multiplexers can be included so that some of these elements are shared between one or more channels/etc.

214 306 1 306 306 306 j k n In the illustrated example, the serial ports of interfaceare subdivided to include a first integer number, j, of CAN ports (e.g.,-, . . . ,-), a second integer number, k, of LIN ports (e.g.,-), and a third integer number, I, of other serial ports, such as FlexRay or I2C (e.g.,-), wherein j, k, and I can each be any positive integer or can be zero. Further, any of j, k, and I can be equal to one another or different.

305 306 1 306 304 1 304 304 304 304 n j k n Each digital channelincludes a filter that corresponds to the type of port for the corresponding serial communication port (e.g.,-,respectively). For example, CAN acceptance filter(s) (e.g.,-through-) are coupled to the CAN ports, LIN acceptance filter(s) (e.g.,-) are coupled to the LIN port(s), and other acceptance filter(s) (e.g.,-) are coupled to the other port(s). The CAN acceptance filter(s) are often separate hardware circuits that correspond to the CAN ports in a one-to-one manner, and similarly LIN and/or other acceptance filter(s)are often separate hardware circuits that correspond to the LIN and/or other ports in a one-to-one manner.

306 1 306 304 1 304 208 306 304 208 j j k k CAN to Stream ID logic hardware circuits (e.g.,-to-) are coupled between each CAN acceptance filter (e.g.,-and-) and Stream-ID-frame-to-Ethernet-frame-generation logic, and LIN-to-Stream-ID logic hardware circuits (e.g.,-) are coupled between each LIN acceptance filter (e.g.,-) and Stream-ID-frame-to-Ethernet-frame-generation logic. For each different network protocol supported, the serial-port-to-stream-ID logic hardware circuits have specific logic to extract the stream ID from that particular protocol/message format.

210 1 210 210 210 j k n. In various examples, the CAN channels-through-can be substantially identical to one another in that they can have different addresses/channel numbers, but the same circuitry otherwise. Similarly, the LIN channels-can be substantially identical to one another in that they can have different addresses/channel numbers, but same circuitry otherwise; and the LIN channels differ from the CAN channels in that one operates using LIN while the other operates using CAN. The same is true of the other channels-

303 1 304 1 303 1 304 1 200 304 1 306 1 208 304 1 200 200 304 1 312 304 1 304 304 200 308 306 1 306 1 306 1 1722 310 306 1 208 208 208 200 k n For example, if the first communication port-is structured to communicate via CAN, then CAN acceptance filter-identifies whether signals/frames on the first serial communication port (CAN1)-are valid CAN signals. Further, the CAN acceptance filter-determines whether a CAN ID in each incoming CAN frame specifies that the incoming CAN frame is intended for a device that is logically linked to the control unit. The CAN acceptance filter-only passes the incoming CAN frame along to the CAN-to-Stream-ID logic circuit-and Stream-ID-frame-to-Ethernet-frame-generation logicwhen the CAN acceptance filter-determines that the CAN ID of the incoming CAN frame specifies a device that is logically linked to the control unit. Otherwise, when the CAN ID of the incoming CAN frame does not match with a device that is logically linked to control unit, then the CAN acceptance filter-disregards the incoming CAN frame and does not pass it to the CAN routing logic. Thus, the CAN acceptance filter-can act as a whitelisting circuit in some regards. The LIN acceptance filters-and other acceptance filters-operate in an analogous manner, albeit using different network protocol frame/message formats. For incoming CAN frames, the CAN ID of the CAN frame is linked to a CAN serial port, and the CAN Acceptance filter accepts only valid CAN IDs into the channel. So if the CAN ID is a valid CAN ID linked to the control unit(and thus listed in the Filter table), the CAN frame is forwarded to the CAN-to-Stream-ID logic-but otherwise the CAN frame is ignored and not passed to the CAN-to-Stream-ID logic-. The CAN-to-Stream-ID logic-then maps the CAN IDs toStream IDs (this is a specific bit-field in 1722 standard) using CAN IDs and Stream IDS stored in the routing table, which can be implemented as a lookup table. The CAN-to-Stream-ID logic circuit-, then forwards the Stream IDs, along with the corresponding payload data from the CAN frames to the Stream-ID-frame-to-Ethernet-frame-generation logic. The Stream-ID-frame-to-Ethernet-frame-generation logicthen maps the Stream IDs to Ethernet Ports and MAC Addresses. The Stream-ID-frame-to-Ethernet-frame-generation logicalso builds an Ethernet frame having the same payload data and MAC destination address that were present in the incoming CAN frame, and specifies a MAC address of the control unitas the MAC source address in this Ethernet frame. The MAC address is a static configuration per control unit in a specific scenario during runtime but the update of this bit-field can be done for every outgoing Ethernet frame. The configuration can be done by the manufacturer depending on his network/routing scenario in the vehicle, and the MAC addresses can be stored in another table on a higher level of abstraction programmed by the manufacturer.

204 200 204 The CPUof the control unitincludes a clock signal received via a clock tree that is distributed over CPUs of the system (e.g., over the vehicle). Through the clock tree, the CPUhas a clock that is synchronized with other control units in the system. The clock tree can cascade a clock signal, one level at a time, between pairs of directly connected control units, until the local clocks of all of the control units are synchronized. Pairs of directly connected control units have consistent delay times between them and so can synchronize their respective local clocks fairly precisely (e.g., within a few nanoseconds). The cascading synchronization of clocks may be performed in accordance with a precision time protocol (PTP) such as, for example, defined in the IEEE 1588 standard.

216 200 204 The Ethernet portsare configured to send and receive time-sensitive Ethernet frames, which comprises encapsulating payloads for transmission with a corresponding Ethernet header and decapsulating received payloads for processing by the appropriate module of the control unit. Thus, when incoming CAN frames arrive and are accepted, the CPUis notified of the incoming CAN frame and generates a timestamp based on its local clock, which is synchronized with other clocks of the system. The timestamp is then encapsulated in the outgoing Ethernet frame, along with the MAC source and destination address, and payload data.

310 310 310 The list of CAN IDs, Stream IDs, and corresponding source and destination MAC addresses in the routing tablecan be hard-coded into the routing table(e.g., by bits stored in read-only memory (ROM) programmed during manufacture), or can be programmed into the routing tableby blowing fuses, programming flash or other volatile or non-volatile memory, or other suitable programming techniques. The list of CAN IDs, Stream IDs, and MAC source and destination addresses can be programmed during the manufacturing, testing, or initialization of the control unit (e.g., at an original equipment manufacturer (OEM) or other suitable location), and/or can be programmed or read at boot up, another regular time interval, or based on an interrupt, timer, or sensor value triggering such an event.

202 206 214 216 202 Thus, because local routing engine hardwarein combination with the DRE+helps provide interoperability between legacy CAN and/or LIN devices (which make use of serial communication ports) and modern high speed devices (which make use of Ethernet ports), the local routing engine hardwareaccelerates processing/translation from CAN/LIN frames to Ethernet frames, to help ensure that high data rates are achievable for system developers.

3 FIG.B 3 FIG.A 3 FIG.B 200 304 200 310 304 1 306 1 310 304 306 200 k illustrates another example of a control unit. In this example, rather than a single/shared routing table (e.g.,in), the control unitofincludes separate filter tables and separate routing tables for each channel. The CAN routing table(s)include semiconductor memory that is coupled between the CAN acceptance filter-and CAN-to-Stream-ID logic-, and stores CAN IDs with corresponding Stream IDs. Similarly, the LIN routing table(s)include semiconductor memory that is coupled between the LIN acceptance filtersand LIN-to-Stream-ID logic-, and stores LIN IDs with corresponding Stream IDs. In examples where the control unitincludes multiple CAN channels, a single CAN routing table can alternatively be shared among those multiple CAN channels. Similarly in examples where the control unit includes multiple LIN channels, a single LIN routing table can alternatively be shared among those multiple LIN channels.

4 FIG. 4 FIG. 402 404 214 200 406 408 410 412 414 416 418 420 422 424 216 200 424 426 428 430 432 434 436 438 436 440 442 444 446 448 450 illustrates a more detailed example that depicts two example incoming CAN frames,received on a CAN port (CAN1)of control unit. Each CAN frame includes a start bit, followed by several identification (ID) bits(e.g., 11 ID bits or 29 ID bits), a remote request framed (RTR) bit, control (CNTRL) bits, data bits, cyclic redundancy check (CRC) bits, acknowledgement bits (ACK), end of frame bits, and Inter Frame Space (IFS) bits.also illustrates a more detailed example of an outgoing Ethernet frameprovided on an Ethernet portof control unit. The Ethernet frameincludes a pre-amble, MAC destination address, MAC source address, Virtual Local Area network (VLAN) tag, Ethernet type field, IEEE P1722 data stream, and CRC data field. The IEEE P1722 data streamincludes a header, stream ID, Audio/Visual Transport Protocol (AVTP) timestamp, gateway (GW) info, packet info, and payload data. In some examples, the Ethernet frame conforms to IEEE1722 AVTP control format (ACF), which is a frame format/protocol for Ethernet that provides capability of sending CAN frames over a time-sensitive, Audio Video Bridging (AVB) network.

402 404 452 454 During network operation, the CAN frames,are driven/generated by respective CAN devices (e.g., control units) that each send a respective CAN frame over a 2-wire serial bus that uses two differential wired-AND signals, CAN Hand CAN L. Each CAN device either drives CANH and CANL to a “dominant” state with CANH>CANL, or do not drive CANH and CANL such that passive resistors pull the 2-wire bus to a “recessive” state with CANH≤CANL. The dominant state represents a 0 data bit, while the recessive state represents a 1 data bit, which effectively gives CAN devices having lower ID numbers priority on the bus.

The exact voltages for a logical 0 or 1 depend on the physical layer used, but a basic principle of CAN is that each CAN device listens to the data on the CAN bus including the transmitting CAN device(s) itself (themselves). If a logical 1 is transmitted by all transmitting CAN devices at the same time, then a logical 1 is seen by all of the CAN devices, including both the transmitting CAN device(s) and receiving CAN device(s). If a logical 0 is transmitted by all transmitting CAN device(s) at the same time, then a logical 0 is seen by all CAN devices. If a logical 0 is being transmitted by one or more CAN devices, and a logical 1 is being transmitted by one or more CAN devices, then a logical 0 is seen by all CAN devices including the CAN device(s) transmitting the logical 1. When a CAN device transmits a logical 1 but sees a logical 0, it realizes that there is a contention and it quits transmitting. By using this process, any CAN device that transmits a logical 1, when another CAN device transmits a logical 0, loses the arbitration and drops out. A CAN device that loses arbitration re-queues its message for later transmission and the CAN frame bit-stream continues without error until only one CAN device is left transmitting.

4 FIG. 402 404 402 404 406 404 402 402 404 For example, in the illustrated 11-bit ID CAN network in, the first CAN frameis transmitted from a first CAN device with a CAN ID of 15 (binary representation, 00000001111) and the second frame CANis transmitted from a second CAN device with a CAN ID of 16 (binary representation, 00000010000). Assuming these two CAN devices start transmission of frames,at the same time, each will first transmit the start bitand then transmit the first six zeros of their ID (i.e., ID10-ID5) with no arbitration decision being made. When ID bit 4 is transmitted by both CAN devices, the second CAN framefrom the second CAN device transmits a 1 (recessive) for its ID, while the first CAN framefrom the first CAN device transmits a 0 (dominant) for its ID. When this happens, the second CAN device with the ID of 16 knows it transmitted a 1, but sees a 0 and realizes that there is a collision and it lost arbitration. Thus, the second CAN device stops transmitting, which allows the first CAN device with ID of 15 to continue its transmission of the remainder of framewithout any loss of data. Thus, the node with the lowest ID wins the arbitration and therefore has the highest priority. The second CAN device will re-queue the second CAN frameand transmit at a later time when the CAN bus is available.

200 304 200 423 425 310 427 427 414 208 424 424 430 424 200 424 444 402 200 204 450 414 402 208 200 200 200 3 4 FIG.- 3 4 FIGS.- 2 3 3 FIGS.,A,B 4 FIG. Thus, the control unitincludes circuitry to receive the CAN frames, and can map the CAN ID of a received, incoming CAN frame to a corresponding Stream ID stored in the routing table (e.g.,) of the control unit. Then, CAN-to-Stream-ID logic can build a Stream ID frame, which includes the Stream IDidentified in the routing tableas well as payload dataas in the incoming CAN frame (e.g.,is bitwise identical to). The Stream-ID-frame-to-Ethernet-frame-generation logiccan then build the outgoing Ethernet frame. The Ethernet frameincludes a Source addressin the Ethernet framespecifying the control unit. The Ethernet framealso includes the AVTP timestampwhich corresponds to a time stamp when the first CAN framewas received at the control unitaccording to the clock in the CPU (e.g.,), and the payloadof Ethernet frame is bitwise identical to the datain the incoming CAN frame. The Ethernet frame can also include the Stream ID corresponding to the incoming CAN frame. Thus, the CAN to Ethernet Frame generation channels (e.g.,of) can capsulize the data of the incoming CAN frame to the payload field of the outgoing Ethernet frame. For example, in the example of, the CAN ID is Node 15, and the CAN routing table links Node 15 to a MAC source address of 00:00:1a:00:53:af (which identifies the control unitand is here a 48-bit hexadecimal address, including six sets of two hexadecimal digits or characters, separated by colons). Although not shown, incoming Ethernet frames can also be “translated” to outgoing CAN frames. Thus, the control unitalso includes CAN arbitration logic to monitor the CAN bus, and determine when the Control Unit(and its CAN ID) can transmit CAN messages with priority on the CAN bus relative to other CAN devices.

5 FIG. 502 504 506 502 202 504 502 506 504 204 508 204 502 506 204 502 508 204 504 208 208 shows more details of another way in which a Serial-port-frame-to-Stream-ID-frame generation logic can be implemented in accordance with some aspects of the present disclosure. These components include an AVTP header and frame generation logic block, a stream buffer, and an Ethernet header and frame generation logic block. The AVTP header and frame generation logic blockhas an input coupled to an output of the local routing engine hardware, and the stream bufferhas an input coupled to an output of the AVTP header and frame generation logic block. The Ethernet header and frame generation logic blockhas an input coupled to an output of the stream buffer. These components are also coupled to CPUvia one or more busses. The CPUcan generate a trigger signal when AVTP frames are completed byand/or when Ethernet frames are completed by, and can manage device IDs such as MAC source addresses and MAC destination addresses. The CPUalso generates timestamps when CAN frames are received, and provides these timestamps to the AVTP header and frame generation logicvia busso the timestamps can be included in corresponding AVTP frames. The CPUalso sets timers, triggers filling and emptying of the stream buffer, and counts frames based on CAN IDs. Although details for only Stream-ID-frame-to-Ethernet-frame-generation logic channel 1/is illustrated, it will be appreciated that other channels generally have the same structure and functionality.

200 214 304 202 200 310 202 302 208 5 FIG. During operation of control unitin, CAN frames are received at the serial ports. An acceptance filterwithin the local routing engine hardwaredetermines whether each CAN frame is valid and intended for the control unit. This determination can be based on the CAN ID in the incoming CAN frame. If the incoming CAN frame has a CAN ID that is listed in the routing tablesof the local routing engine hardware, then the acceptance filterdetermines the CAN frame is valid and accepts the CAN frame. Therefore, the incoming CAN frame is routed to a suitable routing channel (e.g.,), where this routing can be based on the CAN ID and/or stream ID of the incoming CAN frame.

502 440 450 502 414 450 442 204 444 436 436 504 504 204 502 504 504 506 506 426 434 438 216 4 FIG. 4 FIG. Upon receiving the incoming CAN frame, AVTP header and frame generation logic blockgenerates an AVTP frame, including (fields-in). Thus, the AVTP header and frame generation logic blockidentifies dataand optionally stream ID in the incoming CAN frame, and uses those to generate payload dataand stream IDin the AVTP header and frame. The CPUcan provide the AVTP timestampfor the AVTP frame. This information for the AVTP frameis then loaded into the stream buffer, along with this information for other AVTP frames in time. The stream buffercan be a first-in-first-out (FIFO) memory, random access memory (RAM), or any other type of memory. The CPUcan monitor the AVTP header and frame generation logic blockand can trigger writes of the AVTP frames to the stream bufferwhen frames are complete/assembled/built. The CPU can also trigger writes of AVTP frames from the stream bufferto the Ethernet header and frame generation block. The Ethernet header and frame generation blocktakes the AVTP frames, and appends Ethernet frame fields (e.g., fields-in) and a CRCto generate Ethernet frames. These Ethernet frames are then transmitted via the Ethernet port.

6 FIG. 208 shows another example of a Stream-ID-frame-to-Ethernet-frame-generation logicin accordance with some aspects of the present disclosure. Although details for only one frame generation channel is described, it will be appreciated that other frame generation channels can have the same structure and functionality.

6 FIG. 208 602 214 202 214 604 604 604 604 In, the Stream-ID-frame-to-Ethernet-frame-generation logicincludes input and/or output FIFOs or other memories. Typically, there is an input FIFO having an input coupled to serial portvia the local routing engine hardware, and a separate output FIFO having an output coupled to serial port. The output of the input FIFO in this example is coupled to ACF engine mapper hardware, which examines the header information of the AVTP header and generates portions of the Ethernet header and/or Ethernet frame based on the ACF information. Although the ACF engine mapper hardwareis illustrated as one logic block, the ACF engine mapper hardware is typically instantiated as separate ACF engine mappers in the respective channels. Thus, each channel typically has its own ACF engine mapper, such that the ACF engine mappers operate in parallel with the channels. For example, the ACF engine mapper hardwarecan include logic to generate a number of different pre-determined frame formats for incoming FlexRay frames, CAN frames, LIN frames, sensor frames, parallel data frames, serial data frames, and others. Then, the ACF engine mapper hardwarecan build Ethernet frames based on those different frame format types. Because hardware in the ACF engine mapper is configured to generate frame templates for the various frame types, the ACF engine mapper hardware represents an efficient way for a control unit to include multiple different serials ports, and easily and efficiently translate different frame formats received on those various ports to Ethernet frames.

606 606 202 206 14 Further, although much of the above description describes how incoming CAN/LIN/other frames are translated to outgoing Ethernet frames, the other way around is also possible (e.g., Ethernet to CAN/LIN/other). Therefore, to allow for this, the DRE+ includes routing and filtering tablessuch that the DRE+ can map incoming Ethernet frames to outgoing CAN/LIN/other frames. Thus, in this other direction, the incoming Ethernet frame is broken down into CAN or LIN frames, which are filtered within the DRE+ and routed to the corresponding destination CAN or LIN nodes with the help of routing and filtering tables. Consequently, both the Local routing engine hardwareand DRE+have their own separate filter table and routing table.. Thus, DRE+ includes an Ethernet acceptance filter, an Ethernet routing table, and an Ethernet-frame-to-Stream-ID-frame circuit as well as a Stream-ID-frame-to-CAN-frame circuit. The Ethernet acceptance filter has an input coupled to the Ethernet interface. The Ethernet routing table has an input coupled to an output of the Ethernet acceptance filter and an output coupled to the CAN interface. The routing table stores a first plurality of Ethernet IDs and a second plurality of Stream IDs, respectively. These acceptance filters, routing tables, Ethernet-frame-to-Stream-ID-frame circuit and Stream-ID-frame-to-CAN-frame circuits can be implemented as separate channels arranged in parallel with one another.

7 FIG. 700 illustrates a methodin accordance with some examples of the present disclosure. The ordering of the acts/steps of this method can be interchanged in other examples. In addition, in some cases, one or more illustrated acts/steps can be omitted, and/or can be subdivided into multiple acts/steps, and/or additional acts/steps that are not shown can also be included.

702 At, a first frame is received. The first frame has a first network protocol format, and is received over a first serial port of a network device. For example, the first frame can be a CAN frame received over a CAN port.

704 704 306 1 306 j 3 FIG.A At, a first hardware circuit of the network device is used to convert the first frame to a first frame having a Stream identifier (ID) format. For example, in some examples, act/stepcan be carried out by the CAN-to-Stream-ID circuits-to-of.

706 At, a second frame is received. The second frame has a second network protocol format, and is received over a second serial port of the network device. The second network protocol format is different from the first network protocol format. For example, the first frame can be a LIN frame received over a LIN port.

708 708 306 k 3 FIG.A At, a second hardware circuit of the network device is used to convert the second frame to a second frame having the Stream ID format. For example, in some examples, act/stepcan be carried out by the LIN-to-Stream-ID circuits-of. The second hardware circuit can be arranged in parallel with the first hardware circuit.

710 710 208 3 FIG.A At, a third hardware circuit is used to convert the first frame having the Stream ID format and the second frame having the Stream ID format to Ethernet frames. For example, in some examples, act/stepcan be carried out by the Stream-ID-frame-to-Ethernet-frame generation logicof. In some examples, the first network protocol format and the second network protocol format are selected from a group consisting of: Control Area Network (CAN), Local Interconnect Network (LIN), FlexRay, or I2C.

8 FIG. 800 illustrates another methodin accordance with some examples of the present disclosure. The ordering of the acts/steps of this method can be interchanged in other examples. In addition, in some cases, one or more illustrated acts/steps can be omitted, and/or can be subdivided into multiple acts/steps, and/or additional acts/steps that are not shown can also be included.

802 At, an Ethernet frame is received over an Ethernet port of a network device.

804 At, a first hardware circuit of the network device is used to perform Stream ID filtering on the Ethernet frame. Thus, the Steam ID of the Ethernet frame is identified in the Ethernet packet, and the Stream ID selects a routing table to be used for the frame.

806 At, the method breaks down the Ethernet frame and builds the data fields of the Ethernet frame into a CAN, LIN, or other serial frame.

808 At, the method performs CAN, LIN, or other serial filtering based on the Stream ID of the Ethernet frame and/or corresponding CAN, LIN, or other serial frame.

810 At, the method uses a Routing rule look-up to set the destination of the CAN, LIN, or other serial frame to the appropriate serial port of the device based on the Stream ID. Thus, the CAN, LIN, or other serial frame is routed to the appropriate destination device using the appropriate serial port.

While the disclosed subject matter has been described in connection with various embodiments and corresponding Figures, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims below. The above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.

As used in this application, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or”. That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B; or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description and the claims, such terms are intended to be inclusive in a manner similar to the term “comprising”.