Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

VIVADO: crossing clock domain - poor placement message

Status
Not open for further replies.

Ivan_Ryger

Junior Member level 1
Joined
Dec 17, 2010
Messages
16
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,283
Activity points
1,439
Dear colleagues,
I am trying to design a small BCD counter that outputs its value via SPI interface.

The speed of the BCD counter is not critical, it reads an incremental sensor.
The faster part of my design is the SPI interface that runs at a couple tens of kHz.

After studying the concepts of clock domain crossing from fpga4fun webpage, i introduced a FIFO between the slow and fast clock domain in order to synchronize them.

For testing the idea instead of sensor I generate a slow clock by dividing the master clock like this:

Code:
wire divclk, clk_slow;	
reg [26:0] divider;
// clock divider			
always @(posedge clk)
		divider <= divider + 1;	    
assign divclk = divider[17];  // divided clock for SPI controller
assign clk_slow = divider[26]; // divided clock for the counter


afte trying to implement the design, I get the following message:
[Place 30-574] Poor placement for routing between an IO pin and BUFG. If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.
< set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets enable_IBUF] >

enable_IBUF_inst (IBUF.O) is locked to IOB_X0Y61
and enable_IBUF_BUFG_inst (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31

Please has anyone encountered this problem? At least I will need to be directed what to look for or how to interpret the compiler message.

Thank you.
 

Using the outputs of a counter for different clocks is not great practice. I would suggest you use a clock enable instead. In other words, use the same clock for SPI and the counter, but enable the counter using a one-clock wide pulse that's at the slow frequency.

But I don't think that's what your error is. It looks like you're using a non-clock pin for your clock input.
 

But I don't think that's what your error is. It looks like you're using a non-clock pin for your clock input.

Dear Barry,
I am using the standard constraint file for Zybo development board, so I haven't modified the master clock input.


Anyways, it seems that with enabling the clock for only one strike helped to solve the issue with the compiler. I check if the counter has maxed up (by doing logical AND on all its bits) and updating then a register at full clock speed. This should generate short pulse wide 1clk.

Code:
reg clk_slow;
always @(posedge clk)
    if (&(clk))
        clk_slow <= 1'b1;
    else
        clk_slow <= 1'b0;

This is used instead of taking the slow clock from the higher counter register tap.
I don't know if I did it completely right way, but the compiler stopped complaining.
I am going to test my code on the hardware. Thank you for the idea, so far.
 

I'm not a Verilog guy, but that doesn't look right to me. Isn't that just going to set clk_slow high forever?

I would look at your constraints. It looks like you're trying to connect an IBUF to a BUFG. I haven't looked at the exact chip you're using, but this might be the problem. And sometimes the synthesis tool will automatically insert buffers when you don't really want them; check that.
 
Last edited:

I'm not a Verilog guy, but that doesn't look right to me. Isn't that just going to set clk_slow high forever?

I would look at your constraints. It looks like you're trying to connect an IBUF to a BUFG. I haven't looked at the exact chip you're using, but this might be the problem. And sometimes the synthesis tool will automatically insert buffers when you don't really want them; check that.


Yes, you are right, this was a typo. Instead of checking the logical value of clk I planned to check the logical value of the divider.

Code:
reg [26:0] divider;

always @(posedge clk)
		divider <= divider + 1;	    

always @(posedge clk)
    if (&(divider))
        clk_slow <= 1'b1;
    else
        clk_slow <= 1'b0;

- - - Updated - - -

EDIT: I have just ran the implementation, it failed again.

It seems that the implementation tool has really added a BUFG element after IBUF.

I tried to comment out the whole section of BCD counter and the implementation went through fine. It seems that the problem is somewhere around the counter itself. I have to finish for today, will try to take look at it tomorrow.
Thank you for your time.
 

Hi,

I'm missing a lot of informations....
* do you want to build an SPI MASTER or an SPI SLAVE?
* what is your system clock frequency?
* How many bits wide is your BCD counter?
* how wide and how deep (do you need) is your FIFO? How do you trigger input and output?
* show a drawing of your signal flow.

*****
* I don't think you need a FIFO. A simple DFF should do the job.
* with correct clock divider implementation ... there is no crossing of clock domain.
(there are many threads, documents, even video tutorials on how to correctly build a clean clock divider. There are a lot of code examples. Which one did you go through to build your code?)

With signal[26] you try to divide your system clock by 2^27.... this is about 129 million. I don't expect "a couple tens of kHz."

Klaus
 

I will only comment about the placement error message of Vivado.

The reason why you are getting this is explained here along with the solution: http://www.xilinx.com/support/answers/64452.html

It seems that the implementation tool has really added a BUFG element after IBUF.
This is very normal for Vivado to inser such BUFs.
 

Can someone confirm, I'm more a VHDL monkey but in Verilog I believe &divider is a reduction-AND operation? Therefore clk_slow is only '0' for one clk, and clk_slow is '1' for many clk's

Regarding original message. In order to diagnose you need to open up the synthesis and look at the schematic, you'll probably see that
1. Synthesis has place a bufG on the netlist in question.
2. The pin is not an actual clock pin. http://www.xilinx.com/support/answers/64452.html
Go to http://www.xilinx.com/support/package-pinout-files.html, find the component you are using.
Read UG475 Chapter 1 & 2, see that
If you were to open the package file pins
Eight columns containing data for each pin:
° Pin—Pin location on the package.
° Pin Name—The name of the assigned pin.
° Memory Byte Group,
etc etc (please read doc)

Go to the pin in question, see if it has GC CC or MRCC or SRCC (these letters indicate if the pin is clock capable, ergo allowing BUFGs etc)

... Edit
Just seen that whilst I was writing this message I was beaten to link. touché ^^
 

Can someone confirm, I'm more a VHDL monkey but in Verilog I believe ÷r is a reduction-AND operation? Therefore clk_slow is only '0' for one clk, and clk_slow is '1' for many clk's
&divider is a reduction AND operation the result is 1'b1 only if all bits of divider are 1'b1.
|divider would be reduction OR
^divider reduction XOR

- - - Updated - - -

Code:
reg [26:0] divider;

always @(posedge clk)
		divider <= divider + 1;	    

always @(posedge clk)
    if (&(divider))
        clk_slow <= 1'b1;
    else
        clk_slow <= 1'b0;
from the above code &divider will only be active for a single clock cycle therefore clk_slow will only be active for a single clock cycle. Normally clk_slow will be low, so clk_slow in this case can also be used as an enable elsewhere in the design.
 

Hi,

I'm missing a lot of informations....
* do you want to build an SPI MASTER or an SPI SLAVE?
* what is your system clock frequency?
* How many bits wide is your BCD counter?
* how wide and how deep (do you need) is your FIFO? How do you trigger input and output?
* show a drawing of your signal flow.

*****
* I don't think you need a FIFO. A simple DFF should do the job.
* with correct clock divider implementation ... there is no crossing of clock domain.
(there are many threads, documents, even video tutorials on how to correctly build a clean clock divider. There are a lot of code examples. Which one did you go through to build your code?)

With signal[26] you try to divide your system clock by 2^27.... this is about 129 million. I don't expect "a couple tens of kHz."

Klaus

Dear Klaus,
1. I need only a SPI master controller to feed the MAX7219 7 segment driver with serial data.
2. My master clock frequency is 125 MHz and is connected to the pin L16 - feeding directly the programmable logic of Zynq XC7Z010.
3. The BCD counter is four decade-wide (16 bits). Possibly in the future to be widened.
4. Originally, I tried resynchronization with a cascade of D flip-flops, but I ran into the same issue. I wanted to identify if the clock boundary crossing method had something to do with that or something else.
5. The FIFO is currently four samples wide. It is triggered by the divided master clock (divclk) because all the rest of the logic is run at this clock frequency.

6. The divider[26] tap was deliberately chosen to provide a very slow frequency to show the counter increments on the 7 segment display. The SPI clock is run from the 17. th register tap.

P.S. according to the Zynq XC7Z010 package file the pin L16 is IO_L11P_T1_SRCC_35 , thus clock capable.

I will add the signal flow diagram as soon as possible and also try to look into proper generation of the clock signal. Please, if you have a good link to recommend, I will appreciate that.
 
Last edited:

Hi,

2. My master clock frequency is 125 MHz
Thus with counter[26] you generate a slow clock of less than 1Hz = 0.001kHz.
--> It takes at least 16 seconds to transmit your 4 digits data.

4) --> show a drawing of what you want to do.

