Hardware-based efficient data transfer

A unidirectional data transmission device with hardware-configured interfaces and packet processing units addresses the inefficiencies of existing automotive data transmission by enabling efficient, lightweight, and reliable data transfer with up to 128 virtual paths on a single channel, meeting automotive requirements for robustness and energy efficiency.

JP7866682B2Active Publication Date: 2026-05-27INOVA SEMICON
View PDF 6 Cites 0 Cited by

Patent Information

Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
INOVA SEMICON
Filing Date
2023-09-21
Publication Date
2026-05-27

Smart Images

  • Figure 0007866682000001
    Figure 0007866682000001
  • Figure 0007866682000002
    Figure 0007866682000002
  • Figure 0007866682000003
    Figure 0007866682000003
Patent Text Reader

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.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to a transmission device for efficiently transmitting data within an automobile, which enables efficient transfer of data on a single physical channel, for example, 128 virtual data paths (virtuelle datenpfade: virtual data paths). The proposed invention is a unidirectional device that creates a device that can be provided with less technical effort by reducing complexity. The present invention focuses particularly on the requirements in automobiles where weight reduction and high fault tolerance are required. Weight reduction is achieved by simplifying conventional units, and only a single physical path is required, but the device can handle 128 virtual data paths. According to the present invention, by making the structural components unidirectional, robustness against failures is achieved, and thus the structural components can be created particularly simply without having structural features prone to errors. The present invention further relates to an input device in the transmission direction that is partially functionally opposite to the output device in the reception direction, and a packet data processing device in the transmission direction and the reception direction, and to a system configuration including the proposed transmission device and the proposed reception device. Furthermore, a method suitable for a manufacturing plant for providing a system configuration or an input device and an output device, and a computer program product including method steps are proposed. Furthermore, a computer-readable medium including control instructions is proposed.

Background Art

[0002] Patent Document 1 describes a multiprotocol interface with numerous components and bidirectional data paths. In the prior art, various solutions for realizing data communication using software are known. For this purpose, there are various prior art solutions having components implemented by either software or hardware.

[0003] Software implementation, in particular, can be labor-intensive and increase the complexity of the underlying circuitry. Such applications are those that require flexibility and the implementation of dynamic packet switching, for example.

[0004] Modern technologies often utilize proprietary standards designed for high-performance computer networks and do not meet automotive requirements, making them generally unsuitable for automotive use. Automotive applications impose entirely different requirements for 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, high-capacity hardware is usually available, and energy consumption plays a secondary role. Automotive applications, on the other hand, require lightweight designs, high reliability, and energy efficiency. In electric vehicles, high energy consumption directly translates to reduced driving range. In this regard, modern technologies need to create devices that generate data efficiently in many respects with minimal technical effort.

[0005] All of the technologies cited as examples are optimized for transmitting a single data type (video, audio, SPI, Ethernet®). 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, powerful, and data-intensive over the past few decades. The effective and rapid networking of display units, actuators, sensors, and processing units plays a central role here, even if it doesn't determine system performance.

[0007] The display unit, sensors and actuators, as well as the associated processing units, are located relatively far apart within the vehicle. If separate communication solutions are implemented for each interface between the sensors / actuators and the processing unit (GPU / CPU), as in a PC or mobile phone (the latest technology mentioned above), this would mean a massive amount of cabling (weight) whose performance is largely limited due to the spatial distance.

[0008] To reduce the weight of cables and connectors, data connections need to be bundled into a single, identical cable system. For the same type of data, these are the classic SERDES solution (modern technology), a system for transmitting data serially at gigabit data rates.

[0009] To consolidate different data paths, a universal solution is needed, rather than data type (video, audio, etc.) specific solutions. To maximize the reuse of complex data path logic, numerous data interfaces, including existing and constantly emerging ones, need to be mapped to a standardized universal interface.

[0010] Therefore, it is necessary to create devices, system configurations, and processes that do not exhibit the aforementioned drawbacks and can be used in a particularly advantageous manner in automobiles. [Prior art documents] [Patent Documents]

[0011] [Patent Document 1] U.S. Patent Application Publication No. 2013 / 0101058 [Overview of the Initiative] [Problems that the invention aims to solve]

