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

VCC incorrectly routed through a FAN_BOUNCE pip #1400

Closed
acomodi opened this issue Apr 7, 2020 · 2 comments · Fixed by #1573
Closed

VCC incorrectly routed through a FAN_BOUNCE pip #1400

acomodi opened this issue Apr 7, 2020 · 2 comments · Fixed by #1573

Comments

@acomodi
Copy link
Contributor

acomodi commented Apr 7, 2020

There is an issue for which the diff fasm tests fail when running the bram_test_36 test.
The failure is generated by a wrong routing to the constant VCC net of some of the pins of teh BRAM36.

The "wrong" route passes through an additional FAN_BOUNCE pip instead of connecting directly to the VCC_WIRE. As a result, fasm2bels wrongly computes the fixed route, generating a difference in the fasm files.

Even though this is not a critical error, meaning that the route is still valid, there is no straightforward way to teach fasm2bels to take into account the extra-jump to the BOUNCE pip.

One thing to notice is that, at least locally, using the binary heap for the router, helped to solve the problem, but, as discussed in #1386, the problem should not depend on the type of heap used, probably, with different seeds and multiple runs, also the binary heap would fail eventually.

@litghost
Copy link
Contributor

litghost commented Apr 7, 2020

As a result, fasm2bels wrongly computes the fixed route, generating a difference in the fasm files.

The bug is in neither fasm2bels nor fasm2frames. Both tools a respecting the inputs they were given. The problem is in VPR (or other tool) and the routes it chooses. The solution is definitely not to modify fasm2bels, as the underlying bitstreeam uses the additional pip. A filter before fasm2frames or in fasm2frames is valid, or a change to VPR.

@acomodi acomodi changed the title Diff tests fail for BRAM test 36 VCC incorrectly routed through a FAN_BOUNCE pip Apr 16, 2020
@acomodi
Copy link
Contributor Author

acomodi commented Apr 16, 2020

Seen this in another vendor tool ci run as well, this time on the murax test.

@@ -9069,7 +9069,6 @@
 INT_L_X6Y110.CLK_L1.FAN_BOUNCE5
 INT_L_X6Y110.CTRL_L0.FAN_BOUNCE1
 INT_L_X6Y110.CTRL_L1.FAN_BOUNCE1
-INT_L_X6Y110.FAN_ALT5.FAN_BOUNCE1
 INT_L_X6Y110.GFAN0.GND_WIRE
 INT_L_X6Y110.GFAN1.GND_WIRE
 INT_L_X6Y110.IMUX_L25.GFAN0
@@ -9281,7 +9280,6 @@
 INT_L_X6Y114.CTRL_L0.FAN_BOUNCE1
 INT_L_X6Y114.CTRL_L1.FAN_BOUNCE1
 INT_L_X6Y114.ER1BEG1.LOGIC_OUTS_L8
-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
@@ -9954,7 +9952,6 @@
 INT_L_X6Y135.ER1BEG2.ER1END1
 INT_L_X6Y135.ER1BEG3.ER1END2
 INT_L_X6Y135.ER1BEG_S0.SR1END3
-INT_L_X6Y135.FAN_ALT5.FAN_BOUNCE1
 INT_L_X6Y135.GFAN0.GND_WIRE
 INT_L_X6Y135.GFAN1.GND_WIRE
 INT_L_X6Y135.IMUX_L25.GFAN0
@@ -10181,7 +10178,6 @@
 INT_L_X6Y139.CLK_L1.FAN_BOUNCE5
 INT_L_X6Y139.CTRL_L0.FAN_BOUNCE1
 INT_L_X6Y139.CTRL_L1.FAN_BOUNCE1
-INT_L_X6Y139.FAN_ALT5.FAN_BOUNCE1
 INT_L_X6Y139.GFAN0.GND_WIRE
 INT_L_X6Y139.GFAN1.GND_WIRE
 INT_L_X6Y139.IMUX_L10.GFAN0

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

Successfully merging a pull request may close this issue.

2 participants