Patent Application
20240095057
This application claims the benefit of Italian Patent Application No. 102022000019233, filed on Sep. 20, 2022, which application is hereby incorporated herein by reference.
The description relates to communication networks and methods for use in the automotive sector, for instance. Examples as discussed herein facilitate providing a flexible, safe and scalable system architecture for an optimized Ethernet router/switch/gateway for high-speed automotive networks.
The ever-increasing use of sophisticated electronics in the automotive sector has stimulated a continuous trend towards solutions that are:
An object of one or more embodiments is to contribute in providing further improvements in the context discussed in the foregoing.
According to one or more embodiments, such an object is achieved via network architecture (essentially, architecture of a communication system) having the features set forth in the claims that follow.
One or more embodiments relate to a corresponding vehicle. A motor vehicle equipped with an on-board communication network, wherein the network comprises a system as exemplified herein to provide MAC/router/switch/gateway features for such an on-board communication network may be exemplary of such a vehicle.
The claims are an integral part of the technical teaching provided herein in respect of the embodiments.
Examples as discussed herein offer one or more of the following advantages:
Examples as discussed herein provide static configurability of critical parameters of IP cores along with open and flexible architecture (u-architecture) that facilitates functional extension of gateway capabilities.
One or more embodiments will now be described, by way of example only, with reference to the annexed figures, wherein:
Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated.
The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.
The edges of features drawn in the figures do not necessarily indicate the termination of the extent of the feature.
In the ensuing description, various specific details are illustrated in order to provide an in-depth understanding of various examples of embodiments according to the description. The embodiments may be obtained without one or more of the specific details, or with other methods, components, materials, etc. In other cases, known structures, materials, or operations are not illustrated or described in detail so that various aspects of the embodiments will not be obscured.
Reference to “an embodiment” or “one embodiment” in the framework of the present description is intended to indicate that a particular configuration, structure, or characteristic described in relation to the embodiment is comprised in at least one embodiment. Hence, phrases such as “in an embodiment”, “in one embodiment”, or the like, that may be present in various points of the present description do not necessarily refer exactly to one and the same embodiment. Furthermore, particular configurations, structures, or characteristics may be combined in any adequate way in one or more embodiments.
The headings/references used herein are provided merely for convenience and hence do not define the extent of protection or the scope of the embodiments.
Hardware (HW) networking of different automotive communication protocols (Ethernet, LIN, CAN, FlexRay, . . . ) is gradually migrating from a heterogeneous architecture of modules arranged around a central “hub” (gateway/switch) H—as illustrated in
The exemplary hierarchical topology illustrated in
In networks for use, e.g., in the automotive sector, various protocol layers, designated L1 to L7, can be defined as follows:
For instance:
It is noted that:
The designation IP (intellectual property) core—or, briefly IP—is currently applied to a block of logic or data that can be used in producing a field programmable gate array (FPGA) or application-specific integrated circuit (ASIC) for a semiconductor device. IP cores are essentially re-usable and portable: a certain IP core is expected to be easily be inserted into any technology or design methodology. IP cores can be used, for instance, in Ethernet controllers, peripheral component interconnect PCI interfaces, universal asynchronous receiver/transmitter (UART) modules, or central processing units (CPUs), for instance.
As discussed in the introductory portion of the present description, in recent years, in-vehicle networking has gone through extensive development to keep up with requirements of next generation vehicles (e.g., new autonomous driving and entertainment systems).
These developments involve all aspects of in-vehicle networking technology, from the introduction of new physical layer technologies (e.g., Multi-Gigabit Automotive Ethernet) to the development of new network topologies, thus affecting the entire automotive industry supply chain from silicon vendors to OEMs.
Referring to the automotive scenario (this will be considered by way example throughout the present description, being otherwise understood that the embodiments are not restricted to use in the automotive scenario), emerging multimedia/safety applications converge on an Ethernet backbone in addition to conventional communication links (CAN, FlexRay, LIN). As a consequence, micro-controllers for body/chassis/power train applications can take advantage of the availability of networking accelerators based on the Ethernet protocol, including gateway functionalities, security and safety features that facilitate meeting specifications such as Automotive Safety Integrity Level (ASIL) “B” grade.
Existing network accelerators based on conventional devices (switches for consumer/industrial applications may be exemplary of these) can be hardly considered for integrating in a single device/IP core or block all the features specifically required in automotive (safety, gateway functionalities).
Conventional hardware (HW) network accelerators do not generally support a gateway functionality (LIN/CAN/FlexRay over Ethernet), switch/router (L2+) functionalities and ASIL-B safety grade.
Conversely, a purely software-based (SW-based) approach relying on software cores (e.g., using a multi-core platform) involves very high clock frequencies, and may not satisfy performance and Quality-of-Service (QoS) requirements as desirable for the related applications. This may be especially the case of high-end configurations with multiple media access control (MAC) Ethernet ports at high-speed rate (Gbit/s or higher).
More generally, conventional solutions suffer from various drawbacks.
For instance, certain solutions require adaptation (that is, optimization in terms of area and/or power consumption) for a specific use case/application/device.
Certain solutions require developing specific bridges, wrappers or interfaces in order to provide a plug-and-play solution for use in an existing micro-controller reference platform.
These solutions are hardly suitable for use in situations where gateway functionalities are still in the process of being ultimately defined, which may occur in the automotive sector.
Also, additional effort/costs may be involved in meeting with end-customer requests for adaptation of a certain IP solution.
The examples discussed herein present system architecture providing a flexible, safe, secure, and highly configurable network accelerator that is ready to address the requirements of next-generation automotive gateways.
System architecture as exemplified herein is applicable to a variety of networking applications (such as central switch, domain/zone switch/gateway devices, for instance) where hardware (HW) acceleration of networking tasks is beneficial in facilitating improved performance in terms of bandwidth allocation, minimum latency and quality of service of the incoming/outcoming data/audio/video streams.
Examples as discussed herein facilitate (in view of prospected use in next-generation automotive gateways, for instance) integrating a flexible and secure HW network accelerator that is capable of routing traffic with reduced central processing unit (CPU) intervention and at the same time capable of handling different in-vehicle networking technologies (e.g., CAN, Ethernet).
Micro architecture as discussed herein facilitates implementing a flexible multilayer (L2+), e.g., automotive Ethernet switch with high quality of service (QoS) functionalities complying with audio-video bridging (AVB) and time-sensitive networking (TSN) specifications.
In addition to the ability of supporting traffic between multiple media access control (MAC) physical ports (e.g., Ethernet, CAN, LIN) another feature of architecture as discussed herein is provided by the implementation of internal system-on-chip (SoC) virtual machine (VM) ports to route L2/L3 traffic generated and consumed by virtual machines (VMs) each running on a different SoC core.
A more detailed description of system architecture as exemplified herein will now be provided in connection with
The acronyms appearing throughout this description are well known to those of skill in the art. The meaning of acronyms appearing in the following lists of features and the drawings is reproduced in Table I below for immediate reference.
Throughout this description and the claims appended thereto, the designation “wrapper” will be used in its current meaning to designate a hardware module (software configurable) that “wraps” one or more other modules or features thus acting as an intermediary between its own clients (that use the wrapper interface) and the wrapped module(s) that implement the requested functions as a deputy of the wrapper object.
System architecture as exemplified in
HW network accelerator: packet forwarding at wire speed, non-blocking, high performance;
The following is a list of the main sub-blocks included in a networking accelerator 1000 as illustrated in
Reference number 1001 collectively designates a set of internal Ethernet/LIN/CAN/other MAC controllers (#1 to #N, with N=32, for instance). These controller (clocked by a precision time protocol timer 1001A) control data exchange over an Ethernet/LIN/CAN/other data link—not visible in the figures.
Reference number 1002 collectively designates Ethernet/LIN/CAN/other MAC “wrappers” (#1 to #N, with N=32, for instance) including MAC translator and (L2/L3) frame router features, designated 1002A and 1002B, respectively.
The MAC translator features 1002A act between the MAC controllers 1001 and the frame router features 1002B.
Reference number 1003 collectively designates virtual machine (VM) wrappers (#1 to #M) including MAC translator and frame router (L2/L3) features indicated 1003A and 1003B, respectively.
The MAC translator features 1003A act between the frame router features 1003B and a virtual machine (VM) bridge (e.g., AXIM translator) blocks collectively designated 1004 that include direct memory access (DMA) features to interface with SoC internal virtual machines (VMs—not visible in the figure) via an AXIM interface.
Architecture as illustrated in
Reference numbers 1006A, 1006B and 1006C designate three sets of (e.g., sixty-five) queue handlers for the queue management and QoS functionalities in cooperation with a local memory controller 1007.
As exemplified herein, the local memory controller 1007 can be configured as a multi-port memory controller to access the SRAM/frame buffer in a local memory LMEM (usually this is a distinct element with respect to architecture 1000).
As illustrated in
Reference 1008 in
Architecture as illustrated in
Multiple (4×) functional layer architecture for a gateway/switch/router architecture as exemplified herein can be implemented to include a number of sections (sub-systems).
A first section is an Ethernet/LIN/CAN/VM/Other MAC port layer, e.g., the MAC controllers 1001 and the MAC wrappers 1002.
This section can implement a conventional data link (e.g., Ethernet/CAN/LIN) layer for a specific protocol as well as a proprietary data link interface to transfer status/header/payload for each frame which can be exposed to the next layer (MAC generic frame layer).
Another section is a MAC (generic) frame layer for switch (L2)/routing(L2+) functions (physical/virtual machine/configuration host destinations), e.g., the virtual machine (VM) wrappers 1003.
As exemplified herein, this layer includes two distinct sub-sections, namely:
Advantageously, the interface between the switch/router 1003B and the QHND is a point-to-point interface, defined as Tx_frame interface and Rx_frame interface.
As exemplified herein, a queue (data, status) handler layer (QHND) per destination port (Ethernet/LIN/CAN/VM, namely 1006B) and configuration host port (namely 1006C), is provided to implement the QoS function.
Each data/status queue is re-mappable based on the frame priority, and is configurable in terms of size, base address, filling/emptying thresholds, for mapping in the memory LMEM.
Filling/emptying/underflow/overflow status can be monitored by asserting interrupts.
As exemplified herein, each QHND layer (e.g., 1006A, 1006B, 1006C) includes two sub-sections (write and read), namely a write QHND and a read QHND.
The 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 safety mechanisms. The frames delivered to a same destination port with a different queue index are concurrently delivered to the next layer (multi-port memory controller).
The read QHND implements the QoS for the outgoing frames to any Ethernet/LIN/CAN/VM/Other MAC port. The scheduler supports different types of algorithms: strict priority, WRR (weighted round robin) according to the related standards.
As exemplified 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 case of contention/bandwidth limitation on the LMEM memory and/or in cut-through mode; the Tx_frame interface (point to point) includes flow control, data, attributes, frame alignment, frame status, timestamp and safety mechanisms.
As exemplified herein, a multi-port memory controller layer 1007 is provided for bandwidth optimization according to the overall 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 per destination port and per queue that includes flow control, data, address, access type, safety mechanisms.
As exemplified herein, the virtual machine bridge (VMB) 1004 implements a bridge to transmit/receive L2/L2+ frames to/from a virtual machine mapped at SoC level (not visible in the figure) on a multi-core architecture. The L2/L2+ frames are memory mapped in a system memory (SMEM, not visible in the figures) and the virtual machine bridge 1004 is controlling the control/data flow from/to such a memory via an AXIM interface, to/from the internal switch via data link interface.
A VMB-RX direct memory access (DMA) as exemplified herein supports multi-channel (multi-frame buffers in system memory linked to multiple DMA descriptors) and/or multi-frames (linked to a single DMA descriptor) for data flow transfer.
A VMB-TX DMA as exemplified herein supports multi-channel (multi-frame buffers in system memory linked to multiple DMA descriptors) and/or multi-frames (linked to a single DMA descriptor), and dynamic transfer (ingress frame linked to a DMA descriptor depending on the frame attribute, e.g., priority, UDP/TCP port, . . . ) for data flow transfer.
The virtual machine port (VMP) thus implemented corresponds to a MAC port. Thanks to the frame routers 1003B, frames such as L2/L2+ frames can be delivered from/to any VM/MAC port.
System architecture as exemplified herein lends itself to implementing, for instance, the following data flows:
In system architecture as exemplified herein, the embedded AXIM DMA features 1004A can be shared (depending on the static configuration) over multiple virtual machine ports (VMP) and support the L2/L2+ frames delivery from/to SMEM in streaming mode by N-channels configured by (VMB-RX) or N*D (VMB-TX) descriptors of the DMA to control the Xfer features such as base/start address, burst length, frame max/actual length, number of frames, frame type, etc.
A hierarchical (two-layer) round-robin arbitration scheme can be implemented in the queue handlers 1006B to grant the AXIM on the VM port (first layer with higher priority) and (second layer with lower priority) on the DMA channel.
In system architecture as exemplified herein, AXIM transactions linked to each VM port are protected by a VMID identifier to grant the access to the memory regions allocated for the VM (isolation function) ports.
In system architecture as exemplified herein, the configuration host port 1005 is configurable via AXIS slave port or embedded DMA, e.g., as AXIS slave port or AXIM master port (via an internal DMA).
A memory map interface is implemented to allow L2/L2+ frames delivery by the host equivalently to any Ethernet/LIN/CAN/VM/Other MAC port.
In case of incoming frames handled as SW frames (e.g., DA=multicast address per control frame), in system architecture as exemplified herein the configuration host can automatically deliver the frame response with DA=multicast address on all the ports that have received the frame with/without bypassing the forwarding database.
A timestamp (TS) optionally captured on the input port of any physical MAC port (e.g., Ethernet) can be delivered via a status queue (internal switch) to the related physical MAC destination port to support in HW w/o SW intervention the PTP end-to-end transparent clock 1-step mode protocol.
In system architecture as exemplified herein:
Advantageously, two policies are available (SW configurable) for the flush mechanism:
It is noted that, while listed together and optionally combined, the joint presence of these features is not mandatory.
In system architecture as exemplified herein, a gateway functionality for LIN/CAN/other protocols (FEATURE on-development) may be provided wherein:
It is again noted that, while certain features of the examples presented herein are listed together and combined, the joint presence of these features is not mandatory.
System architecture as exemplified herein is statically configurable in respect of parameters such as, e.g., number of MAC ports, number of VM ports, number of AXIM interfaces (DMA), number of queues, number of LMEM ports, and/or L2/L2+ forwarding database size.
Advantageous functional safety (FUSA) features (e.g., 1009, 1010) of system architecture as exemplified herein may include:
Once more, certain features of the examples presented herein being listed together and combined does not imply that the joint presence of these features is mandatory.
System architecture as exemplified herein, provides a number of advantages over existing commercial solutions.
These advantages include, for instance:
Examples as discussed herein provide an optimized and safe solution in terms of area, power consumption (clock frequency) and performance or quality of service in terms of latency and bandwidth for a specific automotive networking use case (central switch, domain gateway or any hybrid use).
Examples as discussed herein provide scalability of a networking solution in terms of number of communication ports, protocol types and bandwidth requirements in order to facilitate achieving an adequate trade-off between cost and performance and high reusability for different use cases (devices, applications).
As noted, possible advantageous features of examples as presented herein include the following:
In examples herein, gateway operation involves flexible HW/SW encapsulation/decapsulation of FlexRay/CAN/LIN protocols into/from IEEE 802.3 Ethernet frames and interfaces such as AXIS, AXIM, APB-coresight, SPP-DMA, APB secure port Ethernet 10/100/1000 Mbps PHYs (RMII, RGMII, . . . )—MAC embedded—CAN, LIN, FlexRay PHYs.
Safety and debug capabilities include ASIL-x configuration (CRC, lockstep, watchdog), performance monitors and data flow breakpoint.
As discussed, possible advantageous features of examples as presented herein include:
In terms of implementation, area/gate/memory size can be based on a static configuration with a core clock frequency targeted at in the range of MHz (depending on FLEX_SGS configurations, MAC/VM ports, connectivity, speed).
Standard compliancy may include:
Without prejudice to the underlying principles, the details and embodiments may vary, even significantly, with respect to what has been described by way of example only without departing from the extent of protection.
The extent of protection is determined by the annexed claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 102022000019233 | Sep 2022 | IT | national |
