Network architecture, corresponding vehicle and method

Abstract

The invention relates to a network architecture, a corresponding vehicle and a method. Using SOC interface bandwidth while minimizing the number of physical ports via on-board use of networked accelerators, e.g., including MAC controller circuitry that provides a MAC port layer to control the exchange of information including data streaming over a data link to a VMP; vM Tx bridge circuitry to process a transmission data stream to the VMP; transmission router / switch circuitry to route or switch data streams from the MAC controller circuitry to the VM Tx bridge circuitry; queue processor circuitry that provides data flow queue management between MAC controller circuitry and VM Tx bridge circuitry. The VM Tx bridge circuitry includes virtual destination address circuitry that implements router or switch virtualization in the transport router / switch circuitry with a virtual machine transport descriptor based on a combination of a VMP tag and a VMEID indicating physical resources selectable for data streaming in the queue processor circuitry.

Description

Technical Field

[0001] The description relates to a communication network as used, for example, in the automotive field.

[0002] Examples as discussed herein facilitate providing a flexible, secure, and scalable system architecture for, for example, an optimized Ethernet router (L2+) / switch (L2) / gateway for high-speed automotive networks. Background Art

[0003] The evolution of automotive technology continues at a rapid pace, with new and complex automotive applications setting ever-increasing connectivity / bandwidth requirements for in-car connectivity.

[0004] Therefore, the ability to integrate an efficient network accelerator capable of switching / routing packets between internal SOC network ports (AXIM ports) with minimal area overhead plays an important role in the new generation of automotive gateway processors.

[0005] The internal system-on-chip (SOC) network port (eg, AXIM) is capable of supporting high bandwidth requirements in standard SOC system interfaces via pipelining, data parallelization, and various superior features such as embedded direct memory access (DMA) features.

[0006] Taking full advantage of the high bandwidth availability of SOC interfaces while minimizing the number of physical ports of the switch and maintaining a large number of virtual machine (VM) ports can represent a challenging goal to pursue.

[0007] This is mainly applicable to exploiting the large bandwidth of the SOC interface with a reduced number of physical ports without significant disadvantages, which leads to a significant reduction in complexity in terms of gate count, logic levels and power consumption. Summary of the invention

[0008] It is an object of one or more embodiments to help provide further improvements to the context discussed above.

[0009] According to one or more embodiments, this object is achieved via a network architecture (essentially an architecture of a communication system) having the characteristics set out in the following claims.

[0010] One or more embodiments are directed to corresponding vehicles. A motor vehicle equipped with an on-board communication network may be a typical example of such a vehicle, wherein the network includes the system exemplified herein to provide MAC / router / switch / gateway features for such on-board communication network.

[0011] One or more embodiments are directed to a corresponding method.

[0012] The claims are an integral part of the technical teaching provided herein with respect to the exemplary embodiments.

[0013] The discussed examples provide a low-cost and high-performance solution for hardware (HW) networking of automotive networks, which facilitates further expansion of existing functionalities of automotive microcontrollers.

[0014] Examples as discussed herein facilitate creating a unified software platform for multiple brands and for providing requests for quotes (RFQs).

[0015] The examples discussed herein provide an alternative, competitive solution where the number of virtual machines (VMs) per AXIM (AXI Master) can be increased while reducing the impact on gate count / complexity; providing additional flexibility in configuring a variable number of VMs per AXIM port depending on application requirements.

[0016] In examples such as those discussed herein, an adequate trade-off is achieved between area / power, performance (latency, bandwidth), and flexibility, while also providing static configurability of key parameters of the intellectual property (IP) core.

[0017] A designated IP (Intellectual Property) core (or simply IP) is currently applied to a block of logic or data that can be used to produce a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC) for a semiconductor device. IP cores are inherently reusable and portable: it is expected that a certain IP core can be easily plugged into any technology or design methodology. For example, an IP core can be used in an Ethernet controller, a Peripheral Component Interconnect PCI interface, a Universal Asynchronous Receiver / Transmitter (UART) module, or a Central Processing Unit (CPU).

[0018] Examples as discussed herein provide an open and flexible micro-architecture that facilitates the extension of functionality supported by the VM.

[0019] Examples as discussed herein facilitate virtualization based on the decoupling between VM physical ports mapped onto queue control / buffer / interconnect resources and VM virtual ports mapped as an extension onto the same physical port.

[0020] Note that at the SOC level, when considering AXIM transactions, there is no essential distinction between physical and virtual (except for the VM identifier tag VMID), because all VMs can be mapped to different DMA descriptors and transported with relevant VM attributes.

[0021] Therefore, the underlying concept of the examples as discussed herein is to map VMP and VMEID labels into routing / forwarding tables with different meanings, and related implementations.

[0022] Thus, examples as discussed herein provide advantages in reducing switch complexity (number of physical ports) and increasing flexibility in VM virtual port assignments over VM physical ports. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] One or more embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0024] Figure 1 is a functional diagram illustrating a network architecture suitable for, for example, an automotive scenario;

[0025] Figure 2 is a general block diagram of a network architecture used, for example, in the automotive field; and

[0026] Figure 3 and Figure 4 is a block diagram illustrating an embodiment of a system architecture according to the present disclosure.

[0027] Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated.

[0028] The drawings are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.

[0029] The edges of a feature depicted in a figure do not necessarily indicate the end of the extent of that feature. DETAILED DESCRIPTION

[0030] In the following description, various specific details are described in order to provide a deep understanding of various examples according to the described embodiments. The embodiments can be obtained without one or more of the specific details or with other methods, components, materials, etc. In other cases, well-known structures, materials, or operations are not described or described in detail so as not to obscure aspects of the embodiments.

[0031] References to "an embodiment" or "one embodiment" in the framework of this description are intended to indicate that a particular configuration, structure, or feature described in connection with the embodiment is included in at least one embodiment. Thus, phrases such as "in an embodiment," "in one embodiment," etc., which may appear in various places in this description, do not necessarily refer to exactly one and the same embodiment. Furthermore, particular configurations, structures, or features may be combined in any suitable manner in one or more embodiments.

[0032] The headings / references used herein are provided for convenience only and do not limit the scope of protection or the scope of the embodiments.

[0033] Furthermore, for simplicity and ease of explanation, the same name may be applied throughout the description to represent a certain node or line and a signal occurring on the node or line. Figure 3and Figure 4 The signals / lines indicated as AXIM WRITE and AXIM READ, respectively, are examples.

[0034] The hardware (HW) networking of different automotive communication protocols (Ethernet, LIN, CAN, FlexRay, ...) is gradually migrating from heterogeneous architectures of modules arranged around a central "hub" (gateway / switch) to a hierarchical topology based on different physical areas and functional domains - e.g. Figure 1 as shown in .

[0035] Figure 1 Example based on physical location in a vehicle V (such as a motor vehicle) application such as Figure 1 The possibility of the architecture shown in , which therefore has a “central brain” 100 and a “zone gateway” 102.

[0036] Figure 1 The exemplary hierarchical topology shown in includes:

[0037] Central Gateway / Switch 100: A high-speed backbone network may be based on a switched Ethernet network (central gateway) for inter-domain communications;

