Archive for June 2014

[GSoC Daily Log]: Issues keep coming up! (another this time)

Sunday, 29th June 2014:

  1. Okay, now it seems my previous success was only short lived. Please read on.
  2. I find that there are two types of flickering going on here. Previously I hadn’t thought them to be occurring due to different reasons. I assumed the flickering due to single issue. But, now it seems there are 2 major( and 1 or more minor) reasons of flickering:
    1. There is a auto-offset feature in AD9984A which updates the offset for each channel’s PGA (Programmable Gain Amplifier). We can set the update frequency for auto-update feature. Datasheet recommends (Table 6) a value of 0b10 for update every 192 clamps. But, This value and every less ones (0b00, 0b01) give severe flickering. Setting this value to 0b11 (3 VSYNCs) removes almost all flickering (As in my previous post). This flickering is not FPGA or clock induced flickering. Instead, this is due to AD9984A and present in the RGB data, not in the clocks or syncs.
    2. The Big Relief in my previous post was actually short lived! :( During that post, I had tried the test with my another FPGA Board (Saturn) acting as a VGA source and generating alternating colored bars, for capturing. I have been using this board for all my tests until now. Using the FPGA as VGA source, I reduced the flickering considerably. But, now with that success, I decided to try with production environment, aka, using the PC’s output for capturing. To my horror, there was another kind of flickering, with my TV blanking off intermittently, suggesting this flickering was more of due to clock issues. This flickering, as opposed to previous one, is FPGA induced due to incorrect clock or syncs
    3. So, now I have another issue, VGA capture from my FPGA (running same code as Jahanzeb’s Test Pattern Generator, but with my patch for dynamic color bars) is working very good (90-95% great) but capture from my PC makes my TV screen go blank intermittently.
    4. I don’t have access to any oscilloscope as of now (and urgently needed to see what's going on inside the wires). I’m thinking of either buying a cheap, low-cost Rigol one, once the GSoC mid-term payment shows up in account or try to get access to one from college, although most probably they won’t let me take it to my home. Lets see how this pans out. Its also that even the cheapest DSOs are priced almost twice or thrice in India compared to US prices. Sigh! :(
  3. Today I also tried different AD9984A register settings (see i2c folder), since I found the reason of first type of flickering to be Auto-Offset Update frequency. So, I thought maybe trying different registers  would also help.
  4. Tried to reduce flickering from PC’s output capture. Every type of tests, namely Oversampling (at 4x), PLL filter, Vsync filter, Hsync filter, sync processor filter, and even raw HSYNC were unable to reduce this flickering (more appropriately screen blanking intermittently)

Posted in , | Leave a comment

[GSoC Daily Log]: Sigh of relief!

Saturday, 28th June 2014:

  • Marked improvement! Around 90-95% flickering and screen-blanking gone! HURRAY! More details and video coming when I wake up. Its 6:30 in the morning here! Working all night is really exhausting, but one does get a nice, peaceful and cool environment! :D
  • Finally, a big sigh of relief! Although, remaining 5% flickering have to be removed

Posted in , | Leave a comment

[GSoC Daily Log]: Cleanup

Friday, 27th June 2014:

  • Cleanup up code quite significantly and directory structure
  • Documented problems faced here.

Posted in , | Leave a comment

[GSoC Daily Log]: Oversampling & some (failed) adventure!

Thursday, 26th June 2014:

  • Once again tried oversampling with a 4x clock of  pixel clock. Good results this time. Had previously tried with 10x clock. It doesn’t work but 4x clock works better.
  • Oversampling resulted in comparatively better capture.
  • Identified HSYNC (ie HSOUT) as the main culprit which results in flickering  and screen going blank.
  • Tried integrating the current into HDMI2USB. Integrating although was successful, the output on screen as well as USB(mplayer) was garbled in VGA mode, but normal in other modes.  Sometimes v4l2 showed timeout. So, I guess,  I have to perfect the capturing first before trying it with HDMI2USB.

Posted in , | Leave a comment

[GSoC Daily Log]: Drivers and PLL

Wednesday, 25th June 2014:

  • Okay, so the cdc_acm driver mentioned in the previous snippet was only reading the data. Was unable to transmit them
  • Tried once again the Vizzini driver. Worked this time (both transmit and receive). Using Ajith’ sample code.
  • Tried to stabilize HSYNC and VSYNC counter values by enabling VSYNC Filter and PLL Filter(reg 0x20 Bit 2 and reg 0x14 Bit 2, here, Green highlighted are the changes)  inside the AD9984A, some observations:
    • It was able to stabilize CounterY at the end of frame to perfect 806 value.
    • It was able to stabilize CounterX value the at end of horizontal line scan to perfect 1343 value.
    • It was unable to stabilize CounterX value at the end of frame. Values vary quite much still.

Posted in , | Leave a comment

[GSoC Daily Log]: Exar drivers

Tuesday, 24th June 2014:

  • Tried Ajith’s UART code on linux.
  • Shenki’s updated driver also didn’t work for me
  • Atlast, since the Vizzini module was blocking my BeagleboneBlack’s USB-Serial from funtioning, I removed it and to my surprise also found the Exar one detected as CDC_ACM device at ttyACM1 and BBB at ttyACM0. Both are working fine
  • Searched for daisy chain enabled SPI EEPROM devices. Couldn’t find them. Updated the doc with additional details regarding this.

Posted in , | Leave a comment

[GSoC Weekly Overview]: First major milestones!

This week started exciting! First of all I couldn’t get any capture in my first attempt. And, if you see the reason for that, you will start laughing! I flipped the code such that when the video *should* be displayed it is not displayed, instead it is ‘displayed’ when it shouldn’t and when one cannot see it. Big #Facepalm

Messy Capture!

The first glimpse of anything sane or anything colorful right at the start of week instilled excitement. Although it was not as expected being quite messed up, it did mean that the AD9984A (my VGA capturing IC! remember?) was working fine. Also, from the captured output shown on HDMI I could think of few possible reasons for the message capture output. I’ve a recorded a sample for the benefit of blog readers :D

From the video, anyone with some knowledge of Digital Electronics can figure out that issue is mostly related to sync/clock. So my next target was to correct this.

Sane Output!

After 1.5 days of tinkering around with code, I got first output which closely resembled the VGA output. Remember how previously talked about that Blue and Red signals were interchanged in the PCB? Well, that showed up now, with Yellow being rendered as Cyan! Fixing this was simple one line code modification. Now, this was a time to rejoice! Hurray!

Once the jubilation settled, it was time to look closely. There was quite a large amount of flickering in the output. The default culprits I assumed once again to be an unstable clock and irregular HSYNCs & VSYNCs.  Also, I kept the possibility of a bug in my code open.

Once again for the readers, I have video captures of the results.

Period of frustration

Initially I thought that it would be easy to remove the flickering but it was not. I rewrote the whole code more than 20 times with different capture mechanisms thinking maybe the fault was with the code, but the output refused to budge. In some cases, flickering would reduce, in some case they would increase greatly. Even oversampling code didn’t work at all(no output). It was then that I decided to first check the clock in more detail. Driving the HDMI code with Jahanzeb’s test pattern with only pixel clock sourced from AD9984A gave at least one concrete evidence that Pixel Clock was not very stable. Maybe due to high frequency and long route from AD9984A to FPGA though the VHDCI connector? There were no flickering but the test image was shaking slightly.
Probing the AD9984A status registers revealed that number of HSYNCs per VSYNC were getting detected correctly.
Once again I thought of more tests (one test was even designed during a dream, one can imagine how frustrated I was!). Alas, all of them failed

Ray of hope!

I remembered my mentor Tim telling me about Ajit (a fellow GSoCer, his blog) having written a code for using the Atlys’ onboard USB-Serial interface. I pinged Ajit on IRC and he instantly replied. Incidentally I suppose, we happen to enjoy working all-night only :D Even Ayush(his blog) enjoys working all-night! Back to topic, Ajit replied quickly my doubts and told me to try his code on Windows (due to Exar’s old linux drivers not functioning properly). I switched to windows and used his code from here in a standalone project. Once working correctly, I added the code to my VGA capture project and modified my code to output debug value over UART. And, voila! I started getting some useful debug information from the board in real-time! Now, instead of firing in darkness, I could do systematic debugging. Head over to my blog snippet on some results from first run of UART debugging enabled code.

Upcoming Week:

I’ve some conflicting targets for upcoming week. On one hand I’m thinking of getting the capture right *perfectly* then proceeding to integration with current HDMI2USB code. On the other hand, I’m thinking of first integrating the code with current HDMI2USB code and then remove the flickering. My reason for even considering the second option is that, I think since the USB streaming happens at very slow rate 15-30fps max. compared to the HDMI output @60fps, the flickering would not be a major bottleneck. This would also make the project closer to the intended target of integrating with HDMI2USB.
But, other argument is that getting the capture perfect should be first priority, and then integrating with HDMI2USB code. I’ll have to discuss this with my mentor in this regard.

Posted in , | Leave a comment

[GSoC Daily Log]: Cleanup, reorder and resolving issues!

Monday, 23rd June 2014:

  • Added documentation for auto-detection
  • Resolved issues in previous I2C documents and Github cleanup and other issues
  • Created the Requirements document for Rev02 of VGA Capture PCB. Almost all issues found up till now added to the requirements doc
  • Weekly Overview
  • Still resolving lots of Doc and Github Repo Issues

Posted in , | Leave a comment

[GSoC Daily Log]: Random Sunday

Sunday, 22nd June 2014:

  • Went to relatives’ house for the day.
  • Upon returning, laptop crashed with error “Kernel Data inpage error”. This had been a common occurrence since I upgraded the HDD just a month back. Ran chkdsk on the entire disk. Took ~6 hours but it found 4 bad clusters in the system partition itself! :o
  • Had a discussion with Ayush on auto-detection feature, EEPROM selection, wiring etc.

Posted in , | Leave a comment

[GSoC Daily Log]: Trails & errors - Part 2

Saturday, 21st June 2014:

  • Tried many different options ofr reducing flickering including porting the code from here Result: Unsuccessful in removing flickering. Same result as before
  • Tried many other hit and trials, all others also resulted in same or worse result. No better result.
  • Finally, fed up after much blind trials, decided on getting a good debug setup.
  • Tried Ajith’s UART code for Atlys. From here. Worked successfully on standalone project.
  • Added the previous UART code to the project. Clocks had to be modified and core-gen removed.
  • Successfully getting UART debug output from the project. Few Observations:
    • At the end of frame, CounterY should be 805 ideally. It fluctuates b/w 805 and 806 with mostly at 806.
    • At the end of frame, CounterX should be 1343 ideally. From the debug output, it fluctuates b/w 1341, 1342 & 1343 (sometimes 0 too :o !)
    • From the AD9984A I2C Status registers, the actual number of HSYNCs per VSYNC reported by AD9984A is 806 which is ideal and correct.
    • Pixel Clock is unstable in that, direct generation of a sample pattern using it also results in slightly flickering output.

Posted in , | Leave a comment

[GSoC Daily Log]: Trails & errors

Friday, 20th June 2014:

  • Removing the DATACK TIMESPEC constraint seems to have removed the frame losses/screen going blank. Consistency: Good. No frame dropping!
  • Adding back DATACK TIMESPEC but now, mentioning period in ‘time’ as ‘ns’ for both TNM_DATACK and TNM_PCLK. Result: Almost same as before. But frame drops. Also I think *slightly* more flickering
  • Removing back the TNM_DATACK but retaining TNM_CLK with 15.384 ns as PERIOD. Result: No frame drop. Flickering same as in first case.
  • Now removing all the timespec constraints. Result: 1 or 2 frame drops. No noticeable performance improvement. Putting them back (except the TNM_DATACK)
  • [Day]
  • Testing: generating HDMI with only pixel clock, others logically generated.
    • With Jahanzeb’s Test Pattern: Still shaking & Frame drops. That means, clock is not stable.
    • With my dynamic test pattern: Still shaking & Frame losses.
  • Now, testing with inbuilt clock, dynamic pattern. Result: Obviously perfect image without any frame loss. So, One culprit is caught: Unstable pixel clock (DATACK)
  • Tried Oversampling: Didn’t work (ie with my implementation which may be wrong)
  • Narrowed down the issue to: Async_edge detected HSYNC/VSYNC vs proper synchronised edge detected HSYNC/VSYNC...also pixel clock is unstable

Posted in , | Leave a comment

[GSoC Daily Log]: Major improvement!

Thursday, 19th June 2014:

  • Tried different cases to remove messy capture and flickers.
  • Rewrote code many times
    • Result: Major improvement in the capture quality
    • Still quite a number of flickerings
  • Previous issue was mostly due to bad code and the incorrect edge detector. HSOUT and VSOUT were also not processed/read properly.
  • Next goal: To remove flickers

Video 1:

Video 2 (from my Desktop PC running Windows XP):

Video 3:

Video 4:

Posted in , , | Leave a comment

[GSoC Daily Log]: Messy capture? Sync/clock issue?

Wednesday, 18th June 2014:

  • Testing VGA Capture:
    • Infinite errors it seems. Totally drained out removing them. Sigh!
    • Once again, I flipped the code such that when the video *should* be displayed it is not displayed, instead it is ‘displayed’ in the front-porch/back-porch/sync-pulse pulse time, when one cannot see it. Big #Facepalm
    • Had to resolve the r,g,b outputs getting trimmed due to cascaded rising_edge statements. Took 3 hours to find the problem.
    • Finally, atleast something on the screen. Not the exact frame expected, but atleast can confirm that AD9984A is working fine.
    • From the video shown below, one can see that this maybe due to sync and clock issues. I think I know the problem


Posted in , , | 2 Comments

[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 , | Leave a comment

[GSoC Daily Log]: Got the DVI app note working

Monday, 16th June 2014:

  • Got the ported DVI App Note from Xilinx working after it refusing to work 6-7 times consecutively. Many slight errors
    • First, the value of CLKFX_DIVIDE and CLKFX_MULTIPLY for DCM_CLKGEN in case of static value is the actual numbers as in, but in case of dynamic value to be programmed, they are the actual values minus one! So, when I ported the code from dynamic programmed to static value, it led to my TV saying “Incompatible signal format”
    • Fixed it but, then I accidentally flipped the values of CLKFX_DIVIDE & CLKFX_MULTIPLY and so I was still getting the same error message on TV. Took some time to figure out that I had flipped the values.
    • The CLKIN_PERIOD of PLL_BASE was set at 13ns. Had to change it to 15.384 for it to work.
    • Rest were simple errors like TIMESPEC constraint not found due to unrouted BUFG Clocks etc. Were easily fixed.
  • Next job would be to capture and display the captured data on the HDMI

Posted in , | Leave a comment

[GSoC Daily Log]: Application Note comes in handy!

Sunday, 15th June 2014:

  • Porting the Xilinx’s DVI App. Note for testing the VGA capture on HDMI. Almost done, Have to test it with a test-pattern and then with actual VGA captured data.

Posted in , | Leave a comment

[GSoC Daily Log]: Took the day off

Saturday, 14th June 2014:

  • Took the day off. Watched TV Series (non-stop!) and had hangout with friends

Posted in , | Leave a comment

[GSoC Daily Log]: Preparing for next major milestone

Friday, 13th June 2014:

  • Started writing capture code
  • Looked on some DVI/HDMI codes to see if they can be used for displaying captured data

Posted in , | Leave a comment


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