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: 
Explorer
Explorer
438 Views
Registered: ‎06-28-2008

Unusually high hold violations were detected on a large number of pins

Jump to solution

Vivado2017.4, Virtex-7 690T.

I only used a new pair of differential clocks with  relevant constraints such as

period, LOC, io_standard, input_delay and IOB instead of the old ones.

The new ports are MRCC ports.

However,

in Phase 2.4 Update Timing

vidado reported----

Unusually high hold violations were detected on a large number of pins.

This may result in high router runtime.

 

In fact, my project only need one hour to finish implementing before.

Now, it stayed in the route process for a dozen of hours and could NOT finish.

 

What can I do to solve the problem ?

Please help me.

0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
394 Views
Registered: ‎05-14-2008

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

You can check the hold issue after Synthesis. Unusually high hold violations usually caused by suboptimal clock structure or lack of correct CDC constraint (as @hongh pointed out). Those problems can be found post-synthesis.

After synthesis finishes, open synthesized design and run "Tools -> Timing -> Report Timing Summary"

If you need help, you can put your timing report here.

-vivian

-------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------------------------------
如果提供的信息能解决您的问题,请标记为“接受为解决方案”。
如果您认为帖子有帮助,请点击“奖励”。谢谢!
-------------------------------------------------------------------------------------------------
0 Kudos
5 Replies
Scholar dpaul24
Scholar
430 Views
Registered: ‎08-07-2014

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

@jlqsczw_2007,

to get help, show us the violating paths and your constrain file.

--------------------------------------------------------------------------------------------------------
FPGA enthusiast!
All PMs will be ignored
--------------------------------------------------------------------------------------------------------
0 Kudos
Moderator
Moderator
406 Views
Registered: ‎11-04-2010

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

Hi, @jlqsczw_2007 ,

In ISE, the paths between unrelated clocks will not be analyzed, but in Vivado, such paths will still be analyzed automatically. Please confirm you have set the proper timing exception constraint, such as set_false_paths/ set_clock_group for the paths cross asynchronous clock domains. 

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

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

You can check the hold issue after Synthesis. Unusually high hold violations usually caused by suboptimal clock structure or lack of correct CDC constraint (as @hongh pointed out). Those problems can be found post-synthesis.

After synthesis finishes, open synthesized design and run "Tools -> Timing -> Report Timing Summary"

If you need help, you can put your timing report here.

-vivian

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

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

 

I used to  think that timing summary could only be read after place and route.

Now after reading ug949,  I opened the clock interaction report after synthesis.

Then I added set_clock_group constraints for those with large hold violations.

And it worked. This could save me more time later.

Thanks.

 

0 Kudos
Historian
Historian
331 Views
Registered: ‎01-23-2009

Re: Unusually high hold violations were detected on a large number of pins

Jump to solution

Then I added set_clock_group constraints for those with large hold violations.

Whoa!

Just because you have large hold time violations between clock domains is not a sufficient reason to simply put the clocks in separate clock groups.

Since you have hold time violations, this means that there are paths between these domains. If that is the case then every path between the domains needs to be analyzed and a proper clock domain crossing circuit (CDCC) is required for each interface going between domains. Each interface may have different requirements in terms of width, amount of data crossing the clock domain boundary, encoding of the data, etc..., and hence each one may require a different kind of CDCC.

Each implemented CDCC will require some kind of timing exception on the actual path crossing the clock domain boundaries (which is now a path inside the CDCC). The correct exception is determined based on the CDCC style. Once you have analyzed all clock domain crossings, placed the approprate CDCC on each interface, and implemented the correct exception constraints for each CDCC then you have solved your hold time problems.

What you have done now (putting the clocks in different clock groups) is merely masking the underlying problem. If you have illegal clock domain crossings, then your system will fail in real life, in spite of the fact that there are no timing violations.

Avrum