[0012] Therefore, an object of the present invention is to propose a transmitting device that can be implemented particularly efficiently and conserve hardware resources, especially with regard to use in automobiles. Furthermore, an object of the present invention is to propose a receiving device that is partially functionally inverse to the transmitting device, as well as a system configuration that combines all the devices together. In addition, an object of the present invention is to propose a method for providing the device, as well as a computer program product equipped 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. Accordingly, an input device in the transmission direction for efficiently transmitting data in an automobile has been proposed, comprising an input interface device having a plurality of input interface units, each having a first group of input interface units hardware-configured to receive continuous data and a second group of input interface units hardware-configured to receive discontinuous data; a packetization device configured to segment the data and enhance the data using transfer information and data protection information; a packet data processing unit of the packetization device for transferring the data; and an output device positioned in the transmission direction to provide the data to a physical transmission channel, wherein the input interface device, the packetization device, and the output device are unidirectionally coupled.

[0014] The proposed input device in the transmission direction is particularly efficient in terms of data transmission because its structure is designed so that data is transmitted in only one direction, and the device is not designed bidirectionally as in the prior art. This simplicity of the input device allows for particularly efficient provision of the device, 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 packetization device, also called a packet data processing device or packet data processing unit, can be controlled to require only one physical data channel. When multiple data paths are used, according to the present invention, it is possible to configure up to 128 virtual data paths on this single physical data channel. As a result, it is not necessary to maintain many physical paths, and only a single physical data channel needs to be maintained, thus achieving a particularly high level of fault tolerance and lightweight design.

[0015] The data is received by an input interface device, passes through an input device in the transmission direction, is multiplexed with packet data from other input interface devices in a packet data processing device, and is then transmitted to an output device in the transmission direction. Multiplexing means simultaneously transmitting multiple signals or information streams over a line in the form of a single composite signal, and then splitting them back into separate signals at the receiving end. Therefore, according to the present invention, packet data from multiple input interface devices are combined.

[0016] Further processing steps can be performed as the data passes through. In particular, it is possible to extract or process the data in a packet data processing device. For example, a packet data processing device can be coupled to an input device to output a corresponding signal.

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

[0018] Furthermore, a segmentation unit configured to generate data packets is provided, thereby providing data packet-specific information. This may be addressing or routing information, or information for protecting data packet-specific information. Data packet-specific information can be protected, for example, by a checksum. According to one aspect of the present invention, data packetization is also controlled by the segmentation unit. This means that 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 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 efficiently implement input devices.

[0020] Furthermore, according to one aspect of the present invention, an output device (Line Coding & Framer Unit) configured to provide data to a physical transmission channel is provided. The output device is hardware-configured to receive data from a packet data processing device (crossbar unit) and then output the data. The output can be transmitted, for example, to a proposed output device in the transmission direction. For this purpose, the output device includes an input device in the transmission 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 may 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), packetization devices (segmentation unit), packet data processing devices (crossbar unit), and output devices (line coding and framer unit) are connected to transfer data in one direction; that is, input data from the input interface devices is transferred to the packetization devices and packet data processing devices, and can then be output using the output devices. No reverse data flow is provided. This makes it possible to implement the proposed input devices particularly efficiently.

[0022] The present invention offers, in particular, the following advantages. - The module can be extended using the application interface without changing the data path logic (while ensuring compatibility and interoperability with existing systems). - Any phys with different bandwidths can be used without changing the data path logic (while ensuring compatibility and interoperability with existing systems). - The hardware solution for adapting to any application interface reduces software effort and guarantees high and efficient data throughput.

[0023] According to one aspect of the present invention, the number of interface units is from 2 to 128, and / or there are up to 128 virtual data paths to the input interface units. This can minimize hardware requirements, so only a single physical interface needs to be provided, and there is also the advantage that 128 virtual data paths can be set. Also, the number of interface units can be changed, in which case there must be at least one input interface unit in the first group and at least one input interface unit in the second group. This enables optimal processing of both continuous and discontinuous data.

