-
Notifications
You must be signed in to change notification settings - Fork 6
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
openXC7 - no Bels remaining of type 'BUFMR' #36
Comments
why do you need to use BUFMR? |
Why not?!
Moreover, due to physical limitations of Artix7 internal architecture and clock routing resources within this particular device, it may not even be possible to cheat that way and mask out the problem. Note that BUFMR is driving two BUFRs:
|
It is difficult to support BUFMR for openxc7 |
@lehaifeng000 Should probably be quite easy to write a fuzzer for it in prjxray |
@hansfbaier Yes, that's right! |
Is the plan then for openXC7 team to pursue this bug to extinction, or for us to try brushing it under the carpet?! |
@Juninho99 as it looks like openXC7 team cannot attend to this bug before late May 2025, we should try to work out a design recipe that avoids the use of BUFMR. |
When using openXC7 (place and route step) we get an error in BUFMR module, 'u_csi_rx_top.u_phy_clk.u_bufmr' to be specific. We know @hansfbaier that you mentioned this could happen in the previous issue (your message: "I already fixed that in my branch, but now the problem is that nextpnr-xilinx does not support BUFM").
Anyways, here is the exact message we've gotten:
ERROR: Unable to place cell 'u_csi_rx_top.u_phy_clk.u_bufmr', no Bels remaining of type 'BUFMR' 2 warnings, 1 error make: *** [Makefile:53: top.fasm] Error 255
These changes are included - fix inverted check condition and error message typos for OSERDESE2 and it fixed previous issue.
Our question now is, what are the next steps?
The text was updated successfully, but these errors were encountered: