A DVP-Based Bridge Architecture to Randomly Access Pixels of High-Speed Image Sensors

Abstract

A design of a novel bridge is proposed to interface digital-video-port (DVP) compatible image sensors with popular microcontrollers. Most commercially available CMOS image sensors send image data at high speed and in a row-by-row fashion. On the other hand, commercial microcontrollers run at relatively slower speed, and many embedded system applications need random access of pixel values. Moreover, commercial microcontrollers may not have sufficient internal memory to store a complete image of high resolution. The proposed bridge addresses these problems and provides an easy-to-use and compact way to interface image sensors with microcontrollers. The proposed design is verified in FPGA and later implemented using CMOS 0.18 um Artisan library cells. The design costs 4,735 gates and 0.12 mm² silicon area. The synthesis results show that the bridge can support a data rate up to 254 megasamples/sec. Its applications may include pattern recognition, robotic vision, tracking system, and medical imaging.

1. Introduction

In recent years, image sensors have increased in quality and capability and at the same time decreased in price, making them desirous to include in small electronic devices and systems. However, these image sensors are difficult to interface with most commercial microcontrollers (MCUs) as these high-speed image sensors produce data at such a high rate that cannot be processed in real time. As a consequence, most high-speed image sensors are difficult to use in low-power and low-speed embedded systems. There is no buffering provided inside the image sensors. Most MCUs have limited internal memory space and may not be able to store a complete frame unless external memory is provided. Moreover, these image sensors send image data in a row-by-row fashion; as a result, the data cannot be accessed randomly; the first row must be read prior to the second row to avoid data loss. Many image processing algorithms, such as transform coding using the Discrete Cosine Transform (DCT) and pattern recognition for robotic vision, need to access pixel values in a random access fashion. Besides, a high-speed clock must be provided to operate the image sensors properly.

In order to overcome these difficulties, researchers in the past have proposed application-specific design of image sensors with control circuitry and dedicated memory embedded on the same chip, as shown in Figure 1. Such sensors are dedicated to particular application and cannot be used for general purpose. In this paper, we present a digital-video-port (DVP) compatible bridge architecture that will "bridge" any general-purpose image sensor with the image processor as shown in Figure 1. In this work, our target is the low-speed and low-power MCU that is realized here as the image processor. The proposed bridge aims to overcome the speed gap between the commercially available image sensors and MCUs. By using the bridge hardware, the image processor can easily initialize any DVP-compatible image sensor and capture image frames. The captured pixel values are then accessed by the image processor at a random fashion through a parallel memory access interface at a desired speed for further processing. The proposed design is synthesized and tested in commercial FPGA board, where the maximum speed achieved is 248 MHz. The VLSI design using standard 0.18 um CMOS Artisan library cells is also presented. The bridge can be used in various embedded system applications including pattern recognition, robotic vision, biomedical imaging, tracking system, where random access of image pixels is required.

Figure 1

Image processor connected with (a) application-specific image sensor and (b) general-purpose image sensor via the proposed bridge.

It should be noted that the commercial high-speed image sensors may be interfaced with more advanced MCUs (such as AT91CAP7E, AT91SAM7S512 from Atmel [1]). However, these microcontrollers contain many additional features (such as six-layer advanced high-speed bus (AHB), peripheral DMA controller, USB 2.0 full-speed device, and configurable FPGA Interface) that may not be required for simple imaging applications. Besides, programming such microcontrollers and implementing the required protocols increase the design cycle time. The purpose of the proposed bridge hardware is to provide a compact, ready-made, and easy-to-use solution that enables interfacing of commercial general-purpose image sensors with simple microcontrollers that are low-cost and easy-to-program (such as 8051 [2, 3], AVR [4], and PIC [5]). Thus the bridge hardware helps to shorten the design/development cycle time and facilitates rapid system level prototyping.

2. Background

In [6–10], presented are some VLSI designs on CMOS image sensors with random access. In [11, 12], the authors have presented two different designs of a random access image sensor based on a data-address bus structure. The work in [13] presents a low-power full-custom CMOS digital pixel sensor array designed for a wireless endoscopy capsule [14]. The proposed architecture reduces the on-chip memory requirement by sharing pixel-level memory in the sensor array with the digital image processor. A dental digital radiographic (DDR) system using a high-resolution charge-coupled device (CCD) imaging sensor was developed and its performance for dental clinic imaging was evaluated in [15]. The work in [16] presents a novel smart CMOS image sensor integrating hot pixel correcting readout circuit to preserve the quality of the captured images for biomedical applications. In [17], an image sensor with an image compression feature using the DCT is presented. In [18], a CMOS image sensor has been designed to perform the front-end image decomposition in a Prediction-SPIHT image compression scheme. In [19], an image sensor unit with sensor to detect the gravity direction and a built-in image rotation algorithm is presented. The system rotates the captured image in the direction of gravity for better viewing that can be used in rescue robots. The paper in [20] discusses a range image sensor using a multispot laser projector for robotic applications. In [21], a pointing device using the motion detection algorithm and its system architecture is presented. The proposed motion detection pointing device uses just binary images of the binary CMOS image sensor (BCIS). In [22], a smart image sensor for real-time and high-resolution three-dimensional (3D) measurement to be used for sheet light projection is presented. A facial image recognition system based on 3D real-time facial imaging by using correlation image sensor is discussed in [23]. The differential geometry theory was employed to find the key points of face image. A design of an image sensor focusing on image identification by adjusting the brightness is presented in [24]. It has GPRS connectivity and can be used in vehicle surveillance system. In [25], a single-chip image sensor for mobile applications realized in a standard 0.35 um CMOS technology is presented. In [26], a solution to reduce the computational complexity of image processing by performing some low-level computations on the sensor focal plane is presented. An autonomous image sensor for real-time target detection and tracking is presented in [27]. In [28], the authors describe and analyse a novel CMOS pixel for high-speed, low-light imaging applications. An 8.3-M-pixel digital-output CMOS active pixel image sensor (APS) for ultra-definition TV (UDTV) application is discussed in [29]. In [30], a hardware accelerator for image reconstruction in digital holographic imaging is presented that focuses to maximize the computational efficiency and minimize the memory transfer overhead to the external SDRAM.

There are some commercial image sensors such as MT9V011 from Aptina [31] and OVM7690 from OmniVision [32] that support partial access of image segments known as "windowing". By configuring the control resisters, the top-left and bottom-right corners of the desired area can be specified. The image sensor then captures and sends an image of the specified rectangle. However, it is not possible to access (and capture) other segments of the same frame with this feature which is required in several image coding applications such as transform coding. There are two more disadvantages of such approach: firstly, the internal control registers need to be reconfigured every time an image capture request is sent, which is an extra overhead; secondly, because of the time taken for this reconfiguration, the sensor will capture a frame that is different in the time instant. Besides, the "windowing" is limited to rectangles only; the image data cannot be accessed in any other shapes.

In summary, the works mentioned above discuss different designs of image sensors targeted to specific application; however, they are not available for general-purpose use. In this paper, we present a novel concept—the design of a bridge architecture that connects the commercial MCUs to any commercial DVP-based general-purpose image sensors. The bridge needs to be configured once with a set of addresses (provided by the manufacture as found in the datasheet) in order to communicate with the image sensor, which makes the design universal and for general-purpose use.

3. Design Objectives

Considering the application types (i.e., robotics vision, imaging, video, etc.) and availability of commercial microcontrollers (MCUs), in this work, we have set the following design objectives to facilitate the interfacing of high-speed image sensors with low-performance MCU.

(i)The bridge hardware should operate at very high speed (over 200 MHz) so that the image pixels can be accessed in real time through high-speed image sensors. As a result, the MCUs (or image processor) using the bridge need not be high performance and high speed.

(ii)The bridge should contain sufficient memory space to store image frames of different resolutions, such as CIF, QVGA, VGA, full HD, and UHDV. Thus, an MCU with limited on-chip memory may be able to access image pixels from the buffer memory of the bridge at the desired speed. Moreover, because of the memory buffer, any image segments of the same frame can be accessed without having to reconfigure the image sensor, which is required in many video coding applications. An example of such application is the Discrete Cosine Transform-based image coding, where several blocks of image segments of the same frame are required.

(iii)The bridge should provide an efficient way to access the image pixels randomly. A more convenient way is to access the 2D pixel arrays using parallel interfacing with row and column positions. This will be a significant improvement over the designs with typical data-address structure [11, 12].

(iv)The usage of the bridge should be robust. As a result, it should provide efficient and easy ways to access image pixels in virtually any shapes, such as rectangles, circles, oval, and points. This facilitates fully random access in any random shapes.

(v)Commercial image sensors from different vendors have unique device parameters along with internal control registers for proper configuration (such as, to configure frame size, colour, and sleep mode). The bridge should be able to communicate with most available image sensors. As a result, the design should be universal so that it can be configured at the beginning with the proper set of parameters for a particular image sensor.

(vi)Commercial image sensors use I2C protocol and DVP interfacing. Hence, the desired bridge hardware must have I2C protocol already configured as well as support DVP interfacing.

(vii)Most commercial image sensors require high-speed external clock for its operation. It is desirable that the bridge supplies that clock so that the clock can be efficiently controlled during operation (i.e., full clock rate during regular operation, reduced rate during sleep or inactivity, etc.). At the same time, the bridge should be able to detect any inactivity and automatically enable the sleep mode of the image sensor—this will result in power savings.

4. The DVP Interface

Most leading commercial CMOS image sensors, both standard-definition (SD) and high-definition (HD), send image data using a common standard interface, known as the DVP interface. The common I/O pins of a typical CMOS image sensor are shown in Figure 2.

Figure 2

DVP interface pins of an image sensor.

The VD (or VSYNC) and HD (or HSYNC) pins indicate the end of frame and end of row, respectively. Pixel data bytes are available for sampling at the DOUT(0 : 7) bus at the positive edge of the DCLK signal. The EXTCLK is the clock input for the image sensor. The frequency of DCLK is half or quarter of the frequency of EXTCLK depending on the configuration of the image sensor. The initialization and configuration of the image sensor is done by the 2-wire (SCL and SDA) I2C protocol. In the context of image sensor, it is often called as Serial Camera Control Bus (SCCB) interface [32]. The frame size, colour, sleep mode, and wake up mode can be controlled by sending I2C commands to the image sensor. The RESET is an active low reset signal for the image sensor. Some image sensors have a pin (PWDN) to control the active-sleep mode. Some HD image sensors may contain additional control pins (as shown as dotted line in Figure 2), which are used in special modes; however, these extra pins may be tied to V_DD or GND or left unconnected in normal operation.

4.1. Standard-Definition (SD) CMOS Image Sensors

The DVP interface is widely used in most commercially available SD CMOS image sensors, such as TCM8230MD from Toshiba [33], OVM7690 from OmniVision [32], MT9V011 from Aptina [31], LM9618 from National [34], KAC-9630 from Kodak [35], and PO6030K from Pixelplus [36].

4.2. High-Definition (HD) CMOS Image Sensors

Most native HD (720p and 1080p) image sensors such as OV10131 from OmniVision [32] and MT9P401 from Aptina [31] use the DVP interface. Some higher-resolution HD image sensors such as OV9810 [32] use an additional interface, called the mobile industry processor interface (MIPI) along with the typical DVP interface. The data output bus DOUT is generally wider than 8 bits in these HD image sensors.

5. The iBRIDGE Architecture

The proposed bridge (referred as iBRIDGE from now) is placed in between the image sensor and the image processor or the microcontroller. Figure 3 shows the interfacing of the iBRIDGE and its internal blocks. The pins on the left hand side are to be connected with an image sensor while those on the right hand side are to be connected to the image processor (or the MCU). There are two types of signals coming from the Image Processor Interface: configuration signals (CfgWr, Init, ReqFrame, and RST) and frame access signals (Data, Col, Row, etc.). The configuration signals are asynchronous in nature whereas the frame access signals depend on the speed of the image processor requesting the "access"; hence these incoming signals do not need to be synchronized with iBRIDGE's internal clock.

Figure 3

Block diagram of the iBRIDGE.

5.1. Configuring the iBRIDGE

The operation starts by first configuring the iBRIDGE's internal registers with a set of predefined addresses so that it can properly communicate with the image sensor. Image sensors of different manufactures have different device ID (or slave address) which is used for such communication using the I2C protocol [37]. The image sensors also have internal control registers used to configure the functionality, such as frame size, colour, and sleep mode, and so forth. These registers are controlled by I2C protocol. The register mapping is also different for different manufacturers; so, the iBRIDGE needs to be configured as well with the proper configuration mapping of the image sensor (found on the datasheet). Table 1 shows the configuration registers implemented inside the iBRIDGE that are required in normal operation. The table may be extended to accommodate additional special features. The content of these registers can be modified by two multiplexed input ports: CfgAdr(3 : 0) and CfgData(7 : 0). In order to write to a register of iBRIDGE, the register address is placed on CfgAdr(3 : 0) bus, the data on CfgData(7 : 0) bus, and the CfgWr pin is asserted high. Thus, the iBRIDGE can be configured for any DVP-compatible image sensor which makes it universal.

Table 1 Configuration register mapping.

5.2. Operation of the iBRIDGE

An external crystal needs to be connected with the iBRIDGE to generate the necessary clock signals. The frequency of the crystal should be the required EXTCLK frequency of the image sensor. In order to capture one frame, at first image processor asserts the RST pin to high and then makes it low. The image capturing process can be started by asserting the Init pin to high. The image sensor will set the frame size and colour according to the information provided in the configuration registers and then image data will began to store in the bridge's memory block. During the image capturing process, Data(9 : 0) goes to high-impedance state. As soon as the image capturing process is completed, the FrameReceived pin goes from low to high. At this time, the image sensor is taken to sleep mode to save power. The Col(9 : 0), Row(8 : 0), and ByteIndex(1 : 0) buses are then used by the image processor to access any pixel of the frame from iBRIDGE's RAM at the desired speed and in a random access fashion. After placing the column and row value on the Col(9 : 0) and Row(8 : 0) bus, the data (pixel value) of that particular location of the frame appears on the Data(9 : 0) bus after a certain time delay, called , which is given by (1). Note that, for an SD image sensor, only the lower 8 bits (Data(7 : 0)) are used:

(1)

where is the time required to calculate the physical memory address from column and row positions and is the access time of the memory. The typical value of is 35 nanosecs for the current design constraints. If the image has more than one bytes-per-pixel (such as RGB888, RGB565, and YUV422), then the other consecutive bytes can be accessed by placing the offset on the ByteIndex(1 : 0) bus. After the desired pixel values are read, the process of capturing the next frame with the same configuration can be repeated by asserting ReqFrame pin from low to high. Most image sensors send some invalid blank bytes and invalid rows while capturing a frame. The time needed to capture a frame, , and the maximum frame-rate, , can be calculated from the following:

(2)

where

(3)

(4)

where is the time required for the image sensor to wake up from sleep mode, is the time required to store a complete frame in memory from the image sensor, is the required number of bits that need to be sent to write in the image sensor's internal registers, is the frequency of the SCL pin of the I2C interface, is the number of blank bytes sent by the image sensor at the beginning of a new frame, is the number of pixel bytes sent by the image sensor for one row, is the number of blank bytes sent by the image sensor for one row, is the number of rows sent by the image sensor for one frame, and n is a constant for dividing the frequency of DCLK.

The maximum FPS achieved by an image processor or microcontroller can be calculated using the following:

(5)

where is the time needed to access the required pixel bytes from the iBRIDGE's memory, is the time required for implementing any desired image processing algorithm by the image processor, is the number of random pixels that need to be accessed (in the worst case, , where and are image width and height, namely), is the number of bytes per pixel, is the number of clock cycle required by the image processor to read a byte from iBRIDGE's memory, and is the frequency of the image processor's clock.

Table 2 shows the above mentioned parameters for a Toshiba image sensor [33]. Similar table can be extracted for other image sensors from the respective datasheets. The timing diagram of the overall operation of the iBRIDGE is shown in Figure 4 (here, microseconds to 2.5 microseconds, i.e., equal to at least one I2C_CLK).

Table 2 Data and blank bytes sent by Toshiba image sensor.

Figure 4

Operational timing diagram of the iBRIDGE.

The iBRIDGE is also compatible with the HD image sensors that use the parallel DVP interface. The procedure to configure the iBRIDGE is similar to that of the SD sensors as discussed above; however, a full-precision Data(9:0) is used to access the pixel data. The following sections describe briefly the internal architecture of the iBRIDGE.

5.3. Sensor Control

This block is used to configure and control different modes of the image sensor. After the Init signal is received, it generates the RESET signal for the image sensor and then waits for 2000EXTCLK cycle, which is required for the image sensor to accept I2C commands for the first time. After the wait period, it sends commands to the image sensor using the I2C interface block to configure it to the required frame size and colour. The command frames are made by taking the information provided in the configuration register as shown in Table 1. After a wake up command is sent, the image sensor starts to produce image data. After a complete frame is received in the bridge's memory, the controller sends a sleep mode command to the sensor to reduce the power consumption. When a ReqFrame signal is received, it sends the wake up command and the next image data starts to store in the memory. The process is implemented in a finite state machine (FSM) structure as shown in Figure 5.

Figure 5

FSM in the sensor control block.

5.4. I2C Interface

This module is used to generate the I2C protocol bits in single master mode [37]. This protocol allows communication of data between I2C devices over two wires. It sends information serially using one line for data (SDA) and one for clock (SCL). For our application, the iBRIDGE acts as master and the image sensor acts as the slave device. Only the required subset of the I2C protocol is implemented to reduce the overall logic usage.

5.5. Clock Generator

The Clock Generator generates the clock signal at the EXTCLK pin, which must be fed to the image sensor. A parallel resonant crystal oscillator can be implemented to generate the clock [38]. An 800 KHz clock signal, called the I2C_CLK, is also required for the I2C Interface and the Sensor Control modules. The clock signal can is generated by dividing the EXTCLK using a mod-n counter. The I2C Interface module generates clock at SCL pin having half of the I2C_CLK frequency. A simplified diagram of this block is shown in Figure 6.

Figure 6

Clock generator module.

5.6. Memory Addressing and Control

This module manages the data pins for the image sensor interface and generates address and control signals for the Memory block of the iBRIDGE. It implements a 19-bit up counter and is connected with the address bus of the memory. The DOUT(7:0) is directly connected with the data bus of the memory. When VD and HD are both high, valid image data comes at the DOUT(7:0) bus. In the valid data state, at each negative edge event of DCLK, the address up-counter is incremented. At each positive edge event of DCLK, WR' signal for the memory is generated. After a complete frame is received, the address up-counter is cleared and FrameReceived signal is asserted high. The simplified diagram of the module is shown in Figure 7.

Figure 7

Memory addressing and control module.

5.7. Random Access Memory (RAM)

A single port random access memory module is used to store a frame. Depending upon the application's requirement, a different memory size can be chosen. In the iBRIDGE, one multiplexer for address bus and two tristate buffer for data-bus are used for proper writing in and reading from the memory.

5.8. Read Address Generator

The Read Address Generator takes the Col (9 : 0), Row (8 : 0) andByteIndex (1 : 0) as inputs and generates the physical memory address from column and row position of the frame. To access a pixel value at column where, and at row R where , the physical memory address is calculated using (6). Here, is the image width and is the image height. Bytes_per_pixel is taken from the configuration register as shown in Table 1. If the Bytes_per_pixel is more than one, the other consecutive bytes can be accessed by placing the offset on ByteIndex bus. Figure 8 shows the internal structure of this block:

(6)

Figure 8

Read address generator module.

6. Performance Evaluation

The proposed iBRIDGE design has been modelled in VHDL and simulated for functional verification. As a proof of concept, as well as to evaluate the performance of the design in real-world hardware, the iBRIDGE has been synthesized in Altera DE2 board's FPGA [39]. Several FPGA pins are connected with different on-board components, such as 512 KB of SRAM, clock generators, and 40 general purpose input/output (GPIO) ports. The internal modules of the iBRIDGE, except the RAM, have been synthesized onto the Cyclone II FPGA. It occupies 433 logic elements (LE), 270 registers, and 6 embedded 9-bit multiplier elements. The iBRIDGE's RAM module is connected with the 512 KB SRAM of the DE2 board. The on-board clock generator is used as the clock input for the bridge. The image sensor interface and the image processor interface of iBRIDGE are assigned with different GPIO ports. A commercial image sensor (TCM8230MD) from Toshiba has been used as the image sensor interface where a commercial MCU (ATmega644) from Atmel serves as the image processor interface. The MCU is then connected to a personal computer (PC) using COM port. A level converter IC (MAX232) was used to generate the appropriate logic levels to communicate with the PC. A software is written in MS Visual Basic to display the captured images. The block diagram of the overall experimental setup is shown in Figure 9. The actual setup is shown in Figure 10. In this setup, the microcontroller is set to run at 1 MHz—it shows that the image pixels can still be fully and randomly accessed while running at such a slower rate.

Figure 9

Block diagram of the experimental setup for verification.

Figure 10

Photograph of the actual experimental setup for verification.

The graphic user interface (GUI) is shown in Figure 11. Here, the user may choose point, rectangle, circle, or full image as the desired region-of-interest. For instance, when the "rectangle" is chosen, the user randomly chooses the top-left and bottom-right coordinates of an image segment using the mouse pointer. The software then sends each column () and row () positions inside the chosen rectangle to the MCU through the PC's COM port. The MCU then places the position values at the row and column buses and reads the corresponding pixel data through the data bus.

Figure 11

A screen-shot of the GUI.

Figures 12(a) and 12(b)–12(d) show a full image and randomly accessed images, respectively, captured by the MCU using the proposed iBRIDGE. It is also possible to access the pixel data in other shapes such as ellipse, pentagon, and hexagon. In that case, the GUI needs to be updated with the corresponding geometric equations. As shown in Figure 12, the image pixel thus can be accessed in a random fashion using the iBRIDGE. The demonstration is shown here using the setup shown in Figure 10 and a software GUI; however, similar access is possible in real time using a hardware-coded MCU at the desired speed, which make the iBRIDGE very useful in embedded system applications such as, pattern recognition, robotic vision, bio-medical imaging, image processing, and tracking system.

Figure 12

Captured image: (a) full image; (b)–(d) randomly accessed pixel image using the iBRIDGE.

The iBRIDGE hardware is synthesized using Synopsys's Synplify Pro [40] for different Xilinx FPGA devices. The synthesis results are shown in Table 3. It should be carefully noted that these results give us a preassessment of the resource utilization of the iBRIDGE chip when implemented in FPGA. The design is however intended to be used in an ASIC platform.

Table 3 Synthesis results on Xlinx FPGA.

The iBRIDGE is later implemented using Artisan 0.18 um CMOS technology. The synthesis results are shown in Table 4. A crystal oscillator pad is placed inside the chip to connect an external crystal. The chip layout (without the memory block) is shown in Figure 13. The design consumes 13.8 mW of power when running at 10 MHz with a 3.0 V supply.

Table 4 Synthesis results in ASIC.

Figure 13

Chip layout of the iBRIDGE core.

In order to show the significance of the proposed iBRIDGE, we present two sets of comparisons. In Table 5, we compare the synthesized hardware data of the iBRIDGE with other image sensors. The first set of sensors are "application-specific" and do not support random access of the image pixels. The second sets of sensors are of general type and support random access, but the image pixel arrays are dedicated with fixed resolution. While comparing with other sensors, we need to remember that the iBRIDGE does not contain any dedicated image sensor, rather facilitates the interfacing of image sensor with image processor, and enables random access. In that sense, the proposed iBRIDGE can be connected to any "general-purpose" DVP-based image sensors of "any resolutions"—this is a key advantage. As an example, in Table 5, we also present the result when the iBRIDGE is interfaced with an advanced OmniVision HD image sensor (OV2710). With such setup, the performance of the iBRIDGE is noticeably better compared to all sensors in terms of pixel array, silicon area, data rate, and power consumption. Note that, in Table 5, the die area (i.e., core area plus the I/O pads) is used for the iBRIDGE.

Table 5 Hardware comparisons with other sensors.

In Table 6, we present the performance of the iBRIDGE when interfaced with both SD (TCM8230MD) and HD (OV2710) image sensors. It can be seen that, with a very little increase in hardware (i.e., 1.96 mm²) and power consumption (i.e., 13.8 mW), any DVP-compatible commercial image sensor can be converted to a high-speed randomly accessible image sensor. Given the data rate, that is 254 megasamples/sec and the equations in Section 4.1, the iBRIDGE supports 333 fps for the VGA () and 56 fps for the full HD () resolution. It is worth noticing from Tables 5 and 6 that this data rate supported by the iBRIDGE is much higher than other image sensors for same frame resolution.

Table 6 Performance advantage of iBridge with commercial image sensors.

To show the advantages of the proposed iBRIDGE, in Table 7 we compare the performance of a low-performance MCU interfaced with iBRIDGE with high-performance MCUs. The comparison is based on two scenarios: one where a high-speed image sensor is connected with a high-performance MCU, and another where the same sensor is connected with a low-performance MCU via the iBRIDGE. The scenarios are shown in Figure 14. It should be noted that, as stated in Section 1, the low-performance MCU cannot be directly interfaced with high-speed image sensors. From Table 7, it can be seen that the iBRIDGE enables simple and quick interfacing of low-performance MCU with high-speed sensors. It also helps to shorten the design/development cycle time and facilitates rapid system level prototyping. Thus the design objectives presented in Section 3 are fully met.

Table 7 Performance advantage of iBRIDGE with high-performance MCU.

Figure 14

Interfacing with image sensor: (a) without iBRIDGE and (b) with iBRIDGE.

7. Conclusion

In this work, the design of a bridge architecture, named as iBRIDGE, is proposed to overcome the speed gap between commercially available CMOS image sensors and microcontrollers. The iBRIDGE can be configured to work with any DVP-based SD and/or HD image sensor. By using the proposed bridge, a slow and low-power microcontroller (or image processor) with little memory capacity can communicate with high-speed image sensors to capture images of large size. The pixel data can also be accessed in a random access fashion through a parallel memory access interface at a desired speed. The control and status registers provide a comprehensive control of the image sensor. The I2C communication protocol is built into the iBRIDGE core. The design is power-efficient as the iBRIDGE forces the image sensor to sleep mode when in data-access mode. An integrated clock generator provides the necessary clock signals eliminating the need for external clock source. When implemented using CMOS 0.18 um Artisan library cells, the design costs 4,735 gates and 0.12 mm² silicon area. The synthesis results show that the iBRIDGE supports a data rate up to 254 MHz and suitable for rapid prototyping in different high-speed and low-power embedded system applications.