04-23-2014 06:39 PM
reg [255:0] pkt_data;
always @ (posedge clk)
pkt_data <= xxxxx;
////////////////////////////used here ///////////////////
dpram a (
dpram b (
dpram c (
dpram d (
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?
04-23-2014 06:43 PM
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.
04-23-2014 06:51 PM
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.
04-23-2014 07:08 PM
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.
04-23-2014 07:41 PM
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?
04-24-2014 01:52 AM - edited 04-24-2014 01:53 AM
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.
04-24-2014 05:47 AM
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:
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.