Hardware-based Ethernet audio and video bridging (EAVB) packet scheduling

Abstract

Various embodiments include an automotive network device that includes a descriptor ordering engine (DSE). The DSE may include: a direct memory access (DMA) controller; a memory organized by channel clusters, each channel cluster comprising a plurality of first-in first-out (FIFO) memories; a timer; and a timestamp (TS) ordering logic component. The DMA controller may be configured to: pull a timestamp-pointer from a packet descriptor stored in an unordered descriptor ring memory; the timestamp is stored in the FIFO memory in a one-to-one correspondence manner; triggering the TS sorting logic component to resort the timestamp-pointer pairs in the FIFO memory, so that the timestamp-pointer pairs are sorted in an ascending order; reading the packet descriptors stored in an unordered descriptor ring memory using the ordered timestamp-pointer in the FIFO memory; and storing the packet descriptors in an ordered descriptor ring memory.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 937,495, filed on October 3, 2022; the entire contents of which are incorporated herein by reference. Background Art

[0003] Over the past few years, modern automobiles have transformed from self-propelled mechanical vehicles to powerful and complex electromechanical systems that include a large number of electronic components, including multiple electronic displays, microphones, speakers, sensors, control units, processors, and systems on chips (SOCs) that enable or control many of the functions, features, and operations of the vehicle.

[0004] Currently, automobile manufacturers use a variety of different types of cables and connections to connect their electronic components to each other (e.g., coaxial cables, shielded cables, simple audio cables, high-definition multimedia interface cables, Ethernet cables, etc.) In recent years, automobile manufacturers have begun to include Ethernet switches in their vehicles and are now moving towards replacing all of the different cable and connection types with Ethernet. Summary of the invention

[0005] Various aspects include a hardware-based Ethernet Audio and Video Bridging (EAVB) packet / descriptor sorting component configured to: streamline streaming and delivery of packets according to a generalized precision time protocol (gPTP) time embedded in an eAVB packet. Various aspects may include an automotive network device that includes a descriptor sorting engine (DSE). The DSE engine may include: a memory organized by channel clusters, each channel cluster including a first-in-first-out (FIFO) memory; a timestamp (TS) sorting logic component; and a direct memory access (DMA) controller coupled to the memory, the TS sorting logic component. The DMA controller may be configured to: pull a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory; trigger the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; and store the packet descriptors in a sorted descriptor ring memory.

[0006] Some aspects may also include an Ethernet media access controller (EMAC) coupled to the DMA controller, wherein the DMA controller may be further configured to: store the timestamp-pointer pairs in a FIFO memory; use the ordered timestamp-pointer pairs in the FIFO memory to read the packet descriptors stored in the unordered descriptor ring memory; and trigger the EMAC to stream data from the ordered descriptor ring memory. Some aspects may also include a processor configured to: in response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), call the DSE to order the data packets.

[0007] In some aspects, the EMAC includes dedicated descriptor ring scanner (DRS) hardware, and the network device also includes a processor configured to: in response to determining that there is an opportunity to modify the EMAC Internet Protocol (EMAC IP), invoke the DRS hardware. In some aspects, invoking the DRS hardware can cause the DRS hardware to: extract the descriptor header pointed to by the descriptor ring buffer read index; compare the timestamp embedded in the descriptor header with the current time to determine whether the timestamp has passed; in response to determining that the timestamp is in the past, trigger the DMA controller of the current descriptor to pass the packet on the network; and increment the descriptor ring buffer read index.

[0008] In some aspects, the data stored in the descriptor ring memory of the order may be audio data. In some aspects, the data stored in the descriptor ring memory of the order may include video data. In some aspects, the data stored in the descriptor ring memory of the order is time-critical network data.

[0009] Further aspects may include a method performed by one or more processors of an automotive network device, the method comprising: pulling a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory; storing the timestamp-pointer pair in a FIFO memory; triggering a TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; using the sorted timestamp-pointer pairs in the FIFO memory to read the packet descriptors stored in the unsorted descriptor ring memory; and storing the packet descriptors in a sorted descriptor ring memory.

[0010] Some aspects may also include triggering an Ethernet media access controller (EMAC) to stream data from the ordered descriptor ring. Some aspects may also include invoking ordering of data packets in response to determining that there is no opportunity to modify an EMAC Internet Protocol (EMACIP).

[0011] Some aspects may also include: in response to determining that there is an opportunity to modify the EMAC Internet Protocol (EMAC IP), calling dedicated descriptor ring scanner (DRS) hardware. Some aspects may also include DRS hardware, which includes: extracting a descriptor header pointed to by a descriptor ring buffer read index; comparing a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; in response to determining that the timestamp is in the past, triggering a direct memory access (DMA) controller of the current descriptor to pass a packet on the network; and incrementing the descriptor ring buffer read index.

[0012] In some aspects, the data stored in the descriptor ring memory of the order may be audio data. In some aspects, the data stored in the descriptor ring memory of the order may include video data. In some aspects, the data stored in the descriptor ring memory of the order may be time-critical network data.

[0013] A further aspect may include an automotive network device having means for performing the functionality of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description given above and the detailed description given below, serve to explain features of the claims.

[0015] Figure 1A and Figure 1B is a block diagram illustrating components of a vehicle suitable for implementing various embodiments.

[0016] Figure 1C is a component diagram of an example vehicle system suitable for implementing various embodiments.

[0017] Figure 2 is a component block diagram illustrating various data flows through components that may be included in a vehicle and / or suitable for implementing various embodiments.

[0018] Figure 3 is a component block diagram illustrating components in a computing system that may be included in a vehicle and configured to manage different types of data flows according to some embodiments.

[0019] FIG. 4A to FIG. 4C is a timing diagram illustrating an example of packet streaming according to some embodiments.

[0020] Figure 5A is a component block diagram illustrating a software-based interleaving solution for communicating packets.

[0021] Figure 5B is a component block diagram illustrating a hardware-based interleaving solution according to an embodiment.

[0022] Fig. 6A is a component block diagram illustrating a hardware-based descriptor sorting engine (DSC) system that may be configured to sort and synchronize packets according to some embodiments.

[0023] Figure 6B is a component block diagram illustrating a system including dedicated descriptor ring scanner (DRS) hardware according to some embodiments.

[0024] Figures 7 to 9 is a timing diagram illustrating the progression of packets from different flows in a system implementing various embodiments.

[0025] Figures 10 to 13 is a process flow diagram illustrating a method of operating a hardware-based packet ordering engine according to various embodiments.

[0026] Fig.14 is a component block diagram illustrating a vehicle display unit according to some embodiments. DETAILED DESCRIPTION

[0027] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and specific implementations are for illustrative purposes and are not intended to limit the scope of protection of the claims.

[0028] In general, various embodiments include hardware-based Ethernet Audio and Video Bridging (EAVB) packet / descriptor sorting components that are configured to streamline streaming and delivery of packets according to the generalized precision time protocol (gPTP) time embedded in the eAVB packets. In some embodiments, these components may include a dedicated descriptor sorting engine (DSE) that is located outside the Ethernet media access controller (EMAC) and is suitable for use when there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), such as when the EMAC IP is licensed from a third party. Some embodiments may also include dedicated descriptor ring scanner (DRS) hardware inside the EMAC, which is suitable for use when there is an opportunity to modify the EMAC hardware IP return to zero (RZ). That is, the embodiments may use a DRS for hardware-based eAVB packet / descriptor sorting to streamline streaming and delivery of packets according to the gPTP time embedded in the eAVB packets.

[0029] In some embodiments, the DSE may include: a direct memory access (DMA) controller; a memory organized by channel clusters, each channel cluster including a plurality of first-in-first-out (FIFO) memories; a timer; and a timestamp (TS) sorting logic component. The DMA controller may be configured to: pull a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory; store the timestamp-pointer pair in the FIFO memory; and trigger the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; the DMA controller may use the sorted timestamp-pointer pairs in the FIFO memory to read a complete packet descriptor stored in an unsorted descriptor ring memory, store the complete packet descriptor in sorted order in a sorted descriptor ring memory, and trigger the EMAC to transfer data from the sorted descriptor ring memory.

[0030] Various embodiments overcome many limitations of conventional solutions for using Ethernet audio and video bridging (EAVB) systems to communicate data to improve audio-video playback. For example, various embodiments can reduce or eliminate gaps, lags, delays, etc. Audio-video playback. In addition, various embodiments can reduce latency, processing workload, and power consumption on computing devices and systems on a chip (SoC). Therefore, various embodiments can be implemented in current and future automotive applications, which may include SOCs that include or implement in-vehicle infotainment (IVI) systems, advanced driver assistance systems (ADAS), and / or modem telematics systems for vehicles. For all these reasons, various embodiments can improve the safety and reliability of vehicles. Additional enhancements, improvements, and benefits will be apparent from the disclosure below.

[0031] The terms "component", "module", "system", etc. may be used herein to refer to computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software being executed, which are configured to perform specific operations or functions. For example, a component may be, but not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and / or a computer running on a processor. By way of example, both an application running on a computing device and a computing device may be referred to as a component. One or more components may reside within a process and / or an execution thread, and a component may be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components may be executed from various non-transient computer-readable media having various instructions and / or data structures stored thereon. Components may communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process-related communication methods.

[0032] The term "system on chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources and / or processors integrated on a single substrate. A single SOC may include circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general and / or specialized processors (digital signal processors, modem processors, video processors, etc.), storage blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.

[0033] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication and sharing of memory and resources.

[0034] The term "multi-core processor" may be used herein to refer to a single integrated circuit (IC) chip or chip package that contains two or more independent processing cores (e.g., central processing unit (CPU) cores, Internet protocol (IP) cores, graphics processor unit (GPU) cores, etc.) configured to read and execute program instructions. A SOC may include multiple multi-core processors, and each processor in the SOC may be referred to as a core.

[0035] Traditionally, automobile manufacturers use a variety of different types of cables and connections (e.g., coaxial cables, shielded cables, simple audio cables, high-definition multimedia interface cables, MOTS cables, Ethernet cables, etc.) to connect their electronic components to each other. In recent years, automobile manufacturers have begun to include Ethernet switches in their vehicles, and are now moving towards replacing all the different cable and connection types with Ethernet. As a result, all components in a vehicle (e.g., speakers, microphones, displays, etc.) can soon be connected to each other via the same Ethernet. While this configuration has many benefits, there are also some technical challenges related to timing, synchronization, latency, performance, and / or power consumption, especially for audio-visual (AV) components.

[0036] AV data communications typically have low latency tolerance and / or high delivery / accuracy assurance requirements. For example, because users can be highly aware of short delays or gaps (even in milliseconds) in audio or video streams. Users can also be highly aware of any differences between two or more corresponding signals (e.g., between audio signals transmitted to different speakers in a vehicle, between audio signals output from a speaker and their corresponding videos presented on a display, etc.). Therefore, it is important for the computing system and / or Ethernet network of the vehicle to accurately synchronize different streams from different components and reduce or minimize packet losses (discarded packets, etc.).

[0037] It is also important for vehicles to support and comply with various standards such as IEEE 1722 for Audio-Video Transport Protocol (AVTP), IEEE 802.1AS for Generalized Precision Time Protocol (gPTP), IEEE 802.1Qav for Forwarding and Queuing of Time-critical Streams (FQTSS), and IEEE 802.1Qat for Stream Reservation Protocol (SRP). Compliance with such standards ensures compatibility between multi-vendor EAVB devices in automotive systems across its various systems and subsystems, such as in-vehicle infotainment (IVI) systems, advanced driver assistance systems (ADAS), and modem telematics systems.

[0038] The Audio-Video Transport Protocol (AVTP) defines a variety of formats for audio and video, including AVTP Audio Format (AAF), MPEG2-TS, H.264, and Motion JPEG (MJPEG). The MPEG2-TS format can be used to transmit combined audio and video streams. Since there are usually multiple independent audio and video components in a vehicle (for example, speakers are separated from displays, microphones are separated from cameras, etc.), audio and video can also be transmitted in separate streams. The AAF format can be used to transmit the audio stream as pulse code modulation (PCM) data (rather than compressed data). The video stream can use H.264 or MJPEG format.

