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.

Sign up for GitHub

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

Jump to bottom

Poor BUFH placement from VPR #1249

Closed
litghost opened this issue Feb 20, 2020 · 2 comments
Closed

Poor BUFH placement from VPR #1249

litghost opened this issue Feb 20, 2020 · 2 comments
Assignees
@litghost @acomodi

Comments

@litghost
Copy link
Contributor

The xc7 vendor CI has been frequently failing with errors like:

ERROR: [Place 30-176] Unroutable Placement! The following clock source instance is driving the following locked load instances. The clock source instance is placed too far away from its load instance to be routable. 
	CLK_HROW_TOP_R_X60Y78_BUFHCE_X1Y20_BUFHCE (BUFHCE.O) is locked to BUFHCE_X1Y20
	$auto$simplemap.cc:420:simplemap_dff$29920CLBLM_R_X35Y110_SLICE_X54Y110_B5_FDRE (FDRE.C) is locked to SLICE_X54Y110
	$auto$simplemap.cc:442:simplemap_dffe$29886CLBLM_R_X33Y111_SLICE_X52Y111_C_FDRE (FDRE.C) is locked to SLICE_X52Y111
	$auto$simplemap.cc:442:simplemap_dffe$29885CLBLM_R_X33Y111_SLICE_X52Y111_B_FDRE (FDRE.C) is locked to SLICE_X52Y111
	$auto$simplemap.cc:442:simplemap_dffe$29884CLBLM_R_X33Y111_SLICE_X52Y111_D_FDRE (FDRE.C) is locked to SLICE_X52Y111
	FDPE_7CLBLL_R_X31Y61_SLICE_X48Y61_D_FDPE (FDPE.C) is locked to SLICE_X48Y61
	FDPE_6CLBLL_R_X31Y61_SLICE_X48Y61_B_FDPE (FDPE.C) is locked to SLICE_X48Y61
	CLBLM_R_X35Y110_SLICE_X55Y110_A_FDRE (FDRE.C) is locked to SLICE_X55Y110

	The above error could possibly be related to other connected instances. Following is a list of 
	all the related clock rules and their respective instances.

	Clock Rule: rule_bufh_bufr_ramb
	Status: PASS 
	Rule Description: Reginal buffers in the same clock region must drive a total number of brams less
	than the capacity of the region
	CLK_HROW_TOP_R_X60Y78_BUFHCE_X1Y20_BUFHCE (BUFHCE.O) is locked to BUFHCE_X1Y20

ERROR: [Place 30-99] Placer failed with error: 'IO Clock Placer failed'
Please review all ERROR, CRITICAL WARNING, and WARNING messages during placement to understand the cause for failure.

A penalty cost was added to avoid the GCLK -> GFAN path, which helped but did not completely resolve the issue. I believe the lingering problem is the use of bounding boxes with clock nets.

If the bounding box from the BUFG to the clock sink excludes the BUFH for the respective clock region, the router will only find the route via the GCLK -> GFAN path.

My proposed solution is 3 steps:

  1. Identified which connections sink at a clock
  2. Always use the full device bb for clock connections to avoid the BUFG -> BUFH -> destination problem. This is okay because the clock nets are restricted in terms of low cost paths
  3. Set the criticality of clock nets very high, so that min delay is followed

@acomodi Have you started any of the above steps? I believe we briefly discussed them on several occasions.
@acomodi
Copy link
Contributor

acomodi commented Feb 20, 2020

@litghost So, I think I better understand what is going on here.

The router is not able to look far enough to see that there is a BUFHCE that can be used to route the clock net and, even though the cost is pretty high, it chooses to get through general interconnect, correct?

By using the full bb cost, we can have the router exploring also the correct dedicated clock network, hence letting it choose the correct path.

Have you started any of the above steps

Not yet, I have just looked into the relevant code and checked where the changes should be applied, but that is still on hold actually. Now that DDR stuff are getting merged, I think I can focus on this issue more

@litghost
Copy link
Contributor Author

Wrong project, moved to f4pga/f4pga-arch-defs#1328

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@litghost litghost

@acomodi acomodi

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@litghost @acomodi