[GSoC Weekly Overview]: Its all about timing!

From my previous Video Conference with my mentor, I learned about a whole new thing called Clock Domain Crossing. I had never heard or known of it before, as most of my designs were simple single-clock ones. This was a completely new thing!


My mentor gave me some pointers on oversampling and clock domain crossing, and gave me  Application Notes from Xilinx on Data & Clock Recovery, Async Oversampling etc. They were quite helpful in getting good understanding of the problem and issues. I also searched-for and found some documents on Clock Domain Crossing, synchronization and metastability. So, this week learnt a handful of new things!

Taking mind off from VGA capture:

After much reading, it started getting boring. So, I decided to implement AD9984A I2C initialization using Atlys as an exciting break from boredom. Wrote the code for AD9984A I2C init and it worked! After some confidence, I decided to implement UART-I2C bridge for AD9984A initialization and dynamic configuration from any PC itself. It would help a user change the brightness and contrast settings, and take low-level control of AD9984A using their PC. So, I wrote the code. But, it turned out to be unreliable. Worked 9 out of 10 times but it would fail the 1 time or so. Anyways, this was much needed break from VGA capture.
Next, day I decided to go back to VGA Capturing. I thought, since I2C part is complete, I should now integrate it into my VGA Capture Test codes, and do away with BeagleBoneBlack, hence freeing up space from my test area. But, the *exact* *same* code refused to work after integration.  I found this was somehow related to the program code getting inferred as BRAM8 instead of Distributed RAM in standalone testing.

Back to VGA Capture:

During reading *lots* of documents, I found some quick simple ideas that could help in improving the condition, such as using removing the DCM_CLKGEN block and directly connecting the DATACK to PLL and try to reduce jitter and skew from it. This was because I read in XAPP861 that DCM’s CLKFX has much higher jitter. But, The screen would stop showing any output even if I was getting the PLL_Lock. Confusing! Also, There is another amusing thing. If I use DCM_SP in place of DCM_CLKGEN, with *exact* same CLKFX_DIVIDE & CLKFX_MULTIPLY values and also same connections, the screen would go blank, but the PLL would indicate locked status.

I strongly suspected, that this may be due to design issue. So, I investigated some documents on DATACK. First, the AD9984A’s datasheet. It’s PCB design guidelines say adding 50-200 ohm resistor to reduce reflections. But, The reference schematic from Analog Devices for AD9984 uses 22 ohm resistors for all clocks (DATACK, HSOUT, VSOUT & SOGOUT) whereas, uses 50 ohm for the data lines. I found one more schematic(FMCVideo_sch_RevD.pdf)  from Xilinx using AD9984A, using the DATACK clock directly as a main clock.  This one didn’t use any series resistor on any digital lines.  I don’t know how much impact it does at 65MHz, but I strongly suspect either this or other physical design issue in the PCB.

Upcoming Week:

It is going to be fun and challenging. Hopefully, I’ll get access to an oscilloscope and see exactly what’s going on with the DATACK, HSOUT and VSOUT signals. I’ll be writing code for oversampling and synchronization, using the techniques learnt from the app notes. Also, I’ll be reserving 3-4 hours each day for PCB designing. So, except a nice (but not finalized :P ) PCB design by next week. Hopefully, some issues with requirements(dimensions etc) for PCBv02 get resolved in next VC with my mentor. Also, this week I’m planning on assembling another PCBv01 for simultaneous testing by other members of community. So, yeah, fun and challenging!

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

Leave a Reply


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