[0039] As described above, the audio and video components may be separate and / or independent of each other, and the audio may be transmitted in a separate stream from the video. In addition, modern vehicles may have 5.1 or 12.1 speakers, multiple microphones (e.g., one for the driver's seat, one for the passenger seat, etc.), multiple displays, etc. Each component may operate its own local audio-video card, and there may be jitter between their respective clocks.

[0040] For all these reasons, synchronization is an important aspect of delivering audio and video as separate streams (eg, using AAF, H.264 or MJPEG formats).The above protocol supports synchronization of all audio and video codecs inside the vehicle, which can be aligned or synchronized via timestamps.

[0041] gPTP supports time synchronization of all components in a vehicle connected via Ethernet. For example, each speaker, microphone, and display can operate with the same wall clock time, periodically synchronizing their clocks to match their time across the system (typically the entire network). One node is designated as the gPTP master node, and all nodes act as slave nodes and attempt to synchronize with the gPTP master node.

[0042] FQTSS supports forwarding key technology that allows the delivery of packets. SRP ensures that guaranteed bandwidth is reserved for audio and video streams in the network. For example, when there are multiple switches and bridges and end nodes (e.g., SOCs, etc.) are transmitting data, SRP can notify switches and bridges that specific streams require specific bandwidth guarantees.

[0043] Various embodiments can be implemented in various host vehicles. Figure 1A and Figure 1B An example vehicle 100 of these host vehicles is illustrated in FIG. Figure 1A and Figure 1B , the vehicle 100 may include a plurality of sensors 102-116 disposed in or on the vehicle for various purposes. Each of the sensors 102-116 may communicate with a control unit 140 and with each other in wired or wireless communication. The control unit 140 may be coupled to any of all of the sensors 102-116 and to other components and subsystems within the vehicle 100 via an Ethernet switch 118.

[0044] Sensors 102-116 may include speakers 102-108, microphones 110, 112, and cameras 114, 116 or other optical sensors or photographic optical sensors. Sensors 102-116 disposed in or on a vehicle may be used for various purposes, such as driver assistance, navigation, control, collision avoidance, location determination, etc., and sensor data about objects and people in or on the vehicle 100 may be provided. In some embodiments, the vehicle may include one or more of a variety of sensors capable of detecting various information useful for navigation, collision avoidance, and general vehicle operation. Examples of such sensors include impact sensors, range sensors, IR sensors, ultrasonic sensors, proximity sensors, occupancy sensors, tire pressure sensors, humidity sensors, temperature sensors, control input sensors, satellite geolocation system receivers, accelerometers, vibration sensors, gyroscopes, gravity meters, dynamometers, strain gauges, strain sensors, and fuel gauge sensors.

[0045] Figure 1C is a component block diagram of a system illustrating components and supporting systems suitable for implementing various embodiments. Figure 1A , Figure 1B and Figure 1C , the vehicle 100 may include onboard equipment, such as a control unit 140, which includes a processor 142, a memory 144, a radio module 146, an input module 148, and an output module 150. The control unit 140 may include, control, access, and / or communicate with various other systems and subsystems in the vehicle 100, such as an onboard network 160, an infotainment system 162, a navigation unit 164, and an actuator 166.

[0046] Although the control unit 140 is described as including separate components, in some embodiments, some or all of the components (e.g., the processor 142, the memory 144, the radio module 146, etc.) may be integrated into a single device or module (such as a system-on-chip (SOC) processing device). Such an SOC processing device may be configured for use in a vehicle and configured (such as configured with processor-executable instructions executed in the processor 142) to perform the operations of the various embodiments when installed in a host vehicle.

[0047] The processor 142 may be configured with processor-executable instructions to perform various embodiments using data and information received from various components and sensors of the vehicle 100, such as speakers 102-108, microphones 110, 112, cameras 114, 116, and / or an in-vehicle entertainment system, etc. In addition, the processor 142 may be configured to control steering, navigation, and other operations of the host vehicle 100. For example, in some embodiments, the processor 142 may be configured to implement safety and driver assistance features of the vehicle.

[0048] The radio module 146 may be configured for wireless communication. The radio module 146 may exchange signals (e.g., command signals for controlling maneuvers, signals from navigational aids, etc.) with the network transceiver 152, and may provide the signals to the processor 142 and / or the navigation unit 164. In some embodiments, the radio module 146 may enable the vehicle 100 to communicate with another vehicle 101 or a wireless communication device via a two-way or one-way communication link.

[0049] The input module 148 may receive sensor data from one or more vehicle sensors 102-116 and electronic signals from other components, including driving control components and navigation components. The output module 150 may be used to communicate with or activate various components of the host vehicle 100, including the driving control components, navigation components, and sensors 102-116. In addition, the output module 150 may be configured to control sensors and onboard displays.

[0050] In some embodiments, the control unit 140 may be coupled to a drive control assembly to control physical elements of the host vehicle 100 related to the handling and navigation of the host vehicle, such as an engine, motor, throttle, steering elements, braking or retarding elements, etc. The drive control assembly may also include components for controlling other equipment of the host vehicle, including speakers, interior and / or exterior information displays (which may include display screens or other devices for displaying information), environmental controls (e.g., air conditioning and heating), exterior and / or interior lighting, and other similar components or subsystems.

[0051] The control unit 140 may receive and use data from the navigation component to determine the current position and orientation of the host vehicle 100, as well as an appropriate route to the destination. The processor 142 may control the vehicle 100 for navigation and maneuvering by controlling the driving control elements. The processor 142 and / or the navigation component may be configured to communicate with a server on a network (e.g., the Internet) using a wireless connection to a cellular data network to receive commands for controlling maneuvers, receiving data useful in navigation, providing real-time position reports, and evaluating other data.

[0052] Examples of vehicle networks 160 include controller area networks (CAN), local interconnect networks (LIN), networks using the FlexRay protocol, media oriented systems transport (MOST) networks, and automotive Ethernet networks. Examples of vehicle actuators 166 include various physical control systems such as for steering, braking, engine operation, lights, direction signals, etc.

[0053] Figure 2 is a component block diagram illustrating various data flows through components that may be included in a vehicle and / or suitable for implementing various embodiments. Figures 1A to 2 , the vehicle may include a head unit 202, a modem telematics system 204, a plurality of Ethernet microphones 206, and a plurality of Ethernet speakers 208, any or all of which may be coupled to each other via an Ethernet switch 118. The head unit 202 may be, may include, may be included in, and / or may implement an in-vehicle infotainment (IVI) system and / or an advanced driver assistance system (ADAS).

[0054] The head unit 202 and the modem telematics system 204 may each include similar components as illustrated. For example, the head unit 202 may include a microphone 207a, a speaker 209a, a digital signal processor (DSP) 210a, a digital-to-analog converter (DAC) and an analog-to-digital converter (ADC) 212a, and a SOC 214a including an application component 216a, an audio and video bridging (AVB) component 218a, an Ethernet driver 220a, an upsampler 222a, and an audio prompt 224a. Similarly, the modem telematics system 204 may include a microphone 207b, a speaker 209b, a DSP 210b, a DAC and an ADC 212b, and a SOC 214b including an application component 216b, an AVB component 218b, an Ethernet driver 220b, an upsampler 222b, and an audio prompt 224b. In some embodiments, the modem telematics system 204 and / or the SOC 214b may be a mobile station modem (MSM) including an integrated cellular modem (in Figure 2 (not shown separately). Figure 2 In the example illustrated in , the modem telematics system 204 also includes an antenna 205 , the DSP 210 b includes a sample rate conversion (SRC) 240 component, and the application component 216 b includes a channel interleaving component 242 .

[0055] The application components 216a, 216b may include one or more Advanced Linux Sound Architecture (ALSA) interface components 226a, 226b, 226c, 226d. The AVB components 218a, 218b may include Ethernet AVB (eAVB) Audio-Video Transport Protocol (AVTP) libraries 230a, 230b, stream reservation protocol (SRP) components 232a, 232b, generalized precision time protocol (gPTP) components 234a, 234b, and media clock recovery and synchronization components 236a, 236b.

[0056] Figure 3 is a component block diagram illustrating components of a computing system 300 that may be included in a vehicle and configured to manage different types of data flows according to some embodiments. Figures 1A to 3 , the computing system 300 may include a SOC 302 (with an embedded operating system), a serial peripheral interface (SPI) hardware driver 304, a digital data stream interface hardware driver 306 (e.g., an integrated inter-IC sound bus (I2S) or a time division multiplexer (TDM)), an I2C hardware driver 308, a peripheral component interconnect (PCI) hardware driver 310, an Ethernet AVB driver 310, a port / buffer handler 312, a traffic shaping 314 component, a time correction 316 component, an error handler 318 component, a device dependency driver 320, an Ethernet AVB software 322 component, a framework application programming interface (API) library 324 component, an AVTP 326 component, a mapping 328 component, a gPTP 330 component, an SPR 332 component, a FQTSS 334 component, a TCP / IP stack 336 component, an IP application 338 component, a user application (EAVB camera, microphone, etc.) component 340, a media player application 342, an IO-audio API 344, a video framework API 346, display framework API 348, IO-audio 350 component, audio driver 352, I2S hardware driver 354, low power audio subsystem (LPASS) 356, video accelerator hardware 358, video hardware driver 360, video driver 362, OpenMax video component 364, mobile development platform (MDP) component 366, display hardware driver 368 and OpenMax / display interface 370.

[0057] In some embodiments, the Ethernet AVB driver 310 and the Ethernet AVB software component 322 may be modified or configured using processor executable instructions to support hardware and / or implement various features of the embodiments. Although not shown separately, the computing system 300 may also include various centralized processing units (CPUs), digital signal processors (DSPs), network processing units (NPUs), neural network signal processors (NSPs), dedicated hardware accelerators, SoC infrastructure cores, etc., which are configured to implement various embodiments.

[0058] AV data communications typically have low latency tolerance and / or high delivery / accuracy guarantee requirements. To meet these requirements, the IEEE protocol defines various categories of automotive packets. Most time-critical applications use Class A streaming, which includes eight thousand (8000) packets transmitted per second at a delivery interval of 125 microseconds (usec). Low-priority streaming tasks can use Class B streaming, which includes four thousand (4000) packets transmitted per second at a delivery interval of 250 microseconds.

[0059] FIG. 4A to FIG. 4C is a timing diagram illustrating an example of Type A streaming according to some embodiments. Figure 5A A software-based interleaving solution for communicating packets is illustrated, which includes applications 502a - 502n , data buffers 504a - 504n , a software stream interleaving 506 component, and an EMAC descriptor buffer 508 configured to communicate packets 510 . Figure 5B A hardware-based interleaving solution is illustrated that includes multi-stream interleaving hardware 550 including an EMAC descriptor buffer 508 .

[0060] refer to Figures 1A to 5B , streaming eight thousand (8000) packets per second (for Class A) requires a 125 microsecond gap between each of the packets. To achieve such a stream, the software thread would need to wake up every 1.5 microseconds to transmit eight (8) packets. However, waking up the software at every 1.5 microsecond interval is a technically challenging task that may consume a large amount of device limited resources (e.g., processing resources, etc.).

[0061] exist Figure 4A In the illustrated example, the software wakes up every one (1) millisecond, creates eight (8) packets, adds a timestamp to the packets, and transmits the packets to the EMAC hardware. The EMAC hardware may schedule so that there is a 125 microsecond gap between each of the packets. For example, the EMAC hardware may receive a packet, wait until the current time exceeds the timestamp time (i.e., the wait time becomes the current time), and begin transmitting the packet in response to determining that the current time exceeds the timestamp time.

[0062] Figure 4B and Figure 4C Demonstrates the use of Figure 5B Some challenges of implementing Type A streaming using the software-based interleaving solution exemplified in Figure 4B illustrates the challenges of implementing Type A streaming for a single stream, and Figure 4C The challenges of implementing Class A streaming for multiple flows are illustrated. In both cases, the software schedule is not highly accurate, and there are delays that may prevent all packets that should be transmitted in an interval from being transmitted in that interval. In practice, the software does not wake up exactly every one (1) millisecond interval, which causes delays that may result in missed intervals 404. The EMAC descriptor buffer 508 may attempt to compensate for the delay so that all packets are transmitted in the correct interval. This may result in prioritizing some packets (by transmitting them in bursts, such as Figure 4B 403), and other packets are transmitted in equal increments. Further, each subsequent scheduling delay may add further delay, resulting in missed intervals 404. In addition, the delays may cause the system to experience intervals 406 including random packet rates, where packets are transmitted at random intervals (e.g., some packets are transmitted in bursts while others are not). The random packet rate 406 may cause packets to not be synchronized across flows and / or packets to not arrive at their destination within the required time.

[0063] refer to Figures 1A to 5B , software threads (applications 502a-n) fill descriptors at independent times. EMAC descriptor buffers 508 are filled back-to-back, and the timing of packets 510 is unordered, unaligned (i.e., received out of order), and / or unsynchronized across flows. A timestamp is placed in each packet descriptor, but packets are not ordered by timestamp. This can lead to various problems on Ethernet networks, including dropped packets and / or unsynchronized flows.

[0064] Fig. 6A A hardware-based system is illustrated that can be configured to sequence and synchronize packets to overcome the challenges of implementing Class A streaming over Ethernet in an automobile, according to some embodiments. It should be understood that Fig. 6A The system illustrated in is scalable hardware and may include multiple sequencing engines to support multiple channels, multiple streams, and multiple different stream categories simultaneously. For the sake of brevity and focusing the discussion on the most relevant details, Fig. 6A The examples illustrated in include hardware for processing both Class A and Class B streams, and the examples below describe processing Class A streams. However, nothing in this application should be used to limit the claims to processing Class A streams.

[0065] refer to Figures 1A to 6A, the hardware-based system includes a CPU 602 component, an EMAC 604 component, a system memory 606, a network on chip (NOC) 608, a descriptor sorting engine (DSE) 610 component, and a time stamp counter (TSC) and time of day (TOD) clock 612 component.

[0066] The CPU 602 components may include an EAVB software stack 614. The EMAC 604 includes various channel direct memory access (DMA) components 616a, 616b. The system memory 606 may include an unordered Class A descriptor ring memory 620, an ordered Class A descriptor ring memory 622, an unordered Class B descriptor ring memory 624, and an ordered Class B descriptor ring memory 626. The DSE 610 components include a DMA controller 630, channel clusters 632a, 632b (each including a first-in-first-out (FIFO) memory 634a-634n for each channel or stream), timers 636a, 636b, and time stamp (TS) ordering logic components 638a, 638b.

[0067] In general, for a multi-stream scenario, each application or eAVB software thread submits multiple packets (example: 8 audio packets equivalent to 1 millisecond duration) to the eMAC driver, which can then write the packets and eMAC descriptors to the unordered Class A descriptor ring memory 620. These descriptors are unordered because they come from different threads that are not time-aligned. The packet descriptor may include a timestamp that indicates the time or time sequence in which the packet should be presented. By reordering packets received out of order (i.e., not time-aligned) based on the timestamp value, the packets can be processed according to the streaming sequence. In general, the DMA controller 630 can be configured to read and write to each block in the system memory 606. The DMA controller 630 can pull the timestamp from the packet descriptor in the unordered Class A descriptor ring memory 620 and store the timestamp in combination with a pointer to the descriptor memory location in the FIFO memory 634a-634n, which stores the descriptor including the timestamp. That is, the DMA controller 630 may pull the timestamp-pointer pair from the packet descriptor stored in the unsorted descriptor ring memory. The TS sorting logic 638a-638b component may reorder the timestamps and associated pointers so that the timestamp-pointer pairs are sorted in ascending order based on the timestamp values ​​within a short (e.g., 1 millisecond, etc.) time period. The TS sorting logic 638a-638b component may then trigger the DMA controller 630 to retrieve the complete packet descriptor using the sorted pointers and store it in the sorted Class A descriptor ring memory 622 in sorted order. The sorted Class A descriptor ring buffer 622 may be a small memory buffer suitable for storing data for only one millisecond (or 2, 4, 8 milliseconds, etc. for other classes). The DMA controller 630 may then trigger the channel DMA 616a, 616b to read the data from the sorted Class A descriptor ring memory 622 and transmit the data via the Ethernet network.

[0068] The TSC counter 612 may synchronize the timers 636a-636b with the network clock and / or to the TOD. The EAVB software stack 322 may configure the timers 636a, 636b and periodically trigger the TS sorting logic 638a-638b just before each millisecond time slot. The EAVB software stack 322 may determine the time window by determining the amount of time remaining (e.g., 50 microseconds, etc.) before the sorting is complete so that the sorted descriptors are available in the sorted Class A descriptor ring memory 622 and the DMA controller 630 may begin transmitting data over Ethernet.

[0069] The EAVB software stack 322 may trigger timers 636a-636b, which may trigger TS sorting logic 638a-638b, which may trigger channel clusters 632a-632b, which may trigger DMA to read all or a portion of descriptors from the unsorted Class A descriptor ring memory 620. Since the descriptors may be large (e.g., 32 bytes, etc.), in some embodiments, the DMA may be configured to prepare only a few parameters from each descriptor. As a more detailed example, the system may include a pointer to the descriptor location in the unsorted Class A descriptor ring memory 620, and each descriptor may include a four-byte timestamp. Since the duration is unlikely to exceed a few milliseconds, the DMA may be configured to read only the lower two bytes of the four-byte timestamp.

[0070] The DMA may store the data retrieved from the unsorted Class A descriptor ring memory 620 into the FIFO memories 634a-634n, and the TS sorting logic 638a-638b may sort all the descriptors in ascending order so that the most recent timestamp may be placed on the top of the FIFO memory 634. When the sorting is complete, the TS sorting logic 638a-638b may trigger the DMA controller 630 to extract the sorted descriptor information from the FIFO memories 634a-634n and pass them to the sorted Class A descriptor ring memory 622.

[0071] Therefore, the DSE 610 can sort the descriptors before handing them over to the EMAC 604 component. The eMAC driver configures the DMA and timers in the descriptor sorting engine. When the timer expires (sorting trigger event), the DMA reads the descriptor header and extracts the gPTP timestamp (32 bits) from the system memory (DDR) for each descriptor and stores it in the local FIFO along with the associated descriptor address pointer.

[0072] The descriptor timestamps can be sorted according to their start time, with the most recently timestamped descriptors placed on the top of the FIFO. Once the descriptor sorting is complete, it triggers the DMA to read the entire contents of each descriptor from the unsorted buffer and pass them to the sorted buffer. The eMAC reads the sorted descriptors for pushing packets out to the network through the eMAC internal DMA channel. In some embodiments, this solution can be applied when there is no opportunity to modify the EMAC IP (i.e., the eMAC IP can be licensed from a third party).

[0073] refer to Figures 1A to 6B ,exist Figure 6B6 illustrates a system including dedicated Descriptor Ring Scanner (DRS) 654a, 654b hardware inside the EMAC 604, which is suitable for use when there is an opportunity to modify the EMAC hardware IP return to zero (RZ). The DRS 654a, 654b hardware allows the DMA channels 616a-616n in the sequencing engine to sort the streams and place them in the proper order so that an engine data management (EDM) channel can deliver the data. Some embodiments may use the DRS for hardware-based eAVB packet / descriptor sorting to streamline streaming and delivery of packets according to the gPTP time embedded in the eAVB packets.

[0074] In a multi-stream scenario, each application or eAVB software thread submits multiple packets (example: 8 audio packets equivalent to 1 millisecond duration) to the eMAC driver, which then writes the packets to the system memory (eMAC descriptors). These descriptors are unordered because they come from different threads that are not time-aligned. The DRS 654a, 654b hardware can extract the descriptor header pointed to by the descriptor ring buffer 620a-620n read index (local DRS 654a, 654b hardware), extract the gPTP timestamp embedded in the descriptor header, and compare the timestamp with the current gPTP time to determine whether the gPTP timestamp is in the past. In response to determining that the gPTP timestamp is in the past, the DRS 654a, 654b hardware can trigger the DMA 616a-616n of the current descriptor and pass the eAVB packet on the network. The DRS 654a, 654b hardware can increment the ring buffer read index and repeat the above operations for the entire descriptor ring.

[0075] Figures 7 to 9 6 is a timing diagram illustrating packets from different flows as they arrive at the Ethernet DMA from an unordered queue to an ordered queue based on an ordering trigger generated by the DSE 610. Figures 7 to 9 In the example illustrated in , different line lengths (eg, long bars and short bars) are used to distinguish different packet flows. Figure 7 The timing of two packet flows 702, 704 starting at the same time and scheduled at 1 ms intervals is illustrated. Figure 8 The timing of two packet flows scheduled at 1 ms intervals is illustrated, and where the second flow starts with a 1 ms delay. Fig. 9 The timing of two packet flows is illustrated, where the first flow is scheduled at 1 ms intervals and the second flow is scheduled at 2 ms intervals.

[0076] Fig.10 A method 1000 of operating a DSE 610 according to some embodiments is illustrated. Figures 1A to 10In block 1002, the DSE 610 may pull a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory (e.g., unsorted Class A descriptor ring memory 620). In block 1004, the DSE 610 may store the timestamp-pointer pair in a memory (e.g., FIFO memory 634). In block 1006, the DSE 610 may trigger the TS sorting logic 638a-638b component to reorder the timestamp-pointer pair in ascending order. In block 1006, the DSE 610 may store the packet descriptor in an sorted descriptor ring memory (e.g., sorted Class A descriptor ring memory 622). The sorted descriptor ring memory may be a small memory buffer suitable for storing data that is only used to store a small amount of data (e.g., data for transmitting 1, 2, 4, or 8 milliseconds, etc.).

[0077] Fig.11 A method 1100 of operating a DSE 610 according to some embodiments is illustrated. Figures 1A to 11 In blocks 1002-1008, DSE 610 may perform the above reference Fig.10 Operations discussed. In block 1102, the DSE 610 may trigger the EMAC to transfer data from an ordered descriptor ring (eg, the ordered Class A descriptor ring 622).

[0078] Fig.12 A method 1200 of operating a network device according to some embodiments is illustrated. Figures 1A to 12 In block 1202, the network device may determine whether there is an opportunity to modify the EMAC IP. In response to determining that there is an opportunity to modify the EMAC IP (i.e., determination block 1202 = "Yes"), the network device may invoke the DRS 654a-654n in block 1204 to provide hardware-based eAVB packet and descriptor ordering to streamline streaming and delivery of packets according to the gPTP time embedded in the packet. In response to determining that there is no opportunity to modify the EMAC IP (i.e., determination block 1202 = "No"), the network device may invoke the DSE in block 1206 to order the data packets and / or perform the method 1000 or 1100.

[0079] Fig.13 A method 1300 of using a DRS 654a-654n according to some embodiments is illustrated. Figures 1A to 13, in box 1302, the DRS 654a-654n hardware may extract the descriptor header pointed to by the descriptor ring buffer 620 read index (local DRS 654a-654n hardware). In box 1304, the DRS 654a-654n hardware may extract the gPTP timestamp embedded in the descriptor header. In box 1306, the DRS 654a-654n hardware may compare the timestamp with the current gPTP time to determine whether the gPTP timestamp is in the past. In determination box 1308, the DRS 654a-654n hardware may determine whether the gPTP timestamp is in the past. In response to determining that the gPTP timestamp has not passed (i.e., determination box 1308 = "No"), the DRS 654a-654n hardware may wait for a predetermined time period and compare the timestamp with the current gPTP time again in box 1306.

[0080] In response to determining that the gPTP timestamp has passed (i.e., determination block 1308 = "Yes"), the DRS 654a-654n hardware may trigger DMA 616a-616n for the current descriptor and deliver the eAVB packet over the network in block 1310. In block 1312, the DRS 654a-654n hardware may increment the ring buffer read index. The DRS 654a-654n hardware may repeat the above operations 1302-1312 for each channel descriptor ring 620a-620n.

[0081] Various embodiments may be implemented on a variety of electronic components in a vehicle, examples of which are illustrated in the form of a vehicle display unit 1400. Fig.14 The vehicle display unit 1400 may include a processor 1402 coupled to an internal memory 1404, a display 1412, and a speaker 1414. Additionally, the vehicle display unit 1400 may include an antenna 1410 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or to a cellular telephone transceiver 1408 coupled to the processor 1402. The vehicle display unit 1400 may also include menu selection buttons or rocker switches for receiving user input.

[0082] The vehicle display unit 1400 may include a sound coding / decoding (CODEC) circuit 1406 that digitizes the sound received from the microphone into data packets suitable for wireless transmission and decodes the received sound data packets to generate an analog signal provided to the speaker to generate sound. In addition, one or more of the processor 1402, the wireless transceiver 1408, and the CODEC 1406 may include a digital signal processor (DSP) circuit (not separately shown).

[0083] The processor 1402 may be any programmable microprocessor, microcomputer, or one or more multi-processor chips that can be configured by software instructions (applications) to perform various functions, including the functions of the various embodiments described below. In some mobile devices, multiple processors 1402 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 1404 before they are accessed and loaded into the processor 1402. The processor 1402 may include internal memory sufficient to store application software instructions.

[0084] Specific implementation examples are described in the following paragraphs. Although some of the specific implementation examples in the following specific implementation examples are described according to the example methods, further example implementations may include: the example methods discussed in the following paragraphs implemented by a computing device for a vehicle, the computing device including a main boot processor configured with processor-executable instructions for performing the operations of the methods of the following specific implementation examples; the example methods discussed in the following paragraphs implemented by a computing device for a vehicle, the computing device including a component for performing the functions of the methods of the following specific implementation examples; and the example methods discussed in the following paragraphs may be implemented as a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of the computing device for a vehicle to perform the operations of the methods of the following specific implementation examples.

[0085] Embodiment 1. A network device, comprising a descriptor sorting engine (DSE). The DSE comprises: a direct memory access (DMA) controller; a memory organized by channel clusters, each channel cluster comprising a plurality of first-in-first-out (FIFO) memories; and a timestamp (TS) sorting logic component, wherein the DMA controller is configured to: pull a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory; trigger the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; and store the packet descriptor in a sorted descriptor ring memory.

[0086] Embodiment 2. According to the network device of embodiment 1, the network device also includes an Ethernet media access controller (EMAC), and the DMA controller is configured to: store the timestamp-pointer pairs in the FIFO memory; use the sorted timestamp-pointer pairs in the FIFO memory to read the packet descriptors stored in the unsorted descriptor ring memory; and trigger the EMAC to transfer data from the sorted descriptor ring memory.

[0087] Embodiment 3. A network device according to any one of embodiments 1 or 2, wherein the network device further comprises a processor, wherein the processor is configured to: in response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), call the DSE to sort the data packets.

[0088] Embodiment 4. A network device according to embodiment 2, wherein the EMAC includes a dedicated descriptor ring scanner (DRS), and the network device includes a processor, the processor being configured to: call the DRS in response to determining that there is an opportunity to modify the EMAC hardware IP return to zero (RZ).

[0089] Embodiment 5. A network device according to Embodiment 4, wherein calling DRS hardware causes the DRS hardware to: extract a descriptor header pointed to by a descriptor ring buffer read index; compare a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; in response to determining that the timestamp is in the past, trigger a DMA controller of the current descriptor to pass a packet on the network; and increment the descriptor ring buffer read index.

[0090] Embodiment 6. A network device as described in any one of Embodiments 1 to 5, wherein the data stored in the ordered descriptor ring memory is audio data.

[0091] Embodiment 7. A network device according to any one of Embodiments 1 to 6, wherein the data stored in the ordered descriptor ring memory includes video data.

[0092] Embodiment 8. A network device according to any one of embodiments 1 to 5, wherein the data stored in the ordered descriptor ring memory is time-critical network data.

[0093] Embodiment 9. A method executed by one or more processors of an automotive network device, the method comprising: pulling a timestamp-pointer pair from a packet descriptor stored in an unsorted descriptor ring memory; storing the timestamp-pointer pair in the FIFO memory; triggering a TS sorting logic component to reorder the timestamp-pointer pair in the FIFO memory so that the timestamp-pointer pair is sorted in ascending order; using the sorted timestamp-pointer pair in the FIFO memory to read the packet descriptor stored in the unsorted descriptor ring memory; and storing the packet descriptor in a sorted descriptor ring memory.

[0094] Embodiment 10. The method of embodiment 9, further comprising: triggering an Ethernet media access controller (EMAC) to stream data from the ordered descriptor ring memory.

[0095] Embodiment 11. The method of embodiment 10, further comprising: in response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), invoking sequencing of the data packets.

[0096] Embodiment 12. The method of any one of embodiments 10 or 11, further comprising: invoking dedicated descriptor ring scanner (DRS) hardware in response to determining that there is an opportunity to modify the EMAC Internet Protocol (EMAC IP).

[0097] Embodiment 13. A method according to embodiment 12, wherein calling the DRS hardware includes: extracting a descriptor header pointed to by a descriptor ring buffer read index; comparing a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; in response to determining that the timestamp is in the past, triggering a direct memory access (DMA) controller of the current descriptor to pass a packet on a network; and incrementing the descriptor ring buffer read index.

[0098] Embodiment 14. The method of any one of Embodiments 9 to 13, wherein the data stored in the ordered descriptor ring memory is audio data.

[0099] Embodiment 15. The method of any one of Embodiments 9 to 14, wherein the data stored in the ordered descriptor ring memory comprises video data.

[0100] Embodiment 16. The method of any one of Embodiments 9 to 13, wherein the data stored in the ordered descriptor ring memory is time-critical network data.

[0101] A variety of different memory types and memory technologies are available or conceivable in the future, any or all of which may be included and used in systems and computing devices implementing various embodiments. Such memory technologies / types may include non-volatile random access memory (NVRAM), such as magnetoresistive RAM (M-RAM), resistive random access memory (ReRAM or RRAM), phase change random access memory (PC-RAM, PRAM or PCM), ferroelectric RAM (F-RAM), spin transfer torque magnetoresistive random access memory (STT-MRAM), and three-dimensional cross-point (3D-XPOINT) memory. Such memory technologies / types may also include non-volatile or read-only memory (ROM) technologies, such as programmable read-only memory (PROM), field programmable read-only memory (FPROM), one-time programmable non-volatile memory (OTP NVM). Such memory technologies / types may also include volatile random access memory (RAM) technologies, such as dynamic random access memory (DRAM), double data rate (DDR) synchronous dynamic random access memory (DDR SDRAM), static random access memory (SRAM), and pseudo-static random access memory (PSRAM). Systems and computing devices implementing various embodiments may also include or use electronic (solid-state) non-volatile computer storage media, such as flash memory. Each of the memory technologies mentioned above includes, for example, elements suitable for storing instructions, programs, control signals, and / or data for use in or for use by the following: advanced driver assistance systems (ADAS), systems on chips (SOCs), or other electronic components of vehicles. Any reference to terms and / or technical details related to individual memory types, interfaces, standards, or memory technologies is for illustrative purposes only, and is not intended to limit the scope of the claims to a specific memory system or technology, unless explicitly stated in the claim language.

