0
\$\begingroup\$

I realise this verilog code isn't ideal, and later on I might ask for general review somewhere but at this time I'm not looking for general review except so far as it affects the issue I have (unless they whole thing is fundementally broken of course, then I want to know!). I realise the timing probably isn't quite right, and hard coded numbers etc are likely bad, it's just a first attempt to learn, and my problem is understanding the warning at the moment.

I'm trying to make a VGA output on a papilio pro. It's somewhat working if I just output the vertical and horizontal sync but when I try to output the rgb signals I get this warning :-

WARNING:ConstraintSystem:119 - Constraint <NET "vga_r" LOC="P78" |> [main.ucf(6)]: This constraint cannot be distributed from the design objects matching 'NET "vga_r"' because those design objects do not contain or drive any instances of the correct type.

WARNING:ConstraintSystem - A target design object for the Locate constraint '<NET "vga_r" LOC="P78" |> [main.ucf(6)]' could not be found and so the Locate constraint will be removed.

module main(input clk_32, output vga_hs, output vga_vs, output vga_r, output vga_g, output vga_b);

    wire clk_50;

    // Use a clock generator IP module to make a 50MHZ clock for the VGA
   clkgen clock_gen(clk_32, clk_50);

   // Current scan line number
   reg[0:9] row_count;

   // Current pixel position in scan line
    reg[0:10] pixel_count;

   always @(posedge clk_50)
    begin
        if (pixel_count == 1599)
         begin
             pixel_count <= 0;
           if (row_count == 524)
              begin
                  row_count <= 0;
              end
              else
              begin
                  row_count <= row_count + 1'b1;
             end
         end
         else
         begin
             pixel_count <= pixel_count + 1;
         end
    end


    // Set "on" only during the visible part of the screen
    wire on;
    assign on = (pixel_count > 112 && pixel_count < 752) && (row_count > 12 && row_count < 492);

    // Assert the hsync and vsync pins during the proper parts of the video frame
    assign vga_hs = ~(pixel_count < 96);
    assign vga_vs = ~(row_count < 2);

    // Just turn on the R,G,B outputs during the main area of the screen for now.
    assign vga_g = on;
    assign vga_b = on;
    assign vga_r = on;

endmodule

and my UCF file contains this which I think is correct...

NET "clk_32"    LOC="P94"   | IOSTANDARD=LVTTL | PERIOD=31.25ns;
NET "vga_vs"   LOC="P99"    | IOSTANDARD=LVTTL;
NET "vga_hs"   LOC="P97"    | IOSTANDARD=LVTTL;
NET "vga_b"    LOC="P92"    | IOSTANDARD=LVTTL;
NET "vga_g"    LOC="P80"    | IOSTANDARD=LVTTL;
NET "vga_r"    LOC="P78"    | IOSTANDARD=LVTTL;

clkgen is a clock generator generated by the tools and appears to be working correctly.

I don't undersdtand what the warning is telling me, it appears to be preventing the synthesis from working though. It all looks right to me but I'm clearly missing something, can anyone see what I'm doing wrong? (And be gentle I'm new to verilog!)

\$\endgroup\$
  • 1
    \$\begingroup\$ Output something else (say, a divided clock) on vga_r etc. The synthesis tool may be optimising it away because it's constant. If you use not pixel_count/400,800,200 for r,g,b respectively you'll get a colour bar generator for free. \$\endgroup\$ – Brian Drummond Dec 20 '12 at 15:26
  • \$\begingroup\$ It's not a constant, it's assigned the value of "on" which is set during the active part of the display. At least that's what I am hoping! I'll try doing what you suggest too though \$\endgroup\$ – John Burton Dec 20 '12 at 15:28
  • \$\begingroup\$ apologies, I see that now. Then my suggestion won't help... I'm not familiar with Verilog! \$\endgroup\$ – Brian Drummond Dec 20 '12 at 15:35
  • 1
    \$\begingroup\$ Most likely answer: Synthesis is merging vga_g, vga_b, and vga_r into a single net, because they are all equivalent. Then place & route can't put them in different locations, because there's only one net in the synthesis output. Solution depends on exactly which tool you are using. I will make this an answer if you confirm the warning is a P&R warning rather than synthesis warning. \$\endgroup\$ – The Photon Dec 20 '12 at 18:23
  • 1
    \$\begingroup\$ Taken from a Xilinx forum: Make sure you have checked "Add I/O Buffers" in the Synthesis properties under the Xilinx specific options tab. \$\endgroup\$ – apalopohapa Dec 20 '12 at 19:07
2
\$\begingroup\$

One possible cause: Synthesis is merging vga_g, vga_b, and vga_r into a single net, because they are all equivalent. Then the translate step can't put them in different locations, because there's only one net in the synthesis output.

Solution 1. Explicitly instantiate your OBUFs.

 OBUF obuf_vga_g ( .I ( on ), .O ( vga_g ) ); 
 OBUF obuf_vga_b ( .I ( on ), .O ( vga_b ) ); 
 OBUF obuf_vga_r ( .I ( on ), .O ( vga_r ) ); 

This makes it explicit in your code that the output nets are buffered from the on signal and attached to output pins. Obviously the tool should already know these nets are connected to output pins because they're outputs of the top level module. Having to do this kind of thing is just one of the quirks of using a tool originally designed to describe logic for the different purpose of designing logic.

Solution 2. Use constraints to eliminate merging of duplicate logic.

Depending on which synthesis tool you use, there should be a constraint available that you can attach to your vga_b, etc, signals to prevent them being merged in the synthesis step. In Synplicity, I believe you would use syn_keep to prevent removing redundant combinatorial logic.

As Apalopohapa noted in a comment, you might also need to turn on a flag to enable Synthesis to automatically generate the OBUFs you need. This should default to 'on', but it doesn't hurt to double-check it.

\$\endgroup\$
  • \$\begingroup\$ Thank you, this does seem to be the problem. It won't be an issue for my real project as I will clearly be sending different signals to each pin. It was only an issue because I wanted to get a simple case tested before moving on. \$\endgroup\$ – John Burton Dec 21 '12 at 8:12
  • \$\begingroup\$ It's one of my biggest annoyances with Verilog design that every small change ends up propagating small changes up and down the design hierarchy, and potentially drastically changing the overall behavior. Especially all the optimization the tools do makes it hard to get a good estimate of resource usage or power needs until you've nearly completed a design. \$\endgroup\$ – The Photon Dec 21 '12 at 17:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.