cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
10,079 Views
Registered: ‎10-25-2009

How to solve such timing failed net?

For code:

reg [255:0] pkt_data;

always @ (posedge clk)

 pkt_data <= xxxxx;

 

 

////////////////////////////used here ///////////////////

dpram a (
.....
  .dina(pkt_data),  
......
);

 

dpram b (
.....
  .dina(pkt_data),  
......
);

 

dpram c (
.....
  .dina(pkt_data),  
......
);

 

dpram d (
.....
  .dina(pkt_data),  
......
);

 

After impl, its route timing always be failed, pls see attach screenshot.

 

I want to know for such case, How should I solve the timing problem, re-design the code or choose fitable implementation strategy?

 

Thanks

无标题.png
0 Kudos
6 Replies
viviany
Xilinx Employee
Xilinx Employee
10,076 Views
Registered: ‎05-14-2008

Please provide detaild path analysis of the timing error which is in the Properties Tab when you select the path. The screenshot doesn't provide enough information to debug.

 

-Vivian

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

Hi viviany,

Pls see the attach.

Its logic level is "0", fanout is "4".

From the Device window, we can see tha its route path is long.

 

无标题1.png
0 Kudos
viviany
Xilinx Employee
Xilinx Employee
10,068 Views
Registered: ‎05-14-2008

Hi Jenny,

 

The information on this pane is helpful for debug but what I need is in the "report" area in the path properties window.

 

Based on current information, you can try to reduce the fanout of the register though it is only 4 but it causes the source far from the destination. You can try manually replicating the register in the code or max_fanout attribute.

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

Hi viviany,

 

The report info as attach shows, pls check.

 

And if use max_fanout attribute, if the system will replicate Pkt_data regs automatically?

 

In coming time, I will try manually replicating register. If in this way, I need add "keep_true" attribute?

 

Thanks

无标题3.png
0 Kudos
graces
Moderator
Moderator
10,029 Views
Registered: ‎07-16-2008

The net has a long delay, yet, the fanout is not high. 

It's typically caused by poor placement or congestion, or impacted by poorly written constraints.

 

I'd recommend that you firstly validate the constraints in synthesized design. One important step is to report clock interaction to ensure all CDC paths are properly covered. Otherwise you'll see unrealistic requirement which prevents the tool from optimizing real critical paths.

 

If constraints are good, consider floorplanning or exploring with other implementation strategies.

-----------------------------------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
If starting with Versal take a look at our Versal Design Process Hub and our Versal Blogs.
-----------------------------------------------------------------------------------------------------------------------
0 Kudos
driesd
Xilinx Employee
Xilinx Employee
10,019 Views
Registered: ‎11-28-2007

Hi Jenny,

 

the slack is not extremely high. Routing seems optimal, it's caused by sub-optimal placement.

However, placement needs to estimates route and 180ps is within the margin.

 

I think in this case you should overconstrain placement as outlined in the Ultrafast Methodology Guide UG949:

screenshot_002.jpg

 

You can add this to your implementation script or in project-mode, add a placement pre.tcl file and routing pre.tcl to undo the overconstraining.

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
0 Kudos