[0102] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of steps in the foregoing embodiments can be performed in any order. Words such as "thereafter", "then", "next", etc. are not intended to limit the order of steps; these words are only used to guide the reader to read the description of the method. In addition, any reference to a claim element in the singular form (e.g., a reference using the article "one", "an", or "said") should not be interpreted as limiting the element to the singular.

[0103] As used in this application, the terms "component", "comparator", "encoder", "element", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software or software being executed, which are configured to perform specific operations or functions. For example, a component can be but not limited to a process, a processor, an object, an executable file, an execution thread, a program and / or a computer running on a processor. By way of example, both an application running on a computing device and a computing device can be referred to as a component. One or more components may reside in a process and / or an execution thread, and a component may be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components may be executed from various non-transient computer-readable media having various instructions and / or data structures stored thereon. Components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor and / or process-related communication methods.

[0104] Each illustrative logic box, module, circuit and algorithm step described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits and steps have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints proposed to the entire system. Although the technician can implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as making it depart from the scope of the claims.

[0105] The hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general purpose processor may be a multiprocessor, but in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, for example, a combination of a DSP and a multiprocessor, a plurality of multiprocessors, one or more multiprocessors combined with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by a circuit system dedicated to a given function.

[0106] In one or more exemplary embodiments, the functions described may be implemented with hardware, software, firmware, or any combination thereof. If implemented with software, the functions may be stored as one or more processor executable instructions or codes on a non-transient computer-readable storage medium or a non-transient processor-readable storage medium. The steps of the method or algorithm disclosed herein may be implemented in a processor executable software module, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage devices, or any other medium that may be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination is also included in the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0107] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the claims are not intended to be limited to the various embodiments shown herein, but should be granted the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. An automobile network device, comprising: A Descriptor Sorting Engine (DSE), the DSE engine comprising: A memory organized by channel clusters, each channel cluster including a first-in-first-out (FIFO) memory; A timestamp (TS) sorting logic component; and a direct memory access (DMA) controller coupled to the memory and the TS ordering logic component, Wherein the DMA controller is configured as: Pulling a timestamp-pointer pair from a packet descriptor stored in an unordered descriptor ring memory; triggering the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; and The packet descriptors are stored in an ordered descriptor ring memory.

2. The automotive network device of claim 1 , further comprising an Ethernet media access controller (EMAC) coupled to the DMA controller, wherein the DMA controller is further configured to: After storing the timestamp-pointer pairs in the FIFO memory, triggering the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; storing the packet descriptors in the sorted descriptor ring memory after reading the packet descriptors stored in the unsorted descriptor ring memory using the sorted timestamp-pointer pairs in the FIFO memory; as well as The EMAC is triggered to stream data from the ordered descriptor ring memory.

3. The automotive network device of claim 2, further comprising a processor configured to, in response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), invoke the DSE to sort the data packets.

4. The automotive network device according to claim 2, wherein: The EMAC includes dedicated Descriptor Ring Scanner (DRS) hardware; and The automotive network device also includes a processor configured to invoke the DRS hardware in response to determining that an opportunity to modify an EMAC Internet Protocol (EMAC IP) exists.

5. The automotive network device according to claim 4, wherein calling the DRS hardware causes the DRS hardware to: Extract the descriptor header pointed to by the descriptor ring buffer read index; comparing a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; In response to determining that the timestamp is in the past, triggering a DMA controller of the current descriptor to transfer the packet over the network; as well as Increment the descriptor ring buffer read index. 6 . The automotive network device of claim 1 , wherein the data stored in the ordered descriptor ring memory is audio data. 7 . The automotive network device of claim 1 , wherein the data stored in the ordered descriptor ring memory comprises video data.

