cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
alexis_jp
Explorer
Explorer
243 Views
Registered: ‎09-10-2019

Timing analysis: use case?

Jump to solution

To avoid wasting time waiting for the end of the implementation to have an idea of which paths might fail, I try to run the Timing summary after the synthesis.

All the xilinx IP cores we use in our design have timings inside the core with way too many failing endpoints.

alexis_jp_3-1618367868988.png

Example with the DDR4 MIG:

alexis_jp_0-1618367664542.png

alexis_jp_4-1618368018700.png

alexis_jp_1-1618367829153.png

alexis_jp_2-1618367849559.png

Same for the MMCM, PCIe Hard IP core, GTYs,

 

  • What's the point of using the Synthesis' timing analysis if it provides completely wrong data?
  • What's the use case in which this can be useful for someone?
  • Any explanation regarding these results?
  • Is something wrong in my project/Xilinx cores?
0 Kudos
1 Solution

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

As the design hasn't been placed or routed, the net delays in the post-synthesis timing report is estimated based on the logic connections and fanout.

As a result the timing result is not accurate. Paths that are flagged as "fail" post-Synthesis would be fixed after routing.

In general, you can focus on the paths with slack larger than 300ps (e.g. -0.4xx ns), especially for very large negative slack.

Those paths may have significant problems like high logic level, high fanout, suboptimal clock topology, or incorrect CDC constraints.

Fixing those problems in the early stage of the design flow would save time and reduce design iterations.

Hope this helps.

-vivian

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

View solution in original post

2 Replies
viviany
Xilinx Employee
Xilinx Employee
238 Views
Registered: ‎05-14-2008

As the design hasn't been placed or routed, the net delays in the post-synthesis timing report is estimated based on the logic connections and fanout.

As a result the timing result is not accurate. Paths that are flagged as "fail" post-Synthesis would be fixed after routing.

In general, you can focus on the paths with slack larger than 300ps (e.g. -0.4xx ns), especially for very large negative slack.

Those paths may have significant problems like high logic level, high fanout, suboptimal clock topology, or incorrect CDC constraints.

Fixing those problems in the early stage of the design flow would save time and reduce design iterations.

Hope this helps.

-vivian

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

View solution in original post

alexis_jp
Explorer
Explorer
215 Views
Registered: ‎09-10-2019

Thank you @viviany.

I would have expected to see that in ug901.
I understand I should care on timing >300ps only and ignore everything else.

0 Kudos