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
Fix fasm2bels issues when running with nextpnr #164
Comments
#161 enabled fasm2bels for nextpnr. However, there are errors that show up when running the litex-linux test:
As the resolution says, it may be necessary to get first all the BEL constraints defined and later all the LOC constraints. This would likely double the size of the |
This will not help. Using an XDC file instead of a TCL file may help, unclear. |
New issue found when running with the updated fasm2bels library the blinky test:
There seems to be a net that cannot be found. |
That might be a bug in fasm2bels, or it could be an antenna CARRY4 from nextpnr. There is FASM feature (e.g. CLBLL_L.SLICEL_X0.PRECYINIT.CIN !00_12 30_13 !30_14) that indicates that a COUT -> CIN connection. If that CARRY4 has not outputs, I believe fasm2bels might not emit it. I would argue that nextpnr shouldn't have emitted the CARRY4 in that case, but it is also a bug for fasm2bels to have an antenna route. If you confirm that the PRECYINIT.CIN for the tile above the antenna route is present, then we should fix fasm2bels. It is also worth exploring whether the CARRY4 is an antenna object (no outputs used) and if so, open an issue on nextpnr-xilinx about emission of antenna CARRY4's. If the PRECYINIT.CIN for the tile above the antenna is not present, then this is only a fasm2bels bug. |
It appears that the COUT->CIN connection is there indeed by looking into the fasm output:
This is the output verilog from fasm2bels related to the problematic CARRY: (* KEEP, DONT_TOUCH *)
CARRY4 #(
) CLBLM_R_X39Y73_SLICE_X60Y73_CARRY4 (
.CI(CLBLM_R_X39Y72_SLICE_X60Y72_COUT),
.CO({CLBLM_R_X39Y73_SLICE_X60Y73_D_CY, CLBLM_R_X39Y73_SLICE_X60Y73_C_CY, CLBLM_R_X39Y73_SLICE_X60Y73_B_CY, CLBLM_R_X39Y73_SLICE_X60Y73_A_CY}),
.CYINIT(1'b0),
.DI({CLBLM_R_X39Y73_SLICE_X60Y73_DO5, CLBLM_R_X39Y73_SLICE_X60Y73_CO5, CLBLM_R_X39Y73_SLICE_X60Y73_BO5, CLBLM_R_X39Y73_SLICE_X60Y73_AO5}),
.O({CLBLM_R_X39Y73_SLICE_X60Y73_D_XOR, CLBLM_R_X39Y73_SLICE_X60Y73_C_XOR, CLBLM_R_X39Y73_SLICE_X60Y73_B_XOR, CLBLM_R_X39Y73_SLICE_X60Y73_A_XOR}),
.S({CLBLM_R_X39Y73_SLICE_X60Y73_DO6, CLBLM_R_X39Y73_SLICE_X60Y73_CO6, CLBLM_R_X39Y73_SLICE_X60Y73_BO6, CLBLM_R_X39Y73_SLICE_X60Y73_AO6})
); The CO outputs are not used anywhere, while the O ones are connected to valid nets. |
The error above looks like the CARRY4 at CLBLM_R_X39Y73.SLICEM_X0 is missing. The Verilog you pasted is missing a "LOC=" annotation. |
Actually the LOC should be in the XDC. For vpr-fasm2bels, carry chains slices are LOCed as follows:
These similar lines above are not present in the nextpnr fasm2bels XDC output. I'll investigate that |
Good point. |
After updating fpga-tool-perf to use the latest version of yosys I can now see two issues that block us from having nextpnr bitstreams run through fasm2bels:
|
These may be nextpnr bugs, if nextpnr is not routing the clocks to the additional ports. Should be straight forward to fix. |
There are some errors produced in the fasm2bels flow described here: #159 (comment).
These errors did not show up for the smaller test designs, but rather when running the more complex ones such as the litex-linux one.
The text was updated successfully, but these errors were encountered: