cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
438 Views
Registered: ‎01-15-2020

Design fails to satisfy timing requirements when ILA added.

Jump to solution

Hello Xilinx Experts,

We have a curious problem. We have a design that implements fine when run without any ILAs. As you can see from the image, the resource usage is quite modest and everything looks happy. If we add an ILA on a single vector, only 15 bits wide, the timing fails quite badly.

Moreover, it fails in the ILA itself.

I have read some posts about taking the signals out of congested areas and onto VIOs. I have tried some of this with limited success. If I delete half of the design, I can get things to hit timing, but this looses other functionality which is really making debugging painful.

All suggestions and ideas gratefully received.

Phil

 

Tags (4)
Screenshot 2020-02-25 at 10.10.38.png
Screenshot 2020-02-25 at 09.17.47.png
Screenshot 2020-02-25 at 09.16.45.png
Screenshot 2020-02-25 at 09.40.43.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
264 Views
Registered: ‎01-15-2020

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

Many thanks for the rapid response @viviany and @klumsde.

I already had Post-Route phys_opt_design set. Enabling Post-Place phys_opt_design seems to have improved stability somewhat.

I am guessing that this timing instability is caused by congestion in the design. I suspect that we could optimise the design further for this, but right now, I just need to qualify the design for production. I am actually able to split the design down the middle (I can delete half and test functionality and then do the same with the other half). The combination of splitting the design and phys_opt_design seems to give me the stability that I need to get this qualified.

I will come back to the group (and share the path) if I get stuck again, but now I have everything I need to move on.

Thanks again! Phil.

View solution in original post

0 Kudos
5 Replies
Highlighted
Moderator
Moderator
391 Views
Registered: ‎04-18-2011

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

Which version of the tools is this?

I've seen instaces where the ILA which normally is generated with timing exceptions inside the core because there are some cdc paths fails timing because a regular expression is used to apply the exception and now the cell naming is different or something. Let me know whice vivado version it is.

If this path happens to be the one into the ILA from fabric you could try the option to add pipeline stages to the input path

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
0 Kudos
Highlighted
Visitor
Visitor
347 Views
Registered: ‎01-15-2020

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

I have tried Vivado 2019.1 and 2019.2 (various subversions).

I saw the additional pipeline stages technique in a previous post. In some cases, this seems to make it worse.

I am not sure that I understand your comment about the regular expression. Some important points though: firstly this is not my design - I am trying to debug an existing product design. Secondly, I have been keeping the ILA generation super simple - single vector; no advanced triggering.

Your communal thoughts are most welcome.

0 Kudos
Highlighted
Moderator
Moderator
338 Views
Registered: ‎04-18-2011

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

OK

So this is not the path from the fabric to the ILA input, so you are correct adding pipline stages here won't help. 

Also I was assuming this timing problem in the ILA was to do with paths between two clock domains, this has happened from time to time where between versions something changes in the heirarchy and our timing exception in the constraints (which use regular expressions to catch groups of these paths) are no longer correct. 

This seems to be just a failing path in one clock domain. 

maybe look at the path in more detail and share it here. 

since it is setup the two root causes of the timing failure are either the logic in the data path or the routing(which will come back to placement to some extent)

Once you look at this you can look at refining the placement of these cells through additional optimizations. 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Xilinx Employee
Xilinx Employee
322 Views
Registered: ‎05-14-2008

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

It is possible that adding ILA makes timing failed.

The slack is not quite high. 

You can try different implemtation strategies and make use of the phys_opt_design for fanout optimization.

If you could provide the failing path details (double clicking the failing paths to open the details), we can analyze why those paths failed.

-vivian

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

Re: Design fails to satisfy timing requirements when ILA added.

Jump to solution

Many thanks for the rapid response @viviany and @klumsde.

I already had Post-Route phys_opt_design set. Enabling Post-Place phys_opt_design seems to have improved stability somewhat.

I am guessing that this timing instability is caused by congestion in the design. I suspect that we could optimise the design further for this, but right now, I just need to qualify the design for production. I am actually able to split the design down the middle (I can delete half and test functionality and then do the same with the other half). The combination of splitting the design and phys_opt_design seems to give me the stability that I need to get this qualified.

I will come back to the group (and share the path) if I get stuck again, but now I have everything I need to move on.

Thanks again! Phil.

View solution in original post

0 Kudos