[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 , . Bookmark the permalink. RSS feed for this post.

Leave a Reply

Search

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