[0038] A set of domain gateways 102 that can "hide" sub-network characteristics to the Ethernet backbone (e.g., CAN2Ethernet, FlexRay2Ethernet, LIN2Ethernet, etc.); and

[0039] Electronic devices 104 are grouped into domains based on functionality (eg, in the case of automotive applications: powertrain, chassis, advanced driver assistance systems or ADAS, body & comfort).

[0040] By way of introduction, the meanings of various abbreviations used throughout this description (most of which are known to those skilled in the art) will now be reviewed for immediate reference:

[0041] VM - Virtual Machine

[0042] VMP - Virtual Machine Port

[0043] VMID - Virtual Machine Identifier

[0044] VMEID - Virtual Machine Extension Identifier

[0045] VSID - Virtual Stream Identifier

[0046] PP - Physical Port (e.g., MAC Port)

[0047] AXIM-AXI Master Port

[0048] VMB - Virtual Machine Bridge

[0049] QoS - Quality of Service

[0050] SP - Strict Priority

[0051] PCP - Priority Code Point

[0052] FLEX_SGS - Flexible / Secure Gateway / Router / Switch

[0053] Virtualization can be implemented in two different modes in FLEX_SGS interconnecting physical (e.g., MAC Ethernet) ports and virtual (SOC interface, e.g., AXIM) ports:

[0054] At the SOC / FLEX_SGS (VM bridge) level, by introducing a VMID to tag any delivered L2 / L3 packets linked to a VMP; the VMP is implemented as a physical port within the FLEX_SGS; or

[0055] At SOC / FLEX_SGS (deep) level, by introducing VMID inside L2 forwarding database / L3 routing table.

[0056] For example, in a network used in the automotive field, the various protocol layers (denoted as L1 to L7) can be defined as follows:

[0057] Layer 1 or L1 protocol (physical): transfers bits over the medium (e.g., Ethernet physical layer);

[0058] Layer 2 or L2 protocol (data link): organizes information into frames and handles delivery within the network;

[0059] Layer 3 or L3 protocol (network): handles internetwork communications (host-to-host communications);

[0060] Layer 4 or L4 protocol (transport): provides reliable messaging (e.g., packet reordering, packet retransmission) systems between processes;

[0061] Layer 5 or L5 protocol (session): establishes communication between two hosts;

[0062] Layer 6 or L6 protocol (expression): compressing and / or encrypting data; and

[0063] Layer 7 or L7 protocol (application): allows access to network resources.

[0064] For example:

[0065] Ethernet switches operate at the L2 layer;

[0066] Routers operate at the L3 layer;

[0067] The gateway operates on different types of L2 protocols by encapsulating / decapsulating based on a hierarchy of defined protocols.

[0068] like Figure 2 The architecture shown in is basically the same as discussed in Italian Patent Application No. 102022000019233 (“Network architecture, corresponding vehicle and method”, inventors are Borgonovo, ReFiorentin), which has not been disclosed to the public at the time of filing this application.

[0069] like Figure 2 The system architecture illustrated in supports a number of key features / functionality, as detailed below:

[0070] HW network accelerator: packet forwarding at high speed, no blocking, high performance;

[0071] Forwarding database: static MAC DA (multicast) / mask, static / dynamic (learning) MAC DA (unicast) hash table, static VLAN ID hash table, static IPv4 / IPv6 address / mask routing table, ARP table;

[0072] L2 frame classification and forwarding based on MAC DA and VLAN ID;

[0073] L2+ frame classification and forwarding based on MAC DA, IPv4 / IPv6 address, and ARP table;

[0074] L2 flows from / to MAC ports, from VMP to MAC ports, and from MAC to VMP ports (optional);

[0075] L2+ flows from / to VMP ports, and from MAC to VMP ports;

[0076] Input priority regeneration x MAC / VMP port;

[0077] Reliable throughput requirements and reduced latency through Quality of Service (QoS): Threshold / cut-through mode in addition to store & forward mode;

[0078] QoS based on 8x traffic classes with different schedulers / shapers;

[0079] Scheduling algorithm: strict priority, weighted round robin (WRR);

[0080] Bandwidth shapers: Credit-based shaper (CBS), Time-aware shaper (TAS) per MAC destination port;

[0081] Concurrent frame management via multiple / configurable queues mapped in LMEM x MAC / VMP destination ports and traffic classes;

[0082] SW (Host) queue mapping in LMEM for local frames + broadcast and multicast frames + PTP, MKA, etc.

[0083] Local memory controller (buffer management, interleaved addressing scheme, multiple memory banks);

[0084] Virtual Machine Bridge (VMB), including embedded high-end AXIMDMA (multi-channel) for L2 / L3 data flow from / to VMP ports (VMs running on the SoC); and

[0085] Security: MACsec integrity check and MKA protocol (hop2hop protection), configuration via HSM (secure port).

