You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi VTR team,
I am striving to achieve a design solution with the shortest possible slack. Despite setting the goal for the solution to 'slack_timing', VPR continues to output a design where several CLBs and multipliers are noticeably placed far from the IOs.
Expected Behaviour
By setting the command options:
--alpha_clustering 1
--place_quench_algorithm slack_timing
--noc_placement_weighting 0
--noc_latency_weighting 0
I expected the worst slack to be the primary consideration for VPR. I utilized VPR to process the netlist from condition_program_first4984.pre-vpr.blif, anticipating a design solution optimized for low slack.
Current Behaviour
Contrary to my expectations, the solution I received was atypical. The multipliers and CLBs were centrally placed within the architecture rather than near the IOs, which are located at the sides. What’s more, a detour path (105,228)->(104,84)->…->(105,228)->(102,65)->(105,229) occurred in the design. The worst slack observed was also below my expectations.
Possible Solution
It is evident that the devices were positioned in inappropriate locations. This issue might stem from an underlying flaw in VTR that needs addressing, or perhaps more explicit operations to prioritize slack in the initial design phase should be implemented.
Steps to Reproduce
Please run the following command:
vpr EArch_fixed_160_230_no_power.xml condition_program_first4984 --circuit_file condition_program_first4984.pre-vpr.blif --device fixed --alpha_clustering 1.0 --noc_placement_weighting 0 --noc_latency_weighting 0 --place_quench_algorithm slack_timing --route_chan_width 100 --noc_swap_percentage 0 --timing_report_detail detailed --timing_report_npaths 100000 --max_router_iterations 150
Context
I am attempting to obtain a high-performance P&R solution but encountered an unexpected detour situation. I would greatly appreciate a prompt response.
I have observed a similar situation with another netlist condition_program_first4681. In this netlist's solution, the register is positioned far from the IOs. I am not sure if these instances are related, so please could you help to clarify? Thank you!
Hi VTR team,
I am striving to achieve a design solution with the shortest possible slack. Despite setting the goal for the solution to 'slack_timing', VPR continues to output a design where several CLBs and multipliers are noticeably placed far from the IOs.
Expected Behaviour
By setting the command options:
--alpha_clustering 1
--place_quench_algorithm slack_timing
--noc_placement_weighting 0
--noc_latency_weighting 0
I expected the worst slack to be the primary consideration for VPR. I utilized VPR to process the netlist from condition_program_first4984.pre-vpr.blif, anticipating a design solution optimized for low slack.
Current Behaviour
Contrary to my expectations, the solution I received was atypical. The multipliers and CLBs were centrally placed within the architecture rather than near the IOs, which are located at the sides. What’s more, a detour path (105,228)->(104,84)->…->(105,228)->(102,65)->(105,229) occurred in the design. The worst slack observed was also below my expectations.
Possible Solution
It is evident that the devices were positioned in inappropriate locations. This issue might stem from an underlying flaw in VTR that needs addressing, or perhaps more explicit operations to prioritize slack in the initial design phase should be implemented.
Steps to Reproduce
Please run the following command:
vpr EArch_fixed_160_230_no_power.xml condition_program_first4984 --circuit_file condition_program_first4984.pre-vpr.blif --device fixed --alpha_clustering 1.0 --noc_placement_weighting 0 --noc_latency_weighting 0 --place_quench_algorithm slack_timing --route_chan_width 100 --noc_swap_percentage 0 --timing_report_detail detailed --timing_report_npaths 100000 --max_router_iterations 150
Context
I am attempting to obtain a high-performance P&R solution but encountered an unexpected detour situation. I would greatly appreciate a prompt response.
Your Environment
CLBs_Positioned_Far_from_IOs.zip
I have observed a similar situation with another netlist condition_program_first4681. In this netlist's solution, the register is positioned far from the IOs. I am not sure if these instances are related, so please could you help to clarify? Thank you!
condition_program_first4681.zip
The text was updated successfully, but these errors were encountered: