Xilinx FPGA learning notes 1-chipscope cannot observe the signal BUFG, xilinx-chipscope

Xilinx FPGA learning notes 1-chipscope cannot observe the signal BUFG, xilinx-chipscope

Today, I started to try to use chipscope and wrote a simple routine of the Water lamp. There was no problem when I started the Integrated Wiring. However, after chipscope was added, an error was always reported.

First case: Using chipscope cannot directly observe the global clock signal, that is, the BUFG signal ----- X

The error is as follows:

ERROR: Location: 1136-This design contains a global buffer instance,
<PLL_u0/clkout1_buf>, driving the net, <CLK_OUT1>, that is driving
Following (first 30) 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 global routing that may cause excessive delay, skew or unroutable
Situations. It is recommended to only use a BUFG resource to drive clock
Loads. If you wish to override this recommendation, you may use
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/clkout?buf.o" CLOCK_DEDICATED_ROUTE = FALSE;>
ERROR: Pack: 1654-The timing-driven placement phase encountered an error.

This error was found one night, and the http://xilinx.eetrend.com/forum/6884 expert replied as follows:

This error indicates that the output of BUFG is connected to a non-clock pin, that is, the ILA logic. In S6, it is recommended that the Global clock output be connected only to the clock pin, otherwise it is difficult to cause wiring problems. The CLOCK_DEDICATED_ROUTE constraint can reduce this error to an alarm and continue to run the layout and wiring. Note that this constraint does not force the clk_we signal to not pass the BUFG, but tells the tool to ignore the usage of such non-optimized clock resources. You can see through FPGA Editor that clk_we is still on BUFG.

It means that under normal circumstances, chipscope cannot observe the signal after BUFG, but it is not true. Experts say: Adding CLOCK_DEDICATED_ROUTE constraints can reduce this error to an alarm.

Blog posts:

ERROR: Location: 1136-This design contains a global buffer instance,
<U_SYS_CLK/U_CLK/BUFG3>, driving the net, <clk100K>, that is driving
Following (first 30) non-clock load pins.
<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 global routing that may cause excessive delay, skew or unroutable
Situations. It is recommended to only use a BUFG resource to drive clock
Loads. If you wish to override this recommendation, you may use
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;>

Processing Process:
1. Add the following content to the ucf file as prompted:
PIN "U_SYS_CLK/U_CLK/BUFG3.O" CLOCK_DEDICATED_ROUTE = FALSE;
But the capture signal is: I feel that this clock is a 50 MHz clock, instead of dividing the clock by 500 kHz, the capture of kHz signal even the same data point appeared, decisive doubt there is a problem;
2. Open the chipscope. cdc file with ue and find one of the actions:
Project. unit <0>. clockChannel = clk50M
I didn't add the clk50M clock in chipscope, so the above one was changed:
Project. unit <0>. clockChannel = U_SYS_CLK clk100K
3. The test result is normal.
In addition, the clock output by bufg can be used as the chipscope clock, but not as the data monitoring. We can use assign clk_temp = clk_bufg to monitor clk_temp. I tried this. It seems that I cannot.

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

Case 2: fpga I/O cannot be directly used as the chipscope sampling clock. Otherwise, the following error will be reported. The input IBUF signal must be used as the sampling clock.

ERROR: NgdBuild: 924-input pad net 'I _ clk' is driving non-buffer primitives:

Check my source code first. Here, I _clk and I _ip cannot be used for sampling clock directly.

`timescale 1ns / 1ps//////////////////////////////////////////////////////////////////////////////////// Company: // Engineer: // // Create Date:    19:26:57 04/11/2015 // Design Name: // Module Name:    TOP // Project Name: // Target Devices: // Tool versions: // Description: //// Dependencies: //// Revision: // Revision 0.01 - File Created// Additional Comments: ////////////////////////////////////////////////////////////////////////////////////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 I _ip_IBUF signal after the ip address IBUF.

Case 3: Using chipscope cannot directly observe fpga I/O, which is similar to the case 2. The case 2 cannot be used for sampling. In this case, it cannot be used for observation or triggering. The same is true for errors:

ERROR: NgdBuild: 924-input pad net 'I _ ip' is driving non-buffer primitives:

Similarly, we can observe the corresponding IBUF signal. However, if I/O is the clock signal of the logic module, the corresponding IBUF cannot be observed. That is, I _ip_IBUF can be observed, while I _clk_BUFGP cannot !!!