Hardware-based efficient data transfer

Abstract

The present invention relates to a transmitting device for efficient data transfer in a motor vehicle, which allows for efficient transmission of data over a single physical channel, e.g., 128 virtual data paths. The proposed invention creates a unidirectional device, which, due to its reduced complexity, can be provided with minimal technical effort. The invention particularly focuses on the requirements of motor vehicles, where low weight and high fault tolerance are required. The weight reduction is achieved by simplifying conventional units, so that only a single physical path is required, while the device can handle 128 virtual data paths. According to the invention, robustness against faults is achieved by making the structural components unidirectional, which can therefore be particularly easily produced without error-prone structural features. The invention further relates to a system configuration comprising an input device in the transmitting direction that is partially functionally opposite to the output device in the receiving direction, packet data processing devices in the transmitting and receiving directions, the proposed transmitting device, and the proposed receiving device. Furthermore, a method suitable for a manufacturing plant for providing the system configuration or the input and output devices, and a computer program product comprising the method steps are proposed. Furthermore, a computer-readable medium containing control instructions is proposed.

Description

[Technical Field]

[0001] The present invention relates to a transmitting device for efficient data transmission within a motor vehicle, which allows for the efficient transfer of data over a single physical channel, e.g., 128 virtual data paths. The proposed invention creates a unidirectional device, which, due to its reduced complexity, can be provided with minimal technical effort. The invention particularly focuses on the requirements of motor vehicles, where weight reduction and high fault tolerance are required. Weight reduction is achieved by simplifying conventional units, so that only a single physical path is required, while the device can handle 128 virtual data paths. According to the invention, robustness against faults is achieved by making the structural components unidirectional, which can therefore be particularly easily produced without error-prone structural features. The invention further relates to an input device in the transmitting direction, which is partially functionally opposite to the output device in the receiving direction, and a packet data processing device in the transmitting and receiving directions, as well as a system configuration comprising the proposed transmitting device and the proposed receiving device. Furthermore, a method suitable for a manufacturing plant for providing the system configuration or the input and output devices, and a computer program product comprising the method steps, are proposed. Additionally, a computer readable medium containing control instructions is proposed. [Background technology]

[0002] US Pat. No. 5,649,999 shows a multi-protocol interface with multiple components and bidirectional data paths. In the state of the art, various solutions are known that realize data communication using software. For this purpose, there are various state of the art solutions having components implemented either by software or by hardware.

[0003] In particular, software implementations can be more effortful and increase the complexity of the underlying circuitry. Such applications are targeted, for example, at application scenarios where flexibility is required and dynamic packet switching needs to be implemented.

[0004] State-of-the-art methods often use proprietary standards designed for high-performance computer networks that do not meet automotive requirements and are therefore generally unsuitable for use in automobiles. Automobiles impose completely different requirements on real-time data transmission and robustness against errors. Methods for transmitting video data are typically designed for end users with powerful computer systems. In such application scenarios, large amounts of hardware are typically available, and energy consumption plays a subordinate role. On the other hand, automobiles must be lightweight, offer high reliability, and conserve energy. For electric vehicles, high energy consumption directly translates into a reduced vehicle range. In this regard, the state-of-the-art needs to create devices that generate data efficiently in many respects, with little technical effort.

[0005] All of these technologies given as examples are optimized for the transmission of one data type (video, audio, SPI, Ethernet), and "bridging" from one interface (e.g., DisplayPort) to another interface with the same data type (e.g., HDMI) is not possible.

[0006] At the same time, electronic systems in vehicles have become increasingly complex, more powerful, and more "data intensive" over the decades. Effective and rapid networking of display units, actuators, sensors and processing units plays a central role here, if not the determining role in system performance.

[0007] The display unit, sensors and actuators, and the associated processing unit are located relatively far apart in the vehicle. If a separate communication solution between the sensors / actuators and the processing unit (GPU / CPU) is realized for each interface, like in a PC or a mobile phone (state of the art as mentioned above), this means a huge amount of cabling (weight) with mostly limited performance due to spatial distances.

[0008] To reduce the weight of cables and connectors, it is necessary to bundle data connections into one and the same cable system. For one and the same type of data, these are classical SERDES solutions (state of the art), i.e. systems for transmitting data serially at gigabit data rates.

[0009] A universal solution is needed to aggregate different data paths, rather than solutions specific to a data type (video, audio, etc.). To maximize the reuse of complex data path logic, the multitude of data interfaces, both existing and emerging, must be mapped to a standardized universal interface.

[0010] There is therefore a need to create devices, system configurations and processes that do not present the drawbacks mentioned above and that can be used in a particularly advantageous way in motor vehicles. [Prior art documents] [Patent documents]

[0011] [Patent Document 1] US Patent Application Publication No. 2013 / 0101058 Summary of the Invention [Problem to be solved by the invention]

[0012] It is therefore an object of the present invention to provide a transmitting device that can be implemented particularly efficiently and saves hardware resources, particularly for use in automobiles. It is also an object of the present invention to provide a receiving device that is partially functionally inverse to the transmitting device, as well as a system configuration in which all devices are combined with each other. It is also an object of the present invention to provide a method for providing the device, as well as a computer program product with a computer-readable storage medium. [Means for solving the problem]

[0013] This problem is solved by the features of claim 1. Further advantageous embodiments are described in the dependent claims. Therefore, an input device in a transmission direction for efficiently transmitting data in a motor vehicle is proposed, the input device comprising: an input interface device having a plurality of input interface units having a first group of input interface units each configured in hardware to receive continuous data and a second group of input interface units each configured in hardware to receive discontinuous data; a packetization device configured to segment the data and enhance the data with forwarding information and data protection information; a packet data processing device of the packetization device for forwarding the data; and an output device arranged in the transmission direction for providing the data to a physical transmission channel, wherein the input interface device, the packetization device, and the output device are unidirectionally communicatively coupled.

[0014] The proposed input device in the transmission direction is particularly efficient in terms of data transmission, since its structure is designed so that data is transmitted in only one direction, rather than bidirectionally, as is the case in the prior art. This simplicity of the input device allows for a particularly efficient implementation, requiring only two types of input interfaces. These input interfaces are of different types and are optimized to receive either continuous or discontinuous data. Furthermore, the packetizer, also referred to as a packet data processor or packet data processor, can be controlled so that only one physical data channel is required. When multiple data paths are used, the present invention allows for the establishment of up to 128 virtual data paths on this one physical data channel. This results in a particularly high level of fault tolerance and lightweight design, since it is not necessary to maintain many physical paths, but only a single physical data channel.

[0015] Data is received at an input interface device, passes through the input device in the transmit direction, is multiplexed with packet data from other input interface devices in a packet data processing device, and is forwarded to be output at an output device in the transmit direction. Multiplexing refers to sending multiple signals or information streams simultaneously on a line in the form of a single composite signal, and then splitting them again into separate signals at the receiving end. Thus, according to the present invention, packet data from multiple input interface devices is combined.

[0016] Further processing steps may be performed as the data passes through, in particular the data may be extracted or processed in a packet data processing device, for example the packet data processing device may be coupled to an input device to output a corresponding signal.

[0017] An input interface device has multiple input interface units. This means that the input interface device can receive data of different virtual channels via multiple physical data channels, with each virtual channel assigned to an input interface unit. Generally, input interface devices or input interface units are implemented to receive either continuous or discontinuous data. The technical differences between these interfaces relate, for example, to the size of the buffer memory or volatile memory provided. Therefore, there are generally two groups of input interface units: one group for receiving continuous data and the second group for receiving discontinuous data. Generally, all data is received through the input interface device. The continuous data stream can be, for example, video data, and the discontinuous data can be control instructions. According to one aspect of the present invention, the two groups of input interface units can be differentiated such that the first group provides faster processing units than the second group. This allows continuous data to be processed with larger memory and / or faster processing power than when processing discontinuous data.

[0018] Furthermore, a segmentation unit is provided that is configured to generate data packets, whereby data packet specific information is provided. This can be information about addressing or routing, or information for protecting the data packet specific information. The data packet specific information can be protected, for example, by a checksum. According to one aspect of the invention, the data packetization is also controlled by the segmentation unit. This means that the application data is formatted into packet data (data cells) and / or the bit width is adjusted.

[0019] A subsequent packet data processing device (Crossbar Unit) according to one aspect of the present invention complements the data packet specific information with forwarding information specifying the destination to which the data is forwarded. This can be static routing, which is particularly efficient to implement. Dynamic routing requires a great deal of technical effort and cannot be implemented efficiently by input devices.

[0020] Furthermore, according to one aspect of the present invention, there is provided an output device (Line Coding & Framer Unit) configured to provide data to a physical transmission channel. The output device is configured in hardware to receive data from a packet data processing device (crossbar unit) and then output the data. The output can be sent, for example, to a proposed output device in a transmit direction. For this purpose, the output device comprises an input device in the transmit direction. The output device is implemented to process, output and / or provide packaged data from the packet data processing device (crossbar unit) to a physical transmission channel. The physical transmission channel can be a cable, and the output device also provides an interface for the cable.

[0021] The input interface devices (burst data interface, stream data interface), packetizer (segmentation unit), packet data processing device (crossbar unit) and output device (line coding and framer unit) are connected to transfer data in one direction, i.e. input data from the input interface devices are transferred to the packetizer and packet data processing device and can then be output using the output device. No data flow in the reverse direction is provided. This allows a particularly efficient implementation of the proposed input device.

[0022] The present invention provides, inter alia, the following advantages: - The modules can be extended using application interfaces without changing the data path logic (while still ensuring compatibility and adaptability with existing systems). It is possible to use any phys with different bandwidths without changing the data path logic (adaptability and compatibility with existing systems remains guaranteed). -Hardware solutions for adaptation to any application interface reduce software efforts and ensure high and efficient data throughput.

[0023] According to one aspect of the invention, the number of interface units is between 2 and 128, and / or there are up to 128 virtual data paths to the input interface units. This has the advantage that the hardware requirements can be minimized, so that only a single physical interface is required, yet 128 virtual data paths can be configured. Also, the number of interface units can be varied, in which case there must be at least one input interface unit of the first group and at least one input interface unit of the second group. This allows optimal processing of both contiguous and non-contiguous data.

[0024] According to a further aspect of the present invention, the input interface device, the packetization device, the packet data processing device, and / or the output device are implemented in hardware. This has the advantage that it is not necessary to implement complex circuits that store and execute software instructions. Instead, the devices can be hard-coded and therefore operate efficiently. Since the devices do not need to handle dynamic processes, they can be provided with little technical effort. This means that all units can be provided hard-wired. This also improves reliability and reduces energy requirements.

[0025] According to a further aspect of the present invention, all units and devices transmit data in only one direction. This has the advantage that structural features can be implemented particularly efficiently. One-way data transmission also ensures that no protection mechanisms need to be provided, since data flow is only possible in one direction. Therefore, defective data cannot be transmitted in the opposite direction, which provides a simple protection mechanism.

[0026] According to a further aspect of the present invention, continuous data can be used as streaming data, and discontinuous data can be used as burst data. This has the advantage that hardware can be adapted to a corresponding transmission concept, thus providing optimized hardware. Thus, the hardware can meet the special requirements of streaming data or burst data. In particular, streaming data has high demands for real-time transmission, since video data is subject to noticeable delays. Mechanisms can be implemented to ensure that streaming data is transmitted continuously, while burst data allows for the suspension of data transmission. Buffer memories can be configured accordingly.

[0027] According to a further aspect of the invention, continuous data has frames (e.g., Hsync, Vsync, DE for video) that segment the continuous data, while discontinuous data typically does not have frame information since it has an implicit beginning and end due to the burst-like data structure. Thus, for continuous data, a particularly efficient circuit is realized that provides hardware-implemented logic that appends frame information to data packets. The same mechanism can optionally be used for discontinuous data to signal the start / end of a burst.

[0028] According to another aspect of the invention, the interface unit for continuous data has a larger buffer memory than the interface unit for discontinuous data, which has the advantage that the memory does not have to be excessively large and the interface for discontinuous data in particular can be designed to be correspondingly efficient, thereby reducing the technical effort involved in providing the data.

[0029] According to a further aspect of the invention, the packetizer adapts the format of the data, which has the advantage that further information such as addresses and / or checksums can be provided to protect the data transmission.

[0030] According to a further aspect of the invention, the input interface device, the packetizer, and the output device are provided with volatile memory, which has the advantage that efficient memories can be created that do not need to store data permanently, and which are particularly easy to manufacture and have high operating speeds.

[0031] According to a further aspect of the invention, the number of interface units in the first group and the number of interface units in the second group are the same, which has the advantage that symmetric processing is possible and therefore specialized interface units can be created.

[0032] However, according to further aspects, the number of interface units in the first group and the number of interface units in the second group can also be varied, which makes it possible to take into account corresponding application scenarios.

[0033] This problem is solved by an output device in a receive direction for efficiently transmitting data in a motor vehicle, the output device comprising: an output interface device having a plurality of output interface units having a first group of output interface units each configured in hardware to transmit continuous data and a second group of output interface units each configured in hardware to transmit discontinuous data; a de-packetization device (reconstruction unit) configured to recover application data from packet data, forwarding information, and data protection information; a packet data processing unit (crossbar unit) configured to receive data on a physical transmission channel; and an input device in the receive direction, wherein the output interface device in the receive direction, the reconstruction unit, the packet data processing device, and the input device in the receive direction are unidirectionally coupled to each other for communication.

[0034] According to one aspect of the present invention, the output device in the receive direction is similar to the input device in the transmit direction, but has an inverse function. This means that the output device in the receive direction provides the inverse function, and the output of the input device in the transmit direction becomes the input of the output device in the receive direction. Thus, data packaged by the input device in the transmit direction is depackaged by the output device in the receive direction and output in the reverse direction. In this respect, all aspects of the input device in the transmit direction also affect the aspects of the output device in the receive direction. Data processing or data transfer in the output device occurs in the opposite direction to that of the input device.

[0035] This problem is also solved by a system configuration that includes a transmitter and a receiver communicatively coupled by a serial data connection, the system configuration can be formed integrally, or the transmitter and receiver can be implemented separately.

[0036] According to a further aspect of the invention, static routing and / or hardwiring is provided between all devices, equipment and units, which has the advantage that architectural features can be efficiently designed and better run-time behavior is achieved.

[0037] According to a further aspect of the present invention, the system configuration is formed integrally. This has the advantage of realizing a compact and robust structure. In this case, integral means that the components cannot be separated non-destructively. This allows the components of the input and output devices, in particular the input interface devices and the output interface devices, to be connected or wired efficiently and with little technical effort.

[0038] According to another aspect of the invention, the input interface device and the output interface device have a direct hard-wired communication connection with each other, which has the advantage that a feedback loop is formed without breaking the unidirectionality, thereby allowing functional testing to be performed without significant technical effort.

[0039] According to a further aspect of the present invention, a functional test can be performed in which identical data is input and then output by direct data communication between the input interface device and the output interface device. This has the advantage that the functionality of the device can be tested in a simple manner. When a data stream is input to the input interface device, the data stream can be output directly from the output interface device via a direct connection, i.e., without passing through any other device. This makes it possible to check whether the data was transmitted correctly. Alternatively, to check whether the processing up to this component was performed according to specifications, the expected output is not the same data but the processed input data. This allows for a simple functional test in data communication with a short feedback loop, excluding other components that are serially connected due to longer data communication.

[0040] This problem is also solved by a method for providing an input device for efficiently forwarding data over a virtual data path, the method comprising the steps of: providing an input interface device having a plurality of input interface units, the input interface units having a first group of input interface units each configured in hardware to receive contiguous data and a second group of input interface units each configured in hardware to receive discontinuous data; providing a packetization device and a packet data processing device configured to enhance the data with forwarding information and data protection information; and providing an output device configured to provide the data to a physical transmission channel, wherein the input interface device, the packetization device, the packet data processing device, and the output device are unidirectionally communicatively coupled.

[0041] One aspect of the present invention is bundling multiple data streams (video, audio, and data) into transport frames and transmitting them serially. Different data formats not only have different bandwidth requirements, but also different latency and bit error rate requirements. In particular, the transmission of today's video data formats requires not only the transmission of pure video data and its frame information, but also the support of encryption methods such as HDCP. All of this requires many different data channels with a wide range of bandwidth, latency, bit error rate, and bit error detection requirements. In addition, this requires a network architecture that is much more complex than a simple transmitter / receiver architecture can provide. An architecture with multiple repeaters where data paths can originate and terminate, allowing data paths to branch (Y), and recombine data paths into a single link would be advantageous.

[0042] According to one aspect of the present invention, the technology follows the basic idea of ​​bundling data of different services, but offers completely new possibilities in terms of network architecture and enables new approaches in the implementation of today's video interfaces. Furthermore, the technology can be used as a universal data transmission system, for example to transmit Ethernet data or camera data or any kind of sensor data.

[0043] In the virtual path of the present invention, all data packets or cells follow the same path, as opposed to IP, where a packet may reach its destination via a different path than previous or next packets, and therefore the latency along the virtual path is constant.

[0044] Virtual paths based on data packets or cells also have the advantage that they can be used as a multiplexing layer for different services (video, audio, Ethernet).

[0045] A virtual path consumes bandwidth only when data is actually being transferred. The virtual path concept implemented herein also allows for a wide range of complex diagnostic and network configuration functions to be realized at run time using separate (virtual) data channels.

[0046] According to one aspect of the invention, between the physical serial interface and the various application data interfaces, an input device in the transmit direction, a packet data processing device in the transmit direction, an output device in the transmit direction, an input device in the receive direction, a packet data processing device in the receive direction, and an output device in the receive direction are implemented.

[0047] According to one aspect of the invention, they are used to multiplex various virtual data paths and to support more complex architectures with repeaters and branches, this processing being primarily performed in packet data processing equipment.

[0048] Another aspect of the present invention is an input device in the transmit direction and an output device in the receive direction that performs the conversion of video (stream) or data, for example Ethernet (packets), into cells (data packets), and the input device in the transmit direction and the output device in the receive direction also have OAM functions for network diagnostics and management.

[0049] According to one aspect of the present invention, this technology can be the basis for transmitting various data formats over serial connections in the car (and elsewhere), thus forming the basis for a new generation of devices.

[0050] The high serial bandwidth requires the definition of architectures, cell formats and interfaces that allow flexible internal data bus widths in order to match the speed of the internal clock system to the capabilities of the chip technology.

[0051] The present invention includes an input device in the transmit direction and an output device in the receive direction, which converts video (stream) or, for example, Ethernet (packet) data into cells (data packets) or converts the cells (data packets) back into the original data. The present invention also includes packet data processing devices in the transmit and receive directions, which process data packets (cells), complement them, multiplex or demultiplex them with other cells, and control the cell flow. The present invention also includes an output device in the transmit direction and an input device in the receive direction, which optimally encode or decode the data packets (cells) for serial transmission, pack them into or depack them from transmission frames, and serialize or deserialize the transmission frames. The serial connection is essentially bidirectional. Theoretically, this connection can be realized over a wide variety of media. In practice, two serial differential Gbps connections are used.

[0052] In the packet data processing device, the segmented data (cell payload data) of the application interface with the header, VP identifier, and CRC is assembled into a complete cell, or the cell is CRC checked, and the payload is transferred to the output device in the receiving direction, where the multiplexing of different cell streams of the input device in the transmitting direction or the distribution of the cell payload to the output device in the receiving direction according to the VP identifier is also performed (feed-in / feed-out).

[0053] According to one aspect of the present invention, the packet data processing device also performs multiplexing and demultiplexing (forwarding) of cell streams in repeaters and splitters. According to one aspect of the invention, the role of the input device in the transmit direction is to adapt the data of the application interface to the format of the user data (payload) field of the cell and to transmit control information to the other side, or to transmit control information to the other side to be used in the adaptation process (clock recovery, framing).

[0054] According to one aspect of the present invention, all virtual data paths are unidirectional, ie, they start at an initiator at the application interface and terminate at one or more targets at the application interface.

[0055] A virtual data path begins at an initiator and terminates at one or more targets. A virtual data path is implemented by a packet data processing unit, which performs the following functions on the virtual path: - Cell multiplexing and demultiplexing - adding or removing cells from the cell stream -VP conversion The method may be used to control a machine providing an input device, a machine providing an output device, a machine providing packet data processing equipment, and / or a machine providing system configuration.

[0056] The problem is also solved by a computer program product with control instructions for implementing the proposed method or for operating the proposed apparatus. Further advantages, features, and details of the present invention will become apparent from the following description in which aspects of the invention are described in detail with reference to the drawings. The features described in the claims and the specification may each be essential elements of the present invention individually or in any combination. Similarly, the features described above and further described herein may be used individually or in any combination. Functionally similar or identical parts or components are designated by the same reference numerals. The terms "left," "right," "top," and "bottom" used in the description of the embodiments refer to normally readable drawing designations or drawings with normally readable reference numerals. The illustrated and described embodiments should not be construed as definitive but are exemplary in nature for purposes of describing the present invention. The detailed description serves the purpose of providing information to those skilled in the art; therefore, known circuits, structures, and methods are not shown or described in detail in the description so as not to obscure the understanding of the description. [Brief explanation of the drawings]