[0024] According to a further aspect of the present invention, the input interface device, packetization device, packet data processing device, and / or output device are implemented in hardware. This has the advantage of not needing to implement a complex circuit for storing and executing software instructions. Instead, the device can be hard-coded and thus operate efficiently. Since the device does not need to process dynamic processes, it can be provided with little technical effort. This means that all units can be provided by hard wiring. Also, this 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 of allowing structural features to be equipped particularly efficiently. Unidirectional data transmission also ensures that there is no need to provide a protection mechanism because data flow is only possible in one direction. Therefore, defective data cannot be transmitted in the reverse direction, which enables a simple protection mechanism.

[0026] According to a further aspect of the present invention, continuous data is available as streaming data, and discontinuous data is available as burst data. This has the advantage that hardware can be adapted to the corresponding transmission concept, and thus optimized hardware can be provided. Thus, the hardware can meet the specific requirements of streaming data or burst data. In particular, streaming data has a high demand for real-time transmission because the video data is subjected to a noticeable delay. Mechanisms can be implemented to ensure that streaming data is transmitted continuously and that burst data allows for the pausing of data transmission. Buffer memory can be configured accordingly.

[0027] According to a further aspect of the present invention, continuous data has frames (e.g., Hsync, Vsync, DE in the case of video) that segment the continuous data, while discontinuous data implicitly has a start and end due to a burst-like data structure and therefore does not usually have frame information. Accordingly, in the case of continuous data, a particularly efficient circuit can be realized that provides hardware-implemented logic to attach frame information to the data packet. 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 present invention, the interface unit for continuous data has a larger buffer memory than the interface unit for discontinuous data. This has the advantage that the memory does not need to be excessively large, and the interface for discontinuous data can be designed to be more efficient in particular. This reduces the technical effort involved in providing the data.

[0029] According to a further aspect of the present invention, the packetization device adapts the data format. This has the advantage of being able to provide further information such as addresses and / or checksums to protect data transmission.

[0030] According to a further aspect of the present invention, the input interface device, the packetization device, and the output device are equipped with volatile memory. This has the advantage of creating efficient memory that does not require the persistent storage of data. Volatile memory is particularly easy to manufacture and also has high operating speed.

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

[0032] However, in a further embodiment, the number of interface units in the first group and the second group can also be varied. This makes it possible to take corresponding application scenarios into consideration.

[0033] This problem is solved by an output device in the receiving direction for efficiently transmitting data in an automobile. The output device comprises an output interface device having a plurality of output interface units, each having a first group of output interface units hardware-configured for transmitting continuous data and a second group of output interface units hardware-configured for transmitting discontinuous data; a reverse packetization device (reconstruction unit) configured to reconstruct application data from packet data, transfer 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 receiving direction. The output interface device in the receiving direction, the reconstruction unit, the packet data processing unit, and the input device in the receiving direction are coupled to communicate in one direction.

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

[0035] This problem can also be solved by a system configuration comprising a transmitter and a receiver connected via a serial data connection for communication. The system configuration can be formed as a single unit, or the transmitter and receiver can be implemented separately.

[0036] According to a further aspect of the present invention, static routing and / or hardwiring is provided between all devices, equipment and units. This has the advantage of allowing for efficient design of structural features and achieving better runtime behavior.

[0037] According to a further aspect of the present invention, the system configuration is formed integrally. This has the advantage of achieving a compact and robust structure. In this case, integral means that the components cannot be separated non-destructively. This makes it possible to connect or wire the components of the input and output devices, particularly the input interface device and the output interface device, efficiently and with minimal technical effort.

[0038] According to another aspect of the present invention, the input interface device and the output interface device have a direct hardwired communication coupling with each other. This has the advantage of forming a feedback loop without disrupting the unidirectional nature of communication. This allows functional testing to be performed without requiring significant technical effort.

[0039] According to a further aspect of the present invention, a functional test can be performed such that the same data is input and subsequently output via direct data communication between an input interface device and an output interface device. This has the advantage of allowing the functionality of the device to 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 direct coupling, i.e., without passing through other devices. This allows checking whether the data has been transmitted correctly. Alternatively, to check whether processing up to this component has been performed according to specifications, the expected output is not the same data, but the processed input data. This enables a simple functional test in data communication via a short feedback loop, excluding other components coupled in series in response to longer data communications.

[0040] Furthermore, this problem is solved by a method for providing an input device for efficiently transferring data over a virtual data path, the method comprising the steps of: preparing an input interface device having a plurality of input interface units, each having a first group of input interface units hardware-configured to receive continuous data and a second group of input interface units hardware-configured to receive discontinuous data; preparing a packetizer and a packet data processing device configured to enhance the data with transfer information and data protection information; and preparing an output device configured to provide the data to a physical transmission channel, wherein the input interface device, packetizer, packet data processing device, and output device are unidirectionally coupled.

[0041] One aspect of the present invention involves bundling multiple data streams (video, audio, and data) into transport frames and transmitting them serially. Different data formats have not only different bandwidth requirements but also different latency and bit error rate requirements. In particular, transmitting today's video data formats requires not only the transmission of pure video data and its frame information but also support for 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 to this, a network architecture far more complex than what a simple transmitter / receiver architecture can provide is required. An architecture is advantageous that has multiple repeaters that can start and end data paths, can branch (Y) data paths, and can reintegrate data paths into a single link.

[0042] According to one aspect of the present invention, the technology follows the basic idea of ​​bundling data from different services, but offers entirely new possibilities with respect to network architecture and enables new methods in the implementation of today's video interfaces. Furthermore, the technology can be used as a general-purpose data transmission system for transmitting, for example, Ethernet® data, camera data, or any kind of sensor data.

[0043] In the virtual path of this invention, all data packets or cells travel along the same path. This is in contrast to IP, where packets may travel along different paths to reach their destination than preceding or succeeding packets; therefore, latency on the virtual path is constant.

[0044] Virtual paths based on data packets or cells also have the advantage of being usable as multiplexing layers for different services (video, audio, Ethernet®).

[0045] Virtual paths consume bandwidth only when data is actually being transferred. The virtual path concept implemented herein also enables the realization of complex and extensive diagnostic and network configuration functions at runtime using separate (virtual) data channels.

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

[0047] According to one aspect of the present invention, these are used to multiplex various virtual data paths and support more complex architectures having repeaters and branches. This processing is mainly carried out in a packet data processing unit.

[0048] Another aspect of the present invention is a transmitting input device and a receiving output device that perform the conversion of video (stream) or, for example, Ethernet (packet) data into cells (data packets). This transmitting input device and receiving output device also includes OAM (Network Automation) functions for network diagnostics and management.

[0049] According to one aspect of the present invention, this technology can serve as a basis for transmitting various data formats via serial connections in vehicles (and other locations). Thus, this forms the basis for a new generation of devices.

[0050] Due to the wide serial bandwidth, it is necessary to define an architecture, cell format, and interface that allows for flexible internal data bus width 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 transmission direction and an output device in the reception direction, which performs the conversion of video (stream) or, for example, Ethernet (packet) data into cells (data packets) or the conversion of cells (data packets) back into the original data. The present invention further includes packet data processing devices in the transmission and reception directions, which process data packets (cells), complement them, and multiplex or demultiplex them with other cells to control cell flow. Furthermore, the present invention comprises an output device in the transmission direction and an input device in the reception direction, which optimally encode or decode data packets (cells) for serial transmission, pack them into or depack them from transmission frames, and serialize or deserialize these transmission frames. A serial connection is fundamentally bidirectional. Theoretically, this connection can be implemented over a wide variety of media. In practice, two serial differential GBps connections are used.

[0052] In the packet data processing unit, segmented data (cell payload data) of the application interface, which has a 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. Also, here, multiplexing of different cell streams from input devices in the transmitting direction or distribution of cell payloads according to the VP identifier to output devices in the receiving direction occurs (feed-in / feed-out).

[0053] According to one aspect of the present invention, the packet data processing device also performs multiplexing and demultiplexing (transferring) of cell streams in repeaters and splitters. According to one aspect of the present invention, the role of the input device in the transmission direction is to adapt the application interface data to the format of the cell's user data (payload) field and transmit control information to the other party, or to transmit the other party's control information for use in adaptation processing (clock restoration, frame formation).

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

[0055] A virtual data path is initiated at an initiator and terminates at one or more targets. The virtual data path is implemented by a packet data processing unit and performs the following functions over the virtual path: - Cell multiplexing and demultiplexing - Adding or removing cells from a cell stream -VP conversion This method can be used to control a machine that provides an input device, a machine that provides an output device, a machine that provides a packet data processing device, and / or a machine that provides a system configuration.

[0056] This problem can also be solved by implementing the proposed method or by a computer program product that includes control instructions for operating the proposed device. Further advantages, features, and details of the present invention will become apparent from the following description, which describes aspects of the invention in detail with reference to the drawings. The features described in the claims and specification may be essential elements of the invention, individually or in any combination. Similarly, the features described above and those further described herein may be used individually or in any combination. Functionally similar or identical parts or components are given the same reference numerals. The terms “left,” “right,” “up,” and “down” used in the description of embodiments refer to the orientation of drawings that are normally readable or that have normally readable reference numerals. The illustrated and described embodiments should not be understood as definitive, but are essentially illustrative for the purpose of illustrating the invention. The detailed description is intended to inform those skilled in the art, and therefore known circuits, structures, and methods are not shown or described in detail in this description so as not to hinder the understanding of this description. [Brief explanation of the drawing]

[0057] [Figure 1] Figure 1 is a schematic flowchart of a method for providing an input device according to one aspect of the present invention. [Figure 2] Figure 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] Figure 3 shows a system configuration comprising a proposed transmitting device and a proposed receiving device according to another aspect of the present invention. [Modes for carrying out the invention]

[0058] Some of these figures show parameters that are well known to those skilled in the art in English, used as parameters, and should not be translated. Figure 1 shows a schematic flowchart of a method for providing an input device for efficiently transferring data over a virtual data path, the method comprising: step 100 preparing an input interface device having a plurality of input interface units, each having a first group of input interface units hardware-configured to receive continuous data and a second group of input interface units hardware-configured to receive discontinuous data; step 101 preparing a packetization device configured to enhance the data with transfer information and data protection information; and step 102 providing 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 coupled.

[0059] Figure 2 shows a schematic block diagram of a transmitting device for efficient data transfer. An input interface device 10 is shown at the bottom, and the input interface device 10 has different input interface units, for example, a first group of input interface units on the left and a second group of input interface units on the right. At the bottom, six representative input arrows are shown out of up to 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 up to 128 virtual paths at the bottom are processed within the input device 10, the packetization unit 20, and the packet data processing device, and then output by the output device at the top. Further process steps or functions can be performed here. The input interface device 10 transfers the data to the packetization unit 20. The data is then output in the transmission direction 30 via the output device.

[0060] Figure 2 shows a schematic block diagram of a receiver similar to, but functionally reversed from, Figure 2, for efficient data output. An output interface device 10 is shown at the bottom, and it has 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. At the bottom, six representative output arrows are shown out of up to 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 up to 128 virtual paths at the bottom are received from the input device at the top and then processed within the output device 10, the reverse packing unit 20, and the packet data processing unit. Further process steps or functions can be performed here. For example, the output interface device 10b receives data from the reverse packing unit 20. The data is received by the input device in the receiving direction 30.

[0061] Figure 3 shows a system configuration with the transmitting device positioned at the top. This configuration consists of an input device, also called an input interface device 10, located in the upper left in the transmission direction; a packet data processing device, also called a packetization device 20, located in the upper center in the transmission direction; and an output device, also called an output device 30, located in the upper right in the transmission direction. As can be seen from Figure 3, each device can implement further functional or structural features. As can be seen from Figure 3, data is transferred strictly in one direction. This system configuration realizes a general-purpose, modular, high-capacity data transfer system.

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

[0063] The other unit at the bottom represents a receiving device consisting of an input device located in the lower right of the receiving direction, a packet data processing device located in the lower center of the receiving direction, and an output device located in the lower left of the receiving direction. On the far right, a serial data link connects the transmitting and receiving devices, which can be implemented as a cable or fiber optic cable.