8. The automotive network device of claim 1, wherein the data stored in the ordered descriptor ring memory is time-critical network data.

9. A method performed by one or more processors of an automotive network device, the method comprising: Pulling a timestamp-pointer pair from a packet descriptor stored in an unordered descriptor ring memory; triggering the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; as well as The packet descriptors are stored in an ordered descriptor ring memory.

10. The method according to claim 9, further comprising: storing the timestamp-pointer pair in the FIFO memory; reading the packet descriptors stored in an unordered descriptor ring memory using the ordered timestamp-pointer pairs in the FIFO memory; as well as An Ethernet Media Access Controller (EMAC) is triggered to stream data from the ordered descriptor ring memory.

11. The method according to claim 10, further comprising: In response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), sequencing of the data packets is invoked.

12. The method according to claim 10, further comprising: In response to determining that an opportunity to modify the EMAC Internet Protocol (EMAC IP) exists, dedicated Descriptor Ring Scanner (DRS) hardware is invoked.

13. The method of claim 12, wherein invoking the DRS hardware comprises: Extract the descriptor header pointed to by the descriptor ring buffer read index; comparing a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; In response to determining that the timestamp is in the past, triggering a direct memory access (DMA) controller of the current descriptor to transfer the packet over the network; as well as Increment the descriptor ring buffer read index.

