[GSoC Weekly Overview]: Progress & Divergence!

As the title says, this week witnessed some progress on the project and also some divergence. Actually, the divergence was related to getting the test apparatus ready for capturing VGA and confirming that it is correctly captured. A slight detour, but necessary one.

HSYNC & Pixel Clock Detection

This was a minor part, actually left from previous week. I was able to correctly get the HSYNC and Pixel Clock from AD9984A IC with a 1024x768@60Hz test VGA signal connected to it. I tested the HSYNC using the same method as with VSYNC here. And, for Pixel Clock, I used a large clock divider counter(29-bit) so that its output signal will have a large time period (of ~8.2 seconds) and measured it using a stopwatch, taking different observations and finding the mean value. The value came very close to expected.

Preparing the test-setup for VGA Capture

As I had mentioned in my previous weekly overview post, there are two methods for testing the VGA capture.
  • One was to capture the VGA signal and output it to HDMI/DVI directly to see if VGA is getting captured correctly.
  • Second method is to directly integrate the capture code into HDMI2USB code and test directly over USB.

Selecting one option from these was a tough decision. Selecting the first one meant first getting a working HDMI code setup and hence a slight divergence from the project. Whereas, selecting the second option meant slightly high risks, even though it was lucrative since a working second option would have greatly propelled the project speed. After some thinking, I decided to go for the first option, ie, testing the capture on HDMI first then, integrating it thereafter on HDMI2USB.

I looked for various available DVI/HDMI codes and found some really good ones. But, either most of the codes didn’t utilize the SERDES & TMDS signalling available on Spartan 6 or were too complex for my purpose and also required quite a few changes to them. The one I found best for my purpose was the Xilinx’s DVI Application Note and the code. It had the added benefit of Atlys as the test hardware. So, I decided to go for it.

The Xilinx’s DVI Application Note’s code is made for testing various resolution mode namely VGA, SVGA, XGA, HDTV720P and SXGA. But, I needed only XGA for my test code. So, I had to remove most of the extraneous codes from it and also change the SPI configured DCM_CLKGEN to static configuration since I needed only a fixed clock instead of different clock for different resolutions.

Porting the code didn’t take much time but it refused to work for 6-7 times consecutively, even after me removing errors one after another. Thankfully, I finally got the stripped down DVI code working (here).

Now, the first next task for me is to test the VGA capture on the HDMI and see if its getting captured correctly.

Upcoming Week:

The first job right tomorrow would be to test the VGA capture on HDMI. Then, the next actions would depend on this test’s results. If the capture is good, or if there is even a slight hint of capture working then my next target would be to get the frame displayed fully on the HDMI. The color and brightness+contrast can be ignored for time-being since they would have to be optimized using I2C by setting the relevant gain and offset registers. If frames are getting captured then it would be a very large milestone for the project.
But, if the test results are not good or a failure, I’ll have to get back to debugging the capture code and the I2C initialization to see if there was any error in that.
So, good test results would mean, next week I’ll be working on integrating the capture code to HDMI2USB and also getting back to the I2C VHDL cores. And, a bad test result would mean the upcoming week would be spent on debugging the codes.

Posted in , . Bookmark the permalink. RSS feed for this post.

Leave a Reply

Search

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by LiteThemes.com.