cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
15,943 Views
Registered: ‎09-12-2007

Vivado Timing Analyzer not using correct constraint

Jump to solution

I am using Vivado 2013.4. My design is failing a period timing constraint for an 80MHz clock. 100% of the flip-flops in this clock domain are clocked on the rising edge, but the timing report lists 2700 nets that are failing a timing requirement from the falling edge of the clock to the rising edge of the clock. This falling edge to rising edge timing requirement does not exist in either the timing constraints nor the actual design.

Is there either a) a way to specify the timing constraints to be rising edge to rising edge only or b) an improved version of Vivado that can recognize the clock edge used on each net in the design and use the correct timing requirement for that net?

Thanks in advance for your help!
John LeVieux

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
24,998 Views
Registered: ‎09-12-2007

Hi Vivian,

I believe I have discovered why falling edge to rising edge timing requirements were used by timing analyzer in some of the nets in my design.

While reviewing the timing constraints, I realized that the ports in the "get_ports" directive were from a differential I/O clock including 1 non-inverting signal and 1 inverting signal. The timing analyzer handled this by clocking the source flip-flop with the non-inverting differential signal and the destination flip-flop with the inverting differential signal. The source and destination clocks should be an output of a global clock buffer instead of a differential I/O signal.

I expect that changing the timing constraint to use the global clock buffer will resolve my timing requirement issue. I will post an update after I make the change and test it.

Thanks for your support!
John

View solution in original post

0 Kudos
12 Replies
Highlighted
Xilinx Employee
Xilinx Employee
15,939 Views
Registered: ‎09-20-2012
Hi,

Is this rising to falling analysis being done for cross clock domain paths?

You can use set_false_path -rise_from -fall_to to prevent this analysis from being done.

Thanks,
Deepika.
Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,931 Views
Registered: ‎07-16-2008

Can you post the failing timing path for a look?

-------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,928 Views
Registered: ‎05-14-2008

Although it specifies rising-to-falling, falling-to-falling or falling-to-rising in the timing report, the requirement is calculated correctly as rising-to-rising. You can use -unique_pins option for report_timing. This will prevent the timer from returning several times the same topological path.

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
Highlighted
Adventurer
Adventurer
15,913 Views
Registered: ‎09-12-2007

Hi Deepika/,

 

Thanks for the reply post.

 

No, the rising to falling timing analysis was entirely within the 80MHz clock domain and did not involve any other clocks ("Intra-Clock Paths"). The failing timing requirements were from the falling edge of the 80MHz clock to the rising edge of the 80MHz clock. These timing requirements seem to be in error since the flip-flops at both end-points of all nets are clocked on the rising edge in all cases with no exceptions.

 

These erroneous timing requirements may well be causing big problems with the Vivado routing algorithm.

 

Thanks for your support!

John

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,905 Views
Registered: ‎05-14-2008

can you attach your timing report here?

 

-Vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
24,999 Views
Registered: ‎09-12-2007

Hi Vivian,

I believe I have discovered why falling edge to rising edge timing requirements were used by timing analyzer in some of the nets in my design.

While reviewing the timing constraints, I realized that the ports in the "get_ports" directive were from a differential I/O clock including 1 non-inverting signal and 1 inverting signal. The timing analyzer handled this by clocking the source flip-flop with the non-inverting differential signal and the destination flip-flop with the inverting differential signal. The source and destination clocks should be an output of a global clock buffer instead of a differential I/O signal.

I expect that changing the timing constraint to use the global clock buffer will resolve my timing requirement issue. I will post an update after I make the change and test it.

Thanks for your support!
John

View solution in original post

0 Kudos
Highlighted
Adventurer
Adventurer
15,898 Views
Registered: ‎09-12-2007

Hi Vivian,

Changing the timing constraint to use the output of the global clock buffer did indeed fix the issue I had and now the timing analyzer requirements are now 100% rising edge to rising edge.

Thanks for your support!
John

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
15,891 Views
Registered: ‎05-14-2008

can you post your original timing constraints and current timing constraints related to this issue? 

Creating clock on ports should work and is the recommeded way. Are you creating your clock on both the p-side and n-side of the differential clock?

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
15,882 Views
Registered: ‎09-12-2007

The original constraint was referencing the differential version of the clock at the FPGA I/O as follows.

create_clock -period 12.44200038909912100 -name AD_OUTCLK -waveform {0.00000000000000000 6.22100019454956050} [get_ports {AD_OUTCLK_N AD_OUTCLK_P}]

The n-side and p-side of the differential were never directly used. The differential clock was immediately converted into a single-ended version of the clock, connected to a BUFG, then distributed as a global clock to all 100% of the loads.

Still, the timing requirements in Timing Analyzer made the n-side the clock at the source flip-flops and the p-side the clock at the destination flip-flops. This resulted in timing requirements referenced from falling edge to rising edge while the requirements should have been from rising edge to rising edge. These timing requirements did not match the actual design.

Changing the constraint to reference the following net that is the output of the BUFG fixed the incorrect timing requirements.

create_clock -period 12.442 -name CLK_80M -waveform {0.000 6.221} [get_nets Exg2_i/Exgine_Top_Level_1/CLK_80M_OUT]

After making this change, all timing constraints are met.

Thanks for your support!
John

 

0 Kudos
Highlighted
Guide
Guide
10,770 Views
Registered: ‎01-23-2009

You would probably be better off applying the constraint only to the P side input of the differential buffer.

 

When you applied the clock to both the P and N side, it saw two propagation paths for the clock - one non-inverting through the P side and one inverting through the N side.

 

By applying it to the output of the input buffer, your set_input_delay and set_output_delay commands won't be correct, since they will be timed against this internal clock, rather than the clock a the ports of the FPGA.

 

create_clock -period 12.44200038909912100 -name AD_OUTCLK -waveform {0.00000000000000000 6.22100019454956050} [get_ports AD_OUTCLK_P]

 

Avrum

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
10,768 Views
Registered: ‎05-14-2008

John, would you please attach the timing report in which "falling edge to rising edge" is analyzed? I'm curious what the problem looks like.

 

Creating clock on the FPGA I/O port is recommended rather than creating on an internal node such as BUFG. If all your timing paths in your design are inter-clock paths (not crossing clock domain (CDC) paths), this is not a problem. But for CDC paths and input/output paths, this should be taken care of because this affects the clock skew and clock uncertainty calculation.

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
10,745 Views
Registered: ‎09-12-2007

Sorry but I did not save the timing analysis when I was having that problem. I will describe what the analysis reported.

 

That was happening was that the timing analysis for each timing requirement within the clock domain with the differential I/O timing constraint had the source clock referenced to the P-side and the destination clock referenced to the N-side. So the timing requirement ended up being from the falling edge of the clock to the rising edge.

 

0 Kudos