[0057] [Figure 1] FIG. 1 is a schematic flow chart of a method for providing an input device according to one embodiment of the present invention. [Figure 2] FIG. 2 is a schematic block diagram of a transmitting device for efficiently transferring data according to a further aspect of the present invention, or a schematic block diagram of a receiving device for efficiently transferring data according to a further aspect of the present invention. [Figure 3] FIG. 3 is a diagram illustrating a system configuration including the proposed transmitting device and the proposed receiving device according to another embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0058] Some of these figures show parameters that are well known to those skilled in the art in English notation, are used as parameters, and should not be translated. FIG. 1 shows in a schematic flow chart a method for providing an input device for efficiently forwarding data over a virtual data path, the method comprising step 100 of providing an input interface device comprising a plurality of input interface units having a first group of input interface units each hardwired to receive contiguous data and a second group of input interface units each hardwired to receive discontinuous data; step 101 of providing a packetizer configured to enhance the data with forwarding information and data protection information; and step 102 of providing an output device configured to provide the data to a physical transmission channel, wherein the input interface device, packetizer, and output device are unidirectionally communicatively coupled.

[0059] FIG. 2 shows a schematic block diagram of a transmission device for efficient data transfer. The input interface device 10 is shown at the bottom, which includes different input interface units, e.g., a first group of input interface units on the left and a second group of input interface units on the right. Six representative input arrows are shown at the bottom, out of a maximum of 128 input arrows describing virtual paths. In practice, the inputs at the bottom are implemented via physical channels. Similarly, the output arrows at the top can also be implemented as physical channels. The maximum of 128 virtual paths at the bottom are processed within the input device 10, packetization unit 20, and packet data processing device, and then output by the output device at the top, where further process steps or functions can be implemented. The input interface device 10 forwards the data to the packetization unit 20. The data is then output in the transmission direction 30 via the output device.

[0060] FIG. 2 shows a schematic block diagram of a receiving device similar to that shown in FIG. 2 but with reversed functionality for efficiently outputting data. The output interface device 10 is shown at the bottom, which includes different output interface units, e.g., a first group of output interface units on the left and a second group of output interface units on the right. Six representative output arrows are shown at the bottom, out of a maximum of 128 output arrows describing virtual paths. In practice, the outputs at the bottom are implemented via physical channels. Similarly, the input arrows at the top can also be implemented as physical channels. The maximum of 128 virtual paths at the bottom are received from the input devices at the top and then processed within the output device 10, the depacking unit 20, and the packet data processing device. Further process steps or functions may be implemented here. For example, the output interface device 10b receives data from the depacking unit 20. The data is received by the input devices in the receive direction 30.

[0061] FIG. 3 shows a system configuration with the transmitter at the top, which consists of an input device, also called input interface device 10, in the upper left, in the transmission direction; a packet data processing device, also called packetizer device 20, in the upper center, in the transmission direction; and an output device, also called output device 30, in the transmission direction, in the upper right. As can be seen from FIG. 3, the individual devices can be implemented with additional functions or structural features. As can be seen from FIG. 3, data is transferred strictly in one direction. This system configuration allows for a versatile, modular, large-capacity data transfer system.

[0062] The burst data interface on the left side may represent an input interface unit for receiving discontinuous data. The stream data interface may represent an input interface for receiving continuous data. In one aspect of the invention, the segmentation unit corresponds to a packetization device. In one aspect of the invention, the crossbar unit corresponds to a packet data processing device.

[0063] The other unit at the bottom shows a receiving device consisting of an input device at the bottom right in the receiving direction, a packet data processing device at the bottom center in the receiving direction, and an output device at the bottom left in the receiving direction. At the right end, a serial data link connects the transmitter and receiver, which can be implemented as a cable or a fiber optic cable.

[0064] The top three blocks are components of the transmitter, and the bottom three blocks are components of the receiver. The transmitter units and devices are followed by the receiver units and devices via arrows on the right. Again, data is transferred in one direction, outputting to the left via up to 128 virtual data channels.

[0065] In Figure 3, a direct coupling between the input interface device and the output interface device is indicated by the solid black arrow. The upper input interface device and the lower output interface device have a direct, hard-wired communication coupling to each other. This shortens the communication path, which can be used in test mode. Thus, the components on the right are isolated from the communication path, and signals are effectively output by the output interface device, regardless of processing in the input interface device or the output interface device. This coupling can be a direct, hard-wired communication coupling. This can be implemented efficiently, especially when the system configuration is integrally formed.

[0066] The structural features shown can be explained as follows. According to one aspect of the present invention, the present invention provides a generic hardware (burst / stream) solution for transmitting data from any application interface, always using the same data cells. The transmission system implements a virtual data path between the application interfaces over a serial link based on the data cells. It also provides the option to directly access the virtual data path over the cell interface to perform a "repeat" function (forwarding data in the data path without modifying the data / cells).

[0067] The present invention comprises the following: a) Burst data interface input Application data buffer for burst-type data (PCI, SPI, I2C). Buffering of burst data to enable seamless packaging of data cells in segmentation units. b. Formatting application data into cell data - adjusting bit width. c. Transition from application cycle system to cell cycle system. d. Providing a general mechanism for marking data packets (e.g. burst start / end) for the purpose of synchronizing data and control signals on the application interface.

[0068] b) Burst Data Interface Output Application Data Buffer for Bursty Data (PCI, SPI, I2C): Buffering of cell data to allow uninterrupted data bursts at the application interface. b. Formatting cell data into application data - adjusting bit width. c. A transition from a cell cycle system to an application cycle system with the option to generate application cycles. d. Providing a general mechanism for evaluating data packet markings (e.g. burst start / end) for the purpose of synchronizing data and control signals on the application interface.

[0069] c) Stream Data Interface Input Application data buffer for continuous data (video, audio). Buffering of video data to allow seamless packaging of data cells in segmentation units. b. Formatting application data into cell data - adjusting bit width. c. Transition from application cycle system to cell cycle system. d. Providing a general mechanism for marking data packets for the purpose of synchronizing data and frame signals at the application interface (e.g., Hsync, Vsync, DE) d) Stream data interface output Application data buffer for continuous data (video, audio): Buffering of cell data to allow for a continuous, uninterrupted data stream at the application interface. b. Formatting cell data into application data - adjusting bit width. c. A transition from a cell clock system to a continuous data source synchronous clock system with the option to generate an application clock. d. Providing a general purpose mechanism for evaluating markings of data packets (e.g., Hsync, Vsync, DE) for the purpose of synchronizing data and frame signals at the application interface.

[0070] e) Segmentation unit / packaging facility Creation of data cells with cell-specific information data for cell routing and cell data protection. Control of cell packaging (formatting application data into cell data - adjusting bit width).

[0071] f) Reconstitution Unit / Depackaging Device Recovery of application data from data cells based on cell specific information data for cell routing and cell data protection. Control of cell depackaging (formatting cell data into application data - bit width adjustment).

[0072] g) Crossbar unit for cell coupling a. Receiving data cells from different ports (burst data interface, stream data interface, cell interface) and assigning routing information to the cells based on their origin (port). b. Multiplexing of all received cells to one output (line coding and framer unit). c. Control of cell stream latency via a configurable priority-based arbitration mechanism.

[0073] h) Crossbar unit for cell separation a. Outputting data cells to various ports (burst data interface, stream data interface, cell interface) based on the cell routing information. b. Demultiplexing all received cells (from the line decoding and deframer unit) to multiple outputs.

[0074] i) Line Coding and Framer Unit a. Adaptation of the cell data rate to the link data rate by inserting empty cells. b. Coding of data for serial data transmission.

[0075] j) Line Decoding and De-Framer Unit a. Serial data decoding. b. Removal of empty cells.

[0076] k) Tx physical layer interface a. Parallel data to serial data conversion. b. Conversion of serial data bits into electrical or optical signals.

[0077] l) Rx physical layer interface a. Conversion of electrical or optical signals into serial data bits. b. Converting serial data to parallel data.

[0078] Not described herein is a data memory or computer readable medium having a computer program product containing control instructions for performing the proposed methods or operating the proposed system configurations.

[0079] Physical layer interface (Tx and Rx) Purpose and Function The physical layer interface provides an electrical connection to the physical transmission medium. The primary transmission medium is a differential 100 ohm line, although optical transmission media are also an option.

[0080] The physical transmission format varies depending on the data rate, being NRZ for low data rates and PAM4 for high data rates. The physical layer interface functional block performs serialization of M-bit parallel line-coded data (M=raw serializer bit width) on the transmitting side and performs recovery of the serial clock and bit-serial data on the receiving side and deserialization into M-bit parallel line-coded words. The serial data transmission is based on the "embedded clock" concept, i.e. no clock is transmitted, only serial data, which allows clock recovery by line coding.

[0081] The cell clock frequency is primarily determined by the SERDES "raw bit width" M. For example, for 30 Gbps and a raw bit width M=128, the core clock frequency is 234.375 MHz.

[0082] Interface to Physical Media In the direction of the transmission medium, the functional block of the physical layer interface according to one aspect of the invention implements two unidirectional differential bit-serial 100 ohm interfaces: one transmit interface and one receive interface. The physical medium comprises differential forward and return lines throughout. This configuration allows for arbitrary operation of the optical medium without major adaptation circuitry.

[0083] Regarding the physical medium, the focus is on twisted pair cable because at high frequencies its insertion loss is equal to that of twisted pair cable. Considering that single-ended transmission has a 6 dB attenuation compared to differential transmission, coaxial cable remains without any advantage.

[0084] The maximum cable length depends on the data rate (and cable diameter). According to one aspect of the invention, a bit clock system for serializing data is generated in the transmit direction using a PLL. Data / symbols are transmitted using this bit clock. The bit clock forms the basis of the Tx clock system. The Tx data path is directed in the opposite direction to this clock system (target synchronous).

[0085] In the receive direction, the bit clock used to serialize the data is recovered from the received serial data stream using a CDR. This bit clock forms the basis of the Rx clock system. The Rx data path is oriented in the same direction as this timing system (source synchronous).

[0086] The core clock frequency may be primarily determined by the SERDES "raw bit width," M. For example, for 30 Gbps and a raw bit width, M=128, the core clock frequency is 234.375 MHz. As SERDES technology can vary, M also varies. Therefore, the cell format and cell data interface between various functional units or devices must support flexible SERDES bit widths or decouple the cell format from the cell line data width.

[0087] Line coding and framing device and line decoding and deframer device Purpose and Function According to one aspect of the present invention, an output device in the transmit direction or an input device in the receive direction generates M-bit wide line code symbols for a SERDES interface from an N-bit wide transmit frame (see 7. Transmission Frame and Cell Format for details), and again generates an N-bit wide transmit frame from the M-bit symbols of the SERDES interface in the receive direction.

[0088] The main function of the output devices in the transmit direction and the input devices in the receive direction is to assemble transmission frames from cells in the transmit direction and conversely to disassemble transmission frames into cells in the receive direction.

[0089] To adapt the data rate of the cell stream to the data rate of the serial transmission, these devices can insert empty cells in the transmit direction (from the application interface to the serializer) in accordance with one aspect of the present invention. The availability of cells depends on the total bandwidth requirements of all application interfaces. Thus, in accordance with one aspect of the present invention, cells are processed (collected, assembled, and combined) using a system clock and therefore do not form a continuous flow of cells.

