Xilinx FPGA Learning Note A-chipscope cannot observe the signal BUFG

Today began to try to use the Chipscope, wrote a simple running lights of the routine, the beginning of the integrated wiring when there is no problem, but add chipscope after the overall error.

First case: The global clock signal can not be observed directly with chipscope, i.e. the BUFG signal-----X

The error is as follows:

error:place:1136-this design contains a global buffer instance,
   <pll_ U0/clkout1_buf>, driving the net, <clk_out1>, which is driving the
   following (first) Non-clock Load Pins.
   < PIN:CLK_OUT1_INV_1_o1_INV_0.A6;
   < pin:u_ila_pro_0/u0/i_tq0. G_tw[0]. U_tq. D
   this is not a recommended design practice in Spartan-6 due to limitations in
   the glob Al routing that may cause excessive delay, skew or unroutable
   situations.  it are recommended to Use a BUFG resource to drive clock
   loads. If you wish to override this recommendation, the
   clock_dedicated_route constraint (given below ) in the. UCF file to demote
   this message to a WARNING and allow your design to continue.
   < PIN "Pll_u0/clkout1_buf. O "Clock_dedicated_route = FALSE;
Error:pack:1654-the Timing-driven Placement phase encountered an error.

This error was found one night, see http://xilinx.eetrend.com/forum/6884 experts reply as follows:

This error is prompting you to design the output of the BUFG to a non-clock pin, which is the ILA logic. In S6, it is recommended that the global clock output only connect to the clock pins, otherwise it is difficult to cause cabling problems easily. The constraint of adding clock_dedicated_route can reduce this error to alarm and continue to run layout and cabling. It is important to note that this constraint does not force the CLK_WE signal to pass through BUFG, but rather tells the tool to ignore such non-optimized clock resource usage issues. You can see through the FPGA editor that Clk_we is still on the BUFG.

It means that under normal circumstances chipscope can not observe the BUFG after the signal, but it is not really can not, experts said: add clock_dedicated_route the constraints of the error to reduce the alarm

User Blog Http://blog.163.com/[email protected]/blog/static/88629551201452611949339 describes the implementation of this method:

error:place:1136-this Design contains a global buffer instance,
<U_SYS_CLK/U_CLK/BUFG3>, driving the net, <clk100k>, that's driving the
   following (first ) Non-clock load Pins.
   < Pin:u_ila_pro_0/u0/i_tq0. G_tw[0]. U_tq. D
   This isn't a recommended design practice in Spartan-6 due to limitations in
   the Glob Al routing that may cause excessive delay, skew or unroutable
   situations.  It's recommended to only Use a BUFG resource to drive clock
   loads. If you wish to override this recommendation, the
   clock_dedicated_route constraint (given below ) in the. UCF file to demote
   this message to a WARNING and allow your design to continue.
   < PIN "U_SYS_CLK/U_CLK/BUFG3. O "Clock_dedicated_route = FALSE;

Process:
    1. Follow the prompts to include in the UCF file:
                 pin "U_sys_clk/u_clk/bufg3. O"Clock_dedicated_route = FALSE;
but grab the signal is, feel this clock is 50MHz clock, and not I divide the 100KHz clock, crawl 100KHz signal unexpectedly the same data point appeared 500, decisively doubt there is a problem;
2. Open the CHIPSCOPE.CDC file with your UE and discover one of the behaviors:
project.unit<0>.clockchannel=clk50m
and I did not add clk50m clock in the Chipscope, so the above one is modified as:
PROJECT.UNIT<0>.CLOCKCHANNEL=U_SYS_CLK clk100k
3. The results are tested normally.
In addition: BUFG output clock can be used as chipscope clock, but not as data monitoring, we can assign CLK_TEMP=CLK_BUFG, monitoring clk_temp. I tried that, like I couldn't.

In short, the chipscope cannot directly observe the global clock signal of the BUFG output.

The second situation: the FPGA IO can not be directly as the chipscope sampling clock, otherwise it will be reported as the following error, must use the input ibuf after the signal as the sampling clock, will not error.

Error:ngdbuild:924-input pad net ' i_clk ' is driving Non-buffer primitives:

First look at my source code, where I_CLK and i_ip are not able to do the sampling clock directly

' Timescale 1ns/1ps////////////////////////////////////////////////////////////////////////////////////Company:/ /Engineer://///Create date:19:26:57 04/11/2015//Design Name://Module name:top//Project Name://Target De Vices://Tool Versions://Description:////Dependencies:////Revision://Revision 0.01-file created//Additional Co Mments:////////////////////////////////////////////////////////////////////////////////////module TOP (I_CLK, I_ IP, O_CLK, o_led); Input I_clk,i_ip;output o_clk;output rego_led;reg [7:0] Delay_cnt;wire clk_out1; (* keep= "TRUE" *) Wire clk_out2;always @ ( Posedge i_clk) beginif (!i_ip) delay_cnt<=8 ' H00;else if (delay_cnt==8 ' hFF) begindelay_cnt<=8 ' h00; Endelsebegindelay_cnt<=delay_cnt+1 ' b1;endendalways @ (Posedge i_clk) beginif (delay_cnt==8 ' hFF) o_led<=~o_led; Elseo_led<=o_led;endendmodule<span style= "color: #ff0000;" ><span style= "Background-color:rgb (255, 255, 255); ></span></span>

You can use the I_CLK ibuf signal I_CLK_BUFGP or the IBUF signal after the IP i_ip_ibuf. I won't call the police.

Third case: With Chipscope can not directly observe the FPGA IO, similar to the second case, the second case is not used for sampling, here is not used to observe and trigger. The same is true for the error:

Error:ngdbuild:924-input pad net ' i_ip ' is driving Non-buffer primitives:

It is possible to observe the corresponding IBUF signal in the same vein. But if this IO is the clock signal of the logic module, its corresponding ibuf can not be observed. That is i_ip_ibuf can be observed, and I_CLK_BUFGP can not!!!

Xilinx FPGA Learning Note A-chipscope cannot observe the signal BUFG