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

Flaky xc7 vendor tests #1196

Closed
litghost opened this issue Dec 3, 2019 · 2 comments
Closed

Flaky xc7 vendor tests #1196

litghost opened this issue Dec 3, 2019 · 2 comments
Assignees
@litghost

Comments

@litghost
Copy link
Contributor

litghost commented Dec 3, 2019 •
edited

There are currently two xc7 vendor CI flakes:

1:

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_X1Y18_BUFHCE (BUFHCE.O) is locked to BUFHCE_X1Y18
	The loads are distributed to 1 user pblock constraints. In addition, there are 20 loads not in user pblock constraints.

	Displaying only the first 20 or fewer instances under each constraint as list of loads is too long

And 2:

--- /tmpfs/src/github/symbiflow-arch-defs-presubmit-xc7-vendor/build/xc7/tests/bram_test/bram_test_36/artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test/top.bit.fasm	2019-12-03 11:17:42.766868834 -0800
+++ /tmpfs/src/github/symbiflow-arch-defs-presubmit-xc7-vendor/build/xc7/tests/bram_test/bram_test_36/artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test/design_bram_test_36_vivado.bit.fasm	2019-12-03 11:24:40.031996830 -0800
@@ -4159,7 +4159,6 @@
 INT_L_X6Y114.ER1BEG2.LOGIC_OUTS_L13
 INT_L_X6Y114.FAN_ALT0.GFAN0
 INT_L_X6Y114.FAN_ALT4.GFAN0
-INT_L_X6Y114.FAN_ALT5.FAN_BOUNCE1
 INT_L_X6Y114.GFAN0.GND_WIRE
 INT_L_X6Y114.GFAN1.GND_WIRE
 INT_L_X6Y114.IMUX_L10.GFAN0

I know what the issue is with the second, but I haven't been able to replicate the first locally yet.
@litghost litghost self-assigned this Dec 3, 2019
@acomodi
Copy link
Contributor

acomodi commented Dec 4, 2019

For the first issue my guess would be that the BUFHCE output traverses a clock region to get to another one, producing an invalid route.
This could happen only in the case the clock signal is being routed through logic cells, instead of the dedicated clock network as, to get to another clock region through the dedicated network, the signal should be correctly routed through another BUFHCE.

I suspect this is a kind of issue related to #1153

@litghost litghost mentioned this issue Dec 22, 2019
Merged
@litghost
Copy link
Contributor Author

#1573

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

@litghost litghost

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@litghost @acomodi