5) --> it is 4 sample deep.... I assume it is 16 bits wide. Please confirm, or show it in the drawing.
all the rest of the logic is run at this clock frequency
--> I assume you did not read through the clock dividing concept. Most (maybe all) of the circuitry needs to be driven by the 125MHz master clock. The divider just controls the "enable".
Again: a drawing of your concept should clarify...

6)
The SPI clock is run from the 17. th register tap.
Even 17.tap is not able to generate clocks in the 10kHz range. You should not have difficulties to calculate this...do you?

Please, if you have a good link to recommend
This is very basic stuff, thus there are many sources for the same information.
I recommend to go to the FPGA manufacturer's internet site.
Don't rely on random people's information. Look for FPGA manufacturers, HDL tools manufacturers, universities....they are reliable.
And they even provide videos and code examples

Klaus
 

Hi,


Thus with counter[26] you generate a slow clock of less than 1Hz = 0.001kHz.
--> It takes at least 16 seconds to transmit your 4 digits data.
Klaus, the clock at 26th tap should be 125MHz/2^26 what is roughly 1.9Hz. The counter updates every clock strike, so transmitting the 16 digits data through parallel interface to the FIFO is at 1.9Hz and not every 16 seconds.
The second side of the FIFO can run at much higher speed.

4) --> show a drawing of what you want to do.

5) --> it is 4 sample deep.... I assume it is 16 bits wide. Please confirm, or show it in the drawing.
Please find attached the full concept what I am trying to do. The SPI interface along with the finite state machine works fine. I tested sending commands to MAX7219 turning the LED display on and showing a couple numbers.

bcd counter.jpg

--> I assume you did not read through the clock dividing concept. Most (maybe all) of the circuitry needs to be driven by the 125MHz master clock. The divider just controls the "enable".
Again: a drawing of your concept should clarify...
Not yet, I am still looking for an appropriate article.

6)
Even 17.tap is not able to generate clocks in the 10kHz range. You should not have difficulties to calculate this...do you?
Sorry for my non-consistent calculations, it should be around 950 kHz in this case. However, this works just fine, since it is within timing specs of MAX7219.


This is very basic stuff, thus there are many sources for the same information.
I recommend to go to the FPGA manufacturer's internet site.
Don't rely on random people's information. Look for FPGA manufacturers, HDL tools manufacturers, universities....they are reliable.
And they even provide videos and code examples
Klaus

Klaus, thank you for this suggestion. I will try looking for rather this type of documents.
 

Hi,

Can you confirm the 1.9Hz?
According my calculation
tap0 is divided by 2^1
tap1 is divided by 2^2
...
tap26 is divided by 2^27

... I'll come back later...

Klaus
 

Klaus, I don't have the code right by hand, but you are right. We don't start numbering from 1 but from zero.
Then the frequency should be halved.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top