Archive for July 2014

[GSoC Daily Log]

Thursday, 31st July 2014:

  • Worked on 2-FIFO implementation

Posted in , | Leave a comment

[GSoC Daily Log]: Fixed I2C Problems in VHDL


Wednesday, 30th July 2014:

  • Fixed I2C problem with code.
  • Also, tried I2C using Picoblaze softcore processor. Seems good. Uses similar resources.

Posted in , | Leave a comment

[GSoC Weekly Overview]: PCB sent for Fab!

The biggest news of this week was PCB being sent for Fab to Hackvana!

Here is the design sent to Fab: http://gerblook.org/pcb/JB6z7ixXL2hbVSKhU6CjCk

KiCad Design files are on the repository: https://github.com/rohit91/HDMI2USB-vmodvga

Pictures:


Front:

PCB Front


Back:
 
PCB Back

Upcoming Week:

With the PCB sent for fab, I’ll order 0.1uF 0805 caps, since I don’t have them and they are required in PCB Rev02. Some other components required will also be ordered. And, I’ll be moving back to working on VGA capture and fixing I2C problem.

Posted in , | Leave a comment

[GSoC Daily Log]

Saturday, 26th July 2014:

  • Felt unwell. (Maybe due to drinking chilled water in monsoons? This one gets added to my ‘Things to avoid’ list). Slept a lot.

Posted in , | Leave a comment

[GSoC Daily Log]:

Friday, 25th July 2014:

  • Completed routing of PCB (w/o length-matching). Fixed Issues with silkscreen, ground plane and other issues listed on github. Now trying length-matching

Posted in , | Leave a comment

[GSoC Daily Log]:

Thursday, 24th July 2014:

  • Looked on various ways to do length-matching. Tried Freerouter. Unsuccessful. Patched KiCad’s source with code from https://bugs.launchpad.net/kicad/+bug/594089. Compilation (make clean)  failed 3 times. Succeeded on last try. But ate up most of the time. Also, it turned out to be not too intuitive.

Posted in , | Leave a comment

[GSoC Daily Log]:

Wednesday, 23rd July 2014:

  • PCB Design started from scratch. Changed components placement, PCB dimensions, and layout. Initial routing 40% done. Without length-matching.
  • Fixed some issues listed on github

Posted in , | Leave a comment

[GSoC Weekly Overview]: PCB!

This week was all about PCBs. Although I did work first 2 days of the week on VGA Capture code, but once the components ordered from Mouser arrived, I had to get to the task of assembling the PCB. I also got inducted into TimVideos Hardware Hackers Team! Wooohooo!! Felt awesome! But, that also means I have to get a deeper understanding of git. I got reminded of this quote (from Spiderman I guess?) “With great power comes great responsibility”

PCB v01:

The most difficult part in the soldering the PCB were the 0402 package resistor networks. They were  huge pain. Whatever and however you do the soldering, some pads would either get bridged or remain unconnected at all! Due to repeated soldering, the remaining components and PCB were also getting heat stressed, which is not a good thing to happen.
Once satisfactorily soldered the resistor networks, I soldered the remaining components namely ADP3334 voltage regs, ferrite beads and some decoupling caps.
After the soldering and cleaning (since huge amount of flux remained stuck after soldering), it was time to test the board.
Upon connecting it with power supply, all the voltages were normal. Next job was to check if the chip was responding or not. I soldered 2 wires on I2C_SDA and I2C_SCL lines and connected them to BeagleboneBlack and ran the python scripts for AD9984A initialization and reading. Yeah, the chip was working fine. Next job was to test the signals coming out of the IC. I loaded the AD9984A test bitfiles I had created previously. The HSOUT, VSOUT and DATACK signals were fine. So, the PCB was working fine and was ready to ship.

I shipped the PCB using DHL to my mentor yesterday itself. Now the time was to focus on PCB-v02. Tracking Link

PCB v02:

