Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packing Devices from Two Separate Parts of a Netlist into a Single CLB #2726

Open
WindFrank opened this issue Sep 17, 2024 · 1 comment
Open

Comments

@WindFrank
Copy link

WindFrank commented Sep 17, 2024

Packing Devices from Two Separate Parts of a Netlist into a Single CLB
Hi VTR team,
I merged two netlists into a single BLIF file and used VPR to obtain its design solution on the architecture. However, I noticed that the worst slack of the solution was much lower than expected.

solution_whole

solution_abnormal_clb

Expected Behaviour

It would be more optimal if the devices from the two netlists were packed into two separate CLBs and placed closer to their respective IOs.

Current Behaviour

Upon reviewing the design, I found that a single CLB contained devices from both merged netlists. VPR had to consider the connections from this CLB to the IOs on two opposite sides of the architecture, resulting in the CLB being placed in the middle of the architecture.

Possible Solution

I have experimented with the command options for Packing and Placement as outlined in the VTR documentation, but have seen no improvement. I suspect that the packing algorithm may need to be examined for potential bugs. Additionally, it might be beneficial for the VTR flow to consider implementing a strategy that involves splitting inappropriately packed CLBs.

Steps to Reproduce

Run the following command:
vpr EArch_fixed_160_230_no_power.xml condition_program_first2713_and_condition_program_first5685.pre-vpr --circuit_file condition_program_first2713_and_condition_program_first5685.pre-vpr.blif --device fixed --route_chan_width 100 --alpha_clustering 1 --place_quench_algorithm slack_timing --noc_placement_weighting 0 --noc_latency_weighting 0 --noc_swap_percentage 0 --timing_report_detail detailed --timing_report_npaths 100000 --fix_clusters condition_program_first2713_and_condition_program_first5685_fixed_pin.place

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

@WindFrank
Copy link
Author

Same_structure_on_VTR_master
I encountered the same situation in the VTR-master as of October 4th. The FLE named condition_program_first2713^MIN~52-0[0] was placed far from other CLBs or IOs closely related to it, which contributed to poorer slack.

I am currently researching how to optimize placement by analyzing the graph structure of a netlist. To avoid such abnormal test cases and achieve better QoR, a more appropriate weight calculation may be necessary. Could you please review this case? I would appreciate any help to improve VTR. Thank you. @vaughnbetz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant