Finally, after weeks of working on the demosaic core on software simulation, the real hardware implementation starts! The week went with the couple of frustrations on debugging the Xilinx PlanAhead tool, and the excitement on implementation of demosaic core on FPGA. 😆 😆 😆

Using Zedboard to Test the Core

This is the first time I use an FPGA, and it came across to be the powerful Zedboard. Although I had some hard time learning to use it at first, but later I found that the Zedboard is really impressing. For the debugging of the Zedboard, I wrote about my experience on another blog here.

The biggest challenge to use the Zedboard is to figure out how to test the demosaic core on it. After studying about the Zedboard tutorial, I figured out to generate the clock using the Zedboard Cortex-A9 processor, which is using C code. Just like interfacing with microcontroller/microprocessor, I port the input/output from the demosaic core from/to the Cortex-A9 processor, and to monitor it on the computer using UART. The generation of the clock is triggered by pressing a button on the keyboard, and toggle signal is sent to the demosaic core clock input. Then, the processor should be polling the output from the core, and display it to the computer using UART.

The debugging is awfully difficult initially, because I have no idea whether the core is working fine. I started out with instantiating only the timing signals, and surprisingly the ADC output that had been generated was successful! Later, I instantiate all the demosaic core, and test out the output of the R,G,B ports. It was so exciting when I saw that the RGB output is exactly the same as the Icarus Verilog simulation, but with some bug on the control signal. At this point, I knew that at least the demosaic core calculation and selection of interpolation method was working fine.

Debug the Circuitry on FPGA

This could be the biggest mistake that I ever made during the design, in which I had focused on the functionality of the circuitry and ignored the pipelining that should have been made, and resulting in the X (don’t care) result on the demosaic core. In the FPGA implementation, the X signal could really result in 1 or 0 (randomly), and resulting in the malfunction of the circuitry. Thus, the design of the circuitry must be taken care of for all, without any X signal in between, to confirm the functionality of circuit all the time.

Besides, I also found that the contents of the BRAM could not be reset. The reset signal to be asserted to the BRAM, only assures that the output of the BRAM on the reset will be zero, but it does not actually write into the BRAM. The implementation of the design into FPGA really open my eyes wide, experiencing the real chip design.

After I had solved for the X signal issue, I have tested the RGGB pattern on the demosaic core, and the result is exactly the same as the Icarus Verilog simulator! Unfortunately, I could not show the hardware result here yet, but the image below shows the input/output of the demosaic core, which is simulated by the Icarus Verilog simulator.

DemosaicResult

The demosaic core has 2 lines and 10 cycles latency, which can be showed by above. The ADC_out is the input to the demosaic core, and after 2 lines and 10 cycles of clock latency, the demosaicked output is R,G and B, which has 20,78 and 60 respectively. The example is using on the first pixel (R) of RGGB pattern, and therefore the ADC_out value has the same value as the Red pixel. The blue and red pixel values are the interpolated result.

Instantiate the Core on PlanAhead

One thing that I found weird about the Xilinx PlanAhead tool, is when I try to instantiate a 8-bit input/output port. The PlanAhead tool treat the component[7:0] as an array, getting only the component[7] value to be the input or output. This result in getting only a single-bit information instead of 8-bit information. Thus, the proper way of instantiating the core in PlanAhead is as folllowing:

.component ( component ) , although the component is 8-bit width long. wire [7:0] component;

Alternative to Test the Demosaic Core

To further test on the demosaic core, I have also thought of using the SD card, reading a Bayer image from an SD card, process it through the demosaic core, and write it back into the SD card. The result of the image should be a demosaicked image with full RGB colours.

Next week, I should be able to show the comparison of the hardware and software implementation of the demosaic core.

 


0 Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.