The third day of week was mostly spent of schematic and netlist parts association. Having finalized the footprint that I would be using, it was time for PCB routing. In the meantime, after discussion from Joelw on IRC I got to know that those (tiny monsters) resistor networks were redundant since Atlys already has 50ohms resistors on each lines of VHDCI signals. Happy with the information, I quickly removed the resistor networks and associated standalone resistors. The last 2 days were spent routing and correcting the schematic. Yeah, while routing, I encountered at least 7 errors(better word: mistakes) in schematic, like I2C pullup resistors accidently connected to same line! The PCB is now fully routed. Some tweaks and changes might be done before sending it for fab. I used same design rules and track-width and drills as in Jahanzeb’s version. All DRC errors are resolved now. The VHDCI connector, although, seems treacherous. It has very tight clearances, pushing the DRC to limits. But, I suppose I have to contend with it. Hopefully the fab correctly routes it.

The current design looks like this:
Screenshot - 22_07_2014 , 2_24_00 AM.png


Upcoming Week:

With the PCB sent to fab after slight tweaks etc, I’ll get time to work on VGA Capture. I couldn’t work on that in this week due to more attention provided to the PCB. But, now I can work on the capture. The FIFO based implementation looks promising. I’m planning a 2-FIFO based buffer this week to see if I can perfectly stabilize the capture or not. If it works then I’ll integrate I2C with the code. After that, I’ll move onto integration with current HDMI2USB. Although, a better way would be to say testing with code integrated on HDMI2USB since I’ve already integrated the capture module into HDMI2USB, so only testing with perfect capture is required. But, the most important task is to get capture perfect, which is still eluding me!

Posted in , | Leave a comment

[GSoC Daily Log]:

Monday, 21st July 2014:

  • PCB Routing complete. Ready for review. Some minor changes & tweaks may be done before sending for Fab. Github

Posted in , | Leave a comment

[GSoC Daily Log]:

Sunday, 20th July 2014:

  • PCB Routing: 70% ratsnest routed. Fine tuning remaining. Commit

Posted in , | Leave a comment

[GSoC Daily Log]:

Saturday, 19th July 2014:

  • All soldering done. Power Supply fix done. Voltages Normal
  • Next Job: Check if IC is responding using I2C.
  • Update: I2C Test Done. AD9984A Responding properly. Initialization and configuration using I2C successfully done. Connected to Atlys. DATACK, VSOUT & HSOUT Test OK.
  • That means, the second PCB of version 1 is officially now ready to ship.

Posted in , | Leave a comment

[GSoC Daily Log]:

Friday, 18th July 2014:

  • Got the package from Mouser
  • Soldered the ICs, Beads and the 0402 Resistor Networks.
  • 0603 0.1uf Caps, and then power supply ‘fix’ and then testing is remaining

Posted in , | Leave a comment

[GSoC Daily Log]:

Thursday, 17th July 2014:

  • Worked on PCB’’s schematic.
  • Added headers for unused signals.

Posted in , | Leave a comment

[GSoC Daily Log]:

Wednesday, 16th July 2014:

  • Reordered the components through Mouser. Should be delivered by Friday. Hugh shipping and customs :/
  • Writing code for 2-FIFO implementation. Tomorrow, will work on PCB

Posted in , | Leave a comment

[GSoC Weekly Overview]: Change of Plan

Big news of the week is: I have changed to Plan B implementation for capturing VGA. This change was forced due to narrowing road in the first implementation. The final nail in coffin was when even Xilinx’s AD9984A code (from UG458) gave the exact same result as my code. Gah! So, I decided enough is enough, lets move to plan B. And the results do look promising!

What’s exactly is Plan B?

In this implementation, I’m using a 24-bit wide and 4096 dept FIFO with independent read and write clocks.
Why independent clocks? Thats because the DATACK and the img_pclk are different, even though supposedly at same frequency, but they drift over time. So, I’ll be pushing data into the FIFO first using DATACK, then after slight delay, I’ll start reading it using the accurate clock img_pclk (which would be driving the whole HDMI encoder). The problem of FIFO overflow and underflow is eliminated by a simple realization that out of the complete line-scan period (1344) only 1024 cycles are the active ones. That means, I can use rest of the cycles to synchronize and reset the FIFO at the appropriate time.
I have done the simulations and just at the time of this writing, ran it on Atlys! And lo! The flickerings are gone!! The image looks perfect from a distance, but when I go near, I see the pixels shaking by 1 (or max 2) pixels. I think I can correct this using a 2-FIFO pipeline, where 1 one written and the other one is read.
I’m pretty much happy with the result of 4 days of coding and simulation.

PCBv02

Unfortunately, due to my priority to VGA Capturing (due to less and less time remaining), the target for at least a partially routable PCB was not achieved. But, the schematic is pretty much up for review. After some changes if required, I will finalize it and move to PCB routing.
Also, this week I bought my first ever Hot-Air Soldering Machine for soldering the AD9984A and other ICs to the second prototype of PCBv01. The prototype has been partially soldered. Parts remaining to be soldered are AD3334 voltage reg, Ferrite Beads and Resistor Network. I’m awaiting their delivery from Element14.

In all, I’m happy with this week. Very good progress in the capturing and some in PCB area.

Upcoming Week:

This week my goal will be to finalize the PCB and and get the VGA capture rock solid. And, I’m confident [yeah, confidence returned after 3 weeks of almost continuous failures! :) B-) ] that I’ll complete this goal. The PCB might get delayed by 1-2 days max. After that, my focus in remaining weeks would be PCBv02 testing (after receiving from fab), HDMI2USB integration (which is going to give some headache, so I’m taking some buffer time for that). Minor issues like, I2C and autodetection features are 1 or 2 day jobs max.

So, after much delay due to capturing (&timing?) headache, the project is back on track!! Feels awesome!

Posted in , | Leave a comment

[GSoC Daily Log]:

Monday, 14th July 2014:

  • Ran the FIFO based implementation on Atlys. Seems to work. Image starts tearing as going down.  
  • Update: Flicerking Fixed!! Slight shaking (by 1 or max 2 pixels) remain.
  • Will try 2-FIFO implementation to see if that removes it.

Posted in , | Leave a comment

[GSoC Daily Log]:

Sunday, 13th July 2014:

  • Spent the writing code for the FIFO based implementation for VGA Capture and Simulation testbench. Watched FIFA World Cup 2014 Final thereafter.

Posted in , | Leave a comment

[GSoC Daily Log]:

Saturday, 12th July 2014:

  • Since, even Xilinx’s code for AD9984A from UG458 failed, I’m writing a new FIFO based implementation with independent reading and writing clocks.
  • Day spent in working out its state diagram and starting preliminary coding

Posted in , | Leave a comment

[GSoC Daily Log]:

Friday, 11th July 2014:

  • Found an old code from Xilinx’s UG458 which also uses AD9984A for VGA Capturing. Adapted and used the exact same code in my project. Gives same result as mine! :/ Intriguing! See the repo for the commit.
  • Added Test Points in the schematic

Posted in , | Leave a comment

[GSoC Daily Log]:

Thursday, 10th July 2014:

  • Worked on schematic. Added I2C Buffers and EEPROM. Fixed ERC Errors
  • Worked on VGA Capture code. Got slight improvement in capture quality. Code pushed to repo.

Posted in , | Leave a comment

[GSoC Daily Log]:

Wednesday, 9th July 2014:

  • Spent the day in VGA PCBv02 Requirements and looking for suitable I2C buffer IC
  • Rest of the time was spent in tinkering with PLL phase adjustment and jitter filter setting using Clocking Wizard

Posted in , | Leave a comment