[0090] In the receive direction (from the deserializer to the application interface), empty cells are discarded. Cells are extracted from the serial frame. As in the transmit direction, cells are transferred with a data valid signal because the cell data rate is lower than the bandwidth for the system clock.

[0091] The packet data processing unit processes the cell flow and, in addition to generating the cell header and CRC or extracting the data from the cells by CRC checking, also implements the so-called add-drop multiplexer function.

[0092] This means that in the transmit direction, cells are collected by various service functions, assigned VP identifiers, cell headers and footers are generated and collected by the peer-to-peer interface, and then multiplexed into a common cell stream (additional functions).

[0093] In the receive direction, according to one aspect of the invention, the cell stream is distributed from the input device in the receive direction to the various service functions and peer-to-peer interfaces according to the VP identifier. Data destined for the service function is unpackaged and CRC checked (drop function). All cells whose VP identifier does not belong to any service function are forwarded to the peer-to-peer interface (forward function).

[0094] Input device in the transmit direction and output device in the receive direction Purpose and Function Here, cell-based virtual data paths are converted back to physical data paths, which are connected to various application interfaces via a generic service interface for stream or burst data.

[0095] Types of application interfaces include, for example, stream data such as video and audio data, and burst data in packets of almost any kind. The way in which stream and / or burst data is packaged into or depackaged from cells is not coded into the cells themselves. Instead, it is determined based on a virtual connection established between two endpoints.

[0096] In the transmit direction, an input device according to one aspect of the present invention, together with an application-specific interface, forms the starting point of a cell-based virtual data path. In the receive direction, the output devices, together with the application-specific interfaces, form the endpoints for the cell-based virtual data paths.

[0097] One of the main functions of these devices (in combination with application specific interfaces) is to enable format conversion (bit width) of streaming or burst data of any bit width into an N-bit wide cell line data format.

[0098] The interface between the stream data or burst data functions to these two devices has the bit width (N) of the cell line. The stream data or burst data interface combines clock domain traversal and bit width conversion of data from the application interface to the N bits of the cell line. The payload of the cell line is already formatted so that the self-filler and cell header fit on the first and last cell line, respectively.

[0099] According to one aspect of the present invention, the cell provides the capability to transmit payload information data in addition to payload data, which may be used to generate video or audio frame signals in the case of stream data, or packets, transactions, or bursts in the case of burst data.

[0100] Binding a frame signal to streaming data The basic idea of ​​connecting a frame signal to a data stream is to define a significant anchor point (or points) in the time sequence of the frame signal and transmit this (or these) using payload information bits to enable unambiguous synchronization of the data stream and the frame signal. Ideally, this is done by placing a fixed point in the data stream at a fixed point within the marked data cells. To recover the timing of the frame signal, a free-running timing generator is used, which can generate the entire timing independently. The timing is then adapted to the data stream by analyzing the payload information bits and adapting the timing to the defined points within the data cells.

[0101] Stream data (continuous data stream) The stream data interface combines a conversion from the application clock domain to the cell clock domain and a bit-width conversion of the data from the application interface to the N bits of the cell row, whose payload is already pre-formatted so that the self-filler and cell header fit into the first and last cell row.

[0102] Streaming data is (usually) synchronized to the source, where clock domain crossing of the data path from the application clock domain to the cell clock domain is performed.

[0103] A data buffer is provided in the transmit direction, into which source synchronous data is written by the application clock. An input device in the transmit direction retrieves data from this buffer as needed and performs data format conversion into N-bit wide cell rows. Frame signals (e.g., Hsync, Vsync, DE) are encoded into payload information bits so that the frame signals can be reconstructed at the receiver side.

[0104] In the receive direction, cell data is written into a data buffer by an output device in the receive direction. The frame signal is reconstructed based on the payload information bits. The transmit application clock is recovered, for example, using buffer fill levels and clock synthesis.

[0105] If data encryption is required (HDCP), this function encrypts or decrypts the cell data. Since there are different types of stream data, such as audio and video, including encrypted and unencrypted types, different implementations of the basic functions may exist (for example, VStream In / Out, AStream In / Out, EncVStream In / Out).

[0106] Burst data (discontinuous data stream) The burst data interface combines overflow from the application clock domain to the cell clock domain and bit-width conversion of burst data from the application interface to N bits of cell rows, whose payloads are already pre-formatted so that the self-filler and cell headers fit into the first and last cell rows.

[0107] The burst data is (usually) synchronized to an external clock and has different identification signals for direction and data type (address / data / byte enable). This data is usually accompanied by control lines to implement a particular protocol.

[0108] A data buffer is provided in the transmit direction, and burst data is written to the data buffer by the interface clock. An input device in the transmit direction retrieves data from the buffer as needed and performs data format conversion into N-bit wide cell rows.

[0109] In the receive direction, cell data from the output device is written into a data buffer in the receive direction, and interface control signals are reconstructed based on the payload information bits. The payload information bits are used to generate control signals for the application specific interface or to synchronize protocol state machines in the application specific interface.

[0110] Because there are different interfaces that provide burst-like data (SPI, I2C, MII), there may be different implementations of the basic functionality (e.g., SPIBurst, I2CBurst, MIIBurst).

[0111] Therefore, the in / out interfaces of the streams will also be (slightly) different, but their structure should be the same. Cell Formatting According to one aspect of the present invention, a cell includes a header having a fixed bit length, a payload area having four selectable bit lengths, and a footer having a fixed bit length.