[0086] In such Figure 2 In the networking accelerator 1000 shown in FIG. 1 , reference numeral 1001 collectively designates a set of internal Ethernet / LIN / CAN / other MAC controllers (e.g., #1 to #N, where N=32). These controllers (clocked by the Precision Time Protocol timer 1001A) control data exchanges on the Ethernet / LIN / CAN / other data links (not visible in the figure).

[0087] Reference numeral 1002 collectively designates Ethernet / LIN / CAN / other MAC "wrappers" (eg, #1 through #N, where N=32), including MAC translator and (L2 / L3) frame router features, designated 1002A and 1002B, respectively.

[0088] The MAC translator feature 1002A acts between the MAC controller 1001 and the frame router feature 1002B.

[0089] Reference numeral 1003 collectively designates a virtual machine (VM) wrapper (#1 through #M), including MAC translator and frame router (L2 / L3) features, indicated as 1003A and 1003B, respectively.

[0090] The MAC translator feature 1003A acts between the frame router feature 1003B and a virtual machine (VM) bridge (e.g., AXIM translator) block (collectively designated as 1004), which includes a direct memory access (DMA) feature to connect to the SoC's internal virtual machine (VM - not visible in the figure) interface via the AXIM interface.

[0091] like Figure 2 The architecture shown in 1005 includes a SW Ethernet port (bridge) 1005 for a host. This bridge includes an AXIS wrapper 1005 that includes MAC translator features and L2 / L3 frame router features, plus an AXIS bridge coupled to the wrapper 1005 for configuration and management of the network by the host via the AXIS control and programming interface and the interrupt request (IRQ) interface.

[0092] The current meaning of the name "wrapper" as used in this document is to designate a hardware module (software configurable) that "wrappers" one or more other modules or features, thereby acting as an intermediary between its own clients (using the wrapper interface) and the (one or more) wrapped modules that implement the requested functionality as proxies for the wrapper object.

[0093] The bridge 1005 including the AXIS and IRQ interfaces may be considered as an example of an Ethernet interface port.

[0094] For example, the user manual for the AXIS1611 network interface card, which can be retrieved at the URL "www.axis.com / dam / public / 26 / 5d / 64 / axis-1611-network-interface-card-for-canon-capt-printers--user%E2%80%99s-manual-en-US-30913.pdf", indicates that the AXIS1611 is designed for 10Mbps and 100Mbps Fast Ethernet networks. The AXIS1611 is equipped with an auto-sensing function that detects the speed of the local network segment and changes the speed of its data communication between 10Mbps and 100Mbps accordingly. Moreover, a basic tutorial on Ethernet interfaces, which can be retrieved at the URL "docs.nvidia.com / networking / display / MLNXENv521040 / Ethernet+Interface", explicitly includes a section on interrupt request (IRQ) naming, explaining that once the driver assigns IRQs, they are named mlx5_comp <x>@pci:<pci_addr> , so that the IRQ corresponding to the (interface, ndr) channel in use will be renamed <interface> - <x>, while the rest retain their default names.

[0095] Figure 2 The representation with dashed lines on the right highlights the possibility of configuring the block 1005 (referred to as configuration host port in the cited Italian patent application No. 102022000019233) as a bridge 1005 to / from the host via AXIM.

[0096] exist Figure 2 , reference numerals 1006A, 1006B, and 1006C designate three groups (eg, sixty-five) of queue handlers that cooperate with a local memory controller 1007 for queue management and QoS functionality.

[0097] The local memory controller 1007 may be configured as a multi-port memory controller to access SRAM / frame buffers in the local memory LMEM (typically this is a different element relative to the architecture 1000).

[0098] like Figure 2 As shown in the figure, the three groups of queue processors include:

[0099] A first group of queue processors 1006A (#1 to #N) for the MAC controller 1001;

[0100] A second set of queue handlers 1006B (#(N+1) to #(N+M)) for virtual machine (VM) wrappers (#1 to #M) 1003; and

[0101] (Single) queue processor 1006C (#(N+M+1)), for host port 1005.

[0102] Figure 2 Reference numeral 1008 denotes an L2 / L2+ forwarding database (static DA table, dynamic DA hash table, VLAN ID hash table, IP address routing table, ARP table), which is configured to cooperate with SW port 1005, for example, to receive configuration and management instructions from a host.

[0103] like Figure 2 The architecture shown in FIG. 1 also includes functional safety mechanisms (SM), such as, for example, a fault collector feature 1009 configured to cooperate with a fault interface Fault Intf (not visible in the figure) and a fault collector feature 1009 configured to cooperate with an APB Advanced Peripheral Bus (APB) debug features 1010 that cooperate with the interface (not visible in the figure).

[0104] The multiple (4x) functional layer architecture of the gateway / router / switch architecture illustrated herein may be implemented to include multiple parts (subsystems).

[0105] The first part is the Ethernet / LIN / CAN / VM / other MAC port layer, for example, the MAC controller 1001 and the MAC wrapper 1002 .

[0106] This part may implement conventional data link (e.g. Ethernet / CAN / LIN) layers for a specific protocol as well as a proprietary data link interface to transfer the status / header / payload of each frame that may be exposed to the next layer (MAC generic frame layer).

[0107] Another part is the MAC (generic) frame layer for switch (L2) / routing (L2+) functions (physical / virtual machine / configuration host destination), for example, virtual machine (VM) wrapper 1003.

[0108] As illustrated herein, this layer consists of two distinct sub-parts, namely:

[0109] MAC translator 1003A, for remapping a specific data link interface (Ethernet / LIN / CAN / VM / other) to a generic frame interface; and

[0110] The switch (L2) / router (L2+) function 1003B is used to deliver the frame to the queue handler (QHND) in a set 1006B of destination ports according to the forwarding database (L2 / L2+).

[0111] Advantageously, the interface between the router / switch 1003B and the QHND is a point-to-point interface, defined as a Tx_frame interface and an Rx_frame interface.

[0112] As illustrated herein, a queue (data, status) handler layer (QHND) is provided for each destination port (Ethernet / LIN / CAN / VM, ie, 1006B) and configuration host port (ie, 1006C) to implement QoS functionality.

[0113] Each data / status queue can be remapped based on frame priority and can be configured in terms of size, base address, fill / empty thresholds for mapping in memory LMEM.

[0114] The fill / empty / underflow / overflow status can be monitored by asserting an interrupt.

[0115] As illustrated herein, each QHND layer (eg, 1006A, 1006B, 1006C) includes two sub-parts (write and read), namely, a write QHND and a read QHND.

[0116] Write QHND supports concurrent incoming frames received from any Ethernet / LIN / CAN / VM / other MAC port (e.g., at 1001). The Rx_frame interface (point-to-point) includes flow control, destination port, queue index, data, attributes, frame alignment, frame status, timestamp, and security mechanisms. Frames with different queue indexes delivered to the same destination port will be delivered concurrently to the next layer (multi-port memory controller).

[0117] Read QHND to implement QoS for outgoing frames to any Ethernet / LIN / CAN / VM / other MAC port. The scheduler supports different types of algorithms according to relevant standards: strict priority, WRR (weighted round robin) and / or different types of shapers (such as credit-based, time-aware).

[0118] As illustrated herein, a pre-fetch buffer is implemented on the read data path from the memory LMEM via the controller 1007 to avoid underflow conditions on the Tx side in pass-through mode and / or in case of contention / bandwidth limitations on the LMEM memory; the Tx frame interface (point-to-point) includes flow control, data, attributes, frame alignment, frame status, timestamp and security mechanisms.

[0119] As illustrated herein, a multi-port memory controller layer 1007 is provided for bandwidth optimization based on the total bandwidth required by the source / destination ports. The interface between the local memory controller (LMC) 1007 and the QHND features 1006A, 1006B, and 1006C is a point-to-point interface for each destination port and each queue, which includes flow control, data, address, access type, and security mechanisms.

[0120] As illustrated herein, a virtual machine bridge (VMB) 1004 implements a bridge to transmit / receive L2 / L2+ frames to / from a virtual machine (not visible in the figure) mapped at the SOC level on a multi-core architecture. The L2 / L2+ frames are memory-mapped in a system memory (SMEM, not visible in the figure), and the virtual machine bridge (VMB) 1004 controls the control / data flow from / to such memory via an AXIM interface and controls the control / data flow to / from an internal switch via a data link interface.

[0121] The VMB-Rx direct memory access (DMA) illustrated herein supports multiple channels (multiple frame buffers in system memory linked to multiple DMA descriptors) and / or multiple frames (linked to a single DMA descriptor) for data stream transfer.

[0122] The VMB-Tx DMA as illustrated in this article supports multi-channels (multiple frame buffers in system memory linked to multiple DMA descriptors) and / or multi-frames (linked to a single DMA descriptor), as well as dynamic transfer (entry frames linked to DMA descriptors, depending on frame attributes, such as priority, UDP / TCP port...) for data stream transfer.

[0123] The virtual machine port (VMP) thus implemented corresponds to the MAC port. With the help of the frame router 1003B, frames such as L2 / L2+ frames can be delivered from / to any VM / MAC port.

[0124] The system architecture as exemplified herein is suitable for implementing, for example, the following data flow:

[0125] L2 / L2+ frames from MAC / VMP to MAC / VMP via internal switch, MAC / VMP ports;

[0126] L2 / L2+ frames from HOST to MAC / from MAC to HOST via AXIS bridge 1005, internal switch, MAC port; and

[0127] L2 / L2+ frames from HOST to VM / from VM to HOST via AXIS bridge 1005, internal switch, AXIM write / read DMA 1004A, MAC port.

[0128] In the system architecture as illustrated in this document, the embedded AXIM DMA feature 1004A can be shared on multiple virtual machine ports (VMPs) (depending on static configuration) and supports delivery of L2 / L2+ frames from / to SMEM in streaming mode through N channels configured by DMA's (VMB-RX) or N*D (VMB-TX) descriptors to control Xfer features such as base address / start address, burst maximum length, frame maximum / actual length, number of frames (sequential buffer mode), frame type, etc.

[0129] A hierarchical (two-tier) round-robin arbitration scheme may be implemented in queue processor 1006B to grant AXIMs on VM ports (first tier with higher priority) and DMA channels (second tier with lower priority).

[0130] In such Figure 2 In the system architecture illustrated in , the AXIM transactions linked to each VM port are protected by a VMID identifier to authorize access to the memory region allocated for the VM (isolation function) port.

[0131] In such Figure 2 In the system architecture illustrated in FIG. 1 , the configured host port (bridge) 1005 may be configured via an AXIS slave port or embedded DMA, for example, as an AXIS slave port or an AXIM master port (via internal DMA).

[0132] A memory mapped interface is implemented to allow L2 / L2+ frames to be equivalently delivered by the host to any Ethernet / LIN / CAN / VM / other MAC port.

[0133] If incoming frames are processed as SW frames (e.g., for each control frame DA=multicast address), then in a system architecture as illustrated herein, the configured host can automatically deliver frame responses with DA=multicast address on all ports where the frame was received, with or without bypassing the forwarding database.

[0134] Optionally the timestamp (TS) captured on the input port of any physical MAC port (e.g. Ethernet) can be delivered to the associated physical MAC destination port via the status queue (internal switch) to support the PTP end-to-end transparent clock 1-step mode protocol in HW without (w / o) SW intervention. Optionally the timestamp (TS) captured on the input port of any physical MAC port (e.g. Ethernet) can be delivered to the associated HOST / VM port via the status queue (internal switch)

[0135] In such Figure 2 In the system architecture shown in the example:

[0136] L2 / L2+ frame transmission on the authorized queues according to QoS configuration can be optionally initiated at the threshold level (cut-through mode) to minimize the switch latency;

[0137] Advantageously, IPv4 / IPv6 routing tables partitioned by horizontal / vertical memory groups may be provided to reduce latency introduced by IP address searches; and

[0138] A flushing mechanism for incoming Rx frames on any Ethernet / LIN / CAN / VM / other MAC port at 1001 is implemented by writing QHND to restore the queue status without (w / o) causing the switch to be unavailable, except for lost frames affected by related fault conditions (e.g., CRC, parity errors on the data path, MAC overflow conditions).

[0139] Advantageously, for the refresh mechanism, two strategies are available (SW configurable):

[0140] Backpressure flow control (queue processors are in hold mode while MAC is buffering (FIFO) or flushing);

[0141] Per-queue flow control (last frame flushed by the queue handler for a full queue).

[0142] It is to be noted that, although these features are listed together and may optionally be combined, their joint presence is not mandatory.

[0143] In a system architecture as exemplified herein, a gateway functionality for LIN / CAN / other protocols (Feature FERTURE under development) may be provided, where:

[0144] LIN / CAN frames can be optionally encapsulated / decapsulated into / from Ethernet frames, or forwarded directly to the LIN / CAN physical port; and

[0145] The LIN / CAN forwarding database includes an address resolution table (LIN / CANID to MAC DA address) and a port / address forwarding table (TBC / TBD).

[0146] Note again that although certain features of the examples presented herein are listed together and combined, the common presence of these features is not mandatory.

[0147] The system architecture as illustrated herein is statically configurable in terms of parameters such as, for example, the number of MAC ports, the number of VM ports, the number of AXIM interfaces (DMA), the number of queues, the number of LMEM ports and / or the L2 / L2+ forwarding database size.

[0148] Advantageous functional safety (FUSA) features of the system architecture as exemplified herein (e.g., 1009, 1010) may include:

[0149] Watchdog counter (up / down) and / or timer on the control signals (req / ack) of each interface (external: AXIM, AXIS, ..., internal: Rx_frame / Tx_frame interfaces, etc.);

[0150] QHND Tx frame counter, Rx frame counter, LMEM pending frame counter x destination port x queue to monitor flow control between Rx_frame and Tx_frame interfaces;

[0151] The QHND destination port selector (Rx_frame interface) in the status queue of the transmitted frame is copied to verify the correct frame delivery on the actual destination port;

[0152] QHND full data / status queue interrupt to monitor flow control x queue / destination port;

[0153] QHND AVB / CBS average bandwidth monitor x queue / transmission port;

[0154] QHND TAS time-aware shaper monitors x queues / transmission ports;

[0155] End-to-end protection (parity bits) on the data path from / to the source / destination ports;

[0156] Memory data protection via error correction code (ECC); and

[0157] Frame erroring (to MAC / VM TX path) to invalidate outgoing frames in case of failure conditions.

[0158] Again, the fact that certain features of the solutions presented herein are listed together and combined does not mean that the common presence of these features is mandatory.

[0159] like Figure 2 The system architecture represented in is an exemplary arrangement that provides many advantages associated with the features, such as:

[0160] Use a single physical port connected to the configuration HOST;

[0161] Increased number of physical ports bridged to single or multiple SOC interfaces (e.g., AXIM) via internal bridges;

[0162] Virtualization is performed through multiple VM physical ports connected to multiple VM bridges to provide high-performance DMA services to transfer L2 / L3 packets for a subset of VM physical ports (physically connected to the VM bridges), and the L2 / L3 packets on the SOC interface (e.g., AXIM) are marked via a VMID identifier linked to each VM port.

[0163] As mentioned in the introductory section of this description, automotive technology continues to evolve rapidly, with new and complex automotive applications placing ever-increasing connectivity / bandwidth requirements on in-vehicle connections.

[0164] Therefore, the ability to integrate efficient network accelerators capable of switching / routing packets between internal SOC network ports (AXIM ports) with minimal area overhead plays an important role in the new generation of automotive gateway processors.

[0165] In this context, it is found that Figure 2 The system architecture represented in has flaws such as:

[0166] For bandwidth / delay limits of a single physical port and configuration of HOST load;

[0167] Increased switch complexity and cost for multiple physical ports; and

[0168] Virtualization is only partially implemented to support isolation of L2 / L3 packets.

[0169] Taking full advantage of the large bandwidth of the SOC interface while minimizing the number of physical / VM ports of the switch and maintaining a large number of virtual machine (VM) ports can represent a challenging goal to pursue.

[0170] like Figure 3 and Figure 4 The arrangement illustrated in facilitates this goal via routing table (for L3) / forwarding database (for L2) entries and VMB extensions to support virtualization in the networking accelerator 2000, which can be configured for data exchange over Ethernet / LIN / CAN / other data links (again not visible in the figure for simplicity).

[0171] As combined Figure 2 As already mentioned, the system architecture as exemplified herein is suitable for implementing various types of data flows, such as for example:

[0172] L2 / L2+ frames from MAC / VMP to MAC / VMP via internal switch, MAC / VMP ports;

[0173] L2 / L2+ frames from HOST to MAC / from MAC to HOST via AXIS bridge 1005, MAC port from the HOST interface internal switch; and

[0174] L2 / L2+ frames from HOST to VM / from VM to HOST via AXIS bridge 1005, internal switch, AXIM write / read DMA 1004A, MAC port.

[0175] As shown, data exchange may include different modes of operation via MAC controller circuitry (collectively referred to as 2001), with the involvement of router (for L3) and / or switch (for L2) circuitry, Figure 3 In the case of 2002, it is specified and Figure 4 In this case, it is specified as '2002'.

[0176] Figure 3 (called "receive" for simplicity: it's actually a VM transmit) and Figure 4 The case (called "transmit" for simplicity: it's actually a VM receive) is a general example of the following situation:

[0177] A system architecture in which data (frames) are transmitted from a physical location to a virtual (realized) location ("received"), e.g. Figure 3 exemplified in ); and

[0178] A system architecture in which data (frames) are transferred from a virtualized location to a physical location ("transmission", e.g. Figure 4 exemplified in ).

[0179] Although this case is not illustrated in order to avoid making the present description too lengthy and complex, the solution as illustrated herein is also applicable for use in an architecture in which data (frames) are transferred between virtual (source and destination) locations.

[0180] Advantageously, if Figure 3 and Figure 4 The system architectures illustrated in each of the examples can be instantiated and used in conjunction so that Figure 4 The architecture illustrated in the example can be used in conjunction with Figure 3 The virtual machine (transmit) descriptor defined in the discussion is the same as the virtual machine (receive) descriptor of the same origin, ie, identified via the virtual machine port VMP tag in conjunction with the virtual machine extension identifier WMEID.

[0181] As used herein, the term "homologous" has its conventional meaning of identifying entities based on identical relationships or structures.

[0182] Furthermore, in order to avoid making this specification too lengthy and complicated, Figure 2 and its related instructions are provided as reference to Figure 3 and Figure 4 Related description.

[0183] Therefore, as long as Figure 3 and Figure 4 Consistent, combined Figure 2 The details of the parts and elements described will apply to Figure 3 and Figure 4 For the sake of brevity, the corresponding parts and components that appear in Figure 3 and Figure 4 Repeat the detailed description.

[0184] exist Figure 3 and Figure 4 In the example, reference 2003 and 2004 represent the virtual machine bridge VMB transmission (VMB Tx- Figure 3 ) and VMB receive (VMB Rx- Figure 4 )Circuit system:

[0185] Respectively include controllers 2003A and 2004A;

[0186] respectively including direct memory access (DMA) circuit systems 2003B, 2004B; and

[0187] Included are virtual / physical destination address facilities (configuration registers, DMA descriptors) 2003C, 2004C, respectively, which may be configured to utilize a virtual machine extension identifier (VMEID), as discussed below.

[0188] Optionally, the facilities 2003C, 2004C are capable of processing virtual stream identifiers (VSI) and virtual sub-stream identifiers (VSSID) (in the case of memory virtualization performed by the system memory management unit)

[0189] Figure 3 Virtual Machine Bridge Transmission Circuitry (VMB Tx) 2003 and Figure 4 The virtual machine bridge receiving circuit system (VMB Rx) 2004 can be configured to cooperate with the system memory 2008 to process data streams exchanged on the virtual machine port VMP (eg, a VM running on the SoC) Figure 3 AXIM writes and specifies 2003D Figure 4 AXIM read specified as 2004D in ).

[0190] Collaboration may occur with or without intervention of circuitry 2005 configured as a system memory management unit (SMMU), a network on chip (NOC), or a firewall.

[0191] The memory 2008 may be, for example, an SRAM (static random access memory), an SDRAM (synchronous dynamic random access memory), or a DDR (double data rate) memory configured to exchange physical address information (eg, AXIM) with the circuit system 2005 .

[0192] If provided, circuitry 2005 may facilitate sharing of profile page tables with peripheral devices, thereby providing virtual device support compatibility at the system level.

[0193] The data flow between VMB Tx, Rx circuitry 2003, 2004 and memory 2008 may occur via an (embedded) high-end direct memory access (DMA) (multi-channel) link. The AXI protocol may be a possible choice for this purpose. This may involve having an AXIM write phase ( Figure 3 ) and AXIM read phase ( Figure 4 )'s AXIM interface.

[0194] Thus, the system 2000 as discussed herein is an example of a system that includes:

[0195] Media Access Control (MAC) controller circuitry 2001 configured to provide a MAC port layer that controls the exchange of information over a data link (e.g., Ethernet / CAN / LIN); and

[0196] Virtual Machine Transmission VM Tx Bridge Circuit System ( Figure 3 2003) and the virtual machine receiving VM Rx bridge circuit ( Figure 4 2004), configured to cooperate with a memory (such as memory 2008) to process transmission / reception data streams from / to a virtual machine port (VMP).

[0197] That is, Figure 3 and Figure 4 The architecture shown in is configured as:

[0198] Data is sent via a data stream to the virtual machine port (VMP) (see Figure 3 AXIM in write) write to memory 2008; and / or

[0199] Data is read from memory 2008 via a data stream from a virtual machine port (VMP) (see Figure 4 AXIM in read).

[0200] Both the write and read phases may benefit from the availability of virtual address and virtual machine identifier (VMID) information, which may optionally include VSID and VSSID information as previously discussed.

[0201] exist Figure 3 In the architecture shown in , the path between the MAC controller 2001 and the virtual machine transmission VM Tx bridge circuit system 2003 includes a router 2002 (MAC protocol, MACP) and a write queue processor (WQHND) 2006A plus a read queue processor (RQHND) 2006B that cooperate with a local memory controller 2007 and related local memory, wherein the write queue processor (WQHND) 2006A and the read queue processor (RQHND) 2006B are arranged between the router 2002 and the VM Tx circuit system 2003.

[0202] In such Figure 4 In the architecture shown in , the path between the MAC controller 2001 and the virtual machine receive VMB Rx bridge circuit system 2004 includes a router 2002' and a write queue processor (WQHND) 2006A and a read queue processor (RQHND) 2006B that cooperate with the local memory controller 2007 and the relevant local memory, wherein the router 2002' is arranged between the VM Rx circuit system 2004 and the write queue processor (WQHND) 2006A, and the read queue processor (RQHND) 2006B is arranged between the memory controller 2007 and the MAC controller 2001.

[0203] It should be noted that the write queue processor 2006A and the read queue processor 2006B are configured to Figure 3 In the architecture shown in (“receive” - Rx, i.e., VM transmission) and in Figure 4 In the architecture shown in (“Transmit” - Tx, i.e. VM Receive) “swap” their roles.

[0204] In such Figure 3 In the architecture shown in:

[0205] The router or switch circuitry 2002 is coupled between the MAC controller circuitry 2001 and the queue processors 2006A, 2006B, wherein the queue processor 2006A is coupled to the router circuitry 2002 to receive the virtual machine port transmission signal VMP Tx therefrom; and

[0206] The signal VMP Tx is forwarded to the virtual machine bridge circuit (VMB Tx) 2003 via the read queue processor 2006B with the support of the local memory controller 2007 .

[0207] In such Figure 4 In the architecture shown in:

[0208] Router or switch circuitry 2002' is coupled between queue processors 2006A, 2006B and virtual bridge circuitry (VMB Rx) 2004;

[0209] Direct memory access receive information from virtual machine (VM) core 2009 is supplied to VM Rx circuitry 2004 (virtual destination address 2004C) in the form of DMARx descriptors; and

[0210] The write queue processor 2006A is coupled to the router circuit 2002 ′ to receive therefrom (from the virtual machine bridge 2004 ) the virtual machine port receive signal VM Rx (as the MACP Tx signal), which arrives at the read queue processor 2006B under the support of the local memory controller 2007 .

[0211] In both cases, the local memory controller 2007 may be configured as a multi-port memory controller to cooperate with the local memory LMEM (which is typically a distinct element from the networking accelerator 2000).

[0212] Figure 3 and Figure 4 The representation is an example of the possibility of using (in both cases) a routing table (RTB) or a forwarding database (FWD) 3000 to manage a networking accelerator 2000, for example, in a vehicle V (such as Figure 1 Instantiated in a central / domain / regional gateway in the architecture on a motor vehicle as shown in FIG.

[0213] The designated routing table (RTB) and forwarding database (FWD) are used (in relation to L3 and L2 operational contexts, respectively) to represent a data table 3000 stored in a router or network host that lists routes to network destinations.

[0214] The routing table / forwarding database may be stored in any manner known to those skilled in the art. Figure 3 and Figure 4 For example, the routing table / forwarding database may be stored in multiple memory banks associated with a dedicated memory controller (e.g., see Figure 2 1008 in FIG. 1004 ).

[0215] like Figure 3 and Figure 4 As illustrated in FIG. 3 , such a routing table / forwarding database 3000 may include the following fields:

[0216] 3000A-Control (CNTRL) includes enable and subnet mask data signals;

[0217] 3000B - Next Hop IP Address field (NH_DA); and

[0218] 3000C-Destination IP address field (IP_DA).

[0219] In case of a forwarding database (L2 switch), the fields IP_DA and NH_DA are replaced by the field ETH_DA (Ethernet Destination Address).

[0220] As discussed below, the routing table / forwarding database 3000 illustrated herein also includes additional fields, namely:

[0221] 3000D and 3000E - for frames to be transmitted (e.g., frames "received", i.e., frames transmitted by the VM, such as Figure 3 ) is routed to a virtual machine port (VMP); and

[0222] 3000F - Applies to frames to be transmitted (e.g., frames received by the VM, such as Figure 4 The case where the datagram is routed to a physical port (such as a MAC port, MACP) as illustrated in FIG.

[0223] The structure of table 3000 is common to both cases, but the fields involved are different.

[0224] The control data field (CNTRL) 3000A indicates whether to communicate (over the Ethernet / CAN / LIN link) using the IP address of the IP packet or the next hop IP address, which is intended to be mapped to the corresponding MAC address to be inserted into the Ethernet / CAN / LIN frame.

[0225] like Figure 3 The architecture shown in (jointly) utilizes two additional tags 3000D and 3000E, namely:

[0226] 3000D - Virtual Machine Extension Identifier, VMEID; and

[0227] 3000E - Virtual Machine Port, VMP.

[0228] like Figure 4 The architecture shown in utilizes tag 3000F, ie, MAC Port (MACP).

[0229] In such Figure 3 In the architecture shown in , virtual machine port transmission (VMP Tx) occurs from router / switch circuitry 2002 to write queue processor WQHND 2006A and from read queue processor RQHND 2006B to virtual machine bridge 2003 - configured for transmission (VM Tx) to block 2005 and then to memory 2008 - where:

[0230] Make fields / tags 3000A, 3000B, 3000C and 3000E available to the router / switch circuitry 2002 and the port (AXIM in the example considered) to the virtual machine bridge VM Tx 2003; and

[0231] Tags 3000D and 3000E are made available through the VMP Tx interface (status) to select the appropriate DMA Tx descriptor in the virtual machine bridge VM Tx 2003 to facilitate the AXIM transaction.

[0232] Therefore, tags 3000D and 3000E can be utilized to select DMA Tx descriptors to control DMA AXIM write transactions, and tag 3000E can also select the queue processor circuitry to allocate / select the physical queue mapped in LMEM. Tag VMP selects the physical resources for buffering / queuing, and tag VMEID selects only VM DMA Tx descriptors to implement router / switch virtualization, where the VMEID and VMP tags define the VMID propagated on the AXIM interface.

[0233] In such Figure 4 In the architecture shown in , virtual machine port reception (VMP Rx) occurs from virtual machine bridge circuitry 2004 (VMB Rx, configured to receive (VM Rx) from memory 2008 via circuitry 2005 (if present)) to router / switch circuitry 2002' and then to write queue processor WQHND 2006A and from read queue processor RQHND 2006B to MAC circuitry 2001, where:

[0234] fields / tags 3000A, 3000B, 3000C and 3000F linked to the (in the considered example AXIM) port of the router / switch circuitry 2002′ and thus to the virtual machine bridge VMB 2004, so that VM Rx descriptor selection into the virtual machine bridge 2004 can occur via software SW (e.g. in VM core 2009); and

[0235] Tags 3000D and 3000E are linked as DMA Tx descriptors to virtual destination address circuitry 2004C in virtual machine bridge (VMB Rx) circuitry 2004 to facilitate AXIM transactions, and tag 3000F is linked by router 2002' through the MACPTX interface (state) to select the appropriate QHND resources (queue and destination port).

[0236] In this case, table 3000 is not currently used for virtualization, and in the (purely exemplary) case considered here, the destination port is a MAC port.

[0237] The case of a "VM to VM" path (not visible for simplicity, but represents a possible embodiment) can be implemented as a combination of Figure 3 and Figure 4 Describes the combination of architectures.

[0238] In this case, the VMEID field / tag can be used twice, namely:

[0239] Select VM DMA Tx Descriptor in table 3000; and

[0240] The (homologous) VM DMARx descriptor is selected in / by VM core 2009 .

[0241] Parameters involved in instantiating a table (such as table 3000 illustrated herein) include:

[0242] AXIM_N: number of ports (e.g., AXIM) or virtual bridge (VMB) units;

[0243] AXIM_VMP_VN[AXIM_N-1:0]: the number of VMP ports per VMB unit;

[0244] AXIM_VMEID_VN[AXIM_N-1:0]: the maximum number of different VMEID tags supported by each VMB unit; and

[0245] AXIM_VM_VN[] = AXIM_VMP_VN[] * AXIM_VMEID_VN[] = the number of virtual machines, VM x AXIM_N.

[0246] In the arrangement shown herein, a VMP (Virtual Machine Port) tag 3000E is provided to link FLEX_SGS internal ports / queues 2007 (8=PCP queue in LMEM frame buffer), AXIM ports (such as the port coupled to line 2004A) and direct memory access (DMA) descriptors.

[0247] A Virtual Machine Port (VMP) tag 3000E can be linked / transported by each L3 frame (e.g., in case of an AXIM transaction). The same concept applies to switches for L2 frames (using the forwarding database FWD).

[0248] In the arrangement shown herein, the virtual machine extension identifier VMEID tag 3000D is used to link DMA descriptors without FLEX_SGS internal port allocation (in terms of queue control, queue buffers, interconnect resources, etc.): for example, multiple VMIDs can share the same queue (e.g., 8 queues) in the FLEX_SGS port / queue indicated by 2007.

[0249] Optionally, in an arrangement as shown herein, the VMEID tag 3000D may be linked / transported via each L3 frame (in the case of an AXIM transaction) where the virtual flow identifier VSID and the virtual sub-flow identifier VSSID are embedded in the DMA (Tx) descriptor supplied to the virtual machine bridge (VMB) 2004.

[0250] In this regard, the reference to the fields / tags VSID, VSSID is only for completeness. These fields are optional and can in principle be removed.

[0251] In an arrangement as shown herein, the VSID and VSSID tags may thus (optionally) be concatenated / transported by each L3 or L2 frame (eg, in the case of an AXIM transaction).

[0252] Partial virtualization and full virtualization are provided according to the tags VMEID (3000D) and VMP (3000E) entered in table 3000.

[0253] In an arrangement as shown herein, the bandwidth limiting factor in the fully virtualized case is mainly determined by the AXIM bandwidth and latency (network-on-chip, NOC) and the LMEM bandwidth.

[0254] Therefore, the number of virtual machines can be flexibly expanded as long as it is not constrained by the number of virtual machine ports (VMPs). For example, in the case of virtualization via VMEID tags, the eight priority code point (PCP) queues of each VMP can be shared by multiple virtual machines. The quality of service can be extended based on the stored procedure (SP), the complete base set (CBS) of the AXIM interface.

[0255] If the VMEID tag 3000D is not used, the arrangement as shown herein provides a degree of backward compatibility and can also be applied to L2 frame switches as an extension of the DA dynamic table.

[0256] Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what is described merely by way of example, without departing from the scope of protection.

[0257] The scope of protection is determined by the appended claims.

[0258] The system (2000) may include: a media access control (MAC) controller circuit system (2001) configured to provide a MAC port layer to control the exchange of information, wherein the exchange of information includes the transmission of data streams to a virtual machine port (VMP) via a data link (Ethernet / CAN / LIN); a virtual machine transmission (VM Tx) bridge circuit system (2003) configured to process transmission data streams to the virtual machine port (VMP); a transmission router / switch circuit system (2002) configured to route / switch data streams from the MAC controller circuit system (2001) to the VM Tx bridge circuit system (2003); and a queue processor circuit system (2006A, 2006B) configured to provide queue management of data streams between the MAC controller circuit system (2001) and the VM Tx bridge circuit system (2003), wherein the VM The Tx bridge circuit system (2003) includes a virtual destination address circuit system (2003C) configured to implement router / switch virtualization in the transmission router / switch circuit system (2002) based on a combination of a virtual machine port (VMP) tag (3000E) and a virtual machine extension identifier (VMEID) (3000D) indicating physical resources that can be selected for data flow transmission in the queue processor circuit system (2006A, 2006B) using a virtual machine transmission descriptor (2003C).

[0259] The system can be configured to transmit packets from the transport router / switch circuitry (2002) to the queue processor circuitry (2006A, 2006B) and from the queue processor circuitry (2006A, 2006B) to the VM Tx bridge circuitry (2003C). The data flow of the Tx bridge circuit system (2003) is used to realize data flow transmission to the virtual machine port, wherein the virtual destination address circuit system (2003C) is configured to: detect the virtual machine port (VMP) tag (3000E) and the virtual machine extension identifier (VMEID) (3000D); realize router / switch virtualization in the transmission router / switch circuit system (2002) via the virtual machine transmission descriptor (2003C) based on the combination of the virtual machine port (VMP) tag (3000E) and the virtual machine extension identifier (VMEID) (3000D); and select physical resources in the queue processor circuit system (2006A, 2006B) based on the virtual machine port (VMP) tag (3000E).

[0260] The virtual machine transport descriptor (2003C) may be linked to the virtual machine port (VMP) label (3000E) and the virtual machine extension identifier VMEID (3000D) as an entry in the routing table / forwarding database (3000).

[0261] The system can be configured to implement data stream transmission from a virtual machine receiving VMB Rx bridge (2004) to a receiving router / switch circuit system (2002') based on a virtual machine receiving descriptor that is homologous to the virtual machine transmitting descriptor (2003C), and the virtual machine receiving descriptor is preferably selected by a virtual machine (VM) core (2009) via software.

[0262] The system can be configured to implement data flow transmission to and from the virtual machine port in the following manner: based on the virtual machine transmit descriptor (2003C) obtained from the routing table / forwarding database (3000) to implement data flow transmission with data flow from the transmit router / switch transmit circuit system (2002) to the VM Tx bridge circuit system (2003); and based on the virtual machine receive descriptor selected by the virtual machine (VM) core (2009) to implement data flow transmission with data flow from the virtual machine receive VM Rx bridge (2004) to the receive router / switch circuit (2002').

[0263] The system (2000) may include a memory (2008), wherein the system may be configured to: write data (AXIM write) to the memory (2008) via a data stream to a virtual machine port (VMP); and / or read data (AXIM read) from the memory (2008) via a data stream from the virtual machine port (VMP).

[0264] A vehicle (V) equipped with an onboard communication network (100, 102, 104), wherein the network may include a system (2000) providing MAC / router / switch / gateway circuitry for the onboard communication network (100, 102, 104).

[0265] A method may include: controlling the exchange of information via a media access control (MAC) controller circuit system (2001) for providing a MAC port layer, the exchange of information including data stream transmission to a virtual machine port (VMP) via a data link (Ethernet / CAN / LIN); processing the transmission data stream to the virtual machine port (VMP) via a virtual machine transmission (VM Tx) bridge circuit system (2003); routing / switching the data stream from the MAC controller circuit system (2001) to the VMTx bridge circuit system (2003) via a transmission router / switch circuit system (2002); arranging the MAC controller circuit system (2001) and the VM Tx bridge circuit system (2003) via a queue processor circuit system (2006A, 2006B); The invention relates to a transmission router / switch circuit system (2002) and a transmission router / switch circuit system (2002) for implementing router / switch virtualization via a virtual destination address circuit system (2003C) in the VM Tx bridge circuit system (2003) based on a combination of a virtual machine port (VMP) tag (3000E) and a virtual machine extension identifier (VMEID) (3000D) indicating a physical resource selectable for data flow transmission in a queue processor circuit system (2006A, 2006B).

[0266] The method may include implementing data stream transmission from a virtual machine receive (VMB Rx) bridge (2004) to a receiving router / switch circuit system (2002') based on a virtual machine receive descriptor that is homologous to the virtual machine transmit descriptor (2003C), and the virtual machine receive descriptor is optionally selected by a virtual machine (VM) core (2009) via software.

[0267] The method may include implementing data flow transmission to and from a virtual machine port by: implementing data flow transmission with a data flow from the transmitting router / switch transmitting circuit system (2002) to the VM Tx bridge circuit system (2003) based on the virtual machine transmit descriptor (2003C) obtained from the routing table / forwarding database (3000); and implementing data flow transmission with a data flow from the virtual machine receiving VM Rx bridge (2004) to the receiving router / switch circuit system (2002') based on the virtual machine receive descriptor selected by the virtual machine (VM) core (2009).

[0268] The various embodiments described above can be combined to provide further embodiments. All U.S. patents, U.S. patent application publications, U.S. patent applications, foreign patents, foreign patent applications, and non-patent publications cited in this specification and / or listed in the Application Data Sheet are incorporated herein by reference in their entirety. If necessary, aspects of the embodiments can be modified to adopt the concepts of the various patents, applications, and publications to provide further embodiments.

[0269] These and other changes can be made to the embodiments in light of the above detailed description. In general, in the following claims, the terms used should not be interpreted to limit the claims to the specific embodiments disclosed in the specification and claims, but should be interpreted to include all possible embodiments and the full range of equivalents to which these claims are entitled. Therefore, the claims are not limited by the present disclosure.< / x> < / interface> < / x>

Claims

1. A system comprising: a media access control (MAC) controller circuitry configured to provide a MAC port layer to control the exchange of information, wherein the exchange of information includes transmission of a data stream over a data link to a virtual machine port (VMP); a virtual machine transmit (VM Tx) bridge circuitry configured to handle transmit data flows to a virtual machine port VMP; a transport router / switch circuitry configured to route or switch data streams from the MAC controller circuitry to the VM Tx bridge circuitry; as well as a queue processor circuitry configured to provide queue management of data flows between the MAC controller circuitry and the VM Tx bridge circuitry, The VM Tx bridge circuitry includes a virtual destination address circuitry configured to implement virtualization of a router or switch in a transport router / switch circuitry using a virtual machine transport descriptor based on a combination of a virtual machine port (VMP) tag and a virtual machine extension identifier (VMEID) indicating a physical resource in a queue processor circuitry that is selectable for data stream transmission.

2. The system of claim 1, wherein the system is configured to implement data stream transmission to the virtual machine port with virtual destination address circuitry in the VM Tx bridge circuitry for data streams from the transport router / switch circuitry to the queue processor circuitry and from the queue processor circuitry to the VM Tx bridge circuitry, wherein the virtual destination address circuitry in the VM Tx bridge circuitry is configured to: Detect both VMP tag and VMEID; Virtualizing a router or switch in a transport router / switch circuitry via a virtual machine transport descriptor based on a combination of a VMP tag and a VMEID; and A physical resource in the queue processor circuitry is selected based on the VMP tag.

3. The system of claim 1, wherein the virtual machine transport descriptor is linked to the VMP label and the VMEID as an entry in a routing table or forwarding database.

4. The system of claim 1, wherein the system is configured to implement data stream transmission for a data stream from a virtual machine receive (VMB Rx) bridge to a receiving router / switch circuit system based on a virtual machine receive descriptor that is cognate with a virtual machine transmit descriptor, the virtual machine receive descriptor being selected by a virtual machine (VM) core via software.

5. The system of claim 4, wherein the system is configured to implement data streaming to and from the virtual machine port by: implementing data flow transmission with data flow from the transport router / switch transport circuitry to the VM Tx bridge circuitry based on the virtual machine transport descriptor obtained from the routing table or forwarding database; Data streaming is accomplished with data flows from the VM Rx bridge to the receiving router / switch circuitry based on the virtual machine receive descriptor selected by the VM core.

6. The system of claim 1, comprising a memory, wherein the system is configured to perform at least one of the following: Writing data to memory via a data stream to the VMP; and / or Data is read from memory via a data stream from the VMP.

7. A vehicle equipped with an on-board communications network, wherein the network includes the system of claim 1 to provide MAC / router / switch / gateway circuitry for the on-board communications network.

8. A method comprising: controlling exchange of information, the exchange of information comprising transmission of a data stream via a data link to a virtual machine port (VMP) via a media access control (MAC) controller circuitry, the MAC controller circuitry being configured to provide a MAC port layer; Processing of transmission data flow to the VMP via a virtual machine transmission (VM Tx) bridge circuitry; routing or switching data streams from the MAC controller circuitry to the VM Tx bridge circuitry via the transport router / switch circuitry; providing queue management for data flow between the MAC controller circuitry and the VM Tx bridge circuitry via the queue processor circuitry; as well as Virtualization of a router or switch in a transport router / switch circuitry is achieved via a virtual destination address circuitry in a VM Tx bridge circuitry using a virtual machine transport descriptor based on a combination of a virtual machine port (VMP) tag and a virtual machine extension identifier (VMEID) indicating a physical resource in a queue processor circuitry that can be selected for data stream transmission.

9. The method of claim 8, comprising implementing data stream transmission with a data stream from a virtual machine receive (VMB Rx) bridge to a receiving router / switch circuitry based on a virtual machine receive descriptor cognate with a virtual machine transmit descriptor, the virtual machine receive descriptor being selected by a virtual machine (VM) core.

10. The method of claim 9, comprising implementing data stream transmission to and from the virtual machine port by: implementing data flow transmission with data flow from the transport router / switch transport circuitry to the VM Tx bridge circuitry based on the virtual machine transport descriptor obtained from the routing table or forwarding database; and Data flow transmission is implemented based on the VM receive descriptor selected by the VM core to flow data from the VM receive VM Rx bridge to the receiving router / switch circuitry.

11. A collection of non-transitory computer-readable media storing content that, when executed by one or more processors, causes a method to be performed, the method comprising: controlling exchange of information, the exchange of information comprising transmission of a data stream via a data link to a virtual machine port (VMP) via a media access control (MAC) controller circuitry, the MAC controller circuitry being configured to provide a MAC port layer; Processing of transmission data flow to the VMP via a virtual machine transmission (VM Tx) bridge circuitry; routing or switching data streams from the MAC controller circuitry to the VM Tx bridge circuitry via the transport router / switch circuitry; providing queue management for data flow between the MAC controller circuitry and the VM Tx bridge circuitry via the queue processor circuitry; as well as Virtualization of a router or switch in a transport router / switch circuitry is achieved via a virtual destination address circuitry in a VM Tx bridge circuitry using a virtual machine transport descriptor based on a combination of a virtual machine port (VMP) tag and a virtual machine extension identifier (VMEID) indicating a physical resource in a queue processor circuitry that can be selected for data stream transmission.

12. A collection of non-transitory computer-readable media as described in claim 11, wherein the method includes implementing data stream transmission based on a virtual machine receive descriptor that is homologous to a virtual machine transmit descriptor to implement data stream transmission from a virtual machine receive (VMB Rx) bridge to a receiving router / switch circuit system, the virtual machine receive descriptor being selected by a virtual machine (VM) core.

13. The collection of non-transitory computer readable media of claim 12, wherein the method comprises implementing data streaming to and from the virtual machine port by: implementing data flow transmission with data flow from the transport router / switch transport circuitry to the VM Tx bridge circuitry based on the virtual machine transport descriptor obtained from the routing table or forwarding database; and Data flow transmission is implemented based on the VM receive descriptor selected by the VM core to flow data from the VM receive VM Rx bridge to the receiving router / switch circuitry.

Images