Patent Description:
External camera or radar transmitters use MIPI CSI-<NUM> (Mobile Industry Processor Interface Camera Serial Interface <NUM>) virtual channel and data interleaving to send different video/radar data streams and types of data (ADC data, embedded data). Microcontroller video/radar receiver acquisition systems are expected to correctly handle the routing of data to different regions of memory even if the processing requirements of different data types and virtual channels differ.

Traditionally, the number of buffers on such systems is generally same as the number of virtual channels multiplied by the number of supported data types. Additionally, safety data insertion via inter frame or intra frame packets/line by the external radar/video is becoming common, to identify faults in the data receiving communication channels, for system reliability over such links.

In other systems, the software itself may insert such safety lines/packets at the earliest point in the receiver acquisition path. Systems which support the insertion of safety lines without a buffer overhead do so by cropping the active data content. Systems which do not crop the active lines for replacing safety lines have a buffer overhead (over and above the actual functional buffers) to handle safety line processing.

<CIT> describes a video device that includes: a host processor comprising at least one input video port configured to receive a plurality of video data signals that comprise video data and embedded data from a plurality of virtual channels in a received frame; and a memory operably coupled to the host processor and configured to receive and store video data. The host processor is configured to segregate the video data from the embedded data in the received frame and process the embedded data individually.

<CIT> describes a system for receiving at least two data streams and providing a single input data stream to a MIPI's CSI Tx. The system includes a control logic configured to control reading of data stored in the buffers to a multiplexer, the read-side clock being a multiple of a frequency of a fixed frequency clock. The control logic is further configured to control the multiplexer to combine data read from each buffer that corresponds to a complete unit of data into a separate portion and multiplex the separate portions into the input data stream.

Aspects of the present disclosure are set out in the accompanying independent claims. Further features according to embodiments are set out in the dependent claims. Combinations of features from the dependent claims may be combined with features of the independent claims as appropriate and not merely as explicitly set out in the claims.

According to an aspect of the present disclosure, there is provided a method according to claim <NUM>.

According to another aspect of the present disclosure, there is provided a system according to claim <NUM>.

By determining the one or more data types and virtual channels required for an application, and then allocating the circular buffers based on the determined data type(s) and virtual channel(s), there is no need to provide buffers in memory for all possible applications, data types and virtual channels. This may considerably reduce the memory space required for the provision of the buffers. Moreover, the provision of a dedicated buffer for safety data lines may allow the same functional path to be used to process the functional lines and safety lines, without cropping active lines in the received data.

The allocation of the circular buffers may be performed at system start-up.

The at least one safety data line and the at least one functional data line may be received from an external component. The external component may, for instance be a RADAR system of a vehicle, or an external camera of the vehicle. There may be more than one external component.

The at least one safety data line may be processed using a same functional path as a functional path used for processing the at least one received functional data line.

The at least one safety data line is generated locally by software of the system. In such cases, the at least one safety data line is received/processed along a different data path to the data path used for processing the at least one received functional data line.

The method includes performing a self-test routine (e.g. a Built-in-Self-Test (BIST) routine) in which test data is generated locally (e.g. by software of the system) and received along the aforementioned different data path along which the at least one safety data line is received. Accordingly, embodiments of this disclosure can obviate the overhead associated providing the system with separate BIST logic.

The at least one safety data line may be received or generated while no functional data lines are being received.

The one or more applications may include vehicle RADAR and/or an external camera of a vehicle.

According to a further aspect of the present disclosure, there is provided a computer program product on a carrier medium, comprising program instructions for implementing the method of any of claims <NUM> to <NUM>.

According to another aspect of the present disclosure, there is provided a vehicle comprising the system of any of claims <NUM> to <NUM>.

Embodiments of this disclosure will be described hereinafter, by way of example only, with reference to the accompanying drawings in which like reference signs relate to like elements and in which:.

Embodiments of this disclosure are described in the following with reference to the accompanying drawings.

<FIG> shows the multiplexing of safety lines and functional lines using a configurable buffer architecture according to an embodiment of this disclosure.

The system <NUM> in <FIG> may include a processor and memory (e.g. Static Random Access Memory (SRAM)). The memory may store software including program instructions executable by the processor for implementing the methods described herein. The system <NUM> may be included in a vehicle such as a car, van or truck, for processing data relating to various applications. These applications may, for instance, include the processing of vehicle RADAR data and the processing of camera (e.g. an external camera) data such as video data.

The system in <FIG> includes a number of functional blocks. These will be described below.

Block <NUM> is operable to perform pixel processing and buffer management for the data to be processed. In the present embodiment, the pixel processing and buffer management block <NUM> includes a number of sub-blocks. These sub-blocks include a pixel processing and data type and virtual channel identification sub-block <NUM>, an Advanced eXtensible Interface (AXI) handling sub-block <NUM>, an active chirp/video data buffer management block <NUM> and an embedded/user defined buffer management sub-block <NUM>.

Block <NUM> is an RX controller block for handling receipt of data according to one or more data types and virtual channels. For instance, the data types include RADAR data or video data as noted above. In the present embodiment, the RX controller block <NUM> may be configured to processes the received data according to the Mobile Industry Processor Interface Camera Serial Interface <NUM> (MIPICSI2) specification.

The RX controller block <NUM> may include a number of sub-blocks. These sub-blocks may include a lane merging sub-block <NUM>, a pixel formatting sub-block <NUM>, a data cyclic redundancy check (CRC) sub-block <NUM> and an error correction code header (ECC) sub-block <NUM>.

The system <NUM> may also include a multiplexer <NUM>. As will be described below, the multiplexer is operable to multiplex safety data lines and functional data lines received from one or more external devices such as a vehicle RADAR system or video camera, before passing them on to the RX controller block <NUM>. The multiplexer <NUM> may also be operable to receive and multiplex safety lines that are received from software <NUM> (e.g. Microcontroller software) of the system <NUM> with the functional data lines received from the external device(s). The multiplexer <NUM> may also be operable to receive and multiplex both safety lines and functional data lines that are received from software <NUM>, e.g. as part of a Built In Self Test (BIST) procedure.

The system <NUM> also includes a physical layer <NUM>. The physical layer <NUM> may be compatible with the Mobile Industry Processor Interface (MIPI) DPHY physical layer standard. The physical layer <NUM> includes a plurality of lanes for the receipt of data from the external devices noted above. These lanes may include a number of RX data lanes <NUM>. In the present embodiment, there are four such data lanes (for receiving differential data signals DP0, DN0, DP1, DN1, DP2, DN2, DP3, DN3), although in principle any number of data lanes may be provided. The physical layer <NUM> may also include a clock lane <NUM> associated with the data lanes <NUM>. The clock lane <NUM> is operable to review differential clock signal CKP, CKN. The physical layer <NUM> may also include a calibration block <NUM> for calibration of the data lanes <NUM> and clock lane <NUM>. The physical layer <NUM> is connected to the multiplexer <NUM>, to allow the received data to be passed to the multiplexer <NUM> for multiplexing and subsequent provision to the RX controller block <NUM> and the pixel processing and buffer management block <NUM>.

The system <NUM> is operable to allocate a plurality of circular buffers in memory. These circular buffers are allocated according to a number of determined data type(s) and virtual channel(s). The circular buffers that are required for operation of the system may be determined at system start-up. The determination may be made on knowledge of the applications that will be required to be handled by the system <NUM>. For instance, as noted above, the applications may include vehicle RADAR and an external camera of the vehicle. With knowledge of the applications that will be implemented, including knowledge of the data types and virtual channels that will be needed, the system <NUM> can accordingly allocate a required number of circular buffers in memory, for buffering the output of the multiplexer <NUM>. The knowledge of the required applications may be stored in the memory of the system for retrieval at system start-up, and/or may be determined by interrogation of the external devices (e.g. vehicle RADAR system, external camera system) at system start-up.

Because the circular buffers are allocated according to knowledge of the required applications at system start-up, only the required number of circular buffers may be allocated, reducing memory size requirements for the system. This may be compared, for instance, with an approach in which enough memory space must be provided in the system for circular buffers according to all possible applications, data types and virtual channels.

In the embodiment shown in <FIG>, N circular buffers are allocated. These circular buffers may include:.

It will be appreciated that the buffers allocated in <FIG> are just examples, and that any combination of buffers allocated according to data type and virtual channel is envisaged.

In accordance with embodiments of this disclosure, the circular buffers are allocated in memory according to the determined data type(s) and virtual channel(s), e.g. at system start-up. Typically, one or more of the circular buffers is allocated to safety data lines. Although a plurality of circular buffers may in principle be allocated to safety line data, it is envisaged that in practice, for a given combination of data types and virtual channels, a single circular buffer may be allocated to safety line data. This can allow safety line processing for the various applications handled by the system to be accommodated in a manner that minimises memory space requirements for the allocation of the circular buffers. Irrespective of the number of circular buffers that are allocated to safety line data, the remining buffers would typically be allocated to functional data lines.

To process the incoming data, the system <NUM> may store the data in the circular buffers according to the allocation of each buffer. For instance, this may involve storing functional data lines in a circular buffer allocated to functional data lines for that data type and virtual channel. This may also involve storing safety data lines in a (the) circular buffer allocated to safety data lines. The received data may be put into the circular buffers described herein following some processing, and data type and virtual channel identification. The circular buffers are located in the system memory. Typically, placing the received data in the circular buffers according to data type and virtual channel may be the final step performed by the pixel processing and buffer management block <NUM>.

To summarize, <FIG> shows a method <NUM> of acquiring data according to an embodiment of this disclosure. In step <NUM>, the system may determining one or more data types and virtual channels required for one or more applications as described above. In step <NUM>, the system <NUM> may allocate a plurality of circular buffers in memory according to the determined data type(s) and virtual channel(s), in which one or more of the circular buffers are allocated to safety data lines and in which the remaining circular buffers are allocated to functional data lines. In step <NUM>, the system <NUM> may storing at least one functional data line in a circular buffer allocated to functional data lines according to a data type and virtual channel of the functional data line. In step <NUM>, the system <NUM> may store at least one safety data line in a circular buffer allocated to safety data lines.

<FIG> shows a method <NUM> of handling safety lines according to an embodiment of this disclosure.

In step <NUM>, the system shown in <FIG> begins to receive data. As noted previously, the data may be associated for a range of applications, but for the purposes to this embodiment, it may be assumed that the data comprises data from an external device or devices such as a vehicle RADAR system or (e.g. video) camera system.

In step <NUM>, the received data are written to the appropriate circular buffer in the memory. As part of this, the pixel processing and buffer management block <NUM> may direct the received data to the relevant buffer based on virtual channel and data type identifiers that may be included in the data, according to the allocation of the circular buffers made at system start up. Any additional functionality (such as calibration data for the RADAR system) can also be accommodated by directing the received data to the appropriate buffer in this way.

In step <NUM>, the system <NUM> may determine whether safety lines are present in the received data. As part of this determination, the system <NUM> may also determine the origin of the safety lines. If the safety lines are being inserted by software <NUM> (e.g. Microcontroller software) of the system <NUM>, then the method may proceed to step <NUM>. On the other hand, if the safety lines are being inserted by an (e.g. Mobile Industry Processor Interface Camera Serial Interface <NUM> (MIPICSI2) compliant) external device (such as a vehicle radar system or vehicle camera), the method may proceed to step <NUM>.

In step <NUM>, since it has been determined that the safety lines are being inserted by an external device, then the RX controller block <NUM> allows the same path (see the PHY-Protocol Interface (PPI) path labelled <NUM> in <FIG>) as the path for functional data reception from the physical layer <NUM> to continue to be exercised for the receipt of the safety lines. Because of the aforementioned allocation of the circular buffers in memory, the insertion of the safety lines may be implemented without requiring any of the active image data or RADAR data to be cropped. In particular, because a separate buffer is allocated to be used for storing safety line data (to the buffer(s) used for functional data lines), cropping of the active image data or RADAR data can be avoided.

In step <NUM>, since it has been determined that the safety lines are being inserted by system software, the RX controller block <NUM> chooses an alternate PHY-Protocol Interface (PPI) data path <NUM> shown in <FIG>, for the receipt of the safety lines from the software <NUM>. Again, because of the aforementioned allocation of the circular buffers in memory, the insertion of the safety lines may be implemented without requiring any of the active image data or RADAR data to be cropped. Again, because a separate buffer is allocated to be used for storing safety line data (to the buffer(s) used for functional data lines), cropping of the active image data or RADAR data can be avoided.

Following step <NUM> or <NUM>, the method may return to step <NUM>, for the allocation of subsequent functional data to the appropriate circular buffer. Subsequently, the method may proceed once more to step <NUM> or step <NUM> if it is determined in again in step <NUM> that safety lines are present in the received data.

<FIG> shows a method <NUM> of handling safety lines with support for Built In Self Test (BIST) functionality according to another embodiment of this disclosure.

In step <NUM>, the system shown in <FIG> begins to receive data. As noted previously, the data may be associated for a range of applications, but for the purposes to this embodiment, it may be assumed that the data comprises data from an external device or devices such as a vehicle RADAR system or (e.g. video) camera system. The received data are written to the appropriate circular buffer in the memory.

In step <NUM>, while the (e.g. MIPI DPHY) physical layer <NUM> is being initialised, software <NUM> or a built in Pseudo Random Number Generator (PRNG) can feed BIST data using the data path <NUM> in <FIG> (i.e. the data path that was used for the insertion of software generated safety lines in the method of <FIG>). This data may be used for the self testing of the digital circuitry of the system <NUM>.

Following the Built In Self Testing procedure in step <NUM>, initialisation of the system <NUM> including the physical layer <NUM> may be completed, and the normal operation of the system <NUM> may begin. Accordingly, the remainder of the method of <FIG> may be similar to that described above in relation to <FIG>.

In step <NUM>, data received from one or more external devices (e.g. a vehicle RADAR system or a vehicle camera) are written to the appropriate circular buffer in the memory. As part of this, the pixel processing and buffer management block <NUM> may direct the received data to the relevant buffer based on virtual channel and data type identifiers that may be included in the data, according to the allocation of the circular buffers made at system start up. Again, any additional functionality (such as calibration data for the RADAR system) can also be accommodated by directing the received data to the appropriate buffer in this way.

In step <NUM>, since it has been determined that the safety lines are being inserted by an external device, then the RX controller block <NUM> allows the same path (see the PHY-Protocol Interface (PPI) path labelled <NUM> in <FIG>) as the path for functional data reception from the physical layer <NUM> to continue to be exercised for the receipt of the safety lines. Because of the aforementioned allocation of the circular buffers in memory, the insertion of the safety lines may be implemented without requiring any of the active image data or RADAR data to be cropped.

In step <NUM>, since it has been determined that the safety lines are being inserted by system software, the RX controller block <NUM> chooses an alternate PHY-Protocol Interface (PPI) data path <NUM> shown in <FIG>, for the receipt of the safety lines from the software <NUM>. Note that this is the same path that was used in step <NUM> for feeding the BIST data to the digital circuitry of the system <NUM>. Again, because of the aforementioned allocation of the circular buffers in memory, the insertion of the safety lines may be implemented without requiring any of the active image data or RADAR data to be cropped.

The method of <FIG> can allow the system <NUM> to implement Built In Self Test (BIST) procedures in a manner that does not expressly require the provision of dedicated BIST logic. This is because the path <NUM> that is used during normal operation for the insertion of safety lines by the software <NUM> is re-used by the system for supplying BIST data from the software <NUM>. This can increase the available chip space in or more integrated circuits of the system <NUM> and reduce the overall cost of the system <NUM>.

<FIG> shows a data packet <NUM>. The packet <NUM> includes a frame start <NUM>, a frame end <NUM>, a packet header <NUM>, a checksum portion <NUM> (which may also include a filler if required for the physical layer <NUM> (e.g. under DPHY)), and a payload. The payload includes a frame <NUM> of data. The frame <NUM> may for instance comprise RADAR data or video data received from a vehicle RADAR system or external camera of the vehicle. The frame <NUM> may also include a number of lines of embedded data <NUM>, <NUM>. In particular, zero or more lines of embedded data <NUM> may be included at the start of the frame <NUM> and zero or more lines of embedded data <NUM> may be included at the end of the frame <NUM>. The embedded data <NUM>, <NUM> may for instance comprise safety data lines or test data (BIST) lines of the kind described above.

As shown by the arrow labelled <NUM> in <FIG>, the payload data in each packet must be a multiple of some predetermined number of bits (e.g. <NUM> bits) in length. Line blanking of the packet is shown at <NUM>, and frame blanking is shown by the arrow labelled <NUM>.

When a single circular buffer is used per virtual channel, the lines of embedded data <NUM>, <NUM> must be located at the start of the frame or at the end of the frame as noted above. This is because it is not possible to capture embedded data that is located in between lines of frame data <NUM>. In the data packet <NUM> of <FIG>, if embedded data were to be located in between active lines of frame data <NUM>, then the actual RADAR data or video data may be overwritten when using a single buffer per virtual channel.

<FIG> shows a data packet <NUM> according to an embodiment of this disclosure. The data packet <NUM> in <FIG> is similar in some ways to the data packet <NUM> shown in <FIG>. Accordingly, the data packet <NUM> may include a frame start <NUM>, a frame end <NUM>, a packet header <NUM>, a checksum portion <NUM> (which may also include a filler if required for the physical layer <NUM> (e.g. under DPHY)), and a payload. The payload includes a frame <NUM> of data. Again, the frame <NUM> may for instance comprise RADAR data or video data received from a vehicle RADAR system or external camera of the vehicle. As shown by the arrow labelled <NUM> in <FIG>, the payload data in each packet must be a multiple of some predetermined number of bits (e.g. <NUM> bits) in length. Line blanking of the packet is shown at <NUM>, and frame blanking is shown by the arrow labelled <NUM>.

The frame <NUM> may also include a number of lines of embedded data <NUM>, <NUM>, <NUM>, <NUM>. Again, the embedded data <NUM>, <NUM>, <NUM>, <NUM> may for instance comprise safety data lines of the kind described above.

Some (zero or more) lines of embedded data <NUM> may be included at the start of the frame <NUM> and some (zero or more) lines of embedded data <NUM> may be included at the end of the frame <NUM>. Additionally, as can be seen in <FIG>, some (zero or more) lines of embedded data <NUM>, <NUM> may be included at locations with the frame data <NUM>, i.e. neither at the start of the frame data (as per the embedded data <NUM>) nor at the end of the frame data (as per the embedded data <NUM>). Thus, in accordance with embodiments of this disclosure embedded data (e.g. lines of safety data, or test data) can be inserted between lines of functional data in the frame data <NUM>. This can be achieved by allocating more than one circular buffer to each virtual channel (i.e. a buffer for functional data and a buffer for safety line data). Maintaining separate buffers for different data types as described herein can allow the embedded data to be located anywhere in the frame, without the possibility of overwriting any data. This allocation of the circular buffers can be made at system start up as noted previously.

Claim 1:
A method (<NUM>) of acquiring data, the method comprising:
determining one or more different data types and virtual channels required for one or more applications (<NUM>);
allocating a plurality of separate circular buffers in memory according to the determined different data type(s) and virtual channel(s), in which one or more of the circular buffers are allocated to safety data lines and in which one or more of the remaining circular buffers are allocated to functional data lines (<NUM>);
storing at least one functional data line in a said circular buffer allocated to functional data lines according to a data type and virtual channel of the functional data line (<NUM>); and
storing at least one safety data line in a said circular buffer allocated to safety data lines (<NUM>), wherein the at least one safety data line is generated locally by software and is received along a different data path to a data path used for processing the at least one received functional data line and
performing a self-test routine in which test data is generated locally and received along said different data path along which the at least one safety data line is received.