• 0
greedyhao

Timing constraints are not met.

Question

Hello,

When I following The Zynq Book Tutorials(exercises 5b) , I met a error unfortunately. It says that 'Timing constraints are not met.'.

I have no idea how to solve it. Could anybody do me a favor.

DeepinScreenshot_select-area_20181008221007.thumb.png.8ed9da8db8675260209663b169fa7897.png

timing_1.rpx

------

More detail shows below:

DeepinScreenshot_select-area_20181009125427.thumb.png.d0aaa51b6ee4c28b0f447b1d133029fa.png

Edited by greedyhao

Share this post


Link to post
Share on other sites

11 answers to this question

Recommended Posts

  • 0

Hi,

I also did tutorials but didn't occur this problem. However, you can set false path or create clock group to fix your timing error.

 

Reference: https://www.beyond-circuits.com/wordpress/tutorial/tutorial16/

Share this post


Link to post
Share on other sites
  • 0

To solve a timing problem, you need to dig into the timing report. From your screenshot, we can see there are failing intra-clock timing constraints on clk_fpga_0. In order to resolve the failures, you need to look at what paths are failing.

You posted the .rpx file but it's easier to look at the report outside Vivado.

Share this post


Link to post
Share on other sites
  • 0

Hi @n3wbie,

Thank you for your reply. I had looked through the link you offered.

But I still don't know set which two clock into a group. Please forgive my poor knowledge of the fpga.

Regards,

Share this post


Link to post
Share on other sites
  • 0

Hi @greedyhao,

Go to Implementation -> Edit Timing Constraints -> Set Clock Groups

1513002577_Screenshotfrom2018-10-0915-06-20.thumb.png.0279cc1c7dd4a7de6ed01b8f42fa8e77.png

 

Then another window will open and you just have to put the names of clock there:

32340720_Screenshotfrom2018-10-0915-10-10.thumb.png.5b77b9f9802f74ce99356e2f293962be.png

Hope this helps. :)

Share this post


Link to post
Share on other sites
  • 0

is it possible that this block isn't meant to be used at 100 MHz?

There are 27 levels of logic, the signal needs 18 ns through the transistors alone plus another 15 ns for routing delay. The design demands the signal to be ready after 10 ns...

I may be wrong, observing from the distance, but this looks like a typical beginner mistake in the "IP block" (if this is 3rd party, non-Xilinx): Leave sufficient registers = delay in any non-critical path. Done consistently, it will also speed up P&R tremendously - the  job gets so much easier.
If it were an output from the IP block, you could fix the situation by running the output through a chain of ~ 5 registers, and turning register rebalancing on in the options.

But, I suspect, this was tested with a lower-frequency clock (e.g. 12 MHz from USB is popular)

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now