[0112] The cell structure is a sequence of bits as follows: - A 7-bit virtual path identifier (VP) that represents the unique address of the virtual path. - A 3-bit sequence number (SN) that consecutively numbers the cells in their order. - A 2-bit wide cell type (CT) identifier that specifies the length of the user data. - Payload Information (PI) 3 bits wide containing additional information about the payload, which can also be used to synchronize the payload data with frame data or control data. - A 10-bit wide CRC polynomial (HCRC) for error protection of the header information. The polynomial has a Hamming distance of 5 to a 21-bit bit sequence (P=0x2B9). The payload (PL) area has a length of 187, 411, 635, or 859 bits depending on the CT value. The shortest payload is chosen to be larger than the bus width of the largest supported (video) streaming (which should simplify the mapping of streaming data to cell payloads). - Finally, a 12-bit wide CRC polynomial (PCRC) for error protection of user data. This polynomial has a Hamming distance of 4 up to a 2035-bit bit sequence (P=0x8F3).

[0113] Transfer Frame Format According to one aspect of the invention, a transmission frame comprises a sequence of M-bit wide words. The frame starts with an M-bit wide "comma" word from a sequence of comma words defined for frame alignment. This is followed by K cells. A cell consists of 2, 4, 6 or 8 N-bit wide words carrying a header, payload and footer. These N-bit wide words are coded into M-bit wide symbols (line coding).

Claims

1. 1. A transmitting device for efficiently transferring data in a motor vehicle, comprising: an input interface device (10a) comprising a plurality of input interface units, the input interface units having a first group of input interface units each configured in hardware to receive continuous data and a second group of input interface units each configured in hardware to receive discontinuous data; a packetizer (20a) configured to enrich said data with transport information and data protection information; and an output device (30a) in a transmission direction configured to provide the data to a physical transmission channel, wherein the input interface device (10a), the packetization device (20a), and the output device (30a) are unidirectionally communicatively coupled.

2. 2. A transmitting device according to claim 1, characterized in that the number of interface units is between 2 and 128 and / or there are a maximum of 128 virtual data paths to the input interface units.

3. 3. The transmitting device according to claim 1, wherein the input interface device (10a), the packetizing device (20a) and the output device (30a) are implemented in hardware.

4. 4. A transmitting device according to any one of claims 1 to 3, characterized in that all units and devices are set to transmit the data in one direction only.

5. 5. The transmitting device according to claim 1, wherein the continuous data exists as streaming data and the discontinuous data exists as burst data.

6. 6. A transmitting device according to claim 1, wherein the continuous data has frames and the discontinuous data does not have frames.

7. 7. A transmitting device according to claim 1, wherein the interface unit for continuous data has a larger buffer memory than the interface unit for discontinuous data.

8. 8. A transmitting device according to any one of claims 1 to 7, characterized in that the packetizing device (20a) adapts the data to its data format.

9. 9. The transmitting device according to any one of claims 1 to 8, characterized in that the input interface device (10a), the packetizing device (20a) and the output device (30a) comprise volatile memories.

10. 10. The transmitting device according to claim 1, wherein the number of interface units in the first group is the same as the number of interface units in the second group.

11. 1. A receiving device for efficient transfer of data in a motor vehicle, comprising: an output interface device (10b) comprising a plurality of output interface units, the output interface units having a first group of output interface units each configured in hardware to transmit continuous data and a second group of output interface units each configured in hardware to transmit discontinuous data; a de-packetizer (20b) configured to separate the data from transport information and data protection information; and an input device arranged in a receive direction (30b) to receive the data on a physical transmission channel, wherein the output interface device (10b), the depacketization device (20b), and the input device (30b) are unidirectionally communicatively coupled.

12. 12. A system configuration comprising a transmitter according to any one of claims 1 to 10 and a receiver according to claim 11, wherein the transmitter and receiver are communicatively coupled by a serial data connection.

13. 13. A system configuration according to claim 12, characterized in that static routing and / or hard wiring is provided between all devices, equipment and units.

14. 14. The system configuration according to claim 12 or 13, wherein the system configuration is integrally formed.

15. 15. A system arrangement according to any one of claims 12 to 14, characterized in that the input interface device (10a) and the output interface device (10b) have a direct hard-wired communication coupling with each other.

16. 16. The system configuration according to claim 15, wherein the system configuration is set so that a functional test can be performed in such a way that identical data is input and then output by direct data communication between the input interface device (10a) and the output interface device (10b).

17. 1. A method for providing an input device for efficiently routing data over a virtual data path, comprising: providing (100) an input interface device comprising a plurality of input interface units, the first group of input interface units being each configured in hardware to receive continuous data and a second group of input interface units being each configured in hardware to receive discontinuous data; providing (101) a packetizer configured to enrich said data with transport information and data protection information; and providing (102) an output device configured to provide the data to a physical transmission channel, wherein the input interface device, the packetization device, and the output device are unidirectionally communicatively coupled.

18. 17. A method of providing a system configuration as claimed in any one of claims 12 to 16, comprising the step of providing a transmitting device as claimed in any one of claims 1 to 10 and a receiving device as claimed in claim 11 in a communicatively coupled state.

19. 19. A computer program product comprising instructions which, when executed by at least one computer, cause the computer to perform the steps of the method according to claim 17 or 18.

20. 19. A computer readable storage medium containing instructions which, when executed by at least one computer, cause the computer to perform the steps of the method according to claim 17 or 18.

Images