[0064] The top three blocks are components of the transmitter, and the bottom three blocks are components of the receiver. Following the transmitter units and equipment are the receiver units and equipment, via the arrow on the right. Here again, data is transferred in one direction and output to the left via up to 128 virtual data channels.

[0065] In Figure 3, the direct coupling between the input interface device and the output interface device is indicated by the black-filled arrow. The upper input interface device and the lower output interface device have a direct hardwired communication coupling with each other. This shortens the communication path, which can be used in test mode. Therefore, the components on the right are isolated from the communication path, and the signals are efficiently output by the output interface device, regardless of whether processing is performed in the input or output interface device. This coupling can be a direct hardwired communication coupling, which can be efficiently implemented, especially when the system configuration is formed as a single unit.

[0066] The illustrated structural features can be explained as follows: According to one aspect of the present invention, the present invention provides a general-purpose hardware (burst / stream) solution for transmitting data from any application interface using the same data cell at all times. The transmission system implements a virtual data path between application interfaces via a serial link based on the data cell. It also provides an option to directly access the virtual data path via the cell interface to perform a "repeat" function (transferring data along the data path without changing the data / cell).

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

[0068] b) Burst data interface output a. Application data buffer for burst-type data (PCI, SPI, I2C). Buffering of cell data to enable uninterrupted data bursts in the application interface. b. Formatting cell data into application data - adjusting bit width. c. Transition from a cell cycle system to an application cycle system, which has the option to generate application cycles. d. Providing a general-purpose mechanism for evaluating data packet markings (e.g., burst start / end) for the purpose of synchronizing data and control signals of the application interface.

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

[0070] e) Segmentation Units / Packaging Equipment a. Generation of data cells containing cell-specific information data for cell routing and cell data protection. Control of cell packaging (formatting application data into cell data - bit width adjustment).

[0071] f) Reconfiguration unit / reverse packaging device a. Recovering application data from data cells based on cell-specific information data for cell routing and cell data protection. Controlling cell depackaging (formatting cell data into application data - adjusting bit width).

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

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

[0074] i) Line coding and framer unit a. Adapting cell data rates to linked data rates by inserting empty cells. b. Coding of data for serial data transmission.

[0075] j) Line decoding and deframer unit a. Decoding of serial data. b. Remove empty cells.

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

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

[0078] This specification does not describe any data memory or computer-readable medium having a computer program product containing control instructions for carrying out the proposed method or for operating the proposed system configuration.

[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. However, optical transmission media can also be considered.

[0080] The physical transmission format varies depending on the data rate; NRZ is used for low data rates, and PAM4 is used for high data rates. The physical layer interface function block serializes M-bit parallel line coded data (M = raw serializer bit width) at the transmitting end, and at the receiving end, it performs serial clock and bit serial data reconstruction, as well as deserialization to an M-bit parallel line coded word. Serial data transmission is based on the "embedded clock" concept; that is, no clock is transmitted, only serial data, which allows for clock reconstruction via line coding.

[0081] The cell clock frequency is primarily determined by the "raw bit width" M of SERDES. For example, with a speed of 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 transmitting medium, a functional block of the physical layer interface according to one aspect of the invention implements two unidirectional differential bit serial 100-ohm interfaces: one is the transmitting interface and the other is the receiving interface. The physical medium includes differential forward lines and differential return lines throughout. This configuration also allows arbitrary operation of the optical medium without major adaptive circuitry.

[0083] Regarding physical media, the focus is on twisted-pair cables because their insertion loss at high frequencies is equal to that of twisted-pair cables. Considering that single-ended transmission has a 6dB attenuation compared to differential transmission, coaxial cables have no advantage whatsoever.

[0084] The maximum cable length depends on the data rate (and cable diameter). According to one aspect of the present invention, a bit clock system for serializing data is generated in the transmission 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 synchronization).

[0085] In the receiving direction, the bit clock used to serialize the data is reconstructed from the received serial data stream using 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 synchronization).

[0086] The core clock frequency can be determined primarily by the "raw bit width" M of SERDES. For example, with a bit width of 30 GBps and a raw bit width M = 128, the core clock frequency is 234.375 MHz. Since SERDES technology can change, M also changes. Therefore, cell formats and cell data interfaces between various functional units or devices must either support flexible SERDES bit widths or decouple the cell format from the cell line data width.

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

[0088] The main functions of the output device in the transmission direction and the input device in the reception direction are to assemble a transmission frame from cells in the transmission direction, and conversely, to decompose the transmission frame into cells in the reception direction.

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

[0090] In the receiving direction (from the deserializer to the application interface), empty cells are discarded. Cells are extracted from the serial frame. Similar to the transmitting direction, the cell data rate is lower than the bandwidth relative to the system clock, so cells are transmitted along with a data validity signal.

[0091] The packet data processing unit processes cell flows. In addition to generating cell headers and CRCs, or extracting data from cells through CRC checks, it implements a so-called add-drop multiplexer function.

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

[0093] In the receiving direction, according to one aspect of the present invention, the cell stream is distributed from the input device in the receiving direction to various service functions and peer-to-peer interfaces according to the VP identifier. Data for service functions is depackaged 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 (forwarding function).

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

[0095] Application interface types include, for example, stream data of video and audio data, and burst data of almost all types of packets. How stream and / or burst data is packaged into or depackaged from a cell is not coded within the cell itself. Instead, it is determined by the configuration between two endpoints or based on a virtual connection.

[0096] In the transmission direction, an input device according to one aspect of the present invention, along with an application-specific interface, forms the starting point of a cell-based virtual data path. In the receiving direction, the output device, along with an application-specific interface, forms the endpoint for the cell-based virtual data path.

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

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

[0099] According to one aspect of the present invention, the cell provides a function to transmit payload information data in addition to payload data. The payload information data is used, for example, to generate video or audio frame signals in the case of stream data, and to generate packets, transactions, and bursts in the case of burst data.

[0100] Binding frame signals to streaming data The basic idea behind connecting a frame signal to a data stream is to define key anchor points (or multiple anchor points) within the time sequence of the frame signal and transmit these (or these) using payload information bits to enable precise synchronization between the data stream and the frame signal. Ideally, this is done by aligning fixed points in the data stream with fixed points within marked data cells. To restore the timing of the frame signal, a free-roaming timing generator capable of independently generating the entire timing is used. The timing is then fitted to the data stream by analyzing the payload information bits and fitting the timing to defined points within the data cells.

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

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

[0103] A data buffer is provided in the transmission direction, and source synchronization data is written to the data buffer by the application clock. Input devices in the transmission direction retrieve data from this buffer as needed and perform data format conversion to 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.

[0104] In the receiving direction, cell data is written to a data buffer by the output device in the receiving direction. The frame signal is reconstructed based on the payload information bits. The transmitting application clock is regenerated, for example, using the buffer fill level and clock synthesis.

[0105] If data encryption is required (HDCP), this function encrypts or decrypts the cell data. Stream data can come in various types, including audio and video, and may or may not be encrypted. Therefore, different implementations of basic functionality 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 with a conversion of the bit width of the burst data from the application interface to the N bits of the cell row. The cell row payload is already pre-formatted so that the selfetter and cell header fit the first and last cell rows.

[0107] Burst data is (usually) synchronized with an external clock and has different identification signals for direction and data type (address / data / byte enable). This data typically involves control lines to implement a specific protocol.

[0108] A data buffer is provided in the transmission direction, and burst data is written to the data buffer by the interface clock. Input devices in the transmission direction retrieve data from this buffer as needed and perform data format conversion to N-bit wide cell rows.

[0109] In the receiving direction, cell data from the output device is written to the data buffer in the receiving direction. The interface control signal is reconfigured based on the payload information bits. Payload information bits are used to generate control signals for application-specific interfaces or to synchronize protocol state machines within application-specific interfaces.

[0110] Because the interfaces providing burst-like data (SPI, I2C, MII) are different, there may be different implementation forms with different basic functions (e.g., SPIBurst, I2CBurst, MIIBurst).

