Communication device, communication method, and program

Abstract

The present disclosure relates to a communication device, a communication method, and a program, configured so as to make it possible to support more varied uses and to increase the reliability of communication. A physical layer is mounted with a CCI protocol as an upper layer, and transmits and receives data including an extension header and an extension footer with another communication device. A CCI-FS processing unit compares a Destination ID contained in the extension header with an ID (Source ID) of the communication device, and determines whether to access the communication device. The physical layer has a non-symmetrical upper layer for point-to-point topology, and is a MIPI A-PHY designed so as to be able to share the same physical wiring for high-speed data transfer, control data, and power. The present technique is applicable to, for example, a communication system used for a connection with a vehicle-mounted camera.

Description

[Technical Field]

[0001] The present disclosure relates to a communication device, a communication method, and a program, and more particularly to a communication device, a communication method, and a program that can accommodate a wider variety of uses and improve the reliability of communication. [Background technology]

[0002] CSI (Camera Serial Interface)-2 ver. 4.0, which is currently undergoing standardization, defines two types of packet structures: one that uses C-PHY in the physical layer, and one that uses D-PHY in the physical layer.

[0003] In recent years, the CSI-2 standard has been used not only in mobile devices but also in a wide variety of applications, such as in-vehicle and IoT (Internet of Things), and as a result, it is expected that the existing packet structure will not be able to support these applications. Therefore, the MIPI (Mobile Industry Processor Interface) Alliance is considering extending the packet structure, such as the existing packet header and packet footer, to support a wider range of applications.

[0004] Patent Document 1 proposes a system that utilizes the CSI-2 standard to reduce the number of data buses when connecting a processing device and multiple image sensors.

[0005] Conventional standards such as CCI (Camera Control Interface) and I2C (Inter-Integrated Circuit) were developed for the mobile market and are communication systems with insufficient error detection capabilities. In contrast, automotive CIS (CMOS Image Sensors) require increased reliability, similar to that of automotive communications. For example, to comply with ISO26262 (Functional Safety), error detection functions such as CRC and MessageCount are required.

[0006] Patent Document 2 discloses a technique for performing communication by adding a CRC to the I2C protocol. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] Japanese Patent Application Publication No. 2017-211864 [Patent Document 2] Japanese Patent Application Laid-Open No. 2002-175269 Summary of the Invention [Problem to be solved by the invention]

[0008] However, simply adding a CRC to the I2C protocol to improve communication reliability, as disclosed in the aforementioned Patent Document 2, would result in a loss of compatibility with the existing CCI standard. Therefore, existing CCI circuits are expected to recognize the CRC added at the final stage as register write data. As a result, not only would error detection be impossible, but writing an incorrect value to an incorrect register address could result in unintended operation and even system deadlock.

[0009] As mentioned above, the expansion of the packet structure of the CSI-2 standard is being considered, but in doing so, it is necessary to maintain compatibility with the existing CSI-2 standard while enabling it to transmit more information and accommodate a wider range of applications, and it is also necessary to ensure that the packet structure does not violate the regulations prohibiting packet modification on the transmission path.

[0010] The present disclosure has been made in light of the above circumstances, and aims to enable a wider variety of applications to be accommodated and to improve the reliability of communications. [Means for solving the problem]

[0011] A communication device according to one aspect of the present disclosure includes a physical layer in which the CCI (Camera Control Interface) protocol is implemented as an upper layer, and which transmits and receives data including an extended header and an extended footer to and from other communication devices, and a CCI-FS processing unit which compares a Destination ID included in the extended header with an ID (Source ID) possessed by the communication device to determine whether or not access is to be made to the communication device.

[0012] A communication method or program according to one aspect of the present disclosure includes transmitting and receiving data including an extended header and an extended footer to and from another communication device via a physical layer in which a CCI (Camera Control Interface) protocol is implemented as an upper layer, and comparing a Destination ID included in the extended header with an ID (Source ID) held by the communication device to determine whether or not the communication device is being accessed.

[0013] In one aspect of the present disclosure, a physical layer in which the CCI (Camera Control Interface) protocol is implemented as an upper layer transmits and receives data including an extended header and an extended footer to and from other communication devices, and compares the Destination ID included in the extended header with an ID (Source ID) held by the communication device to determine whether or not the communication device is being accessed. [Brief explanation of the drawings]

[0014] [Figure 1] 1 is a block diagram showing a configuration example of a first embodiment of a communication system to which the present technology is applied. [Figure 2] FIG. 10 is a block diagram showing a configuration example of a second embodiment of a communication system to which the present technology is applied. [Figure 3] FIG. 10 is a diagram illustrating a first example of the overall packet structure of an extended packet for D-PHY. [Figure 4] FIG. 10 is a diagram illustrating a first example of the packet structure of an extended short packet for D-PHY. [Figure 5] FIG. 10 is a diagram illustrating a first example of the packet structure of an extended long packet for D-PHY. [Figure 6] FIG. 10 is a diagram illustrating a first example of the overall packet structure of an extended packet for C-PHY. [Figure 7] FIG. 10 is a diagram illustrating a first example of the packet structure of an extended short packet for C-PHY. [Figure 8] FIG. 10 is a diagram illustrating a first example of the packet structure of an extended long packet for C-PHY. [Figure 9] FIG. 2 is a block diagram illustrating a configuration example of an image sensor. [Figure 10] FIG. 2 is a block diagram illustrating a configuration example of an application processor. [Figure 11] 10 is a flowchart illustrating a process in which the image sensor transmits a packet. [Figure 12] 10 is a flowchart illustrating an extended mode transmission process. [Figure 13] 10 is a flowchart illustrating a process in which an application processor receives a packet. [Figure 14] 10 is a flowchart illustrating an extended mode reception process. [Figure 15] FIG. 10 is a diagram illustrating a second example of the overall packet structure of an extended packet for D-PHY. [Figure 16]FIG. 10 is a diagram illustrating a second example of the packet structure of an extended long packet for D-PHY. [Figure 17] FIG. 10 is a diagram illustrating a second example of the packet structure of an extended short packet for C-PHY. [Figure 18] FIG. 10 is a diagram illustrating a second example of the packet structure of an extended long packet for C-PHY. [Figure 19] FIG. 10 is a block diagram illustrating a modified example of the configuration for switching between D-PHY and C-PHY. [Figure 20] FIG. 10 is a block diagram showing a configuration example of a third embodiment of a communication system to which the present technology is applied. [Figure 21] FIG. 10 is a diagram illustrating an example of the structure of an extended packet for D-PHY that complies with the packet modification prohibition provision. [Figure 22] FIG. 10 is a diagram illustrating an example of the structure of an extended packet for C-PHY that complies with the packet modification prohibition provision. [Figure 23] FIG. 10 is a diagram illustrating an example of the structure of an extended packet for A-PHY that complies with the packet modification prohibition provision. [Figure 24] 10 is a flowchart illustrating a packet transmission / reception process that complies with the packet modification prohibition rule. [Figure 25] FIG. 1 is a block diagram showing an example of the configuration of an image sensor that complies with the packet modification prohibition provision. [Figure 26] FIG. 1 is a block diagram showing an example of the configuration of an application processor that complies with the packet modification prohibition provision. [Figure 27] FIG. 1 is a block diagram illustrating an example of the configuration of a communication system in which an image sensor and an application processor are directly connected to each other. [Figure 28] FIG. 10 is a diagram illustrating an example of a packet configuration of a read command generated on the application processor side. [Figure 29] FIG. 10 is a diagram illustrating an example of a packet configuration of a read command transferred by A-PHY. [Figure 30] 10A and 10B are diagrams illustrating an example of a packet configuration of a read command and read data on the image sensor side. [Figure 31] FIG. 10 is a diagram illustrating an example of a packet configuration of read data transferred by A-PHY. [Figure 32] FIG. 10 is a diagram illustrating an example of a packet configuration of read data acquired on the application processor side. [Figure 33] FIG. 10 is a diagram illustrating an example of a packet configuration of write data generated on the application processor side. [Figure 34] 10 is a diagram illustrating an example of a packet configuration of write data transferred by A-PHY. FIG. [Figure 35] 10 is a diagram illustrating an example of a packet configuration of write data acquired on the image sensor side. FIG. [Figure 36] FIG. 10 is a diagram illustrating an overview of an extended packet header ePH and an extended packet footer ePF. [Figure 37] 10 is a flowchart illustrating an initial setting and confirmation operation of communication processing using CCI-FS. [Figure 38] 10 is a flowchart illustrating a write operation using CCI-FS. [Figure 39] 10 is a flowchart illustrating a read operation using CCI-FS. [Figure 40] FIG. 1 is a block diagram illustrating an example of the configuration of a communication system in which an image sensor and an application processor are connected via SerDes. [Figure 41] FIG. 10 is a diagram illustrating an example of a packet configuration of a read command generated on the application processor side. [Figure 42] FIG. 10 is a diagram illustrating an example of a packet configuration of a read command output via I2C / I3C. [Figure 43] FIG. 10 is a diagram illustrating an example of a packet configuration of a read command transferred by A-PHY. [Figure 44] 10 is a diagram illustrating an example of a packet configuration of read data generated by a slave-side SerDes device. FIG. [Figure 45] 10A and 10B are diagrams illustrating an example of a packet configuration of a read command and read data on the image sensor side. [Figure 46] FIG. 10 is a diagram illustrating an example of a packet configuration of read data output via I2C / I3C. [Figure 47] FIG. 10 is a diagram illustrating an example of a packet configuration of read data transferred by A-PHY. [Figure 48] FIG. 10 is a diagram illustrating an example of a packet configuration of read data output via I2C / I3C. [Figure 49] FIG. 10 is a diagram illustrating an example of a packet configuration of read data acquired on the application processor side. [Figure 50] 10 is a flowchart illustrating an initial setting and confirmation operation of communication processing using CCI-FS. [Figure 51] 10 is a flowchart illustrating a write operation using CCI-FS. [Figure 52] 10 is a flowchart illustrating a read operation using CCI-FS. [Figure 53] 10 is a flowchart illustrating Sequence A_Write (AP time) processing. [Figure 54] 10 is a flowchart illustrating Sequence A_Read_CMD (AP) processing. [Figure 55] 10 is a flowchart illustrating Sequence C (AP) processing. [Figure 56] 10 is a flowchart illustrating Sequence B (SerDes (Slave)) processing. [Figure 57] 10 is a flowchart illustrating Sequence A_Read_Data (AP time) processing. [Figure 58] 10 is a diagram showing details of an extension packet header ePH0, an extension packet header ePH1, and an extension packet header ePH2. [Figure 59] FIG. 10 is a diagram showing details of an extended packet header ePH3. [Figure 60] FIG. 10 is a diagram showing details of an extended DT of an extended packet header ePH. [Figure 61] FIG. 1 is a block diagram showing an example of a conventional I2C hardware configuration. [Figure 62] FIG. 10 is a diagram showing an example of a waveform during data transfer on an I2C bus. [Figure 63] FIG. 1 is a block diagram illustrating an example of a CCI-related configuration in a communication system having an A-PHY direct connection configuration. [Figure 64] FIG. 1 is a diagram illustrating an example of a network connection configuration. [Figure 65] FIG. 2 is a block diagram showing an example of a circuit configuration of a CCI-FS processing unit. [Figure 66] FIG. 2 is a diagram illustrating an example of a register configuration. [Figure 67] FIG. 10 is a diagram illustrating an example of a register configuration in a bridge configuration. [Figure 68] FIG. 10 is a diagram illustrating an example of a register configuration of an error-related register. [Figure 69] FIG. 10 is a diagram showing a modified example of an extended packet header ePH in the packet configuration of write data generated on the application processor side. [Figure 70] FIG. 10 is a diagram illustrating a modified example of an extended packet header ePH in the packet configuration of a read command generated on the application processor side. [Figure 71] FIG. 10 is a diagram illustrating a flow between an application processor and an image sensor in an A-PHY direct connection configuration. [Figure 72] FIG. 10 is a diagram illustrating a flow using the Clock Stretch method. [Figure 73] FIG. 2 is a block diagram showing a detailed configuration example of an image sensor including a CCI-FS processing unit. [Figure 74] FIG. 2 is a block diagram illustrating a detailed configuration example of an application processor including a CCI-FS processing unit. [Figure 75] 1 is a block diagram illustrating an example of the configuration of an embodiment of a computer to which the present technology is applied. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, specific embodiments to which the present technology is applied will be described in detail with reference to the drawings.

[0016] <Example of communication system configuration> FIG. 1 is a block diagram showing a configuration example of a first embodiment of a communication system to which the present technology is applied.

[0017] 1, the communication system 11 is configured by connecting an image sensor 21 and an application processor 22 via a bus 23. For example, the communication system 11 is used for CSI-2 connection inside an existing mobile device such as a smartphone.

[0018] The image sensor 21 is configured by incorporating, for example, a lens, an imaging element (neither of which are shown), and an extended mode-compatible CSI-2 transmission circuit 31. For example, the image sensor 21 transmits image data of an image captured by the imaging element to the application processor 22 via the extended mode-compatible CSI-2 transmission circuit 31.

[0019] The application processor 22 is configured by incorporating an extended mode-compatible CSI-2 receiver circuit 32 together with an LSI (Large Scale Integration) that performs processing according to various applications executed in a mobile device equipped with the communication system 11. For example, the application processor 22 receives image data transmitted from the image sensor 21 using the extended mode-compatible CSI-2 receiver circuit 32, and can process the image data according to the application using the LSI.

[0020] The bus 23 is a communication path that transmits signals in accordance with the CSI-2 standard, and the possible transmission distance for signals is, for example, approximately 30 cm. The bus 23 also connects the image sensor 21 and the application processor 22 via multiple signal lines (I2C, CLKP / N, D0P / N, D1P / N, D2P / N, D3P / N) as shown in the figure.

[0021] The extended-mode-compatible CSI-2 transmitter circuit 31 and the extended-mode-compatible CSI-2 receiver circuit 32 support communication in extended mode, an extension of the CSI-2 standard, and can transmit and receive signals to and from each other. Note that the detailed configurations of the extended-mode-compatible CSI-2 transmitter circuit 31 and the extended-mode-compatible CSI-2 receiver circuit 32 will be described later with reference to FIGS. 9 and 10.

[0022] FIG. 2 is a block diagram showing a configuration example of a second embodiment of a communication system to which the present technology is applied.

[0023] 2, communication system 11A is configured such that image sensor 21 and SerDes device 25 are connected via bus 24-1, application processor 22 and SerDes device 26 are connected via bus 24-2, and SerDes device 25 and SerDes device 26 are connected via bus 27. For example, communication system 11A is used for connection in an existing vehicle-mounted camera.

[0024] Here, the image sensor 21 and the application processor 22 are configured in the same manner as the image sensor 21 and the application processor 22 in FIG. 1, and a detailed description thereof will be omitted.

[0025] Buses 24-1 and 24-2, like bus 23 in Figure 1, are communication paths that transmit signals in accordance with the CSI-2 standard, and are configured with multiple signal lines (HS-GPIO, I2C / I3C, CLKP / N, D0P / N, D1P / N, D2P / N, D3P / N) as shown in the figure.

[0026] The SerDes device 25 is configured to include a CSI-2 receiving circuit 33 and a SerDes (Serializer Deserializer) transmitting circuit 34. For example, the CSI-2 receiving circuit 33 communicates with the extended-mode-compatible CSI-2 transmitting circuit 31 in accordance with the normal CSI-2 standard, thereby acquiring a bit-parallel signal transmitted from the image sensor 21. The SerDes device 25 then converts the acquired signal into a bit-serial signal, and transmits the signal to the SerDes device 26 by the SerDes transmitting circuit 34 communicating with the SerDes receiving circuit 35 over one lane.

[0027] The SerDes device 26 is configured to include a SerDes receiver circuit 35 and a CSI-2 transmitter circuit 36. For example, the SerDes device 26 acquires a bit-serial signal transmitted by the SerDes receiver circuit 35 performing one-lane communication with the SerDes transmitter circuit 34. The SerDes device 26 then converts the acquired signal into a bit-parallel signal, and transmits it to the application processor 22 by the CSI-2 transmitter circuit 36 performing communication with the extended-mode-compatible CSI-2 receiver circuit 32 in accordance with the normal CSI-2 standard.

[0028] Bus 27 is a communication path that transmits signals in accordance with standards such as A-PHY and FPD (Flat Panel Display)-LINK III, and the transmission distance over which signals can be transmitted is long, for example, about 15 m.

[0029] These long-distance physical layer interfaces enable the automotive industry to enable advanced driver assistance systems (ADAS), autonomous driving systems (ADS), and other surround sensor applications, including cameras and in-vehicle infotainment (IVI) displays. MIPI A-PHY has an asymmetric data link layer (asymmetric upper layer) in a point-to-point topology, allowing the same physical wiring to be shared for high-speed data transmission, control data, and power. It serves as the foundation for end-to-end systems designed to simplify the integration of cameras, sensors, and displays, while also incorporating functional safety and security.

[0030] The communication systems 11 and 11A configured in this manner can transmit and receive data in packets with an extended packet structure, as described below, using the extended mode-compatible CSI-2 transmitter circuit 31 and the extended mode-compatible CSI-2 receiver circuit 32. This allows for support for a wider variety of applications, such as RAW24, SmartROI (Region of Interest), and GLD (Graceful Link Degradation), as described below.

[0031] <First example of packet structure> A first example of the packet structure of a packet used in communication between the enhanced mode-compatible CSI-2 transmitter circuit 31 and the enhanced mode-compatible CSI-2 receiver circuit 32 will be described with reference to FIGS.

[0032] FIG. 3 shows the overall packet structure of a packet used in the extended mode of CSI-2 when the physical layer is D-PHY (hereinafter referred to as an extended packet for D-PHY).

[0033] As shown in Figure 3, the packet header and footer of the D-PHY extended packet have the same packet structure as the existing CSI-2 standard. For example, the packet header stores VC (Virtual Channel), which indicates the number of virtual channel lines, DataType, which indicates the data type, WC (Word Count), which indicates the data length of the payload, and VCX / ECC. The packet footer also stores CRC (Cyclic Redundancy Check).

[0034] In the existing CSI-2 standard, data types 0x38 to 0x3F are defined as reserved for data types transmitted in packet headers. Therefore, in the D-PHY extended packet, new setting information is defined to identify the extended mode on the receiving side using the existing reserved data types.

[0035] For example, the data type is ·DataType[5:3]=3'b111: Extended mode DataType[2]=Reserve (RES: Reserved for future expansion) DataType[1:0]=extension mode type (four extension modes available) Define

[0036] That is, among the data types 0x38 to 0x3F defined as reserved in the existing CSI-2 standard, for example, DataType[5:3] is defined as extended mode setting information, and DataType[1:0] is defined as extended type setting information. The extended mode setting information indicates whether or not the mode is extended. For example, when DataType[5:3] is 3'b111, it indicates extended mode. Furthermore, when four types of extended mode are provided, namely extended mode 0, extended mode 1, extended mode 2, and extended mode 3, the extended type setting information indicates which of these types it is. For example, when DataType[1:0] is 2'b00, it indicates that the type of extended mode is extended mode 0.

[0037] In extended mode 0 (DataType[1:0]=2'b00), for example, a packet structure in which the payload is separated into four parts is defined. That is, the payload in extended mode 0 is separated into an extended packet header (ePH), an optional extended packet header (OePH), a legacy payload, and an optional extended packet footer (OePF), as shown in FIG. 3. The extended packet header may be transmitted repeatedly.

[0038] The extended packet header is placed at the beginning of the payload in the existing CSI-2 standard, and must be transmitted in extended mode. For example, as shown in the figure, the extended packet header consists of configuration information such as an SROI identification flag, an extended VC (Virtual Channel), an extended DataType, an OePH selection flag, and an OePF selection flag. Here, the extended VC extends the VC, which was 4 bits in the existing CSI-2 standard, to 8 bits, and the extended DataType extends the DataType, which was 4 bits in the existing CSI-2 standard, to 8 bits.

[0039] For example, in a D-PHY packet, the existing packet header already has 4 bits for VC, and by defining the extended packet header's extended VC as 4 bits, a total of 8 bits can be achieved. Specifically, OePH[7:0] = {5'h00,RSID,XY_POS,MC} and OePF[3:0] = {3'h0,pCRC} can be defined, allowing for on / off control of packet transmission as required for each application.

[0040] The optional extended packet header and optional extended packet footer are selectively transmitted depending on the application.

[0041] The legacy payload corresponds to the same payload as the existing CSI-2 standard.

[0042] In this way, by setting the extended packet header, optional extended packet header, and optional extended packet footer as needed, it becomes possible to transmit data suitable for various applications. Furthermore, data transmitted in the extended packet header, optional extended packet header, and optional extended packet footer uses a 26-bit + 6-bit ECC (Error Correction Code). This allows the existing packet header circuit to be reused, suppressing an increase in circuit size and improving error tolerance.

[0043] As a specific application example of such an extended packet for D-PHY, Fig. 4 shows the packet structure of a short packet (hereinafter referred to as an extended short packet for D-PHY) used in the extended mode of CSI-2 when the physical layer is D-PHY. Similarly, Fig. 5 shows the packet structure of a long packet (hereinafter referred to as an extended long packet for D-PHY) used in the extended mode of CSI-2 when the physical layer is D-PHY.

[0044] 4, in the D-PHY extended short packet, the data type extended type setting information stored in the packet header indicates that the type of extended mode is extended mode 0 (DT[5:0]=0x1C(5'b111_0_0)). Also, the data type short packet setting information stored in the extended packet header indicates that it is a short packet (DT[7:0]=0x00 (Frame Start Code(Short Packet))).

[0045] In this way, when the extended mode is selected and the data type stored in the extended packet header is DT[7:0]=0x00-0x0F, the packet is treated as an extended short packet, and the optional extended packet header always contains data including the Short Packet Data Field of the extended short packet. This Short Packet Data Field is the same as that defined in the existing CSI-2 standard.

[0046] When transmitting an extended short packet, the MC (MessageCount for GLD) and RSID (Vehicle Line Number and Source ID) of the optional extended packet header may be transmitted, but the legacy payload and pCRC are not required and therefore must not be transmitted. If they are transmitted by mistake, they will be ignored by the receiving side.

[0047] 4, the extended short packet can expand the bit width of the data type and virtual channel compared to the extended short packet conforming to the existing CSI-2 standard, and can support various applications defined by the optional extension packet header. Furthermore, if these functions are not required, the extended short packet conforming to the existing CSI-2 standard may be transmitted together with the extended long packet.

[0048] In an extended long packet for D-PHY as shown in Figure 5, the data type extended type setting information stored in the packet header indicates that the type of extended mode is extended mode 0 (DT[5:0] = 0x1C (5'b111_0_0)). Also, the data type short packet setting information stored in the extended packet header indicates that it is a type other than a short packet (DT[7:0] is other than 0x00 to 0x0F (= extended long packet)). Therefore, data including a short packet data field is not transmitted in an extended long packet.

[0049] Furthermore, in accordance with the settings of the extension packet header, the optional extension packet header, legacy payload, and optional extension packet footer are stored in a payload conforming to the existing CSI-2 standard and transmitted. Because they are stored in the existing payload and transmitted in this way, the existing SerDes transmitter circuit 34 and SerDes receiver circuit 35 (FIG. 2) recognize them as the same as image data transmitted in the existing payload, and transmit them as is to the subsequent stages.

[0050] The application processor 22 at the final stage can determine the extended mode based on the data type DT[5:0] in the packet header. Therefore, the application processor 22 can interpret the contents of the payload in order, starting from the extended packet header, and extract the desired extended mode data.

[0051] Fig. 6 shows the overall packet structure of a packet used in the extended mode of CSI-2 when the physical layer is C-PHY (hereinafter referred to as an extended packet for C-PHY). Note that in the extended packet for C-PHY shown in Fig. 6, a description of the configuration common to the extended packet for D-PHY in Fig. 3 will be omitted, and only different configurations will be described.

[0052] For example, in an extended packet for C-PHY, the extended mode is identified by the data type, as in the extended packet for D-PHY in Figure 3, and all data corresponding to each application executed by the application processor 22 is embedded in the payload and transmitted.

[0053] As shown in Figure 6, the extended packet for C-PHY transmits the packet header twice, just like a packet for C-PHY that complies with the existing CSI-2 standard, and arranges data in 16-bit units because C-PHY converts 16 bits to 7 symbols. An extended packet header is placed at the beginning of the payload, but with regard to virtual channels, the beginning of the existing packet header for C-PHY was reserved for this purpose, so virtual channels are not stored in the extended packet header. Of course, virtual channels may be stored in the extended packet header, just like an extended packet for D-PHY.

[0054] Furthermore, because the optional extended packet header and optional extended packet footer have a large number of bits, a flag called OePHF is prepared, and when this flag is 1, the OePH / OePF information is transmitted next. After the ePH information and OePH information, a CRC is transmitted as an extended packet header, and a similarly configured packet header is transmitted twice. In this way, by maintaining the same structure as the existing mechanism for transmitting packet headers twice, it is possible to achieve both circuit reuse and error tolerance.

[0055] As a specific application example of such an extended packet for C-PHY, Fig. 7 shows the packet structure of a short packet (hereinafter referred to as an extended short packet for C-PHY) used in the extended mode of CSI-2 when the physical layer is C-PHY. Similarly, Fig. 8 shows the packet structure of a long packet (hereinafter referred to as an extended long packet for C-PHY) used in the extended mode of CSI-2 when the physical layer is C-PHY.

[0056] The extended short packet for C-PHY shown in FIG. 7 has a packet structure that is not significantly different from that of the extended short packet for D-PHY shown in FIG. 4, and the extended long packet for C-PHY shown in FIG. 8 has a packet structure that is not significantly different from that of the extended long packet for D-PHY shown in FIG. 5.

[0057] <Configuration example of image sensor and application processor> FIG. 9 is a block diagram showing an example of the configuration of the image sensor 21 including the extended mode-compatible CSI-2 transmission circuit 31.

[0058] 9 , in addition to the extended mode-compatible CSI-2 transmission circuit 31, the image sensor 21 is configured to include pixels 41, an AD converter 42, an image processing unit 43, a pixel CRC calculation unit 44, a physical layer processing unit 45, an I2C / I3C slave 46, and a register 47. The extended mode-compatible CSI-2 transmission circuit 31 is also configured to include a packing unit 51, a packet header generation unit 52, an extended packet header generation unit 53, an extended packet footer generation unit 54, selection units 55 and 56, a CRC calculation unit 57, a lane distribution unit 58, a CCI slave 59, and a controller 60.

[0059] The pixels 41 output analog pixel signals corresponding to the amount of light received, and an analog-to-digital converter (ADC) 42 converts the pixel signals output from the pixels 41 into digital signals and supplies them to an image processing unit 43. The image processing unit (ISP) 43 supplies image data obtained by performing various image processes on an image based on the pixel signals to a pixel CRC calculation unit 44 and a packing unit 51. The image processing unit 43 also supplies a data enable signal data_en indicating whether the image data is valid to the packing unit 51 and the controller 60.

[0060] The pixel CRC calculation unit 44 calculates and obtains a CRC for each pixel in the image data supplied from the image processing unit 43, and supplies the CRC to an extended packet footer generation unit 54.

[0061] The physical layer processing unit 45 can perform physical layer processing for both C-PHY and D-PHY. For example, the physical layer processing unit 45 performs physical layer processing for C-PHY when a C-layer enable signal cphy_en supplied from the controller 60 is enabled, and performs physical layer processing for D-PHY when the C-layer enable signal cphy_en is disabled. The physical layer processing unit 45 then transmits the packets divided into four lanes by the lane distribution unit 58 to the application processor 22.

[0062] The I2C / I3C slave 46 performs communication under the initiative of an I2C / I3C master 72 (FIG. 10) of the application processor 22, based on the I2C (Inter-Integrated Circuit) or I3C (Improved Inter Integrated Circuits) standard.

[0063] Various settings transmitted from the application processor 22 are written to the register 47 via the I2C / I3C slave 46 and the CCI slave 59. Here, the settings written to the register 47 include, for example, communication settings in accordance with the CSI-2 standard, extended mode settings indicating whether or not extended mode is used, and fixed communication settings required for communication in extended mode.

[0064] The packing unit 51 performs packing processing to store the image data supplied from the image processing unit 43 in the payload of a packet, and supplies the payload to the selection unit 55 and the lane distribution unit 58 .

[0065] When the packet header generator 52 is instructed to generate a packet header in accordance with a packet header generation instruction signal ph_go supplied from the controller 60 , the packet header generator 52 generates a packet header and supplies it to the selector 55 and lane distributor 58 .

[0066] That is, the packet header generator 52 generates a packet header that stores setting information indicating conditions set for data transmitted in a packet, for example, a data type indicating the type of data, in accordance with the existing CSI-2 standard. Furthermore, the packet header generator 52 stores extended mode setting information indicating whether the extended mode uses an extension header in an unused area of the data type, which is setting information indicating the type of data transmitted in a packet and is defined as unused in the existing CSI-2 standard. Furthermore, the packet header generator 52 stores extended type setting information indicating which of multiple types of extended modes provided is used in the unused area.

[0067] The extension packet header generator 53 generates an extension packet header and an optional extension packet header in accordance with an extension packet header generation instruction signal eph_go and an extension packet header enable signal ePH_en supplied from the controller 60, and supplies them to the selector 56 and the lane distributor 58. In addition, the extension packet header generator 53 is supplied with an in-vehicle row number, a source ID (identification), and the like depending on the application of the image sensor 21, and stores them in the extension packet header or the optional extension packet header as necessary.

[0068] That is, the extension packet header generator 53 generates an extension packet header that stores setting information such as that shown in Fig. 3, separately from the packet header generated by the packet header generator 52. Furthermore, when transmitting an optional extension packet header, the extension packet header generator 53 stores optional extension packet header setting information indicating that an optional extension packet header is to be transmitted in the extension packet header as optional extension packet header setting information (OePH[7:0]) indicating whether or not an optional extension packet header is to be transmitted, and generates the optional extension packet header following the extension packet header.

[0069] The extended packet footer generator 54 generates an optional extended packet footer in accordance with the extended packet footer generation instruction signal epf_go and the extended packet header enable signal ePF_en supplied from the controller 60 , and supplies the generated optional extended packet footer to the selector 56 and the lane distributor 58 .

[0070] That is, when a packet transmitted in extended mode is an extended long packet that stores data transmitted as a payload in the existing CSI-2 standard, the extended packet footer generation unit 54 generates an optional extended packet footer that is placed following the legacy payload in which the data is stored.

[0071] Furthermore, a C-layer enable signal cphy_en is supplied from the controller 60 to the packet header generator 52, the extended packet header generator 53, and the extended packet footer generator 54. When the C-layer enable signal cphy_en indicates valid, the packet header generator 52 generates a packet header for C-PHY, the extended packet header generator 53 generates an extended packet header and optional extended packet header for C-PHY, and the extended packet footer generator 54 generates an optional extended packet footer for C-PHY. On the other hand, when the C-layer enable signal cphy_en indicates invalid, the packet header generator 52 generates a packet header for D-PHY, the extended packet header generator 53 generates an extended packet header and optional extended packet header for D-PHY, and the extended packet footer generator 54 generates an optional extended packet footer for D-PHY.

[0072] In accordance with the C-layer enable signal cphy_en supplied from the controller 60, if the C-layer enable signal cphy_en is valid, the selector 55 selects the packet header supplied from the packet header generator 52 and supplies it to the selector 56. On the other hand, if the C-layer enable signal cphy_en is invalid, the selector 55 selects the payload supplied from the packing unit 51 and supplies it to the selector 56.

[0073] In accordance with a data selection signal data_sel supplied from the controller 60, the selector 56 selects one of the packet header or payload selectively supplied via the selector 55, the extended packet header and optional extended packet header supplied from the extended packet header generator 53, and the optional extended packet footer supplied from the extended packet footer generator 54, and supplies the selected one to the CRC calculator 57.

[0074] The CRC calculation unit 57 calculates the CRC of the packet header, payload, extended packet header, optional extended packet header, or optional extended packet footer selectively supplied via the selection unit 56, and supplies the CRC to the lane distribution unit 58.

[0075] Under the control of the controller 60, the lane distribution unit 58 distributes the payload supplied from the packing unit 51, the packet header supplied from the packet header generation unit 52, the extended packet header and optional extended packet header supplied from the extended packet header generation unit 53, the optional extended packet footer supplied from the extended packet footer generation unit 54, and the CRC supplied from the CRC calculation unit 57 to four lanes in accordance with the CSI-2 standard, and supplies them to the physical layer processing unit 45.

[0076] A CCI (Camera Control Interface) slave 59 performs communication under the initiative of a CCI master 88 (FIG. 10) of the application processor 22 based on the CSI-2 standard.

[0077] The controller 60 reads out various settings stored in the register 47 and, according to those settings, controls each block constituting the extended mode-compatible CSI-2 transmission circuit 31. For example, the controller 60 controls switching between transmitting packets with a packet structure conforming to the existing CSI-2 standard and transmitting packets with a packet structure in extended mode, depending on the content of the data to be transmitted.

[0078] The image sensor 21 is configured in this way, and can generate an extended packet having the packet structure as described with reference to FIGS.

[0079] FIG. 10 is a block diagram showing an example of the configuration of an application processor 22 including an extended mode-compatible CSI-2 receiver circuit 32.

[0080] 10 , in addition to the extended mode-compatible CSI-2 receiver circuit 32, the application processor 22 is configured to include a physical layer processing unit 71, an I2C / I3C master 72, a register 73, and a controller 74. The extended mode-compatible CSI-2 receiver circuit 32 is configured to include a packet header detection unit 81, a lane merging unit 82, an interpretation unit 83, selection units 84 and 85, a CRC calculation unit 86, an unpacking unit 87, and a CCI master 88.

[0081] The physical layer processing unit 71 can perform physical layer processing for both C-PHY and D-PHY. As described above, the physical layer processing unit 45 of the image sensor 21 performs physical layer processing for either C-PHY or D-PHY, and the physical layer processing unit 71 performs the same physical layer processing as that performed by the physical layer processing unit 45.

[0082] The I2C / I3C master 72 takes the lead in communicating with the I2C / I3C slave 46 (FIG. 9) of the image sensor 21 based on the I2C or I3C standard.

[0083] In the register 73, various settings to be written by the controller 74 to the register 47 of the image sensor 21 are recorded.

[0084] The controller 74 controls each block that constitutes the application processor 22 .

[0085] The packet header detection unit 81 detects a packet header from the packet supplied from the physical layer processing unit 71 and checks the data type stored in the packet header. If the extended mode setting information in the data type of the packet header indicates the extended mode (DataType[5:3]=3'b111), the packet header detection unit 81 supplies an extended mode detection flag indicating the extended mode to the interpretation unit 83, the selection unit 84, and the selection unit 85. The packet header detection unit 81 also supplies a merging enable signal mrg_en indicating whether or not to enable merging of the four divided lanes to the lane merging unit 82 based on the packet header.

[0086] That is, the packet header detection unit 81 detects a packet header that stores setting information (such as a data type) indicating conditions set for data transmitted in a packet in accordance with the existing CSI-2 standard. In this case, the packet header detection unit 81 outputs an extended mode detection flag in accordance with extended mode setting information indicating whether an extended mode using an extended header is in effect, and the extended mode setting information is stored in an unused area defined as unused in the existing CSI-2 standard in the data type, which is setting information indicating the type of data transmitted in the packet. This allows the unit to switch between receiving packets with a packet structure in accordance with the existing CSI-2 standard and receiving packets with a packet structure in the extended mode. Furthermore, the packet header detection unit 81 recognizes which type of extended mode is in effect among multiple types of extended modes provided as extended modes, in accordance with extended mode type information stored in an unused area of a data type defined as unused in the existing CSI-2 standard.

[0087] When the merge enable signal mrg_en supplied from the packet header detection unit 81 is valid, the lane merging unit 82 merges the packets divided into four lanes supplied from the physical layer processing unit 71. Then, the lane merging unit 82 supplies the packet of one lane to the interpretation unit 83, the selection unit 84, and the selection unit 85.

[0088] If the extended mode detection flag supplied from the packet header detection unit 81 indicates the extended mode, the interpretation unit 83 reads the extended packet header, optional extension packet header, and optional extension packet footer from the packet supplied from the lane merging unit 82 based on the packet structure of the extended mode. Then, the interpretation unit 83 interprets the setting information stored in the extended packet header, optional extension packet header, and optional extension packet footer.

[0089] That is, the interpretation unit 83 receives an extension packet header placed at the beginning of a payload conforming to the existing CSI-2 standard as an extension header and interprets the setting information stored in the extension packet header. Furthermore, when the optional extension packet header setting information stored in the extension packet header indicates that an optional extension packet header that is selectively transmitted depending on the application is to be transmitted, the interpretation unit 83 receives an optional extension packet header following the extension packet header and interprets the setting information stored in the optional extension packet header. Furthermore, when a packet transmitted in extended mode is an extended long packet that stores data transmitted as a payload in the existing CSI-2 standard, the interpretation unit 83 receives an optional extension packet footer placed following the legacy payload in which the data is stored and interprets the optional extension packet footer.

[0090] The interpretation unit 83 then reads out, for example, the vehicle row number and source ID stored in the optional extension packet header, and outputs them to a subsequent LSI (not shown).

[0091] If the extended mode detection flag supplied from the packet header detection unit 81 does not indicate the extended mode, that is, if a packet with an existing packet structure is supplied, the interpretation unit 83 stops without performing the above-mentioned processing.

[0092] The selector 84 selectively supplies data to an unpacking unit 87 based on the packet structure of the existing packet or the packet structure of the extended packet in accordance with the extended mode detection flag supplied from the packet header detector 81 .

[0093] The selector 85 selectively supplies data to a CRC calculator 86 based on the packet structure of the existing packet or the packet structure of the extended packet in accordance with the extended mode detection flag supplied from the packet header detector 81 .

[0094] The CRC calculation unit 86 calculates the CRC of the packet header, payload, extension packet header, optional extension packet header, or optional extension packet footer selectively supplied via the selection unit 85. If a CRC error is detected, the CRC calculation unit 86 outputs a CRC error detection signal indicating this to a downstream LSI (not shown).

[0095] The unpacking unit 87 performs an unpacking process to extract image data stored in the payload selectively supplied via the selection unit 84, and outputs the acquired image data to a downstream LSI (not shown).

[0096] The CCI master 88 takes the lead in communicating with the CCI slave 59 (FIG. 9) of the image sensor 21 based on the CSI-2 standard.

[0097] The application processor 22 is configured in this way, and can receive an extension packet sent from the image sensor 21, interpret the setting information stored in the extension packet header, optional extension packet header, and optional extension packet footer, and acquire image data.

[0098] <Communication processing> The communication processing performed by the image sensor 21 and the application processor 22 will be described with reference to FIGS.

[0099] FIG. 11 is a flowchart illustrating a process in which the image sensor 21 transmits a packet.

[0100] For example, processing begins when the image sensor 21 is connected to the application processor 22 via the bus 23. In step S11, the controller 60 determines whether or not to use the extended mode when starting communication with the application processor 22. For example, the controller 60 checks the extended mode setting stored in the register 47, and determines that the extended mode will be used if the extended mode setting indicating the use of the extended mode has been written by the application processor 22.

[0101] If the controller 60 determines in step S11 that the extended mode will not be used, the process proceeds to step S12.

[0102] In step S12, the I2C / I3C slave 46 receives a command to start transmitting image data transmitted from the application processor 22 (in step S54 of FIG. 13, which will be described later). Furthermore, the I2C / I3C slave 46 receives communication settings conforming to the CSI-2 standard transmitted together with the transmission start command, and writes the settings to the register 47 via the CSI slave 59.

[0103] In step S13, the image sensor 21 performs a conventional packet transmission process, transmitting a packet having a packet structure conforming to the existing CSI-2 standard to the application processor 22 based on the communication settings stored in the register 47.

[0104] On the other hand, if the controller 60 determines in step S11 that the extended mode is to be used, the process proceeds to step S14.

[0105] In step S14, the I2C / I3C slave 46 receives fixed communication settings required for communication in extended mode (for example, a copy of each lane of PH / PF in GLD mode) and writes them to the register 47 via the CCI slave 59.

[0106] In step S15, the I2C / I3C slave 46 receives a command to start transmitting image data transmitted from the application processor 22 (in step S57 of FIG. 13, which will be described later). Furthermore, the I2C / I3C slave 46 receives communication settings conforming to the CSI-2 standard transmitted together with the transmission start command, and writes them into the register 47 via the CSI slave 59.

[0107] In step S16, the controller 60 determines whether or not to start transmitting packets, and waits until it determines to start transmitting packets.

[0108] If it is determined in step S16 that packet transmission should be started, the process proceeds to step S17, where the controller 60 determines whether the data should be transmitted in the extended mode. Here, the controller 60 determines that the data should be transmitted in the extended mode depending on the content of the data to be transmitted, for example, if the data is data that would be transmitted in a use case of an application example described below.

[0109] If the controller 60 determines in step S17 that the data should be transmitted in the extended mode, the process proceeds to step S18, where an extended mode transmission process (see FIG. 12) is performed to transmit an extended packet corresponding to the extended mode.

[0110] On the other hand, if the controller 60 determines in step S17 that the data is not to be transmitted in the extended mode, the process proceeds to step S19.

[0111] In step S19, the controller 60 determines whether or not to transmit a short packet. For example, the controller 60 determines to transmit a short packet at the start and end of a frame.

[0112] If the controller 60 determines in step S19 to transmit a short packet, the process proceeds to step S20. In step S20, the packet header generator 52 generates a packet header and transmits a short packet with a conventional packet structure to the application processor 22.

[0113] On the other hand, if the controller 60 determines in step S19 not to transmit a short packet (i.e., to transmit a long packet), the process proceeds to step S21. In step S21, the packing unit 51 stores the image data in the payload, and the CRC calculation unit 57 calculates the CRC to generate a long packet with a conventional packet structure, which is then transmitted to the application processor 22.

[0114] After the processing of step S18, step S20, or step S21, the process proceeds to step S22, where the controller 60 ends the packet transmission process. Thereafter, the process returns to step S16, and the process of transmitting the packet is similarly repeated for the next packet.

[0115] FIG. 12 is a flowchart illustrating the extended mode transmission process performed in the process of step S18 in FIG.

[0116] In step S31, the packet header generation unit 52 generates a packet header that stores the VC, data type, WC, etc., and transmits it to the application processor 22. At this time, the packet header generation unit 52 writes, to the data type of the packet header, extended mode setting information (DataType[5:3]=3'b111) indicating the extended mode, and extended type setting information (DataType[1:0]=2'b00) identifying that the mode setting of the extended mode is extended mode 0.

[0117] In step S32, the application processor 22 determines whether to transmit an extended short packet. For example, the controller 60 determines to transmit an extended short packet at the start and end of a frame.

[0118] If the application processor 22 determines in step S32 that an extended short packet is to be transmitted, the process proceeds to step S33.

[0119] In step S33, the extension packet header generator 53 transmits an extension packet header in which the data type (DataType[7:0]) is set to short packet in the first byte of the payload. At this time, the extension packet header generator 53 performs various settings (e.g., OePH[7:0], OePF[3:0], etc.) to be stored in the extension packet header.

[0120] In step S34, the extended packet header generator 53 stores a frame number (FN: Frame Number) in the second byte of the payload and transmits it.

[0121] In step S35, the extension packet header generator 53 generates and transmits an optional extension packet header as shown in FIG. 4 in accordance with the setting (OePH[7:0]) made in step S33.

[0122] In step S36, the CRC calculation unit 57 calculates the CRC and transmits it as a packet footer.

[0123] On the other hand, if the application processor 22 determines in step S32 not to transmit an extended short packet (that is, to transmit a long packet), the process proceeds to step S37.

[0124] In step S37, the extension packet header generator 53 transmits an extension packet header in which the data type (DataType[7:0]) is set to other than a short packet in the first byte of the payload. At this time, the extension packet header generator 53 performs various settings (e.g., OePH[7:0], OePF[3:0], etc.) to be stored in the extension packet header.

[0125] In step S38, the extension packet header generator 53 generates and transmits an optional extension packet header as shown in FIG. 5 in accordance with the setting (OePH[7:0]) made in step S37.

[0126] In step S39, the packing unit 51 packs the image data supplied from the image processing unit 43, generates a legacy payload, and transmits it.

[0127] In step S40, the extended packet footer generating unit 54 generates and transmits an optional extended packet footer as shown in FIG. 4 in accordance with the setting (OePF[3:0]) made in step S37.

[0128] In step S41, the CRC calculation unit 57 calculates a CRC and transmits it as a packet footer.

[0129] After the processing of step S36 or S41, the extended mode transmission processing ends.

[0130] As described above, the image sensor 21 can generate and transmit an extended short packet or an extended long packet.

[0131] FIG. 13 is a flowchart illustrating the process in which the application processor 22 receives a packet.

[0132] For example, the process starts when the image sensor 21 is connected to the application processor 22 via the bus 23. In step S51, the controller 74 writes the initial settings of the image sensor 21 (for example, whether C-PHY or D-PHY is to be used as the physical layer) to the register 73 and transmits the settings to the image sensor 21 via the I2C / I3C master 72 and the CCI master 88. As a result, the initial settings are written to the register 47 of the image sensor 21.

[0133] In step S52, the controller 74 determines whether or not the image sensor 21 supports the extended mode. For example, the controller 74 can determine whether or not the image sensor 21 supports the extended mode by acquiring a setting value (e.g., extended PH / PF capability) stored in the register 47 of the image sensor 21 via the I2C / I3C master 72. Alternatively, the controller 74 can determine in advance whether or not the image sensor 21 supports the extended mode based on, for example, a manual input.

[0134] In step S53, the controller 74 determines whether the image sensor 21 supports the extended mode and whether the application executed by the application processor 22 requests the use of the extended mode.

[0135] If the controller 74 determines in step S53 that the image sensor 21 does not support the extended mode or that use of the extended mode is not desired, the process proceeds to step S54.

[0136] In step S54, the controller 74 transmits an image data transmission start command to the image sensor 21 via the I2C / I3C master 72. At this time, the controller 74 also transmits communication settings in accordance with the CSI-2 standard.

[0137] In step S55, the application processor 22 performs conventional packet reception processing to receive packets with a packet structure conforming to the existing CSI-2 standard, based on the communication settings transmitted in step S54.

[0138] On the other hand, if the controller 74 determines in step S53 that the image sensor 21 supports the extended mode and that the application executed by the application processor 22 requests the use of the extended mode, the process proceeds to step S56.

[0139] In step S56, before communication in the extended mode is started, the I2C / I3C master 72 transmits fixed communication settings required for communication in the extended mode, which are then written to the register 47 of the image sensor 21 (step S14 in FIG. 11).

[0140] In step S57, the controller 74 transmits an image data transmission start command to the image sensor 21 via the I2C / I3C master 72. At this time, the controller 74 also transmits communication settings in accordance with the CSI-2 standard.

[0141] In step S58, the packet header detection unit 81 determines whether packet reception has started by checking the data supplied from the physical layer processing unit 71, and waits until it determines that packet reception has started. For example, when the packet header detection unit 81 detects a packet header from the data supplied from the physical layer processing unit 71, it determines that packet reception has started.

[0142] If the packet header detection unit 81 determines in step S58 that packet reception has started, the process proceeds to step S59.

[0143] In step S59, the packet header detection unit 81 checks the data type of the packet header detected in step S58 and determines whether the packet that has started to be received is an extended packet that supports the extended mode. For example, if the extended mode setting information in the data type of the packet header indicates the extended mode (DataType[5:3]=3'b111), the packet header detection unit 81 determines that the packet that has started to be received is an extended packet.

[0144] If the packet header detection unit 81 determines in step S59 that the packet that has started to be received is an extended packet, the process proceeds to step S60, where an extended mode reception process (see FIG. 14) is performed to receive the extended packet.

[0145] On the other hand, if the packet header detection unit 81 determines in step S59 that the packet that has started to be received is not an extended packet, the process proceeds to step S61.

[0146] In step S61, the packet header detection unit 81 checks the data type (DataType[5:0]) of the packet header detected in step S58, and determines whether the packet that has started to be received is a short packet.

[0147] In step S61, if the packet header detection unit 81 determines that the packet that has started to be received is a short packet, the process proceeds to step S62. In step S62, the packet header detection unit 81 receives a short packet with a conventional packet structure transmitted from the image sensor 21.

[0148] On the other hand, if the packet header detection unit 81 determines in step S61 that the packet that has started to be received is not a short packet (i.e., reception of a long packet has started), the process proceeds to step S63. In step S63, the unpacking unit 87 receives the payload of the long packet with the conventional packet structure transmitted from the image sensor 21 and extracts the image data, and the CRC calculation unit 86 receives the WC+1-th byte transmitted following the packet header as a CRC.

[0149] After the processing of step S60, step S62, or step S63, the process proceeds to step S64, where the controller 74 ends the packet reception process. Thereafter, the process returns to step S58, and the packet reception process is repeated in the same manner for the next packet.

[0150] FIG. 14 is a flowchart illustrating the extended mode reception process performed in step S60 of FIG.

[0151] In step S71, the packet header detection unit 81 determines whether the mode setting of the extended mode is extended mode 0. For example, if the extended type setting information in the data type of the packet header indicates extended mode 0 (DataType[1:0] = 2'b00), the packet header detection unit 81 determines that the mode setting of the extended mode is extended mode 0.

[0152] In step S71, if the packet header detection unit 81 determines that the mode setting of the extended mode is extended mode 0, the process proceeds to step S72. In step S72, the interpretation unit 83 receives the first byte of the payload as an extended packet header.

[0153] In step S73, the interpretation unit 83 checks the data type (DataType[7:0]) of the extension packet header received in step S72 to determine whether the packet that has started to be received is an extension short packet.

[0154] If the interpretation unit 83 determines in step S73 that the packet is an extended short packet, the process proceeds to step S74. In step S74, the interpretation unit 83 receives an optional extension packet header in accordance with the setting (OePH[7:0]) stored in the extension packet header received in step S72.

[0155] In step S75, the CRC calculation unit 86 receives the WC+1 byte transmitted following the optional extension packet header as a CRC.

[0156] On the other hand, if the interpretation unit 83 determines in step S73 that the packet is not an extended short packet (i.e., reception of an extended long packet has started), the process proceeds to step S76. In step S76, the interpretation unit 83 receives an optional extension packet header in accordance with the setting (OePH[7:0]) stored in the extension packet header received in step S72.

[0157] In step S77, the unpacking unit 87 receives the legacy payload of the extended long packet transmitted from the image sensor 21 and extracts the image data.

[0158] In step S78, the interpretation unit 83 receives the optional extension packet footer in accordance with the setting (OePF[3:0]) stored in the extension packet header received in step S72.

[0159] In step S79, the CRC calculation unit 86 receives the WC+1 byte transmitted following the optional extension packet footer as a CRC.

[0160] If it is determined in step S71 that the mode setting of the extended mode is not extended mode 0, the extended mode reception process is terminated after the process of step S75 or the process of step S79.

[0161] As described above, the application processor 22 can receive an extended short packet or an extended long packet and obtain data.

[0162] <Second example of packet structure> A second example of the packet structure of a packet used in communication between the enhanced mode-compatible CSI-2 transmitter circuit 31 and the enhanced mode-compatible CSI-2 receiver circuit 32 will be described with reference to FIGS.

[0163] 3 to 8, emphasis is placed on maintaining compatibility with the existing CSI-2 standard, and the packet header and packet footer have the same packet structure as the existing CSI-2 standard, with the packet structure being extended by an extended packet header, optional extended packet header, and optional extended packet footer.In contrast, in the second structure example described below, the packet header and packet footer are different from those of the existing CSI-2 standard, and the packet structure is extended by an extended packet header and extended packet footer.

[0164] FIG. 15 shows the packet structure of a short packet used in the extended mode of CSI-2 when the physical layer is D-PHY (hereinafter referred to as an extended short packet for D-PHY).

[0165] In the extended short packet for D-PHY shown in Figure 15, like the extended short packet for D-PHY of the first structure example shown in Figure 4, the extended mode is identified by the data type stored in the packet header, which is the same as that of the existing CSI-2 standard.

[0166] On the other hand, in the extended short packet for D-PHY shown in Fig. 15, the frame number is stored in the short packet data field in the 16 bits following the data type of the packet header, just like a short packet conforming to the existing CSI-2 standard. Then, following the packet header, an extended packet header configured in the same way as the extended packet header shown in Fig. 4 is transmitted.

[0167] Therefore, the receiving application processor 22 can interpret the data type stored in the extended packet header and determine that, if it is an extended short packet, the frame number is stored in the data field of the packet header.

[0168] The optional extension packet header in the D-PHY extended short packet shown in Fig. 15 has the same structure as the optional extension packet header in the D-PHY extended short packet of the first structure example shown in Fig. 4. However, since the optional extension packet header has a packet structure that is not embedded in the payload, there is no need to add a CRC to the end.

[0169] FIG. 16 shows the packet structure of a long packet (hereinafter referred to as an extended long packet for D-PHY) used in the extended mode of CSI-2 when the physical layer is D-PHY.

[0170] In the D-PHY extended long packet shown in Figure 16, the extended data is not embedded in the payload but is transmitted as part of the packet header or packet footer. Therefore, the WC in the first packet header simply indicates the byte length of the payload, as in the existing standard.

[0171] FIG. 17 shows the packet structure of a short packet used in the extended mode of CSI-2 when the physical layer is C-PHY (hereinafter referred to as an extended short packet for C-PHY).

[0172] The extended portion of the C-PHY extended short packet shown in Figure 17 is transmitted as an extension of the packet header in accordance with the existing CSI-2 standard, so the extended portion, such as the extended packet header, is inserted after the frame number. As with the existing CSI-2 standard, the packet header ends with a CRC. Furthermore, the packet structure, which is transmitted twice with a SYNC in between, is the same as that of a short packet in accordance with the existing CSI-2 standard.

[0173] FIG. 18 shows the packet structure of a long packet used in the extended mode of CSI-2 when the physical layer is C-PHY (hereinafter referred to as an extended long packet for C-PHY).

[0174] As described above, the extended long packet for C-PHY shown in FIG. 18 differs from the extended long packet for C-PHY of the first structure example shown in FIG. 8 in that the WC in the first packet header indicates the byte length of the payload, as in existing standards.

[0175] As described above, the packet structure of the extended packet of the second structure example shown in Figures 15 to 18 can accommodate a wider variety of applications than conventional ones, similar to the packet structure of the extended packet of the first structure example (Figures 3 to 8).

[0176] However, the extended packet of the second structure example has a packet structure in which the existing packet header and footer are extended without embedding the extended data in the existing payload. Therefore, when the packet structure of the extended packet of the second structure example is adopted, the impact of requiring changes to the conventional communication system cannot be minimized compared to when the packet structure of the extended packet of the first structure example is adopted. That is, for example, the existing SerDes transmitter circuit 34 would need to be changed to the SerDes receiver circuit 35 (FIG. 2).

[0177] As described above, by adopting the extended packet of the first structural example, it is possible to accommodate a variety of applications, including in-vehicle applications, and to construct an in-vehicle system while minimizing the impact of requiring changes to conventional communication systems.

[0178] Furthermore, by adopting the extended packet of the second structural example, although changes are required from the conventional communication system, it is possible to accommodate a variety of applications, such as in-vehicle applications.

[0179] <Modifications of Image Sensor and Application Processor> A modification of the image sensor and application processor will be described with reference to FIG.

[0180] The blocks constituting the image sensor 21 in Fig. 9 and the application processor 22 in Fig. 10 described above are configured to be able to process both D-PHY and C-PHY packets. However, for example, it is also possible to provide both a block that processes D-PHY packets exclusively and a block that processes C-PHY packets exclusively, and switch between the processes performed by each block.

[0181] The image sensor 21A shown in A of FIG. 19 is configured to include a D-layer processing block section 101, a C-layer processing block section 102, a switching section 103, and a controller 60.

[0182] The D-layer processing block unit 101 includes a block that processes packets for D-PHY exclusively, among the blocks that make up the image sensor 21 in Fig. 9. The C-layer processing block unit 102 includes a block that processes packets for C-PHY exclusively, among the blocks that make up the image sensor 21 in Fig. 9. Under the control of the controller 60, the switching unit 103 switches so as to output packets for D-PHY generated in the D-layer processing block unit 101 when D-PHY is used for the physical layer, and to output packets for C-PHY generated in the C-layer processing block unit 102 when C-PHY is used for the physical layer.

[0183] The application processor 22A shown in FIG. 19B is configured to include a switching unit 111, a D-layer processing block unit 112, a C-layer processing block unit 113, and a controller 74.

[0184] The switching unit 111 switches, under the control of the controller 74, so as to supply packets transmitted from the image sensor 21A to either the D-layer processing block unit 112 or the C-layer processing block unit 113. The D-layer processing block unit 112 has a block that is dedicated to processing packets for D-PHY, among the blocks that make up the application processor 22 in Fig. 10. The C-layer processing block unit 113 has a block that is dedicated to processing packets for C-PHY, among the blocks that make up the application processor 22 in Fig. 10.

[0185] In the image sensor 21A and application processor 22A configured as described above, before starting communication, the physical layer to be used can be set between the controller 60 and the controller 74. For example, when D-PHY is used for the physical layer, packets for D-PHY generated in the D-layer processing block unit 101 are transmitted via the switching unit 103 and supplied to the D-layer processing block unit 112 via the switching unit 111 for processing. For example, when C-PHY is used for the physical layer, packets for C-PHY generated in the C-layer processing block unit 102 are transmitted via the switching unit 103 and supplied to the C-layer processing block unit 113 via the switching unit 111 for processing.

[0186] <Example of application of extended packets> The application of the above-mentioned extended packets to the following use cases is being considered, for example.

[0187] For example, the extended packet is being considered for use in a use case such as transmitting higher resolution images (RAW24).

[0188] For example, when transmitting image data in RAW format, the existing CSI-2 standard defines RAW6, RAW7, RAW8, RAW10, RAW12, RAW14, RAW16, and RAW20 as data types to be stored in the packet header. However, in recent years, there has been a demand for the transmission of higher-resolution images to support autonomous driving using in-vehicle cameras. Therefore, by applying extended packets to extend the number of bits in the data type, it is possible to define, for example, the higher-resolution RAW24 as the data type in the extended packet header.

[0189] In addition, the extended packet is being considered for application to SmartROI, a technology that transmits only the image area of interest on the screen.

[0190] For example, currently, many cameras are installed in stadiums, airports, and other locations. If the entire image captured by these cameras is transmitted from the camera to a cloud server via a network such as the Internet, it is expected that the Internet bandwidth will be insufficient and the amount of calculation or data on the cloud side will increase. Therefore, by extracting only the image region of interest at the edge (camera side) and transmitting that image region, it is expected that the Internet bandwidth will be insufficient and the amount of calculation or data on the cloud side will be reduced.

[0191] When transmitting such an SROI, the coordinates of the upper left corner of the rectangular region of interest (ROI) must also be transmitted to inform the receiving side of where on the entire screen the image area of interest corresponds. Furthermore, data for the entire captured image must be sent at a specific timing in response to a command from the receiving side. Therefore, for example, the SROI image and data for the entire image (existing packet header) will be mixed on a frame-by-frame basis.

[0192] Therefore, by applying an extended packet, it becomes possible to transmit coordinate data of 16 bits or more for each of the X and Y coordinates, for example.

[0193] Furthermore, the use case of the extended packet is being considered for application to GLD, which reduces the bandwidth and number of lanes to continue communication even when the channel is degraded. GLD is a proposal under consideration for CSI-2 ver. 3.0.

[0194] For example, in the case of autonomous driving, even if a part of the cable connecting the camera during a collision is disconnected, it is required to continue communication using the non-disconnected cable and automatically stop the vehicle after evacuating to the safety belt. Therefore, an in-vehicle camera interface must at least have a disconnection detection function, and information such as the line number (16 bits) indicating which line of information on the screen, the SourceID (8 bits) indicating which camera sent the information, and the message counter (16 bits) indicating the transmission number is required. Furthermore, when used in combination with the SROI as described above, it is conceivable that this information is transmitted in frame units.

[0195] Therefore, by applying an extended packet, it becomes possible to transmit this information.

[0196] <First configuration example adapted to E2E protection> Referring to FIGS. 20 to 26, a configuration example adapted to the regulation prohibiting packet modification and the like on the transmission path will be described.

[0197] For example, in the communication system 11A having the configuration described with reference to FIG. 2 above, when the interfaces between the image sensor 21 and the application processor 22 are different, it is necessary to convert the packet on the transmission path. That is, in the case of a configuration where the physical layer of the image sensor 21 is D-PHY and the physical layer of the application processor 22 is C-PHY, for example, it is necessary to convert the packet from D-PHY to C-PHY in the SerDes device 26.

[0198] In a configuration where packet conversion is performed in the SerDes device 26 in this way, for example, it violates the regulations defined in ISO26262 (Functional Safety), that is, the regulations prohibiting packet modification and the like on the transmission path (hereinafter referred to as E2E (End-to-End) protection).

[0199] FIG. 20 is a block diagram showing an example of the configuration of a communication system 201 adapted to E2E protection as a third embodiment of a communication system to which the present technology is applied.

[0200] As shown in Fig. 20, communication system 201 is configured by connecting image sensor 211, SerDes device 212, SerDes device 213, and application processor 214. Note that Fig. 20 illustrates an example in which SERDES is A-PHY, but also includes cases in which connection is made using other SERDES standards such as FPD-LINK3. In addition, in the SERDES standard, communication may be performed based on the SERDES standard while maintaining the CIS-2 format (at least the application specific payload). In addition, in the SERDES, physical layer processing units 237 and 247 may include multiple physical layer processing units of other SERDES standards in addition to A-PHY, and the physical layer processing units can be switched depending on the application.

[0201] The image sensor 211 has at least an extended mode compatible CSI-2 transmitter circuit 221, a physical layer processing unit (hereinafter referred to as a C / D-PHY physical layer processing unit) 222 compatible with C-PHY or D-PHY, or both, a slave (hereinafter referred to as an I2C / I3C slave) 223 compatible with I2C or I3C, or both, and a CCI slave 224.

[0202] The SerDes device 212 has at least a CSI-2 receiving circuit 231, a C / D-PHY physical layer processing unit 232, an I2C / I3C master 233, a CCI master 234, a CSI-2 A-PHY packet generating unit 235, a CCI A-PHY packet transmitting / receiving unit 236, and an A-PHY-compatible physical layer processing unit 237. For example, the SerDes device 212 converts packets for C-PHY or D-PHY into packets for A-PHY, and this conversion is determined based on register settings, etc.

[0203] The SerDes device 213 has at least a CSI-2 transmission circuit 241, a C / D-PHY physical layer processing unit 242, an I2C / I3C slave 243, a CCI slave 244, a CSI-2 A-PHY packet receiving unit 245, a CCI A-PHY packet transmitting / receiving unit 246, and an A-PHY-compatible physical layer processing unit 247. For example, the SerDes device 213 converts A-PHY packets into C-PHY or D-PHY packets, and this conversion is determined based on register settings, etc.

[0204] The application processor 214 includes at least an extended mode compatible CSI-2 receiving circuit 251 , a C / D-PHY physical layer processing unit 252 , an I2C / I3C master 253 , and a CCI master 254 .

[0205] The communication system 201 is configured in this manner, and an extended packet having the above-described structure is transmitted from the image sensor 211 and received by the application processor 214. Even if the communication system 201 is configured so that the physical layer processing unit 222 of the image sensor 211 supports D-PHY and the physical layer processing unit 252 of the application processor 22 supports C-PHY, it is necessary to ensure that E2E protection is not violated.

[0206] Therefore, in order to be able to apply E2E protection, the communication system 201 limits the protection scope of E2E protection to an application specific payload (hereinafter referred to as AS payload), which is a payload specific to an application. That is, the AS payload is prohibited from being changed when converting an A-PHY packet to a C-PHY or D-PHY packet, or when converting a C-PHY or D-PHY packet to an A-PHY packet.

[0207] FIG. 21 shows an example of the structure of an extended packet for D-PHY that is extended to support E2E protection.

[0208] As shown in the figure, the AS payload of an extended packet for D-PHY, which is made up of an extended packet header (ePH), packet data, and an extended packet footer (ePF), is limited as the protection scope of E2E protection.

[0209] The extended packet header contains predetermined information that is required when the scope of E2E protection is limited to the AS payload. For example, a packet count PC (Packet Count) indicating the data length of the data stored in the AS payload is added as predetermined information to be written in the extended packet header so that the data length of the packet data can be identified. That is, the packet data has the number of bytes determined by the packet count PC. Also, as predetermined information to be written in the extended packet header, a virtual channel VC (Virtual Channel) indicating the number of lines of the virtual channel is copied to the existing packet header.

[0210] FIG. 22 shows an example of the structure of an extended packet for C-PHY that is extended to support E2E protection.

[0211] As shown in the figure, in the case of an extended packet for C-PHY, the protection scope of E2E protection is limited to the AS payload consisting of an extended packet header (ePH), packet data, and extended packet footer (ePF), just like in the case of an extended packet for D-PHY. Similarly to the case of an extended packet for D-PHY, the extended packet header contains a packet count PC and a virtual channel VC as predetermined information required when the protection scope of E2E protection is limited to the AS payload.

[0212] FIG. 23 shows an example of the structure of an extended packet for A-PHY that is extended to support E2E protection.

[0213] As shown in the figure, even in an extended packet for A-PHY, the protection scope of E2E protection is limited to the AS payload consisting of an extended packet header (ePH), packet data, and extended packet footer (ePF).

[0214] 20, in communication system 201, an extended packet for A-PHY is generated from an extended packet for D-PHY or C-PHY transmitted from image sensor 211 to SerDes device 212. Therefore, the packet count PC and the virtual channel VC are already written in the extended packet header of the extended packet for A-PHY.

[0215] By adopting such a packet structure, the communication system 201 can avoid the AS payload from being altered on the transmission path and comply with E2E protection. Note that the packet structures shown in Figures 21 to 23 can be partially replaced with corresponding packets having the packet structures shown in Figures 3 to 8 and Figures 15 to 18, and some packet generation is replaced.

[0216] FIG. 24 is a flowchart illustrating a packet transmission / reception process adapted to E2E protection.

[0217] For example, processing begins when data to be stored in packet data (e.g., image data) is supplied to the extended mode-compatible CSI-2 transmitter circuit 221. Then, in step S101, the extended mode-compatible CSI-2 transmitter circuit 221 in the image sensor 211 stores the supplied data in packet data. Furthermore, the extended mode-compatible CSI-2 transmitter circuit 221 generates an extended packet header that describes a virtual channel VC and a packet count PC, as shown in FIG. 21 or 22 above. Then, the extended mode-compatible CSI-2 transmitter circuit 221 generates an AS payload by adding an extended packet header and an extended packet footer to the packet data.

[0218] In step S102, the extended mode-compatible CSI-2 transmitter circuit 221 generates an extended packet for C-PHY or D-PHY by adding a packet header for C-PHY or D-PHY and a packet footer for C-PHY or D-PHY to the AS payload generated in step S101. The extended mode-compatible CSI-2 transmitter circuit 221 then transmits the extended packet for C-PHY or D-PHY to the SerDes device 212 via the C / D-PHY physical layer processor 222.

[0219] In step S103, in the SerDes device 212, the CSI-2 receiving circuit 231 receives the C-PHY or D-PHY extended packet transmitted from the image sensor 211 in step S102 via the C / D-PHY physical layer processing unit 232. Then, the CSI-2 receiving circuit 231 obtains the AS payload, excluding the packet header and packet footer, from the received extended packet, and supplies the AS payload to the CSI-2 A-PHY packet generating unit 235 as is.

[0220] In step S104, in the SerDes device 212, the CSI-2 A-PHY packet generator 235 generates an extended packet for A-PHY by adding an A-PHY packet header and an A-PHY packet footer to the AS payload supplied from the CSI-2 receiving circuit 231. Then, the CSI-2 A-PHY packet generator 235 transmits the extended packet for A-PHY to the SerDes device 213 via the physical layer processor 237 that supports A-PHY.

[0221] In step S105, in the SerDes device 213, the CSI-2 A-PHY packet receiver 245 receives the A-PHY extended packet transmitted from the SerDes device 212 in step S104, via the A-PHY-compatible physical layer processor 247. The CSI-2 A-PHY packet receiver 245 then acquires the AS payload, excluding the packet header and packet footer, from the received extended packet, and supplies the AS payload to the CSI-2 transmitter circuit 241 as is.

[0222] In step S106, the CSI-2 transmission circuit 241 generates an extended packet for C-PHY or D-PHY by adding a packet header for C-PHY or D-PHY and a packet footer for C-PHY or D-PHY to the AS payload supplied in step S105 from the CSI-2 A-PHY packet reception unit 245. Then, the CSI-2 transmission circuit 241 transmits the extended packet for C-PHY or D-PHY to the application processor 214 via the C / D-PHY physical layer processing unit 242.

[0223] In step S107, in the application processor 214, the extended mode-compatible CSI-2 receiver circuit 251 receives the C-PHY or D-PHY extended packet transmitted from the SerDes device 213 in step S106 via the C / D-PHY physical layer processor 252. The extended mode-compatible CSI-2 receiver circuit 251 then acquires the AS payload, excluding the packet header and packet footer, from the received extended packet, and outputs various data stored in the packet data of the AS payload to a downstream LSI (not shown). Thereafter, the packet transmission / reception process adapted to E2E protection ends, and the same process is repeated for the next extended packet.

[0224] As described above, the communication system 201 can transmit and receive extended packets without modifying the AS payload on the transmission path by executing packet transmission and reception processing that conforms to E2E protection. In this case, even if the physical layer of the image sensor 211 is D-PHY and the physical layer of the application processor 214 is C-PHY, that is, even if the interfaces are different, E2E protection can be observed.

[0225] Fig. 25 is a block diagram showing a detailed configuration example of the image sensor 211. In the image sensor 211 shown in Fig. 25, the same components as those in the image sensor 21 in Fig. 9 are denoted by the same reference numerals, and detailed description thereof will be omitted.

[0226] 9, the image sensor 211 is configured to include pixels 41, an AD converter 42, an image processing unit 43, a register 47, and a controller 60. The I2C / I3C slave 223 and the CCI slave 224 included in the image sensor 211 correspond to the I2C / I3C slave 46 and the CCI slave 59 in FIG.

[0227] The image sensor 211 includes an extended mode compatible CSI-2 transmission circuit 221 and a physical layer processing unit 222, and the physical layer processing unit 222 is compatible with A-PHY, C-PHY, and D-PHY.

[0228] The extended mode compatible CSI-2 transmitter circuit 221 is configured to include, in addition to the controller 60 and the CCI slave 224, an AS payload generator 301, a selector 302, an A-PHY packet generator 303, a C-PHY packet generator 304, a D-PHY packet generator 305, and a selector 306.

[0229] The AS payload generator 301 generates an AS payload that is limited as the protection range of E2E protection, and outputs the generated AS payload to the selector 302. For example, the AS payload generator 301 includes a packing unit 311, an extended packet header generator 312, and an extended packet footer generator 313.

[0230] The packing unit 311 packs image data supplied from the image processing unit 43 as data to be transmitted, and generates packet data of the number of bytes determined by the packet count PC. For example, the controller 60 can control the number of bytes of packet data generated by the packing unit 311 in accordance with a setting value (e.g., image size) stored in the register 47.

[0231] The extended packet header generator 312 generates an extended packet header describing a packet count PC and a virtual channel VC, and adds it to the packet data, as described with reference to Figures 21 to 23. The extended packet footer generator 313 generates an extended packet footer and adds it to the packet data.

[0232] Under the control of the controller 60, the selector 302 selects one of the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305, which are arranged in parallel, as the output destination for the AS payload supplied from the AS payload generator 301.

[0233] The A-PHY packet generator 303 generates an extended packet for A-PHY from the AS payload supplied via the selector 302, and outputs the packet to the selector 306. For example, the A-PHY packet generator 303 includes an AAL generator 321, an A-PHY packet header generator 322, and an A-PHY packet footer generator 323.

[0234] For example, the AAL (A-PHY Adaptation Layer) generation unit 321 divides the AS payload generated by the AS payload generation unit 301 into 380-byte pieces at a layer called an Adaptation Layer. Then, the A-PHY packet header generation unit 322 adds an A-PHY packet header to the divided AS payloads, and the A-PHY packet footer generation unit 323 adds an A-PHY packet footer.

[0235] The C-PHY packet generator 304 generates an extended packet for C-PHY from the AS payload supplied via the selector 302, and outputs the packet to the selector 306. For example, the C-PHY packet generator 304 includes a C-PHY packet header generator 331, a C-PHY packet footer generator 332, and a C-PHY lane distributor 333.

[0236] For example, a C-PHY packet header generator 331 adds a C-PHY packet header, and a C-PHY packet footer generator 332 adds a C-PHY packet footer to the AS payload generated by the AS payload generator 301. Then, a C-PHY lane distributor 333 distributes the C-PHY extended packet to three lanes in accordance with the CSI-2 standard.

[0237] The D-PHY packet generator 305 generates an extended packet for D-PHY from the AS payload supplied via the selector 302, and outputs the packet to the selector 306. For example, the D-PHY packet generator 305 has a D-PHY packet header generator 341, a D-PHY packet footer generator 342, and a D-PHY lane distributor 343.

[0238] For example, a D-PHY packet header generator 341 adds a D-PHY packet header, and a D-PHY packet footer generator 342 adds a D-PHY packet footer to the AS payload generated by the AS payload generator 301. Then, a D-PHY lane distributor 343 distributes the D-PHY extended packets to four lanes in accordance with the CSI-2 standard.

[0239] The selector 306, under the control of the controller 60, selects one of the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305, which are arranged in parallel, as the output source of the extended packet to be supplied to the physical layer processing unit 222.

[0240] When the physical layer processing unit 222 receives an A-PHY extension packet from the A-PHY packet generation unit 303, it transmits the A-PHY extension packet on lane 1. When the physical layer processing unit 222 receives a C-PHY extension packet from the C-PHY packet generation unit 304, it transmits the C-PHY extension packet on lane 3. When the physical layer processing unit 222 receives a D-PHY extension packet from the D-PHY packet generation unit 305, it transmits the D-PHY extension packet on lane 4.

[0241] In the image sensor 211 configured as described above, the extended mode-compatible CSI-2 transmission circuit 221 is configured so that the AS payload generator 301 is connected to the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305 via the selector 302. This allows the image sensor 211 to generate an AS payload common to the A-PHY extended packet, the C-PHY extended packet, and the D-PHY extended packet using a single AS payload generator 301. That is, the A-PHY packet generator 303, the C-PHY packet generator 304, and the D-PHY packet generator 305 can share the AS payload generator 301, thereby reducing the circuit scale. This allows the image sensor 211 to be made smaller.

[0242] Fig. 26 is a block diagram showing a detailed configuration example of the application processor 214. In the application processor 214 shown in Fig. 26, components common to the application processor 22 in Fig. 10 are denoted by the same reference numerals, and detailed description thereof will be omitted.

[0243] 10, the application processor 214 is configured to include a register 73 and a controller 74. The controller 74 may be implemented by software. The I2C / I3C master 253 and the CCI master 254 included in the application processor 214 correspond to the I2C / I3C master 72 and the CCI master 88 in FIG. 10, respectively.

[0244] The application processor 214 includes an extended mode compatible CSI-2 receiving circuit 251 and a physical layer processing unit 252, and the physical layer processing unit 252 supports A-PHY, C-PHY, and D-PHY.

[0245] The extended mode compatible CSI-2 receiver circuit 251 is configured to include a CCI master 254, a selector 401, an A-PHY packet receiver 402, a C-PHY packet receiver 403, a D-PHY packet receiver 404, a selector 405, and an AS payload receiver 406.

[0246] The selector 401 selects one of an A-PHY packet receiver 402, a C-PHY packet receiver 403, and a D-PHY packet receiver 404 arranged in parallel as the output destination of the extended packet supplied from the physical layer processor 252.

[0247] The A-PHY packet receiver 402 receives an A-PHY extended packet supplied via the selector 401 and outputs it to the selector 405. For example, the A-PHY packet receiver 402 includes an A-PHY packet header interpreter 411, an A-PHY packet footer verifier 412, and an AAL processor 413.

[0248] For example, the A-PHY packet header interpretation unit 411 interprets the contents written in the A-PHY packet header and performs processing required to receive the A-PHY extended packet, and the A-PHY packet footer verification unit 412 verifies the presence or absence of an error using the A-PHY packet footer.Then, the AAL processing unit 413 performs processing to combine the adaptation layers divided in the AAL generation unit 321 of FIG.

[0249] The C-PHY packet receiver 403 receives the C-PHY extended packet supplied via the selector 401 and outputs it to the selector 405. For example, the C-PHY packet receiver 403 includes a C-PHY lane merging unit 421, a C-PHY packet header interpretation unit 422, and a C-PHY packet footer verification unit 423.

[0250] For example, the C-PHY lane merging unit 421 merges C-PHY extended packets that are distributed to three lanes in accordance with the CSI-2 standard and supplied via the physical layer processing unit 252. Then, the C-PHY packet header interpretation unit 422 interprets the contents written in the C-PHY packet header and performs processing required to receive the C-PHY extended packets, and the C-PHY packet footer verification unit 423 verifies the presence or absence of errors using the C-PHY packet footer.

[0251] The D-PHY packet receiving unit 404 receives the D-PHY extended packet supplied via the selector 401 and outputs it to the selector 405. For example, the D-PHY packet receiving unit 404 has a D-PHY lane merging unit 431, a D-PHY packet header interpretation unit 432, and a D-PHY packet footer verification unit 433.

[0252] For example, the D-PHY lane merging unit 431 merges D-PHY extension packets that are distributed to four lanes in accordance with the CSI-2 standard and supplied via the physical layer processing unit 252. Then, the D-PHY packet header interpretation unit 432 interprets the contents written in the D-PHY packet header and performs processing required to receive the D-PHY extension packets, and the D-PHY packet footer verification unit 433 verifies the presence or absence of errors using the D-PHY packet footer.

[0253] The selector 405 selects one of the A-PHY packet receiver 402, C-PHY packet receiver 403, and D-PHY packet receiver 404, which are arranged in parallel, as the output source of the extended packet to be supplied to the AS payload receiver 406.

[0254] The AS payload receiving unit 406 has an unpacking unit 441, an extended packet header interpretation unit 442, and an extended packet footer verification unit 443 corresponding to the AS payload generation unit 301 in FIG. 25. The unpacking unit 441 unpacks the image data packed by the packing unit 311. The extended packet header interpretation unit 442 interprets the extended packet header generated by the extended packet header generation unit 312, for example, reads out the packet count PC and the virtual channel VC. The extended packet footer verification unit 443 verifies the presence or absence of an error using the extended packet footer added by the extended packet footer generation unit 313. Then, the AS payload receiving unit 406 outputs various data stored in the packet data supplied via the selector 405, such as image data, in-vehicle line numbers, SourceID, etc., and CRC errors, etc., to a subsequent LSI (not shown).

[0255] The application processor 214 configured as described above has the extended mode-compatible CSI-2 receiving circuit 251 configured such that the AS payload receiving unit 406 is connected to the A-PHY packet receiving unit 402, the C-PHY packet receiving unit 403, and the D-PHY packet receiving unit 404 via the selector 405. Thereby, the application processor 214 can receive the AS payload common to the extended packets for A-PHY, the extended packets for C-PHY, and the extended packets for D-PHY with one AS payload receiving unit 406. That is, the A-PHY packet receiving unit 402, the C-PHY packet receiving unit 403, and the D-PHY packet receiving unit 404 can share the AS payload receiving unit 406, thereby reducing the circuit scale. Therefore, miniaturization of the application processor 214 can be achieved.

[0256] <Second Configuration Example Adapted to E2E Protection> Referring to FIGS. 27 to 74, a second configuration example adapted to E2E Protection will be described.

[0257] <Configuration Example of A-PHY Direct Connection Structure> The communication system 501 shown in FIG. 27 has a direct connection structure in which the image sensor 511 and the application processor 512 are directly connected by A-PHY (without passing through a SerDes device as described in FIG. 40 to be described later).

[0258] The image sensor 511 includes an A-PHY processing unit 521, a CSIA processing unit 522, a CSI2 processing unit 523, a CSI2-FS processing unit 524, a CCI processing unit 525, a CCI-FS processing unit 526, and a register 527.

[0259] In the A-PHY processing unit 521, the CCI processing unit 525 is implemented as an upper layer, and it transmits and receives data including an extended packet header ePH and an extended packet footer ePF by connecting to the A-PHY processing unit 531 of the application processor 512 via MIPI A-PHY.

[0260] The CCI-FS processing unit 526, for example, compares the Desination ID included in the extended packet header ePH with the ID (Source ID) that the image sensor 511 has, and determines whether it is an access to the image sensor 511.

[0261] The application processor 512 includes an A-PHY processing unit 531, a CSIA processing unit 532, a CSI2 processing unit 533, a CSI2-FS processing unit 534, a CCI processing unit 535, a CCI-FS processing unit 536, a register 537, and a CCI-FS switch 538.

[0262] In the A-PHY processing unit 531, the CCI processing unit 535 is implemented as an upper layer, and it transmits and receives data including an extended packet header ePH and an extended packet footer ePF by connecting to the A-PHY processing unit 521 of the image sensor 511 via MIPI A-PHY.

[0263] The CCI-FS processing unit 536 compares, for example, the destination ID included in the extended packet header ePH with the ID (source ID) of the application processor 512, and determines whether or not the access is to the application processor 512.

[0264] The CCI-FS switch 538 switches so that data is sent and received via the CCI-FS processing unit 536 when the CCI-FS processing unit 536 is enabled, and so that data is sent and received without going through the CCI-FS processing unit 536 when the CCI-FS processing unit 536 is disabled.

[0265] 28 to 32, the transfer of read commands and read data in the communication system 501 will be described.

[0266] FIG. 28 shows an example of the packet configuration of a read command generated by the CCI-FS processing unit 536 of the application processor 512 during a read access.

[0267] As shown in FIG. 28, the read command is made up of an extended packet header ePH* (*=n), an AP (CCI) payload, an extended packet footer ePF1, and an extended packet footer ePF0.

[0268] The extended packet header ePH* (*=n) consists of extended packet headers ePH0 to ePH3 as shown in the figure.

[0269] The extended packet header ePH0 stores an extended VC, an extended DT, an extended PFEN, and an extended PHEN. For example, the extended DT is information indicating the CCI protocol (I2C), and routing processing is performed using the extended DT.

[0270] The extended packet header ePH1 stores Source ID[7:1] and Packet Length. For example, Source ID is information indicating the sender of the CCI protocol (I2C), and response processing is performed based on the Source ID. Packet Length is information indicating the data length.

[0271] The extended packet header ePH2 contains a security descriptor and a message counter. The security descriptor indicates whether security is used or not, and indicates "8'h0" when security is not used. The message counter is information indicating the bucket order, and indicates the count value of messages, and indicates "16'h5" when the message is the fifth.

[0272] The extended packet header ePH3 stores Destination ID[7:1], Read / Write, and Destination Address. Destination ID[7:1] indicates the slave address of the CCI processing unit 525 of the image sensor 511, and is set to "7'h0D" in the illustrated example. For example, the Destination ID is information indicating the destination of the CCI protocol (I2C), and routing is performed based on the Destination ID, and the communication path is referenced. Read / Write indicates reading or writing of data, and indicates "1'b1" in the case of a read. Destination Address indicates the address of the register 527 of the image sensor 511, which is the final destination, and is set to "0x0200" in the illustrated example.

[0273] The AP (CCI) payload stores, for example, various data (Data0[7:0]). The AP (CCI) payload is not transmitted when security is off, but may store dummy data and be transmitted when security is on.

[0274] The extended packet footer ePF1 is not sent when security is turned off.

[0275] The extended packet footer ePF0 includes security data (such as a hash calculation value) used to verify data integrity, and specifically, a CRC calculation value is stored.

[0276] In the application processor 512 , a read command with such a packet structure is generated in the CCI-FS processing unit 536 and supplied to the A-PHY processing unit 531 .

[0277] FIG. 29 shows an example of the packet configuration of a read command output from the A-PHY processing unit 531 of the application processor 512 during read access.

[0278] As shown in FIG. 29, the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the read command supplied from the CCI-FS processing unit 536, treating the read command as within the protection range of E2E Protection.

[0279] A read command with such a packet structure is A-PHY transferred by the A-PHY processing unit 531 of the application processor 512. Then, in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the read command. Thereafter, the read command is supplied to the CCI-FS processing unit 526 via the CCI processing unit 525 at the slave address "7'h0D" indicated by the Destination ID.

[0280] FIG. 30 shows an example of the packet structure of a read command supplied to the CCI-FS processing unit 526 and read data generated by the CCI-FS processing unit 526 during a read access.

[0281] As shown in FIG. 30, the read command with the packet structure shown in FIG. 28 as it is, that is, the read command that is protected by E2E Protection in A-PHY transfer, is supplied to the CCI-FS processing unit 526.

[0282] As shown in the figure, the read data is composed of an extended packet header ePH*(*=n), an AP (CCI) payload, an extended packet footer ePF1, and an extended packet footer ePF0. The AP (CCI) payload stores the read data value read from address 0x0200 of register 527 indicated by the source address information (Destination Address) of the extended packet header ePH of the read command.

[0283] In the image sensor 511 , read data having such a packet structure is generated in the CCI-FS processing unit 526 and supplied to the A-PHY processing unit 521 .

[0284] FIG. 31 shows an example of a packet configuration of read data output from the A-PHY processing unit 521 of the image sensor 511 during read access.

[0285] As shown in FIG. 31, the A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to the read data supplied from the CCI-FS processing unit 526, with the data being protected by E2E Protection.

[0286] The read data having such a packet structure is A-PHY transferred by the A-PHY processing unit 521 of the image sensor 511. Then, in the application processor 512, the A-PHY processing unit 531 removes the A-PHY header and the A-PHY footer from the read data, and the read data is supplied to the CCI-FS processing unit 536.

[0287] FIG. 32 shows an example of the packet structure of read data supplied to the CCI-FS processing unit 536 during read access.

[0288] As shown in FIG. 32, the read data with the packet structure shown in FIG. 30 as it is, that is, the read data that is protected by E2E Protection in the A-PHY transfer, is supplied to the CCI-FS processing unit 536.

[0289] 33 to 35, the transfer of write data in the communication system 501 will be described. Note that the description will be made assuming that access is made from a state in which the CCI-FS processing unit 526 on the image sensor 511 side is enabled.

[0290] FIG. 33 shows an example of a packet configuration of write data generated by the CCI-FS processing unit 536 of the application processor 512 during write access.

[0291] As shown in FIG. 33, the write data is made up of an extension packet header ePH* (*=n), an AP (CCI) payload (write data), an extension packet footer ePF1, and an extension packet footer ePF0.

[0292] The extended packet header ePH* (*=n) consists of extended packet headers ePH0 to ePH3 as shown in the figure.

[0293] The extended packet header ePH0 stores an extended VC, an extended DT, an extended PFEN, and an extended PHEN.

[0294] The extended packet header ePH1 stores Source ID[7:1] and Packet Length.

[0295] The extended packet header ePH2 contains a Security Descriptor and a Message Counter. The Security Descriptor indicates whether security is used or not, and indicates "8'h0" if security is not used. The Message Counter indicates the count value of messages, and indicates "16'h4" if the message is the fourth.

[0296] The extended packet header ePH3 stores Destination ID[7:1], Read / Write, and Destination Address. Destination ID[7:1] indicates the slave address of the CCI processing unit 525 of the image sensor 511, and is set to "7'h0D" in the illustrated example. Read / Write indicates reading or writing data, and indicates "1'b0" for writing. Destination Address indicates the address of the register 527 of the image sensor 511, which is the final destination, and is set to "0x1234" in the illustrated example.

[0297] The AP (CCI) payload stores data (Data0[7:0]) to be written to the image sensor 511, and the value 0xFF becomes the write data.

[0298] The extended packet footer ePF1 is not sent when security is turned off.

[0299] The extended packet footer ePF0 stores the CRC calculation value.

[0300] In the application processor 512 , write data having such a packet structure is generated in the CCI-FS processing unit 536 and supplied to the A-PHY processing unit 531 .

[0301] FIG. 34 shows an example of a packet configuration of write data output from the A-PHY processing unit 531 of the application processor 512 during write access.

[0302] As shown in FIG. 34, the A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the write data supplied from the CCI-FS processing unit 536, with the data being protected by E2E Protection.

[0303] The write data with such a packet structure is A-PHY transferred by the A-PHY processing unit 531 of the application processor 512. Then, in the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer from the write data. Thereafter, the write data is supplied to the CCI-FS processing unit 526 via the CCI processing unit 525 at the slave address "7'h0D" indicated by the Destination ID.

[0304] FIG. 35 shows an example of the packet structure of write data supplied to the CCI-FS processing unit 526 during write access.

[0305] 35, the write data with the packet structure shown in Fig. 33 intact, i.e., the write data protected by E2E Protection in the A-PHY transfer, is supplied to the CCI-FS processing unit 526. Then, the CCI-FS processing unit 526 writes the data stored in the AP (CCI) payload from the address "0x1234" of the register 527 indicated by the CCI command ID information, i.e., the source address information (Destination Address) of the extended packet header ePH of the read command.

[0306] An overview of the extended packet header ePH and the extended packet footer ePF will be described with reference to FIG.

[0307] As shown in FIG. 36, a CCI-FS E2E packet is made up of an extended packet header ePH, packet data, and an extended packet footer ePF, and its packet length is expressed as Length=Byte Count×Data Byte width.

[0308] The extended packet header ePH uses fields such as an extended VC, an extended DT, a message counter, etc. The length of the extended packet header ePH can be changed by the field value (epFEN field) of the extended packet header ePH.

[0309] Packet data is composed of, for example, PL pieces of data (Data 0 to Data PL-1), and its length is Length = Packet Length (PL) × Data Byte Width. In the case of a read command, no data is stored in the packet data when security is off, and one byte of dummy data is stored when security is on. In the case of a write access, write data equivalent to the payload data is stored in the packet data. In the case of a read access, read data equivalent to the payload data is stored in the packet data. When Clock Stretch (Control Code Indicator of ePH0 = 1) is used, a one-byte data payload indicating the type of control is attached to the packet data.

[0310] The length of the extended packet footer ePF1 can be changed by the field setting value (epFEN field) of the extended packet header ePH, and security-related information can also be added.

[0311] The extended packet footer ePF0 is a field setting value of the extended packet header ePH, and can add a CRC-32 calculated from the packet data.

[0312] <Example of communication processing> 37 to 39, a description will be given of communication processing using CCI-FS performed in communication system 501 shown in FIG.

[0313] As shown in FIG. 37, in steps S211 to S222, initial settings and confirmation operations are performed.

[0314] In step S211, the application processor 512 performs two read accesses to the Capability register of the CCI-FS processing unit 526 in the image sensor 511. Note that the number of read accesses is not limited to two, and can be set arbitrarily in terms of functional safety, for example, and may be one or three or more times.

[0315] In step S212, the CSI2-FS processing unit 524 in the application processor 512 determines whether the Capability register value of the CCI-FS processing unit 526 is 1'b1 both times as a result of the read access in step S211. If it is determined in step S212 that the Capability register value of the CCI-FS processing unit 526 is not 1'b1 both times, the process proceeds to step S213.

[0316] In step S213, CSI2-FS processing unit 524 in application processor 512 determines whether the number of retransmissions is three or more. Note that the number of retransmissions is not limited to three and can be set to any number, and the same applies to the number of retransmissions described below. If it is determined in step S213 that the number of retransmissions is not three or more (one or two), the process returns to step S211, and the same processes are repeated thereafter.

[0317] On the other hand, if it is determined in step S212 that the Capability register value of the CCI-FS processing unit 526 is 1'b1 both times, the process proceeds to step S214.

[0318] In step S214, the application processor 512 performs a 1 write access to the Enable register of the CCI-FS processing unit 526 to the image sensor 511.

[0319] In step S215, in the image sensor 511, the CCI-FS processing unit 526 performs 1 write access to the Enable register of the CCI-FS processing unit 536 of the application processor 512.

[0320] In step S216, the slave address of the opposing image sensor 511 is set in the Destination SID register of the CCI-FS processing unit 536 of the application processor 512.

[0321] In step S217, the ePH register of the CCI-FS processing unit 536 of the application processor 512 is set.

[0322] In step S218, the application processor 512 sets the ePH register of the CCI-FS processing unit 526 to the image sensor 511.

[0323] In step S219, the application processor 512 makes a read access to the Enable register and the Error register of the CCI-FS processing unit 526 to the image sensor 511.

[0324] In step S220, the CCI-FS processing unit 536 of the application processor 512 determines whether the Enable register value of the CCI-FS processing unit 526 is 1'b1 and the Error register value is 0 as a result of the read access in step S219.

[0325] If it is determined in step S220 that the Enable register value of the CCI-FS processing unit 526 is not 1'b1 or the Error register value is not 0, the process proceeds to step S221.

[0326] In step S221, CSI2-FS processing unit 524 in application processor 512 determines whether the number of retransmissions is 3 or more. If it is determined in step S221 that the number of retransmissions is 3 or more, the process returns to step S211, and the same processes are repeated thereafter.

[0327] On the other hand, if it is determined in step S213 that the number of retransmissions is three or more, or if it is determined in step S221 that the number of retransmissions is not three or more (one or two), the process proceeds to step S222.

[0328] In step S222, communication is performed using CCI without using CCI-FS, and then the communication process is terminated.

[0329] On the other hand, if it is determined in step S220 that the Enable register value of the CCI-FS processing unit 526 is 1'b1 and the Error register value is 0, the process proceeds to step S223.

[0330] As shown in FIG. 38, in steps S223 to S234, a write operation using CCI-FS is performed.

[0331] In step S223, the CCI-FS processing unit 536 of the application processor 512 sets the ePH register to perform a write operation.

[0332] In step S224, the CCI-FS processing unit 536 of the application processor 512 sets the write data register.

[0333] In step S225, the CCI-FS processing unit 536 of the application processor 512 sets the command execution register to 1.

[0334] In step S226, in the application processor 512, the A-PHY processing unit 531, as shown in Figure 34 above, adds an A-PHY header and an A-PHY footer to the write data generated by the CCI-FS processing unit 536, treating the data as within the protection range of E2E Protection, and performs A-PHY transfer.

[0335] In step S227, the A-PHY processing unit 521 of the image sensor 511 removes the A-PHY header and the A-PHY footer from the write data, and supplies the protection range of E2E Protection to the CCI-FS processing unit 526.

[0336] In step S228, the CCI-FS processing unit 526 in the image sensor 511 checks the Source ID of the image sensor 511 and the Destination SID of the extended packet header ePH from the contents of the extended packet header ePH.

[0337] In step S229, the CCI-FS processing unit 526 in the image sensor 511 determines whether or not the Source ID of the image sensor 511 confirmed in step S228 matches the Destination SID in the extended packet header ePH.

[0338] If it is determined in step S229 that the Source ID of the image sensor 511 matches the Destination SID in the extension packet header ePH, the process proceeds to step S230.

[0339] In step S230, the CCI-FS processing unit 526 in the image sensor 511 checks the Message Counter from the contents of the extended packet header ePH.

[0340] In step S231, the CCI-FS processing unit 526 in the image sensor 511 determines whether the Message Counter (received) of the image sensor 511 confirmed in step S230 matches the Message Counter in the extension packet header ePH.

[0341] If it is determined in step S231 that the Message Counter (received) of the image sensor 511 matches the Message Counter in the extension packet header ePH, the process proceeds to step S232.

[0342] In step S232, the CCI-FS processing unit 526 in the image sensor 511 checks the CRC from the contents of the extended packet footer ePF.

[0343] In step S233, in the image sensor 511, the CCI-FS processing unit 526 determines whether the received value (ePF0) of the extended packet footer ePF confirmed in step S232 matches the CRC calculation result calculated by the CCI-FS processing unit 526.

[0344] If it is determined in step S233 that the received value (ePF0) of the extended packet footer ePF matches the CRC calculation result, the process proceeds to step S234.

[0345] In step S234, in the image sensor 511, the CCI-FS processing unit 526 performs a write process to write write data based on the contents of the extension packet header ePH and the extension packet footer ePF to an address in the register 527. Thereafter, the process proceeds to step S235.

[0346] As shown in FIG. 39, in steps S235 to S247, a read operation using CCI-FS is performed.

[0347] In step S235, the CCI-FS processing unit 536 in the application processor 512 sets the ePH register so that a read operation is performed.

[0348] In step S236, the CCI-FS processing unit 536 in the application processor 512 sets the command execution register to 1.

[0349] In step S237, in the application processor 512, the A-PHY processing unit 531, as shown in Figure 29 above, adds an A-PHY header and an A-PHY footer to the write data generated by the CCI-FS processing unit 536, treating the data as within the protection range of E2E Protection, and performs A-PHY transfer.

[0350] In step S238, the A-PHY processing unit 521 of the image sensor 511 removes the A-PHY header and the A-PHY footer from the write data, and supplies the protection range of E2E Protection to the CCI-FS processing unit 526.

[0351] In step S239, the CCI-FS processing unit 526 in the image sensor 511 checks the Source ID of the image sensor 511 and the Destination SID of the extension packet header ePH from the contents of the extension packet header ePH.

[0352] In step S240, the CCI-FS processing unit 526 in the image sensor 511 determines whether the Source ID of the image sensor 511 confirmed in step S239 matches the Destination SID in the extended packet header ePH.

[0353] If it is determined in step S240 that the Source ID of the image sensor 511 matches the Destination SID in the extended packet header ePH, the process proceeds to step S241.

[0354] In step S241, the CCI-FS processing unit 526 in the image sensor 511 checks the Message Counter from the contents of the extended packet header ePH.

[0355] In step S242, the CCI-FS processing unit 526 in the image sensor 511 determines whether the Message Counter (received) of the image sensor 511 confirmed in step S241 matches the Message Counter in the extension packet header ePH.

[0356] If it is determined in step S242 that the Message Counter (received) of the image sensor 511 matches the Message Counter in the extension packet header ePH, the process proceeds to step S243.

[0357] In step S243, the CCI-FS processing unit 526 in the image sensor 511 checks the CRC from the contents of the extended packet footer ePF.

[0358] In step S244, in the image sensor 511, the CCI-FS processing unit 526 determines whether the received value (ePF0) of the extended packet footer ePF confirmed in step S243 matches the CRC calculation result calculated by the CCI-FS processing unit 526.

[0359] If it is determined in step S244 that the received value (ePF0) of the extended packet footer ePF matches the CRC calculation result, the process ends.

[0360] On the other hand, if it is determined in step S229 of FIG. 38 or step S240 of FIG. 39 that the Source ID of the image sensor 511 and the Destination SID of the extension packet header ePH do not match, the process proceeds to step S245.

[0361] In step S245, the Error register (Routing) on the image sensor 511 side is set to 1, and then the process ends.

[0362] On the other hand, if it is determined in step S231 of FIG. 38 or step S242 of FIG. 39 that the Message Counter (received) of the image sensor 511 does not match the Message Counter of the extended packet header ePH, the process proceeds to step S246.

[0363] In step S246, the Error register (MC) on the image sensor 511 side is set to 1, and then the process ends.

[0364] On the other hand, if it is determined in step S233 of FIG. 38 or step S244 of FIG. 39 that the received value (ePF0) of the extended packet footer ePF does not match the CRC calculation result, the process proceeds to step S247.

[0365] In step S247, the Error register (CRC) on the image sensor 511 side is set to 1, and then the process ends.

[0366] <Configuration example of SerDes connection configuration> In the communication system 601 shown in FIG. 40, the image sensor 611 and the application processor 614 are connected in a SerDes connection configuration via the slave-side SerDes device 612 and the master-side SerDes device 613.

[0367] The image sensor 611 includes an I2C / I3C slave 621, a CCI processing unit 622, a CSI interface 2 - FS processing unit 623, and a register 624.

[0368] [[ID=__]]The slave-side SerDes device 612 includes an A-PHY processing unit 631, a CSIA processing unit 632, a CSI interface 2 - FS processing unit 633, an I2C / I3C master 634, a CCI processing unit 635, a CCI interface 2 - FS processing unit 636, and a register 637.

[0369] The master side SerDes device 613 is configured to include an A-PHY processing unit 641, a CSIA processing unit 642, a CSI2-FS processing unit 643, an I2C / I3C slave 644, a CCI processing unit 645, a CCI-FS processing unit 646, and a register 647.

[0370] The application processor 614 includes an I2C / I3C master 651, a CCI processing unit 652, a CCI-FS processing unit 653, a register 654, and a CCI-FS switch 655.

[0371] In addition, in the SerDes connection configuration shown in Fig. 40, if the CCI configuration or the CCI-FS configuration is implemented as an upper layer protocol, other SerDes standards may be used. For example, by implementing a configuration of an extended packet header ePH, an extended packet footer ePF1, and an extended packet footer ePF0 as shown in Fig. 41 in the payload from the application layer or a layer below that, various SerDes-related standards such as PCIE, USB, DisplayPort, HDMI (registered trademark), LVDS, and FPD-LINK can be applied.

[0372] 41 to 49, the transfer of read commands and read data in the communication system 601 will be described.

[0373] FIG. 41 shows an example of the packet configuration of a read command generated by the CCI-FS processing unit 653 of the application processor 614 during a read access.

[0374] As shown in Fig. 41, the read command is composed of an extended packet header ePH* (*=n), an extended packet footer ePF1, and an extended packet footer ePF0. Details of these are the same as those of the read command described above with reference to Fig. 28.

[0375] In the application processor 614 , a read command with such a packet structure is generated in the CCI-FS processing unit 653 and supplied to the I2C / I3C master 651 .

[0376] FIG. 42 shows an example of the packet configuration of a read command output from the I2C / I3C master 651 of the application processor 614 during read access.

[0377] As shown in Fig. 42, the I2C / I3C master 651 transmits a start condition S followed by the address of the connected sensor, i.e., in the configuration shown in Fig. 40, the address (Slave Address+W 8-bit) of the CCI processing unit 645 of the master-side SerDes device 613. In the example shown in Fig. 42, the address of the CCI processing unit 645 is Slave Address[7:1]=7'h0F. Following this address, the register address (Register Address [15:8] and Register Address [7:0]) of the register 647 of the master-side SerDes device 613 is transmitted. The I2C / I3C master 651 transmits an extended packet header ePH* (*=n), an extended packet footer ePF1, and an extended packet footer ePF0, followed by a stop condition P.

[0378] A read command with such a packet structure is transferred by I2C / I3C from the I2C / I3C master 651 of the application processor 614. In the master-side SerDes device 613, the I2C / I3C slave 644 acquires the read command (extended packet header ePH*(*=n), extended packet footer ePF1, and extended packet footer ePF0). The read command is supplied to the CCI processing unit 645 with Slave Address[7:1]=7'h0F, and then supplied to the A-PHY processing unit 641 via the CCI-FS processing unit 646, CSI2-FS processing unit 643, and CSIA processing unit 642.

[0379] FIG. 43 shows an example of the packet configuration of a read command output from the A-PHY processing unit 641 of the SerDes device 613 on the master side during a read access.

[0380] 43, the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the read command acquired by the I2C / I3C slave 644, with the read command being protected by E2E Protection. Note that the CSI2-FS processing unit 643 adds the address of the CCI processing unit 635 of the master-side SerDes device 613, for example, Slave Address[7:1]=7'h0E, to the extended packet header ePH* (*=n).

[0381] A read command with such a packet structure is A-PHY transferred by the A-PHY processing unit 641 of the master-side SerDes device 613. In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer from the read command. The read command is supplied to the CCI processing unit 635 at the slave address "7'h0E" indicated by the Destination ID via the CSIA processing unit 632, CSI2-FS processing unit 633, and CCI-FS processing unit 636, and then supplied to the I2C / I3C master 634.

[0382] FIG. 44 shows an example of the packet configuration of a read command output from the I2C / I3C master 634 during read access.

[0383] As shown in Fig. 44, the I2C / I3C master 634 transmits a start condition S followed by the address of the connected sensor, i.e., the address (Slave Address+W 8-bit) of the CCI processing unit 622 of the image sensor 611 in the configuration shown in Fig. 40. In the example shown in Fig. 44, the address of the CCI processing unit 622 is Slave Address[7:1]=7'h0D. Following this address, the register address (Register Address [15:8] and Register Address [7:0]) of the register 624 of the image sensor 611 is transmitted. The I2C / I3C master 634 transmits an extended packet header ePH* (*=n), an extended packet footer ePF1, and an extended packet footer ePF0, followed by a stop condition P.

[0384] A read command with such a packet structure is transferred by I2C / I3C from the I2C / I3C master 634 of the slave-side SerDes device 612. Then, in the image sensor 611, the I2C / I3C slave 621 acquires the read command (extended packet header ePH*(*=n), extended packet footer ePF1, and extended packet footer ePF0). The read command is supplied to the CSI2-FS processing unit 623 via the CCI processing unit 622 with Slave Address[7:1]=7'h0D.

[0385] FIG. 45 shows an example of the packet structure of a read command supplied to the CSI2-FS processing unit 623 and read data generated by the CSI2-FS processing unit 623 during a read access.

[0386] As shown in FIG. 45, the read command with the packet structure shown in FIG. 41 as is, that is, the read command that is protected by E2E Protection in A-PHY transfer, is supplied to the CSI2-FS processing unit 623.

[0387] As shown in the figure, the read data is composed of an extended packet header ePH*(*=n), an AP (CCI) payload, an extended packet footer ePF1, and an extended packet footer ePF0. The AP (CCI) payload stores the read data value read from address “0x0200” of register 624 indicated by the source address information (Destination Address) of the extended packet header ePH of the read command.

[0388] In the image sensor 611 , read data with such a packet structure is generated in the CCI-FS processing unit 623 and supplied to the I2C / I3C slave 621 via the CCI processing unit 622 .

[0389] FIG. 46 shows an example of a packet configuration of read data output from the I2C / I3C slave 621 of the image sensor 611 during read access.

[0390] As shown in Fig. 46, the I2C / I3C slave 621 transmits a start condition S followed by the address of the sensor to which it is connected, i.e., in the configuration shown in Fig. 40, the address (Slave Address+W 8-bit) of the I2C / I3C master 634 of the slave-side SerDes device 612. In the example shown in Fig. 46, the address of the I2C / I3C master 634 is Slave Address[7:1]=7'h0D. Following this address, the storage address of the read data (the address of the register 624 of the image sensor 611) is transmitted, followed by the address (Slave Address+R 8-bit) of the I2C / I3C master 634 of the slave-side SerDes device 612. After the I2C / I3C slave 621 transmits the extended packet header ePH* (*=n), the AP (CCI) payload, the extended packet footer ePF1, and the extended packet footer ePF0, a stop condition P is transmitted.

[0391] A read command with such a packet structure is transferred via I2C / I3C from the I2C / I3C slave 621 of the image sensor 611. In the slave-side SerDes device 612, the I2C / I3C master 634 acquires read data (extended packet header ePH*(*=n), AP (CCI) payload, extended packet footer ePF1, and extended packet footer ePF0). The read data is supplied to a CCI processing unit 635 with Slave Address[7:1]=7'h0E, and then supplied to an A-PHY processing unit 631 via a CCI-FS processing unit 636, a CSI2-FS processing unit 633, and a CSIA processing unit 632.

[0392] FIG. 47 shows an example of a packet configuration of read data output from the A-PHY processing unit 631 of the slave-side SerDes device 612 during read access.

[0393] As shown in FIG. 47, the A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the read data acquired by the I2C / I3C master 634, with the data being protected by E2E Protection.

[0394] The read data with such a packet structure is A-PHY transferred by the A-PHY processing unit 631 of the slave-side SerDes device 612. Then, in the master-side SerDes device 613, the A-PHY processing unit 641 removes the A-PHY header and A-PHY footer from the read data. The read data is supplied to the I2C / I3C slave 644 via the CSIA processing unit 642, CSI2-FS processing unit 643, CCI-FS processing unit 646, and CCI processing unit 635.

[0395] FIG. 48 shows an example of a packet configuration of read data output from the I2C / I3C slave 644 of the master-side SerDes device 613 during read access.

[0396] As shown in FIG. 48, the I2C / I3C slave 644 transmits a start condition S followed by the address of the sensor to which it is connected, i.e., in the configuration shown in FIG. 40, the address (Slave Address+W 8-bit) of the CCI processing unit 635 of the master-side SerDes device 613. In the example shown in FIG. 48, the address of the CCI processing unit 635 is Slave Address[7:1]=7'h0F. Following this address, the register address (Register Address [15:8] and Register Address [7:0]) of the register 647 of the master-side SerDes device 613 is transmitted, followed by the address (Slave Address+R 8-bit) of the CCI processing unit 635. Next, the I2C / I3C slave 644 transmits an extended packet header ePH*(*=n), an AP(CCI) payload, an extended packet footer ePF1, and an extended packet footer ePF0, and finally transmits a stop condition P.

[0397] The read data with such a packet structure is transferred by I2C / I3C from the I2C / I3C slave 644 of the master-side SerDes device 613. Then, in the application processor 614, the I2C / I3C master 651 obtains the read command (extended packet header ePH*(*=n), extended packet footer ePF1, and extended packet footer ePF0) and supplies it to the CCI-FS processing unit 653.

[0398] FIG. 49 shows an example of the packet structure of read data supplied to the CCI-FS processing unit 653 during read access.

[0399] As shown in FIG. 49, the read data in the packet structure shown in FIG. 45, that is, the read data that is protected by E2E Protection in the A-PHY transfer, is supplied to the CCI-FS processing unit 653.

[0400] <Example of communication processing> 50 to 57, a description will be given of communication processing using CCI-FS performed in the communication system 601 shown in FIG.

[0401] As shown in FIG. 50, in steps S301 to S317, initial settings and confirmation operations are performed.

[0402] In step S301, the slave address of the opposing image sensor 611 is set in the Destination SID register of the CCI-FS processing unit 653 of the application processor 614.

[0403] In step S302, the ePH register of the CCI-FS processing unit 653 of the application processor 614 is set.

[0404] In step S303, the Destination SID of the Bridge configuration of the CCI-FS processing unit 653 of the application processor 614 is set, and the master side SerDes device 613 is registered. Here, the Address, attribution, and Timeout_no1 registers are also set in the same way, and settings are assumed to be made similarly thereafter.

[0405] In step S304, the application processor 614 sets the ePH register of the CCI-FS processing unit 643 to the SerDes device 613 on the master side.

[0406] In step S305, the application processor 614 sets the Destination SID of the Bridge configuration of the CCI-FS processing unit 643 to the master side SerDes device 613, and registers the slave side SerDes device 612.

[0407] In step S306, the application processor 614 makes a read access to the Error register of the CCI-FS processing unit 643 to the SerDes device 613 on the master side.

[0408] In step S307, the CCI-FS processing unit 653 in the application processor 614 determines whether the register value of the Error register of the CCI-FS processing unit 643 of the master-side SerDes device 613 is 0 as a result of the read access in step S306.

[0409] If it is determined in step S307 that the register value of the Error register of the CCI-FS processing unit 643 of the master-side SerDes device 613 is not 0 (other than 0), the process proceeds to step S308.

[0410] In step S308, in the application processor 614, the CCI-FS processing unit 653 determines whether the number of retransmissions is three or more, and if it determines that the number of retransmissions is not three or more (one or two), the processing returns to step S304, and the same processing is repeated thereafter.

[0411] On the other hand, if it is determined in step S307 that the register value of the Error register of the CCI-FS processing unit 643 of the master-side SerDes device 613 is 0, the process proceeds to step S309.

[0412] In step S309, the application processor 614 sets the ePH register of the CCI-FS processing unit 636 to the slave side SerDes device 612.

[0413] In step S310, the application processor 614 sets the Destination SID of the Bridge configuration of the CCI-FS processing unit 636 to the slave side SerDes device 612, and registers the slave side SerDes device 612.

[0414] In step S311, the application processor 614 makes a read access to the Error register of the CCI-FS processing unit 636 to the slave side SerDes device 612.

[0415] In step S312, the CCI-FS processing unit 653 in the application processor 614 determines whether the register value of the Error register of the CCI-FS processing unit 636 in the slave SerDes device 612 is 0 as a result of the read access in step S311.

[0416] If it is determined in step S312 that the register value of the Error register of the CCI-FS processing unit 636 of the slave-side SerDes device 612 is not 0 (other than 0), the process proceeds to step S313.

[0417] In step S313, in the application processor 614, the CCI-FS processing unit 653 determines whether the number of retransmissions is three or more, and if it determines that the number of retransmissions is not three or more (one or two), the processing returns to step S309, and the same processing is repeated thereafter.

[0418] On the other hand, if it is determined in step S312 that the register value of the Error register of the CCI-FS processing unit 636 of the slave-side SerDes device 612 is 0, the process proceeds to step S314.

[0419] In step S314, the application processor 614 sets the ePH register of the CCI-FS processing unit 623 in the image sensor 611.

[0420] In step S315, the application processor 614 makes a read access to the Error register of the CCI-FS processing unit 623 to the image sensor 611.

[0421] In step S316, the CCI-FS processing unit 653 in the application processor 614 determines whether the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is 0 as a result of the read access in step S315.

[0422] If it is determined in step S316 that the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is not 0 (other than 0), the process proceeds to step S317.

[0423] In step S317, in the application processor 614, the CCI-FS processing unit 653 determines whether the number of retransmissions is three or more, and if it determines that the number of retransmissions is not three or more (one or two), the processing returns to step S314, and the same processing is repeated thereafter.

[0424] If it is determined in step S308, step S313, or step S317 that the number of retransmissions is three or more, the process returns to step S301, and the same processes are repeated thereafter.

[0425] On the other hand, if it is determined in step S316 that the register value of the Error register of the CCI-FS processing unit 623 of the image sensor 611 is 0, the process proceeds to step S318.

[0426] As shown in FIG. 51, in steps S318 to S327, a write operation using CCI-FS is performed.

[0427] In step S318, the CCI-FS processing unit 653 of the application processor 614 sets the ePH register to perform a write operation.

[0428] In step S319, the CCI-FS processing unit 653 of the application processor 614 sets the write data register.

[0429] In step S320, the CCI-FS processing unit 653 of the application processor 614 sets the command execution register to 1 and issues a write command.

[0430] In step S321, the application processor 614 performs Sequence A_Write (AP) processing, which will be described later with reference to FIG.

[0431] In step S322, the master-side SerDes device 613 performs Sequence B (SerDes (Master) mode) processing, which will be described later with reference to Fig. 56. Note that Fig. 56 describes the Sequence B (SerDes (Slave) mode) processing performed by the slave-side SerDes device 612, but the master-side SerDes device 613 can also perform similar processing using the corresponding blocks.

[0432] In step S323, the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the extended DT of the extended packet header ePH of the master side SerDes device 613 via the CSI2-FS processing unit 643 and the CSIA processing unit 642, and performs A-PHY transfer.

[0433] In step S324, the slave SerDes device 612 performs Sequence B (SerDes (Slave) mode) processing, which will be described later with reference to FIG.

[0434] In step S325, the slave-side SerDes device 612 performs Sequence A_Write (SerDes (Slave)) processing, which will be described later with reference to Fig. 53. Note that Fig. 53 describes the Sequence A_Write (AP) processing executed by the application processor 614, but similar processing can also be executed by the corresponding blocks in the slave-side SerDes device 612.

[0435] In step S326, the image sensor 611 performs Sequence B (Image Sensor) processing, which will be described later with reference to Fig. 56. Note that Fig. 56 describes Sequence B (SerDes (Slave)) processing executed by the slave-side SerDes device 612, but similar processing can also be executed by the corresponding blocks in the image sensor 611.

[0436] In step S327, the CCI-FS processing unit 623 of the image sensor 611 performs a write process to write write data based on the contents of the extension packet header ePH and the extension packet footer ePF to an address in the register 624. Thereafter, the process proceeds to step S328.

[0437] As shown in FIG. 52, in steps S328 to S344, a read operation using CCI-FS is performed.

[0438] In step S328, the CCI-FS processing unit 653 of the application processor 614 sets the ePH register to perform a read operation.

[0439] In step S329, the CCI-FS processing unit 653 of the application processor 614 sets the read data register.

[0440] In step S330, the CCI-FS processing unit 653 of the application processor 614 sets the command execution register to 1 and issues a read command.

[0441] In step S331, the application processor 614 performs Sequence A_Read_CMD (AP) processing, which will be described later with reference to Fig. 54. Here, in the Sequence A_Read_CMD (AP) processing, two branched processes are performed in parallel, and the processing proceeds to step S332 according to branch A, or to step S339 according to branch B.

[0442] In step S332, the master-side SerDes device 613 performs Sequence B (SerDes (Master) mode) processing, which will be described later with reference to Fig. 56. Note that Fig. 56 describes the Sequence B (SerDes (Slave) mode) processing performed by the slave-side SerDes device 612, but the master-side SerDes device 613 can also perform similar processing using the corresponding blocks.

[0443] In step S333, the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the extended DT of the extended packet header ePH of the master side SerDes device 613 via the CSI2-FS processing unit 643 and the CSIA processing unit 642, and performs A-PHY transfer.

[0444] In step S334, the slave SerDes device 612 performs Sequence B (SerDes (Slave) mode) processing, which will be described later with reference to FIG.

[0445] In step S355, the slave-side SerDes device 612 performs Sequence A_Read_CMD (SerDes (Slave)) processing, which will be described later with reference to Fig. 54. Note that Fig. 54 describes the Sequence A_Read_CMD (AP) processing executed in the application processor 614, but similar processing can also be executed by corresponding blocks in the slave-side SerDes device 612. Here, in the Sequence A_Read_CMD (SerDes (Slave)) processing, of the two branched processes, the processing does not proceed to branch A, and the processing proceeds to step S336 according to branch B.

[0446] In step S336, the slave-side SerDes device 612 performs Sequence A_Read_Data (SerDes (Slave)) processing, which will be described later with reference to Fig. 57. Note that Fig. 57 describes the Sequence A_Read_Data (AP) processing executed in the application processor 614, but similar processing can also be executed by the corresponding blocks in the slave-side SerDes device 612.

[0447] In step S337, the A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the extended DT of the extended packet header ePH of the slave side SerDes device 612 via the CSI2-FS processing unit 633 and the CSIA processing unit 632, and performs A-PHY transfer.

[0448] In step S338, the master-side SerDes device 613 performs Sequence B (SerDes (Master) mode) processing, which will be described later with reference to Fig. 56. Note that Fig. 56 describes Sequence B (SerDes (Slave) mode) processing executed in the slave-side SerDes device 612, but similar processing can also be executed by the corresponding blocks in the master-side SerDes device 613.

[0449] In step S339, the application processor 614 performs Sequence A_Read_Data (AP) processing, which will be described later with reference to FIG.

[0450] In step S340, the application processor 614 performs Sequence B (AP time) processing, which will be described later with reference to Fig. 56. Note that Fig. 56 describes Sequence B (SerDes (Slave) time) processing executed in the slave-side SerDes device 612, but similar processing can also be executed by the corresponding blocks in the application processor 614.

[0451] In step S341, the CCI-FS processing unit 653 of the application processor 614 stores read data at an address in the register 654 based on the contents of the extension packet header ePH and the extension packet footer ePF.

[0452] In step S342, the image sensor 611, the slave SerDes device 612, the master SerDes device 613, and the application processor 614 perform the above-mentioned read processing and check the error register.

[0453] In step S343, the image sensor 611 and each device (slave side SerDes device 612, master side SerDes device 613, and application processor 614) determine whether the register value of the Error register of each CCI-FS processing unit is 0 or not.

[0454] If it is determined in step S343 that the register values of all the CCI-FS processing units are not 0 (any of the register values is not 0), the process proceeds to step S344.

[0455] In step S344, the error-related register value of the CCI-FS processing unit is checked if the register value is not 0, and the error register is cleared by writing 1 to perform retransmission processing.

[0456] On the other hand, if it is determined in step S343 that the register values of all the CCI-FS processing units are 0, or after the processing of step S344, the processing ends.

[0457] Fig. 53 is a flowchart illustrating the Sequence A_Write (AP) processing performed in step S321 of Fig. 51. Note that Fig. 53 illustrates the processing performed by the application processor 614 as an example, but the Sequence A_Write (SerDes (Slave)) processing in step S325 of Fig. 51 is also performed in the same way.

[0458] In step S351, in the application processor 614, the I2C / I3C master 651 issues a start command and a slave address (Slave Address+W 8-bit shown in FIG. 42).

[0459] In step S352, the application processor 614 determines whether or not the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the master-side SerDes device 613. If it is determined in step S352 that an ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S353.

[0460] In step S353, the I2C / I3C master 651 in the application processor 614 issues a register address (Register Address [15:8] shown in FIG. 42). Here, each time the processing of step S353 is repeated, the payload at or below this register address is transmitted, as shown in FIG.

[0461] In step S354, the application processor 614 determines whether or not the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the master-side SerDes device 613. If it is determined in step S354 that an ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S355.

[0462] In step S355, the I2C / I3C master 651 determines whether or not the transfer of the final data has been completed in the application processor 614. If it is determined in step S355 that the transfer of the final data has not been completed, the process returns to step S353, and the same processes are repeated thereafter.

[0463] On the other hand, if it is determined in step S355 that the transfer of the final data has been completed, the process proceeds to step S356. In step S356, the I2C / I3C master 651 in the application processor 614 issues a stop command. This ends the Sequence A_Write (AP) process, and the process returns to step S322 in FIG.

[0464] On the other hand, if it is determined in step S352 or S354 that an ACK response has not been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S357. In step S357, the I2C / I3C master 651 in the application processor 614 issues a stop command. In this case, the Sequence A_Write (AP) process ends, and the communication process itself ends.

[0465] Fig. 54 is a flowchart illustrating the Sequence A_Read_CMD (AP) processing performed in step S331 of Fig. 52. Note that Fig. 54 illustrates the processing performed by the application processor 614 as an example, but the Sequence A_Read_CMD (SerDes (Slave)) processing in step S335 of Fig. 52 is performed in the same way.

[0466] In step S361, in the application processor 614, the I2C / I3C master 651 issues a start command and a slave address (Slave Address+W 8-bit shown in FIG. 42), and starts a timer.

[0467] In step S362, the application processor 614 determines whether or not the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the master-side SerDes device 613. If it is determined in step S362 that an ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S363.

[0468] In step S363, the I2C / I3C master 651 in the application processor 614 issues a register address (Register Address [15:8] shown in FIG. 42). Here, each time the process of step S363 is repeated, the payload at or below this register address is transmitted, as shown in FIG.

[0469] In step S364, the application processor 614 determines whether the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the SerDes device 613 on the master side.

[0470] If it is determined in step S364 that an ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S365.

[0471] In step S365, the I2C / I3C master 651 in the application processor 614 determines whether the transfer of the final data has been completed.

[0472] If it is determined in step S365 that the transfer of the final data has been completed, the process proceeds to step S366.

[0473] In step S366, the I2C / I3C master 651 issues a stop command in the application processor 614. Thereafter, the process branches into two, and following branch A, the process proceeds to step S332 in Fig. 52. On the other hand, following branch B, Sequence C (at AP) process (see Fig. 55, described later) is performed in step S367, and then the process proceeds to step S339 in Fig. 52.

[0474] On the other hand, if it is determined in step S365 that the transfer of the final data has not been completed, the process proceeds to step S368.

[0475] In step S368, the I2C / I3C master 651 in the application processor 614 determines whether the timer started in step S361 has timed out. If it is determined in step S368 that the timer has not timed out, the process returns to step S363, and the same processes are repeated thereafter.

[0476] On the other hand, if it is determined in step S368 that the timer has timed out, the process proceeds to step S369.

[0477] In step S369, the application processor 614 sets the Error register (Timeout) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related register.

[0478] After the process of step S369, or if it is determined in step S362 or S364 that an ACK response has not been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S370.

[0479] In step S370, the I2C / I3C master 651 issues a stop command in the application processor 614. In this case, the Sequence A_Read_CMD (at AP) process ends, and the communication process itself ends.

[0480] Fig. 55 is a flowchart illustrating the Sequence C (AP) processing performed in step S367 of Fig. 54. Note that Fig. 55 illustrates the processing performed by the application processor 614 as an example, but similar processing can also be performed in the slave-side SerDes device 612.

[0481] In step S381, the I2C / I3C master 651 in the application processor 614 determines whether the timer started in step S361 of Fig. 54 has timed out, and the process waits until it is determined that the timer has timed out. If it is determined that the timer has timed out in step S381, the process proceeds to step S382, and the I2C / I3C master 651 in the application processor 614 performs a polling operation.

[0482] In step S383, the I2C / I3C master 651 in the application processor 614 determines whether the Status register value of the read command is 1 or not.

[0483] If it is determined in step S383 that the Status register value of the read command is 1, the process proceeds to step S384. In step S384, the application processor 614 performs a read access, and then the process returns to step S339 in FIG.

[0484] On the other hand, if it is determined in step S383 that the Status register value of the read command is not 1 (other than 1), the process proceeds to step S385. In step S385, the application processor 614 sets the Error register (Timeout) to 1 and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.

[0485] In step S386, the I2C / I3C master 651 issues a stop command in the application processor 614. In this case, the Sequence C (AP) processing ends, and the communication processing itself ends.

[0486] Fig. 56 is a flowchart illustrating the Sequence B (SerDes (Slave)) processing performed in steps S324 and S334 in Fig. 51. Note that Fig. 56 illustrates processing performed by the slave-side SerDes device 612 as an example, but the Sequence B (SerDes (Master)) processing in step S322 in Fig. 51, the Sequence B (Image Sensor) processing in step S326 in Fig. 51, and the Sequence B (SerDes (Master)) processing in step S332 in Fig. 52 are also performed in the same way.

[0487] In step S391, in the slave SerDes device 612, the CCI-FS processing unit 636 checks the Source ID of the slave SerDes device 612 and the Destination SID of the extended packet header ePH.

[0488] In step S392, in the slave SerDes device 612, the CCI-FS processing unit 636 determines whether or not the Source ID of the slave SerDes device 612 and the Destination SID of the extended packet header ePH do not match.

[0489] If it is determined in step S392 that the Source ID of the slave SerDes device 612 and the Destination SID in the extended packet header ePH do not match, the process proceeds to step S393.

[0490] In step S393, in the slave side SerDes device 612, the CCI-FS processing unit 636 checks the Destination SID of the slave side SerDes device 612 and the Destination SID of the extended packet header ePH.

[0491] In step S394, in the slave SerDes device 612, the CCI-FS processing unit 636 determines whether or not the Source ID of the slave SerDes device 612 matches the Destination SID in the extended packet header ePH.

[0492] If it is determined in step S394 that the Source ID of the slave SerDes device 612 matches the Destination SID in the extended packet header ePH, the process proceeds to step S395.

[0493] In step S395, in the slave SerDes device 612, the CCI-FS processing unit 636 checks the Message Counter from the contents of the extended packet header ePH.

[0494] In step S396, in the slave side SerDes device 612, the CCI-FS processing unit 636 determines whether the Message Counter in the slave side SerDes device 612 matches the received value of the Message Counter confirmed from the contents of the extended packet header ePH.

[0495] If it is determined in step S396 that the Message Counter in the slave SerDes device 612 matches the received value of the Message Counter confirmed from the contents of the extended packet header ePH, the process proceeds to step S397.

[0496] In step S397, in the slave side SerDes device 612, the CCI-FS processing unit 636 checks the CRC calculation result calculated from the extended packet header ePH in the slave side SerDes device 612 and the received value (ePF0) of the extended packet footer ePF.

[0497] In step S398, it is determined whether the received value (ePF0) of the extended packet footer ePF matches the CRC calculation result, and if it is determined that they match, the process returns to step S325 in FIG.

[0498] On the other hand, if it is determined in step S392 that the Source ID of the slave SerDes device 612 and the Destination SID of the extended packet header ePH do not mismatch (match), the process proceeds to step S399.

[0499] In steps S399 to S402, the same processing as in steps S395 to S398 is performed.

[0500] If it is determined in step S402 that the received value (ePF0) of the extended packet footer ePF matches the CRC calculation result, the process proceeds to step S403. In step S403, write access is made to the register 637 of the SerDes device 612 on the slave side.

[0501] If it is determined in step S394 that the Source ID of the slave SerDes device 612 and the Destination SID of the extended packet header ePH do not match, the process proceeds to step S404. In step S404, the CCI-FS processing unit 636 in the slave SerDes device 612 sets 1 to Error register [2] (Routing) and stores the data of the extended packet header ePH and the extended packet footer ePF in the error-related registers.

[0502] If it is determined in step S398 or S402 that the received value (ePF0) of the extended packet footer ePF does not match the CRC calculation result, the process proceeds to step S405. In step S405, in the slave SerDes device 612, the CCI-FS processing unit 636 sets the Error register (CRC) to 1 and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related register.

[0503] If it is determined in step S396 or S400 that the Message Counter in the slave-side SerDes device 612 does not match the received value of the Message Counter confirmed from the contents of the extended packet header ePH, the process proceeds to step S406. In step S406, the CCI-FS processing unit 636 in the slave-side SerDes device 612 sets the Error register (MC) to 1 and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related registers.

[0504] After the processing of steps S403 to S406, the processing of Sequence B (in SerDes (Slave) mode) ends, and the communication processing itself ends.

[0505] Regarding CRC calculation, it is possible to perform it only for E2E Protection, and it is expected that there will be a combination of error detection on each device and whether or not to discard packets.

[0506] Fig. 57 is a flowchart illustrating the Sequence A_Read_Data (AP) processing performed in step S339 of Fig. 52. Note that Fig. 57 illustrates the processing performed by the application processor 614 as an example, but the Sequence A_Read_Data (SerDes (Slave)) processing in step S336 of Fig. 52 is performed in the same way.

[0507] In step S411, the I2C / I3C master 651 in the application processor 614 issues a start command and a slave address (Slave Address+W 8-bit shown in FIG. 48).

[0508] In step S412, the application processor 614 determines whether or not the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the master-side SerDes device 613. If it is determined in step S412 that an ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S413.

[0509] In step S413, in the application processor 614, the I2C / I3C master 651 issues a start command and a slave address (Slave Address+R 8-bit shown in FIG. 48), and starts a timer.

[0510] In step S414, the application processor 614 determines whether or not the I2C / I3C master 651 has received an ACK response from the I2C / I3C slave 644 of the master-side SerDes device 613. If it is determined in step S414 that the ACK response has been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S415.

[0511] In step S415, in the application processor 614, the I2C / I3C master 651 acquires read data from the opposing I2C / I3C slave 644 on the application processor 614 side.

[0512] In step S416, it is determined whether the I2C / I3C master 651 of the application processor 614 has transmitted an ACK and whether the opposing I2C / I3C slave 644 on the application processor 614 side has received the ACK.

[0513] If it is determined in step S416 that the I2C / I3C master 651 of the application processor 614 has transmitted an ACK and that the opposing I2C / I3C slave 644 on the application processor 614 side has received the ACK, the process proceeds to step S417.

[0514] In step S417, it is determined whether the I2C / I3C master 651 of the application processor 614 has transmitted a NACK signal in response to the completion of the transfer of the final data.

[0515] If it is determined in step S417 that a NACK has been transmitted, the process proceeds to step S418. In step S418, the I2C / I3C master 651 in the application processor 614 issues a stop command. This ends the Sequence A_Read_Data (AP) process, and the process returns to step S340 in FIG.

[0516] On the other hand, if it is determined in step S417 that a NACK has not been transmitted, the process proceeds to step S419.

[0517] In step S419, the I2C / I3C master 651 in the application processor 614 determines whether the timer started in step S413 has timed out. If it is determined in step S419 that the timer has not timed out, the process returns to step S415, and the same processes are repeated thereafter.

[0518] On the other hand, if it is determined in step S419 that the timer has timed out, the process proceeds to step S420.

[0519] In step S420, the application processor 614 sets the Error register (Timeout) to 1, and stores the data of the extended packet header ePH and the extended packet footer ePF in the Error-related register.

[0520] After the process of step S420, or if it is determined in step S414 that an ACK response has not been received from the I2C / I3C slave 644 of the master-side SerDes device 613, the process proceeds to step S421. Similarly, if it is determined in step S416 that the I2C / I3C master 651 of the application processor 614 has not transmitted an ACK, or that the opposing I2C / I3C slave 644 on the application processor 614 side has not received an ACK, the process proceeds to step S421.

[0521] In step S421, the I2C / I3C master 651 issues a stop command in the application processor 614. In this case, the Sequence A_Read_Data (at AP) process ends, and the communication process itself ends.

[0522] Here, there are three combinations of access timing from the I2C / I3C master 634 to the I2C / I3C slave 621 when the I2C / I3C slave 621 outputs (see Figure 46), and access timing from the I2C / I3C master 651 to the I2C / I3C slave 644 when the I2C / I3C slave 644 of the master-side SerDes device 613 outputs (see Figure 48), as described below.

[0523] The first access timing is to poll until the read data is acquired, and after preparations for reading the read data are complete, the I2C / I3C master starts the read process.

[0524] The second access timing is when the I2C / I3C master starts a read process after a certain time has elapsed.

[0525] The third access timing uses the Clock Stretch method (refer to FIG. 72 described later). After a certain period of time, the I2C / I3C master starts the read process. At this time, there are two forms: sending read data in chunks and sending read data separately (asserting the Clock Stretch Mode signal).

[0526] <Configuration example of extended packet header ePH> FIGS. 58 to 60 are diagrams showing a configuration example of the extended packet header ePH.

[0527] FIG. 58 shows detailed configuration examples of the extended packet headers ePH0, ePH1, and ePH2. The addition of the extended packet header ePH as shown is defined by reusing the ePH structure in C-PHY and D-PHY for the content of the extended packet header ePH for CCI-FS.

[0528] FIG. 59 shows a detailed configuration example of the extended packet header ePH3. The addition of the extended packet header ePH as shown is defined for the content of the extended packet header ePH for CCI-FS.

[0529] FIG. 60 shows a detailed configuration example of the extended DT of the extended packet header ePH. For example, in order to support CCI-FS, "0xC0:For I2C" and "0xC1:For I3C" are added to the data type of the extended packet header ePH.

[0530] <Example of I2C circuit configuration> FIG. 61 shows a configuration example of a conventional I2C in hardware. For example, it shows a configuration example of I2C in the case of a bus connection configuration at the upper level during hardware implementation. The slave side may be configured to receive AKC / NACK from the upper level. Of course, this is just an example, and the upper bus configuration does not necessarily match.

[0531] Figure 62 shows the waveforms during data transfer on the I2C bus. Note that the I2C bus standard and CCI (I2C) are considered equivalent.

[0532] FIG. 63 is a block diagram showing an example of a CCI-related configuration in a communication system 701 having an A-PHY direct connection configuration, similar to the communication system 501 shown in FIG. 27 above.

[0533] As shown in FIG. 63, in a communication system 701, an image sensor 711 and an application processor 712 are directly connected via an A-PHY.

[0534] The image sensor 711 includes an A-PHY processing unit 721, a CSIA processing unit 722, a CSI2 processing unit 723, a CSI2-FS processing unit 724, a CCI processing unit 725, a CCI-FS processing unit 726, a register 727, and selectors 728-1 and 728-2. As shown in the figure, the selectors 728-1 and 728-2 are arranged to sandwich the CCI-FS processing unit 726, and can switch between enable and disable of the CCI-FS processing unit 726 in accordance with a CCI_FS_Enable signal of the register 727.

[0535] The application processor 712 is configured to include an A-PHY processing unit 731, a CSIA processing unit 732, a CSI2 processing unit 733, a CSI2-FS processing unit 734, a CCI processing unit 735, a CCI-FS processing unit 736, a register 737, and selectors 738-1 and 738-2. As shown in the figure, the selectors 738-1 and 738-2 are arranged to sandwich the CCI-FS processing unit 736, and can switch between enable and disable of the CCI-FS processing unit 736 in accordance with a CCI_FS_Enable signal of the register 737.

[0536] For example, when the CCI_FS_Enable signal indicates enabling CCI-FS (CCI_FS_Enable = 1), as shown by the arrow of the dashed line, data is transmitted and received via the CCI-FS processing unit 726 and the CCI-FS processing unit 736. On the other hand, when the CCI_FS_Enable signal indicates disabling CCI-FS (CCI_FS_Enable = 0), as shown by the arrow of the dotted line, data is transmitted and received without passing through the CCI-FS processing unit 726 and the CCI-FS processing unit 736.

[0537] <Network connection form> FIG. 64 shows an example of the network connection form (topology) of the A-PHY direct connection configuration and the SerDes connection configuration.

[0538] The application processor 801 is directly connected to the image sensor 802 via the A-PHY, and the image sensor 802 can configure a connection form in which it is connected to the sensor 803 via I2C / I3C.

[0539] The application processor 801 is connected to the master-side SerDes device 804 via I2C / I3C, and the master-side SerDes device 804 and the slave-side SerDes device 805 are connected via the A-PHY. The slave-side SerDes device 805 can configure a connection form in which it is connected to two sensors 806-1 and 806-2 via I2C / I3C.

[0540] <Circuit configuration of the CCI-FS processing unit> FIG. 65 is a block diagram showing an example of the circuit configuration of the CCI-FS processing unit. The CCI-FS processing unit 901 and the register 902 shown in FIG. 65 have a common configuration with the CCI-FS processing unit and the register provided in each of the above-described devices.

[0541] 65, CCI-FS processing unit 901 has a CCI-FS switch, registers, etc. in its upper layer, and a CCI processing unit in its lower layer. CCI-FS processing unit 901 is configured with a CCI-FS transmitter 911 and a CCI-FS receiver 912. Various register setting value information is supplied from register 902 to CCI-FS processing unit 901, and an error notification is supplied from CCI-FS processing unit 901 to register 902.

[0542] The CCI-FS transmitter 911 includes an extended packet header ePH generator 921 , an extended packet footer ePF generator 922 , and a destination address checker 923 .

[0543] The extended packet header ePH generation unit 921 has an MC generation unit 941 that generates a Message Counter and a Packet Length calculation unit 942 that calculates the packet length. The extended packet footer ePF generation unit 922 has an extended packet footer ePF1 generation unit 943 that generates an extended packet footer ePF1 and a CRC calculation unit 944 that calculates the CRC to be stored in the extended packet footer ePF0.

[0544] The CCI-FS receiver 912 includes an extended packet header ePH checker 931 , an extended packet footer ePF checker 932 , and a destination address checker 933 .

[0545] The extended packet header ePH check unit 931 has an MC check unit 951 that checks the Message Counter and a packet length calculation and check unit 952 that calculates and checks the packet length. The extended packet footer ePF check unit 932 has an extended packet footer ePF1 check unit 953 that checks the extended packet footer ePF1 and a CRC calculation unit 954 that calculates the CRC to be stored in the extended packet footer ePF0.

[0546] The CCI-FS processing unit 901 can check the destination address of data from a higher layer using a CCI-FS transmission unit 911, generate an extended packet header ePH and an extended packet footer ePF, add them to the data, and supply them to a lower layer. The CCI-FS processing unit 901 can check the destination address of data from a lower layer using a CCI-FS reception unit 912, check the extended packet header ePH and an extended packet footer ePF, and supply them to a higher layer.

[0547] Here, the operation of the CCI-FS processing unit of each device constituting communication system 601 in the example of the SerDes connection configuration shown in FIG. 40 will be described.

[0548] The application processor 614 has a Source ID indicating its own device in the extended packet header ePH in the application processor 614. Then, the CCI-FS processing unit 653 adds the above information and information having a Destination ID indicating the device making the intended access.

[0549] The slave-side SerDes device 612 and the master-side SerDes device 613 have a Source ID that indicates their own device, either by being set in advance or as a unique value. The CCI-FS processing unit 636 and the CCI-FS processing unit 646 set in advance the above information and information having a Destination ID that indicates the connected device and the target device.

[0550] Furthermore, the CCI-FS processing unit 636 and the CCI-FS processing unit 646 compare the destination ID in the received extension packet header ePH with their own ID (Source ID) to determine whether the access is to themselves or indicates a target device (Destination ID). For example, if the destination ID in the received extension packet header ePH matches their own ID (Source ID), they access their own register as an access to an intermediate device (SerDes device). On the other hand, if the destination ID in the received extension packet header ePH does not match their own ID (Source ID), they transfer data to the connected device (Destination ID) as an access to a subsequent device.

[0551] As described above, data is transferred to an intermediate device (SerDes device) or a target device based on the Source ID and Destination ID embedded in the extended packet header ePH, a pre-set or unique Source ID, and pre-set connection destination information, and access is made to the target device.

[0552] The CSI2-FS processing unit 623 of the image sensor 611 accesses its own register as an access to the image sensor 611 when the Destination ID of the received extended packet header ePH matches its own ID (Source ID).

[0553] In this way, the Source ID of each device can be a unique value for each device, a preset value, or a combination thereof.

[0554] 66 to 68 are diagrams showing detailed configuration examples of the register 902. FIG.

[0555] Fig. 66 shows details of addresses 0x000 to 0x109 of the register 902. Fig. 67 shows details of addresses 0x110 to 0x125 of the register 902, illustrating an example of a configuration in a Bridge configuration.

[0556] Fig. 68 shows the error-related registers as details of address 0x200 of register 902. Fig. 68 shows the error-related registers (debug) as details of addresses 0x300 and 0x400 of register 902. Fig. 68 shows the error injection-related registers (debug) as details of address 0x800 of register 902.

[0557] <Modification of extended packet header ePH> With reference to FIGS. 69 and 70, a modification of the extension packet header ePH will be described.

[0558] Fig. 69 shows a modified example of the extension packet header ePH in the packet configuration of write data generated by the CCI-FS processing unit 536 of the application processor 512 during write access, as described above with reference to Fig. 33. The extension packet header ePH shown in Fig. 69 differs from the example configuration shown in Fig. 33 above in the configurations of the extension packet header ePH3 and extension packet header ePH4.

[0559] Fig. 70 shows a modified example of the extension packet header ePH in the packet configuration of write data generated by the CCI-FS processing unit 536 of the application processor 512 during read access, as described above with reference to Fig. 28. The extension packet header ePH shown in Fig. 70 differs from the example configuration shown in Fig. 28 above in the configurations of the extension packet header ePH3 and extension packet header ePH4.

[0560] For example, in the extended packet header ePH shown in Figures 69 and 70, the following combinations are assumed, depending on the implementation.

[0561] Read address information may be stored in the extended packet header ePH or in the AP (CCI) payload. Length information may be stored in the extended packet header ePH or in the AP (CCI) payload. CMD information may be stored in the CCI Command ID in the extended packet header ePH. Command start, restart, and end information is referenced based on the CCI Command ID. CCI information (e.g., Slave Address) may be stored in the AP (CCI) payload using the CCI Header Length. The CCI Header Length is information indicating the header length of the CCI protocol (I2C).

[0562] FIG. 71 is a diagram illustrating the flow between the image sensor 511 and the application processor 512 in the A-PHY direct connection configuration as shown in FIG.

[0563] In the application processor 512, the CCI-FS switch 538 issues a read command and a write command. The CCI-FS switch 538 supplies a slave address (Slave Address+W 8 bits), a register address (Register Address[15:8], Register Address[7:0]), and data (Data*(*=N)[7:0]) to the CCI processing unit 535. The CCI processing unit 535 converts them into an AP(CCI) payload and supplies it to the A-PHY processing unit 531. The A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the AP(CCI) payload and performs A-PHY transfer to the image sensor 511.

[0564] In the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and the A-PHY footer and supplies the AP (CCI) payload to the CCI processing unit 525. The CCI processing unit 525 converts the AP (CCI) payload and, based on the contents of the AP (CCI) payload, writes data to a register 527 in accordance with a write command and reads data from the register 527 in accordance with a read command.

[0565] At this time, the initial setting of CCI-FS Enable is performed by the CCI processing unit 525, and bus conversion such as the register interface and AHB bus is performed. Then, the CCI-FS Enable setting is confirmed via the CCI processing unit 525 or the CCI-FS processing unit 526.

[0566] The CCI processing unit 525 converts the read data (Data*(*=M)[7:0]) read from the register 527 in response to the read command into an AP(CCI) payload and supplies it to the A-PHY processing unit 521. The A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to the AP(CCI) payload and performs A-PHY transfer to the application processor 512.

[0567] In the application processor 512, the A-PHY processing unit 531 removes the A-PHY header and the A-PHY footer and supplies the AP(CCI) payload to the CCI processing unit 535. The CCI processing unit 535 converts the AP(CCI) payload and supplies read data (Data*(*=M)[7:0]) to the CCI-FS switch 538.

[0568] The CCI-FS switch 538 sets the CCI-FS Enable setting and various CCI-FS related registers in the register 537. At this time, register access depends on the implementation. The CCI-FS switch 538 sets various CCI-FS related registers in the register 527 via the register 537, the CCI-FS processing unit 536, the A-PHY processing unit 531, the A-PHY processing unit 521, and the CCI-FS processing unit 526.

[0569] In the application processor 512, the CCI-FS switch 538 issues a read command. The CCI-FS switch 538 supplies a slave address (Slave Address+W 8 bits), a register address (Register Address[15:8], Register Address[7:0]), and data (Data*(*=N)[7:0]) to the register 537. The CCI-FS processing unit 536 converts them into an AP (CCI) payload, adds an extended packet header ePH*(*=n), an extended packet footer ePF1, and an extended packet footer ePF0, and supplies the payload to the A-PHY processing unit 531. The A-PHY processing unit 531 adds an A-PHY header and an A-PHY footer to the payload and performs A-PHY transfer to the image sensor 511.

[0570] In the image sensor 511, the A-PHY processing unit 521 removes the A-PHY header and A-PHY footer, and supplies the extended packet header ePH* (*=n), AP (CCI) payload, extended packet footer ePF1, and extended packet footer ePF0 to the CCI-FS processing unit 526. The CCI-FS processing unit 526 converts the AP (CCI) payload and, based on its contents, reads data from a register 527 in accordance with a read command. At this time, register access depends on the implementation, and bus conversion such as a register interface, AHB bus, or CCI interface is performed.

[0571] The CCI-FS processing unit 526 converts the read data (Data*(*=M)[7:0]) read from the register 527 in response to the read command into an AP(CCI) payload, adds an extended packet header ePH*(*=n), an extended packet footer ePF1, and an extended packet footer ePF0, and supplies the payload to the A-PHY processing unit 521. The A-PHY processing unit 521 adds an A-PHY header and an A-PHY footer to the data, and performs A-PHY transfer to the application processor 512.

[0572] In the application processor 512, the A-PHY processing unit 531 removes the A-PHY header and the A-PHY footer, and supplies the extended packet header ePH*(*=n), the AP(CCI) payload, the extended packet footer ePF1, and the extended packet footer ePF0 to the CCI-FS processing unit 536. The CCI-FS processing unit 536 converts the AP(CCI) payload and supplies read data (Data*(*=M)[7:0]) to the CCI-FS switch 538.

[0573] The above flow has been explained using an example of generating I2C / I3C commands in hardware, but there are other combinations such as the following:

[0574] In the case of software, I2C / I3C generation involves generating the slave address, register address, payload, ACK response reception, transmission, and various control codes (S, Sr, ACK, NACK, P) in software (for example, like GPIO control). In software I2C / I3C command generation, the CPU issues the slave address, register address, and payload in response to ACK reception in the CPU bus settings.

[0575] In the case of hardware, I2C / I3C is generated in the hardware by setting the transfer settings and data in the I2C / I3C HW IP. Various control codes are automatically responded to by the hardware. I2C / I3C command generation in the hardware involves setting the data in the I2C / I3C HW IP in the transfer settings and sending the command. Various control codes are automatically responded to by the hardware.

[0576] FIG. 72 is a diagram illustrating a flow using the Clock Stretch method in write access and read access between the image sensor 611 and the application processor 614 in the SerDes connection configuration as shown in FIG.

[0577] The CCI-FS switch 655 of the application processor 614 supplies the start command and write command (slave address+W 8 bits) to the CCI processing unit 645 of the master-side SerDes device 613 and asserts the Scl_enb signal. In the master-side SerDes device 613, the CCI processing unit 645 supplies the write command to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the write command and performs A-PHY transfer to the slave-side SerDes device 612.

[0578] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the write command to the CCI processing unit 635 (slave). The CCI processing unit 635 (slave) negates the Scl_enb signal and supplies the write command to the CCI processing unit 635 (master). Here, the CCI processing unit 635 that communicates with the master-side SerDes device 613 and functions as a slave is referred to as the CCI processing unit 635 (slave), and the CCI processing unit 635 that communicates with the image sensor 611 and functions as a master is referred to as the CCI processing unit 635 (master).

[0579] The CCI processing unit 635 (Master) transmits a start command and a write command to the image sensor 611.

[0580] In the image sensor 611, the CCI processing unit 622 receives the start command and write command and supplies them to the CSI2-FS processing unit 623. The CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the slave-side SerDes device 612.

[0581] In the slave-side SerDes device 612, when the CCI processing unit 635 (master) receives the ACK response and the Scl_enb signal is negated from the CCI processing unit 635 (slave), the CCI processing unit 635 (master) supplies the ACK response to the CCI-FS processing unit 636. Thereafter, the CCI processing unit 635 (slave) asserts the Scl_enb signal to the CCI processing unit 635 (master).

[0582] The CCI-FS processing unit 636 supplies the ACK response to the A-PHY processing unit 631. The A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the ACK response, and performs A-PHY transfer to the SerDes device 613 on the master side.

[0583] In the master-side SerDes device 613, the A-PHY processing unit 641 removes the A-PHY header and the A-PHY footer and supplies the ACK response to the CCI processing unit 645. When the CCI-FS switch 655 of the application processor 614 negates the Scl_enb signal to the CCI processing unit 645, the CCI processing unit 645 transmits the ACK response to the application processor 614.

[0584] In the application processor 614 , the CCI processing unit 652 receives the ACK response and supplies it to the CCI-FS switch 655 via the CCI-FS processing unit 653 .

[0585] The CCI-FS switch 655 of the application processor 614 supplies the register address (Register Address[7:0]) to the CCI processing unit 645 of the master-side SerDes device 613 and asserts the Scl_enb signal. In the master-side SerDes device 613, the CCI processing unit 645 supplies the register address to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the register address and performs A-PHY transfer to the slave-side SerDes device 612.

[0586] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the register address to the CCI processing unit 635 (slave). The CCI processing unit 635 (slave) negates the Scl_enb signal and supplies the register address to the CCI processing unit 635 (master). The CCI processing unit 635 (master) transmits the register address to the image sensor 611. Thereafter, the CCI processing unit 635 (slave) asserts the Scl_enb signal to the CCI processing unit 635 (master).

[0587] In the image sensor 611, the CCI processing unit 622 receives the register address and supplies it to the CSI2-FS processing unit 623. The CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the slave-side SerDes device 612.

[0588] Thereafter, the ACK response is supplied to the CCI-FS switch 655 in the same manner as described above.

[0589] In the application processor 614 , the CCI-FS processing unit 653 transmits the extended packet header ePH* (*=n) to the master side SerDes device 613 under the control of the CCI-FS switch 655 .

[0590] In the master-side SerDes device 613, the CCI processing unit 645 receives the extended packet header ePH*(*=n), and when the Scl_enb signal is asserted from the CCI-FS switch 655, supplies the extended packet header ePH*(*=n) to the A-PHY processing unit 641. The CCI-FS switch 655 then negates the Scl_enb signal to the CCI processing unit 645. The A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the extended packet header ePH*(*=n), and performs A-PHY transfer to the slave-side SerDes device 612.

[0591] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the extended packet header ePH*(*=n) to the CCI-FS processing unit 636. The CCI-FS processing unit 636 negates the Scl_enb signal and supplies the extended packet header ePH*(*=n) to the CCI processing unit 635 (master). The CCI processing unit 635 (master) transmits the extended packet header ePH*(*=n) to the image sensor 611. Thereafter, the CCI processing unit 635 (slave) asserts the Scl_enb signal to the CCI processing unit 635 (master).

[0592] In the image sensor 611, the CSI2-FS processing unit 623 receives the extended packet header ePH* (*=n). The CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the slave-side SerDes device 612.

[0593] Thereafter, the ACK response is supplied to the CCI-FS switch 655 in the same manner as described above.

[0594] The CCI-FS switch 655 of the application processor 614 supplies the write data (Dara0[7:0]) to the CCI processing unit 645 of the master-side SerDes device 613 and asserts the Scl_enb signal. In the master-side SerDes device 613, the CCI processing unit 645 supplies the write data to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the write data and performs A-PHY transfer to the slave-side SerDes device 612.

[0595] In the master-side SerDes device 613, the CCI processing unit 645 receives the write data, and when the Scl_enb signal is asserted from the CCI-FS switch 655, supplies the write data to the A-PHY processing unit 641. Thereafter, the CSI2-FS processing unit 653 negates the Scl_enb signal to the CCI processing unit 645 under the control of the CCI-FS switch 655. The A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the write data and performs A-PHY transfer to the slave-side SerDes device 612.

[0596] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the write data to the CCI processing unit 635. The CCI processing unit 635 negates the Scl_enb signal and supplies the write data to the CCI processing unit 635 (master). The CCI processing unit 635 (master) transmits the write data to the image sensor 611. Thereafter, the CCI processing unit 635 (slave) asserts the Scl_enb signal to the CCI processing unit 635 (master).

[0597] In the image sensor 611, the CCI processing unit 622 receives the write data and supplies it to the CSI2-FS processing unit 623, which then writes the write data to the register 624. The CSI2-FS processing unit 623 supplies an ACK response indicating that the write data has been successfully written to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the SerDes device 612 on the slave side.

[0598] Thereafter, the ACK response is supplied to the CCI-FS switch 655 in the same manner as described above.

[0599] In the application processor 614, the CCI-FS processing unit 653 transmits the extended packet footer ePF0 to the SerDes device 613 on the master side under the control of the CCI-FS switch 655.

[0600] In the master-side SerDes device 613, the CCI processing unit 645 receives the extended packet footer ePF0, and when the Scl_enb signal is asserted from the CCI-FS switch 655, supplies the extended packet footer ePF0 to the A-PHY processing unit 641. The CCI-FS switch 655 then negates the Scl_enb signal to the CCI processing unit 645. The A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the extended packet footer ePF0 and performs A-PHY transfer to the slave-side SerDes device 612.

[0601] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the extended packet footer ePF0 to the CCI-FS processing unit 636. The CCI-FS processing unit 636 negates the Scl_enb signal and supplies the extended packet footer ePF0 to the CCI processing unit 635 (master). The CCI processing unit 635 (master) transmits the extended packet footer ePF0 to the image sensor 611. Thereafter, the CCI processing unit 635 (slave) asserts the Scl_enb signal to the CCI processing unit 635 (master).

[0602] In the image sensor 611, the CSI2-FS processing unit 623 receives the extended packet footer ePF0. The CSI2-FS processing unit 623 supplies an ACK response indicating successful reception to the CCI processing unit 622, and the CCI processing unit 622 transmits the ACK response to the slave-side SerDes device 612.

[0603] Thereafter, the ACK response is supplied to the CCI-FS switch 655 in the same manner as described above.

[0604] The CCI-FS switch 655 of the application processor 614 supplies the repeat start command and read command (Slave Address+R 8 bits) to the CCI processing unit 645 of the master-side SerDes device 613 and asserts the Scl_enb signal. In the master-side SerDes device 613, the CCI processing unit 645 supplies the read command to the A-PHY processing unit 641, and the A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the read command and performs A-PHY transfer to the slave-side SerDes device 612.

[0605] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies the read command to the CCI processing unit 635 (slave). The CCI processing unit 635 (slave) negates the Scl_enb signal and supplies the read command to the CCI processing unit 635 (master). The CCI processing unit 635 (master) transmits a repeat start command and a read command to the image sensor 611.

[0606] In the image sensor 611, the CCI processing unit 622 receives the repeat start command and the read command and accesses the register 624. The CCI processing unit 622 transmits an ACK response indicating successful reception to the slave side SerDes device 612.

[0607] Thereafter, the ACK response is supplied to the CCI-FS switch 655 in the same manner as described above.

[0608] In the image sensor 611, the CCI processing unit 622 reads out the read data (Data0[7:0]) from the register 624 and transmits it to the SerDes device 612 on the slave side.

[0609] In the slave-side SerDes device 612, the CCI processing unit 635 (master) receives the read data and supplies it to the CCI processing unit 635 (slave), and the CCI processing unit 635 (slave) supplies the read data to the A-PHY processing unit 631. The A-PHY processing unit 631 adds an A-PHY header and an A-PHY footer to the read data and performs A-PHY transfer to the master-side SerDes device 613.

[0610] In the master-side SerDes device 613, the A-PHY processing unit 641 removes the A-PHY header and A-PHY footer and supplies the read data to the CCI processing unit 645, which then transmits the read data to the application processor 614.

[0611] In the application processor 614 , the CCI processing unit 652 receives the read data and supplies it to the CCI-FS switch 655 via the CCI-FS processing unit 653 .

[0612] The CCI-FS switch 655 transmits the NACK response and the stop command to the CCI processing unit 645. The CCI processing unit 645 supplies the NACK response and the stop command to the A-PHY processing unit 641. The A-PHY processing unit 641 adds an A-PHY header and an A-PHY footer to the NACK response and the stop command, and performs A-PHY transfer to the SerDes device 612 on the slave side.

[0613] In the slave-side SerDes device 612, the A-PHY processing unit 631 removes the A-PHY header and A-PHY footer and supplies a NACK response and a stop command to the CCI processing unit 635 (slave). The CCI processing unit 635 (slave) supplies the NACK response and the stop command to the CCI processing unit 635 (master), and the CCI processing unit 635 (master) transmits the NACK response and the stop command to the image sensor 611.

[0614] In the image sensor 611 , the CCI processing unit 622 receives the NACK response and the stop command and supplies them to the CSI2-FS processing unit 623 .

[0615] In the flow described in Figure 72, I2C control commands such as start, repeat start, ACK response, NACK response, and stop set the Control Code Indicator in the extended packet header ePH0 to 1 and indicate each code assigned to the 1-byte payload.

[0616] <Detailed configuration example of image sensor and application processor> Fig. 73 is a block diagram showing a configuration example of the image sensor 211 shown in Fig. 25 described above, which is equipped with a CCI-FS processing unit 1001. In the image sensor 211 shown in Fig. 73, components common to the image sensor 211 in Fig. 25 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0617] 73, the CCI-FS processing unit 1001 is disposed between the CCI slave 224 and the register 47, and MUX units 1002-1 and 1002-2 are disposed on either side of the CCI-FS processing unit 1001. When the CCI-FS processing unit 1001 is enabled in accordance with the cci_fs_en signal supplied from the register 47, the MUX units 1002-1 and 1002-2 transmit and receive data via the CCI-FS processing unit 1001. On the other hand, when the CCI-FS processing unit 1001 is disabled in accordance with the cci_fs_en signal supplied from the register 47, the MUX units 1002-1 and 1002-2 transmit and receive data without passing through the CCI-FS processing unit 1001.

[0618] Fig. 74 is a block diagram showing an example of a configuration in which the application processor 214 shown in Fig. 26 described above is equipped with a CCI-FS processing unit 1101. In the application processor 214 shown in Fig. 74, components common to the application processor 214 in Fig. 26 are denoted by the same reference numerals, and descriptions thereof will be omitted.

[0619] 74, the CCI-FS processing unit 1101 is arranged between the CCI master 254 and the register 73, and MUX units 1102-1 and 1102-2 are arranged to sandwich the CCI-FS processing unit 1101. When the CCI-FS processing unit 1101 is enabled in accordance with the cci_fs_en signal supplied from the register 73, the MUX units 1102-1 and 1102-2 transmit and receive data via the CCI-FS processing unit 1101. On the other hand, when the CCI-FS processing unit 1101 is disabled in accordance with the cci_fs_en signal supplied from the register 73, the MUX units 1102-1 and 1102-2 transmit and receive data without going through the CCI-FS processing unit 1101.

[0620] The following configuration may be adopted as a method for implementing each field in the configuration of the extended packet header ePH. The extended VC is unused in Safe CCI. (It has a similar structure to match the extended header related to MIPI and the header field.) In the extended DT, it may be embedded in the command-related information of the bus from the upper level, or it may be implemented as a signal line setting from the register setting. Although the protocol is described using I2C, the same thing can be done in I3C SDR mode.

[0621] <Computer configuration example> Next, the above-described series of processes (communication method) can be performed by hardware or software. When the series of processes is performed by software, the programs constituting the software are installed in a general-purpose computer or the like.

[0622] FIG. 75 is a block diagram showing an example of the hardware configuration of a computer that executes the above-described series of processes using a program.

[0623] In the computer, a CPU (Central Processing Unit) 1201, a ROM (Read Only Memory) 1202, a RAM (Random Access Memory) 1203, and an EEPROM (Electronically Erasable and Programmable Read Only Memory) 1204 are interconnected by a bus 1205. An input / output interface 1206 is further connected to the bus 1205, and the input / output interface 1206 is connected to the outside.

[0624] In the computer configured as above, the CPU 1201 performs the above-described series of processes by loading programs stored in, for example, the ROM 1202 and EEPROM 1204 into the RAM 1203 via the bus 1205 and executing the programs. Furthermore, the programs executed by the computer (CPU 1201) can be written in advance in the ROM 1202, or can be installed or updated in the EEPROM 1204 from outside via the input / output interface 1206.

[0625] In this specification, the processing performed by a computer according to a program does not necessarily have to be performed in chronological order according to the order described in the flowchart. In other words, the processing performed by a computer according to a program also includes processing that is executed in parallel or individually (for example, parallel processing or processing by objects).

[0626] The program may be processed by a single computer (processor), or may be distributed among multiple computers. Furthermore, the program may be transferred to and executed on a remote computer.

[0627] Furthermore, in this specification, a system refers to a collection of multiple components (devices, modules (components), etc.), regardless of whether all the components are contained in the same housing. Therefore, multiple devices housed in separate housings and connected via a network, and a single device housed in a single housing with multiple modules, are both systems.

[0628] Also, for example, a configuration described as one device (or processing unit) may be divided and configured as multiple devices (or processing units). Conversely, configurations described above as multiple devices (or processing units) may be combined and configured as one device (or processing unit). Of course, configurations other than those described above may be added to the configuration of each device (or each processing unit). Furthermore, as long as the configuration and operation of the entire system are substantially the same, part of the configuration of one device (or processing unit) may be included in the configuration of another device (or other processing unit).

[0629] Furthermore, for example, this technology can be configured as a cloud computing system in which a single function is shared and processed collaboratively by multiple devices via a network.

[0630] Furthermore, for example, the above-described program can be executed in any device, as long as the device has the necessary functions (functional blocks, etc.) and can obtain the necessary information.

[0631] Also, for example, each step described in the above flowchart can be executed by one device or can be shared and executed by multiple devices. Furthermore, if one step includes multiple processes, the multiple processes included in that one step can be executed by one device or can be shared and executed by multiple devices. In other words, multiple processes included in one step can be executed as multiple step processes. Conversely, processes described as multiple steps can be executed collectively as one step.

[0632] In addition, the processing of the steps of a program executed by a computer may be executed in chronological order according to the order described in this specification, or may be executed in parallel or individually at the required timing, such as when a call is made. In other words, as long as no contradiction occurs, the processing of each step may be executed in an order different from the order described above. Furthermore, the processing of the steps of this program may be executed in parallel with the processing of another program, or may be executed in combination with the processing of another program.

[0633] It should be noted that the present technologies described in this specification can be implemented independently and singly, unless a contradiction arises. Of course, any two or more of the present technologies can also be implemented in combination. For example, part or all of the present technologies described in any embodiment can be implemented in combination with part or all of the present technologies described in other embodiments. Furthermore, part or all of any of the present technologies described above can also be implemented in combination with other technologies not described above.

[0634] <Configuration combination example> The present technology can also be configured as follows. (1) A communication device, A physical layer in which the CCI (Camera Control Interface) protocol is implemented as an upper layer and which transmits and receives data including an extension header and an extension footer to and from other communication devices; a CCI-FS processing unit that compares a destination ID included in the extension header with an ID (source ID) held by the communication device and determines whether or not the access is to the communication device; A communication device comprising: (2) The header size of the extension header is variable depending on the field value in the extension header. The communication device according to (1) above. (3) The extension header includes information indicating the bucket order in a field value in the extension header. The communication device according to (1) or (2) above. (4) The extension header includes information indicating the CCI protocol (I2C) in the field value in the extension header, and routing processing is performed using this information. A communication device according to any one of (1) to (3) above. (5) The extension header includes information indicating the sender of the CCI protocol (I2C) in the field value within the extension header, and response processing is performed based on that information. A communication device according to any one of (1) to (4) above. (6) The extension header includes information indicating the data length in a field value in the extension header. A communication device according to any one of (1) to (5) above. (7) The extension header includes information indicating the header length of the CCI protocol (I2C) in a field value in the extension header. A communication device according to any one of (1) to (6) above. (8) The extension header includes ID information of the CCI protocol (I2C) in a field value in the extension header, and makes it possible to refer to the start, restart, and end information of a command based on that information. A communication device according to any one of (1) to (7) above. (9) The extension header includes information indicating the destination of the CCI protocol (I2C) in the field value within the extension header, and routing is performed based on that information, and a communication path is referenced. A communication device according to any one of (1) to (8) above. (10) The size of the extended footer is variable depending on the field value in the extended footer. A communication device according to any one of (1) to (9) above. (11) The extended footer includes security data. A communication device according to any one of (1) to (10) above. (12) The security data is a hash calculation value. The communication device according to (11) above. (13) The physical layer has an asymmetric upper layer with a point-to-point topology, designed to allow high-speed data transmission, control data, and power to share the same physical wiring. A communication device according to any one of (1) to (12) above. (14) The physical layer is MIPI (Mobile Industry Processor Interface) A-PHY The communication device according to (13) above. (15) The communication device Transmitting and receiving data including an extension header and an extension footer with another communication device through a physical layer in which a CCI (Camera Control Interface) protocol is implemented as an upper layer; comparing a destination ID included in the extension header with an ID (source ID) of the communication device, and determining whether or not the access is to the communication device; A communication method including: (16) The computer of the communication device Transmitting and receiving data including an extension header and an extension footer with another communication device through a physical layer in which a CCI (Camera Control Interface) protocol is implemented as an upper layer; comparing a destination ID included in the extension header with an ID (source ID) of the communication device, and determining whether or not the access is to the communication device; A program for executing a process including:

[0635] It should be noted that the present embodiment is not limited to the above-described embodiment, and various modifications are possible within the scope of the gist of the present disclosure. Furthermore, the effects described in this specification are merely examples and are not intended to be limiting, and other effects may also be obtained. [Explanation of symbols]

[0636] 11 Communication system, 21 Image sensor, 22 Application processor, 23 and 24 Bus, 25 SerDes device, 26 SerDes device, 27 Bus, 31 Extended mode compatible CSI-2 transmitter, 32 Extended mode compatible CSI-2 receiver, 33 CSI-2 receiver, 34 SerDes transmitter, 35 SerDes receiver, 36 CSI-2 transmitter, 41 Pixel, 42 AD converter, 43 Image processing unit, 44 Pixel CRC calculation unit, 45 Physical layer processing unit, 46 I2C / I3C slave, 47 Register, 51 Packing unit, 52 Packet header generator, 53 Extended packet header generator, 54 Extended packet footer generator, 55 and 56 Selection unit, 57 CRC calculation unit, 58 Lane distribution unit, 59 CCI slave, 60 Controller, 71 Physical Layer Processing Unit, 72 I2C / I3C Master, 73 Register, 74 Controller, 81 Packet Header Detection Unit, 82 Lane Merging Unit, 83 Interpretation Unit, 84 and 85 Selection Unit, 86 CRC Calculation Unit, 87 Unpacking Unit, 88 CCI Master

Claims

1. A communication device, A physical layer in which the CCI (Camera Control Interface) protocol is implemented as an upper layer and which transmits and receives data including an extended header and an extended footer to and from other communication devices; a CCI-FS processing unit that compares a destination ID included in the extension header with an ID (source ID) held by the communication device and determines whether or not the access is to the communication device; A communication device comprising:

2. The header size of the extension header is variable depending on the field value in the extension header. The communication device according to claim 1 .

3. The extension header includes information indicating the bucket order in a field value in the extension header. The communication device according to claim 1 .

4. The extension header includes information indicating the CCI protocol (I2C) in the field value in the extension header, and routing processing is performed using this information. The communication device according to claim 1 .

5. The extension header includes information indicating the sender of the CCI protocol (I2C) in the field value within the extension header, and response processing is performed based on that information. The communication device according to claim 1 .

6. The extension header includes information indicating the data length in a field value in the extension header. The communication device according to claim 1 .

7. The extension header includes information indicating the header length of the CCI protocol (I2C) in a field value in the extension header. The communication device according to claim 1 .

8. The extension header includes ID information of the CCI protocol (I2C) in a field value in the extension header, and makes it possible to refer to the start, restart, and end information of a command based on the ID information. The communication device according to claim 1 .

9. The extension header includes information indicating the destination of the CCI protocol (I2C) in the field value within the extension header, and routing is performed based on that information, and a communication path is referenced. The communication device according to claim 1 .

10. The size of the extended footer is variable depending on the field value in the extended footer. The communication device according to claim 1 .

11. The extended footer includes security data. The communication device according to claim 1 .

12. The security data is a hash calculation value. The communication device according to claim 11.

13. The physical layer has an asymmetric upper layer with a point-to-point topology, designed to allow high-speed data transmission, control data, and power to share the same physical wiring. The communication device according to claim 1 .

14. The physical layer is MIPI (Mobile Industry Processor Interface) A-PHY 14. The communication device of claim 13.

15. The communication device Transmitting and receiving data including an extension header and an extension footer with other communication devices through a physical layer in which a CCI (Camera Control Interface) protocol is implemented as an upper layer; comparing a destination ID included in the extension header with an ID (source ID) of the communication device, and determining whether or not the access is to the communication device; A communication method including:

16. The computer of the communication device Transmitting and receiving data including an extension header and an extension footer with other communication devices through a physical layer in which a CCI (Camera Control Interface) protocol is implemented as an upper layer; comparing a destination ID included in the extension header with an ID (source ID) of the communication device, and determining whether or not the access is to the communication device; A program for executing a process including:

Images