[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!

Reading:


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

[GSoC Daily Log]: Interesting

Monday, 7th July 2014:

  • Some amusing things going on! 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. Same goes for the case when I directly connect the PLL to DATACK instead of through DCM.
    I suspect this tells that the DATACK clock is not clean.
  • 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 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. 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.

Posted in , | Leave a comment

[GSoC Daily Log]: More Reading

Sunday, 6th July 2014:

  • Read various documents on synchronization and metastability. Best one found was this http://webee.technion.ac.il/~ran/papers/Metastability and Synchronizers.posted.pdf
  • Read all the appnotes provided by mentor. Most of them use LVDS and use the IDELAY to phase shift the incoming data, then pass through a oversampler and finally Data Recovery Unit (DRU). This cannot be used in our case because we are using Single-Ended signals. Also there are 30-bits of signals in total. But nevertheless, got some interesting ideas on how to proceed further.

Posted in , | Leave a comment

[GSoC Daily Log]: Loads of issues

Saturday, 5th July 2014:

  • Loads of issues today: While integrating the i2c-initialization hdl code into my vga capture test code, I experienced another problem. The i2c program in i2c-initialization hdl code when synthesized and implemented standalone is inferred as distributed RAM and is working perfectly. I have pushed the code here(https://github.com/rohit91/HDMI_Test_v06/blob/master/hdl/i2c/i2c_top.vhd) But when I integrate the exact same code into my vga capture test code (modified one also pushed here, the i2c instance is at the bottom), then the program code which is constant is inferred as BRAM8 instead of distributed one in standalone testing, with the bitgen issuing warning “PhysDesignRules:2410 - This design is using one or more 9K Block RAMs (RAMB8BWER).  9K Block RAM initialization data, both user defined and default, may be incorrect and should not be used.  For more information, please reference Xilinx Answer Record 39999.” I looked up this issue here: http://www.xilinx.com/support/answers/39999.html Tried its fixes, but still it won’t work! :/ I guess I’ll have to either use BRAM generator or change the code slightly. Still one more issue at hand, which I had thought to be completely done (see prev. blog post)
  • While browsing the HDMI2USB code which I had modified while integrating the vga capture code , I found that I had left the clock multiplexer for VGA pixel clock commented. Jahanzeb had added the VGA Pixel clock’s multiplexer named  BUFGMUX_VGATP. It is a BUFGMUX resource, for multiplexing clocks. And I had left this commented. That meant when during testing of integrated code, when I pressed the Atlys Right Button (selecting VGA source), the code would select all the signals (rgb, de, hsync, vsync, resx and resy) but the pixel clock would still be of Test Image! :-o This was simple but horrible mistake. I quickly uncommented the code and started its synthesis and implementation, eager to test the result and hoping better results this time. But, there was another bummer for me. The adding another BUFGMUX resulted in code becoming completely unroutable! uhh!

This was the error given by map:
“ERROR:Place:1320 - Unroutable Placement! A BUFGMUX cascade pair is not placed at a routable site. The driver BUFGMUX component img_sel_comp/BUFGMUX_VGATP> is placed at site <BUFGMUX_X2Y10>. The load BUFGMUX component <img_sel_comp/BUFGMUX_PCLK> is placed at site <BUFGMUX_X3Y13>. The driver BUFGMUX must be in TOP half of the chip to be able to route to the load BUFGMUX. This placement is UNROUTABLE in PAR and therefore, this error  condition should be fixed in your design. You may use the CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message to a WARNING in order to generate an NCD file. This NCD file can then be used in FPGA Editor to debug the problem. A list of all the COMP.PINS used in this clock placement rule is listed below. These examples can be used directly in the .ucf file to demote this ERROR to a WARNING. < PIN "img_sel_comp/BUFGMUX_VGATP.O" CLOCK_DEDICATED_ROUTE = FALSE; >”

I tried all 16 possible BUFGMUX locations, one worked(BUFGMUX_X3Y8) but after adding the constraint “NET "DATACK" CLOCK_DEDICATED_ROUTE = FALSE;”. Lets see if this works good.

Posted in , | Leave a comment

[GSoC Daily Log]: Some random low-priority things Part-2

Friday, 4th July 2014:

  • One-off I2C initialization of AD9984A using Atlys in working excellent. Now, I can significantly reduce my test-setup of BeagleBoneBlack and associated wires. This part is considered complete. I can integrate this into my VGA Capture test code.Will push all codes tomorrow.
  • UART-I2C bridge is is unreliable. But, it is not on my priority as of now. But, I can dynamically change value from my PC using python.
  • Now, focus is back to VGA Capture and also Requirements doc for PCB_v02

Posted in , | Leave a comment

[GSoC Daily Log]: Some random low-priority things

Thursday, 3rd July 2014:

  • Took a break from VGA capturing, Wrote VHDL code for I2C initialization of AD9984A and also UART-to-I2C bridge, so that normal users can initialize and changes settings (such as gain, offset etc) dynamically through their PC (like using python serial module). It is working but is not reliable, fails 1 out of 10 times.
  • Standard one-off initialization code almost complete. Will do it by tomorrow.
  • Arranging for a oscilloscope. Talked to some people who could allow me to use it or lend it.

Posted in , | Leave a comment

[GSoC Daily Log]: Reading

Wednesday, 2nd July:

  • Read the about clock-crossing. Some implementation assume data arriving a slower rate compared to both clocks. While some other use FIFOs. 
  • Read the Xilinx’s app-note XAPP224 - Data Recovery. Seems this one can be used. Only problem is that it specifies “ At least one data transition is required in the time that the circuit takes to drift one-quarter clock period. Example for a local oscillator 401 MHz and data arriving a 400Mbps, the circuit requires at least one negative transition every 100 clock cycles to function correctly.” Also it says “Care should be taken if the received data is a raw bitstream, because an adequate number of transitions may not exist.”
  • Started writing a new improved test code

Posted in , | Leave a comment

[GSoC Weekly Overview]: Days of slient hardwork


Lets first start with some good news. After all I’ve plenty of bad news this week!

Integration with HDMI2USB Core

After frustrated with repeated failure of all my tests, I decided to try something new (& adventurous maybe?). I decided to integrate whatever code and working system I had up till now into the HDMI2USB Core. Actually, Jahanzeb already had incorporated most of the VGA code already in it in comments. So, my job got easier!
I can say that the integration went fine as I was able to switch to VGA source using the “Right Button” of Atlys. But, obviously due to imperfect capturing, the output of mplayer through USB, was coming out garbled, but I could atleast deduce that it was actually the garbled output of VGA. I could observe color bars from my test pattern. HDMI output, though, was blank.
[Pic: ToDo: Screenshot of mplayer’s output here?]

Good progress with VGA capturing from test source

I was able to reduce flickering from the VGA capture output. The VGA source used was a FPGA board running Jahanzeb’s test pattern generator code with my patch for alternating color bars. The source for flickering (of Type1, more details later) was the Auto-Offset Update Frequency register. The datasheet’s recommended value itself was giving flickering, but setting the update frequency to 3 VSYNCs seemed to work like magic! And, all this while I was thinking that my  VHDL code was incorrect! (But, hey wait for bad news!)
[Video: TODO Add Video here]

Time for negatives

After some success with test source using FPGA, I decided to try capturing of PC’s output. To my horror, there was a new issue of different type of flickering. That of screen blanking intermittently. Clearly, this AD9984A data related issue, it was more of SYNCs or DATACK issue. I’ll have to do more test and research on this one.

And, all the above text relate last 3-4 days only! So, what I was doing before that, you may ask! Some new things, like trying the Exar Linux drivers and resolving its issues. And, some regular things like code cleanup, repository restructuring etc. Rest time was spent testing various options for reducing flickering (that before that success mentioned above). Thats why the title “Silent hard work”. Its very uncomforting that you try and try things and each one fail, so you have nothing good/exciting to announce. But, projects do have these phases. So, I’ve to give more effort and be focussed.
For more technical oriented viewers, please have a look at the daily logs. If you have any solution/suggestion in mind, kindly do not hesitate to share. It would be very helpful.

Upcoming Week:

This is crucial section. I want to mention some things. First, its 1 month over since I started working from 29th. And second, I have 5-6 weeks only remaining, and these are very crucial for timely and successful completion of project. This require more effort and careful planning.
First, lets see what things are remaining in decreasing of importance(priority):
  • Perfect Capturing from VGA. Time Required: Unpredictable. Hopefully 1 week more.
  • PCB version 2 designing, fabrication, assembly and testing. Time Required: Will require about 6-7 days for designing(including review by mentors and community), 1 week for fabrication(in meantime, I could do other remaining works), and 1-2 days for assembly and finally 1 day for testing if all goes well.
  • I2C Integration into VHDL. Right now I’ve to do many changes to register configuration on-the-fly so I’m using BeagleBone Black for quick prototyping. But, obviously I’ve to integrate I2C into VHDL. Time Required: Will require a day or at-most 2 days.
  • PCB version 3, if version 2 doesn’t come up well. But, there is very less chance of that. I’ll try to ensure version-2 atleast becomes pre-production standard.
  • Any remaining things like documentation, feature implementation on HDMI2USB like auto-detection etc.

So, rather than deciding before hand, I need some discussion with mentor on how to proceed. Should I aim for perfect capture and then move onto PCB, or should I design the PCB and send it for fabrication, in meantime working on correcting the capture while the PCB returns from fab. Uncertain on these things. I’ll have to discuss this with my mentor.






Posted in , | Leave a comment

Search

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