[0111] Therefore, although the stream in / out interfaces will be (slightly) different, their structures should be the same. Cell formatting According to one aspect of the present invention, the 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 route identifier (VP) representing the unique address of a virtual route. - A 3-bit sequence number (SN) that assigns sequential numbers to the cells in that order. - A 2-bit wide cell type (CT) identifier that specifies the length of user data. - 3-bit wide payload information (PI) containing additional information about the payload. This can also be used to synchronize payload data with frame data or control data. - A 10-bit wide CRC polynomial (HCRC) for error protection of header information. The polynomial has a Hamming distance of 5 up 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 selected so that it is greater than the bus width of the largest supported (video) streaming. (This 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 present invention, a transmission frame includes a sequence of M-bit wide words. The frame begins with an M-bit wide "comma" word from a sequence of comma words defined for frame alignment. This is followed by K cells. Each cell consists of 2, 4, 6, or 8 N-bit wide words that carry the header, payload, and footer. These N-bit wide words are coded into M-bit wide symbols (line coding).

Claims

1. A transmission device for efficiently transferring data in an automobile, An input interface device (10) comprising a plurality of input interface units, each having a first group of input interface units hardware-configured to receive continuous data and a second group of input interface units hardware-configured to receive discontinuous data, wherein the interface units for continuous data have a larger buffer memory than the interface units for discontinuous data, and the input interface device (10), A packetization device (20) configured to enhance the aforementioned data with transfer information and data protection information, A transmitting device comprising an output device (30) in the transmission direction configured to provide the aforementioned data to a physical transmission channel, wherein the input interface device (10), the packetization device (20), and the output device (30) are coupled in a unidirectional manner.

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

3. The transmitting device according to claim 1 or 2, characterized in that the input interface device (10), the packetization device (20), and the output device (30) are implemented in hardware.

4. The transmitting device according to claim 1 or 2, characterized in that all units and devices are configured to transmit the data in only one direction.

5. The transmitting device according to claim 1 or 2, characterized in that continuous data exists as streaming data and discontinuous data exists as burst data.

6. The transmitting device according to claim 1 or 2, wherein the packetization device (20) conforms the data to its data format.

7. The transmitting device according to claim 1 or 2, characterized in that the input interface device (10), the packetization device (20), and the output device (30) each have volatile memory.

8. The transmitting device according to claim 1 or 2, characterized in that the number of interface units in the first group and the number of interface units in the second group are the same.

9. A receiving device for efficient data transfer in automobiles, An output interface device (10) comprising a plurality of output interface units, each having a first group of output interface units configured in hardware to transmit continuous data and a second group of output interface units configured in hardware to transmit discontinuous data, wherein the interface units for continuous data have a larger buffer memory than the interface units for discontinuous data, and the output interface device (10), A reverse packetization device (20) configured to separate the aforementioned data from the transfer information and data protection information, A receiving device comprising an input device positioned in the receiving direction (30) for receiving the data on a physical transmission channel, wherein the output interface device (10), the reverse packetization device (20), and the input device (30) are coupled in a unidirectional manner.

10. A system configuration comprising a transmitting device according to claim 1 and a receiving device according to claim 9, wherein the transmitting device and the receiving device are connected to communicate via a serial data connection.

11. The system configuration according to claim 10, characterized in that static routing and / or hardwiring are provided between all devices, equipment and units.

12. The system configuration according to claim 10, characterized in that the aforementioned system configuration is formed integrally.

13. A method for providing an input device for efficiently routing data on a virtual data path, An input interface device comprising a plurality of input interface units, each having a first group of input interface units hardware-configured to receive continuous data and a second group of input interface units hardware-configured to receive discontinuous data, wherein the interface units for continuous data have a larger buffer memory than the interface units for discontinuous data, the steps of preparing the input interface device (100), (101) A step of preparing a packetization device configured to enhance the aforementioned data with transfer information and data protection information, A method comprising the step (102) of preparing an output device configured to provide the aforementioned data to a physical transmission channel, wherein the input interface device, the packetization device, and the output device are coupled in a manner that allows communication in one direction.

14. A method for providing a system configuration according to any one of claims 10 to 12, comprising the step of preparing a transmitting device according to claim 1 and a receiving device according to claim 9 in a state in which they are communicatively coupled.