14. The method of claim 9, wherein the data stored in the ordered descriptor ring memory is audio data.

15. The method of claim 9, wherein the data stored in the ordered descriptor ring memory comprises video data.

16. The method of claim 9, wherein the data stored in the ordered descriptor ring memory is time-critical network data.

17. An automobile network device, comprising: A memory organized by channel clusters, each channel cluster including a first-in-first-out (FIFO) memory; means for pulling a timestamp-pointer pair from a packet descriptor stored in an unordered descriptor ring memory; A component for triggering the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; and Means for storing said packet descriptors in an ordered descriptor ring memory.

18. The automobile network device according to claim 17, further comprising: means for storing said timestamp-pointer pairs in said FIFO memory; means for reading said packet descriptors stored in an unordered descriptor ring memory using said ordered timestamp-pointer pairs in said FIFO memory; and Means for triggering an Ethernet Media Access Controller (EMAC) to stream data from said ordered descriptor ring memory.

19. The vehicle network device according to claim 18, further comprising: Means for invoking ordering of data packets in response to determining that an opportunity does not exist to modify the EMAC Internet Protocol (EMAC IP).

20. The vehicle network device according to claim 18, further comprising: Means for invoking dedicated Descriptor Ring Scanner (DRS) hardware in response to determining that an opportunity to modify an EMAC Internet Protocol (EMAC IP) exists.

21. The automobile network device according to claim 20, wherein the component for invoking the DRS hardware comprises: means for extracting a descriptor header pointed to by a descriptor ring buffer read index; means for comparing a timestamp embedded in said descriptor header with a current time to determine whether said timestamp has passed; means for triggering a direct memory access (DMA) controller of the current descriptor to transfer the packet over the network in response to determining that the timestamp is in the past; and Means for incrementing said descriptor ring buffer read index.

22. The automotive network device of claim 17, wherein the data stored in the ordered descriptor ring memory is audio data.

23. The automotive network device of claim 17, wherein the data stored in the ordered descriptor ring memory comprises video data.

24. The automotive network device of claim 17, wherein the data stored in the ordered descriptor ring memory is time-critical network data.

25. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of an automotive network device to perform operations comprising: Pulling a timestamp-pointer pair from a packet descriptor stored in an unordered descriptor ring memory; triggering the TS sorting logic component to reorder the timestamp-pointer pairs in the FIFO memory so that the timestamp-pointer pairs are sorted in ascending order; as well as The packet descriptors are stored in an ordered descriptor ring memory.

26. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are configured to cause the processor of the automotive network device to perform operations further comprising: storing the timestamp-pointer pair in the FIFO memory; reading the packet descriptors stored in an unordered descriptor ring memory using the ordered timestamp-pointer pairs in the FIFO memory; and An Ethernet Media Access Controller (EMAC) is triggered to stream data from the ordered descriptor ring memory.

27. The non-transitory processor-readable medium of claim 26, wherein the stored processor-executable instructions are configured to cause the processor of the automotive network device to perform operations further comprising: in response to determining that there is no opportunity to modify the EMAC Internet Protocol (EMAC IP), invoking sorting of data packets.

28. The non-transitory processor-readable medium of claim 26, wherein the stored processor-executable instructions are configured to cause the processor of the automotive network device to perform operations further comprising: in response to determining that there is an opportunity to modify the EMAC Internet Protocol (EMAC IP), calling dedicated descriptor ring scanner (DRS) hardware.

29. The non-transitory processor-readable medium of claim 28, wherein the stored processor-executable instructions are configured to cause the processor of the automotive network device to perform operations such that invoking the DRS hardware comprises: Extract the descriptor header pointed to by the descriptor ring buffer read index; comparing a timestamp embedded in the descriptor header with a current time to determine whether the timestamp has passed; In response to determining that the timestamp is in the past, triggering a direct memory access (DMA) controller of the current descriptor to transfer the packet over the network; as well as Increment the descriptor ring buffer read index.

30. The non-transitory processor-readable medium of claim 25, wherein the data stored in the ordered descriptor ring memory comprises one or more of audio data, video data, or time-critical network data.

Images