UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Observer swseo83
Observer
686 Views
Registered: ‎05-23-2017

Why Source Clock Path is too long?

Jump to solution

Hello.

 

Why Source Clock Path is too long for my design? There is nothing around input clock port.

What can be the possible reason for it?

 

Thank you.

 

 

SourceClockPathIsTooLong.jpg
0 Kudos
1 Solution

Accepted Solutions
Scholar watari
Scholar
675 Views
Registered: ‎06-16-2013

Re: Why Source Clock Path is too long?

Jump to solution

Hi @swseo83

 

It's location issue between input port and output port.

 

According to your log file, USB_PKTEND of output signal is located on M17 (near SLICE_X0Y150).

However, clk_usb as input clock is localed on V18.

Therefore, because of the distance between V18 and M17 is so far, source clock path is too long even if there is nothing around input clock port.

 

Best regards,

0 Kudos
7 Replies
Scholar watari
Scholar
676 Views
Registered: ‎06-16-2013

Re: Why Source Clock Path is too long?

Jump to solution

Hi @swseo83

 

It's location issue between input port and output port.

 

According to your log file, USB_PKTEND of output signal is located on M17 (near SLICE_X0Y150).

However, clk_usb as input clock is localed on V18.

Therefore, because of the distance between V18 and M17 is so far, source clock path is too long even if there is nothing around input clock port.

 

Best regards,

0 Kudos
Moderator
Moderator
670 Views
Registered: ‎01-16-2013

Re: Why Source Clock Path is too long?

Jump to solution

Hi,

This looks like output interface of your design.

What exactly constraints you have provided for this interface? 

The clock path looks long because of placement of source element and routing involved.

Also I have seen that your OBUF is driven directly from LUT without even registering the data. This is not recommended practice. You can register the output of last LUT into FF and the connect FF to OBUF that is recommended way.

Thanks,
Yash

 

0 Kudos
Observer swseo83
Observer
630 Views
Registered: ‎05-23-2017

Re: Why Source Clock Path is too long?

Jump to solution
Thank you for your quick reply.

There is an output delay constraint for the issue.
but, I think it does not cause the problem.

set_output_delay -clock [get_clocks clk_usb] -min 2.000 [get_ports {{USB_ABUS[0]} {USB_ABUS[1]} USB_CSn USB_OEn USB_PKTEND USB_RDn USB_WRn}]
set_output_delay -clock [get_clocks clk_usb] -max 0.500 [get_ports {{USB_ABUS[0]} {USB_ABUS[1]} USB_CSn USB_OEn USB_PKTEND USB_RDn USB_WRn}]
0 Kudos
Historian
Historian
623 Views
Registered: ‎01-23-2009

Re: Why Source Clock Path is too long?

Jump to solution

The source clock delay actually has nothing to do with the placement of the clock input or the output buffer.

What you have here is a clock capable pin driving a BUFG. The BUFG is a global clock buffer. From the BUFG (which is located in the middle of the die), the clock can reach all clocked cells. The arrival time of the clock at all these cells is almost identical - that is the purpose of the global clock network, the clock is distributed with as little skew as possible. So it doesn't matter if the clocked cell (the flip-flop) is in one corner, the other corner or anywhere in between the delay of the global clock network is more or less the same.

And that is the reason why the delay is so long. In order to be able to propagate to all cells (with little skew) the insertion delay is quite large. The insertion delay, in this case, includes the delay through the IBUF bringing the clock in (which is at the edge of the die), the route bringing the clock to the BUFG (in the center) and the global clock net delay which distributes the clock to the entire FPGA with little skew. Assuming that pin V18 is a clock capable pin then this delay is basically fixed (if V18 is not fixed and you are using CLOCK_DEDICATED_ROUTE=FALSE then the path from the IBUF to the BUFG will be larger than normal). And it is expected - it is not "too long" it is as long as it needs to be.

Consequently, there is no way to get the data out of the FPGA within one clock period - at least not with this clock insertion architecture. It is specifically because of this that Xilinx provides a mechanism to deskew the input clock - the MMCM is designed to be able to cancel out the majority of this insertion delay. To do this, though, you need to change your current clock architecture (direct to BUFG) to an architecture that uses the MMCM. An example of this is shown in UG472, figure 3-11 (in version 1.14) in the section "MMCM and PLL Use Models". This will reduce your clock insertion and make it "more possible" to get the data out within one 10ns clock period.

Also, trying to drive an interface this way is not recommended. Whenever possible, the output of the FPGA should come directly from an IOB flip-flop. Your interface uses a fabric flip-flop with some combinatorial logic after it to drive the OBUF. This leads to poor timing performance. If possible you should redesign your interface so that the outputs come directly from flip-flops (with no combinatorial logic) - when done this way, and with the IOB property of the port set to TRUE, the flip-flop will be placed in the IOB.

Finally, your constraints are clearly incorrect - it is not possible to have a set_output_delay -max that is smaller than the -min - this just doesn't make sense. The -max should be the setup time requirement of your external device and the -min should be the negative hold of your device. Your constraints are saying your external device needs 0.5ns setup, so the data must be valid no later than 0.5ns before the clock edge, and a hold time of -2ns, which means that the data can become invalid 2ns before the clock edge; 1.5ns before it becomes valid. This is clearly impossible...

Avrum

0 Kudos
Observer swseo83
Observer
610 Views
Registered: ‎05-23-2017

Re: Why Source Clock Path is too long?

Jump to solution
Thank you very much for your kind and detailed explanation.
As you mentioned, I realized that something wrong for the timing constraints and correct them as below.
set_output_delay -clock [get_clocks clk_usb] -max 2.000 [get_ports {{USB_ABUS[0]} {USB_ABUS[1]} USB_CSn USB_OEn USB_PKTEND USB_RDn USB_WRn}]
set_output_delay -clock [get_clocks clk_usb] -min -0.500 [get_ports {{USB_ABUS[0]} {USB_ABUS[1]} USB_CSn USB_OEn USB_PKTEND USB_RDn USB_WRn}]

I would also like to use MMCM, but it is not likely to utilize it because of the input data coming from an external device, as we posted for the issue, linked in https://forums.xilinx.com/t5/Timing-Analysis/How-to-match-the-phase-of-the-clock/td-p/919734.

Thank you.
0 Kudos
Highlighted
Observer swseo83
Observer
563 Views
Registered: ‎05-23-2017

Re: Why Source Clock Path is too long?

Jump to solution
I am trying to use MMCM as you said. However, I encountered the following issue:
There is still uncertainty in communicating with the external device because the input clock and the output clock generated by the MMCM do not exactly coincide in phase.

1. When using an externally generated clock, the length of the Source Clock Path is too long to satisfy the timing constraints.
2. Using the internal MMCM, the timing constraints can be satisfied, but the Timing Reports can not be relied upon due to the phase difference between the incoming and outgoing clocks entering the MMCM.

https://forums.xilinx.com/t5/Timing-Analysis/How-to-align-the-phase-of-the-output-clock-which-is-generated-by/m-p/920744
0 Kudos
Historian
Historian
540 Views
Registered: ‎01-23-2009

Re: Why Source Clock Path is too long?

Jump to solution

but the Timing Reports can not be relied upon due to the phase difference between the incoming and outgoing clocks entering the MMCM.

This is just not true. See my response in that other thread - a phase error from the MMCM is completely normal and expected. Furthermore, the timing analysis done by the tool is correct - if there is a phase error from the MMCM this is factored in to the timing analysis of the design. If constraints are constructed correctly and the tool says the design meets timing then it will work - taking into consideration all factors inside the FPGA.

Avrum

0 Kudos