-
Notifications
You must be signed in to change notification settings - Fork 78
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
Question: Possible to test tools without .xdc file? #271
Comments
@nelsobe There should be no problem of leaving unmapped I/Os, if you are only interested in the synthesis step only. For P&R this makes it a bit more challenging, and random mapping of IOs might result in an unroutability error later in the flow. |
@acomodi Thanks for the reply. This is helpful. When you talk about random mapping of IOs, are you saying there is a way to ask the tools to map them (and they will be random) or are you saying we would need to do the random mapping ourselves? |
@nelsobe By default, at least for VPR, the I/O mapping happens similarly as any other block in the device, that is that it will be handled by the placer algorithm, so the outcome will be "random" in the sense that it will be automatically be placed by the tool. |
Yesterday I ran a basys3 project through symbiflow via Edalize and discovered that without having the constraints file the vpr_io_place script fails altogether due to a runtime error. I initially fixed it by adding square brackets to allow for an empty array but I think a better solution is to warn the user if there's no constraints and they haven't flagged that that's what they want. Edit: The error happens at line 193 in the file vpr_io_place.py ($INSTALL_DIR/$FPGA_FAM/install/share/symbiflow/scripts/) |
When a design won't go through the tools it would be nice to be able to narrow down the issue by only compiling the individual module with the problem and posting the results with the issue. However, to do so requires an .xdc file be created, which is painstaking for modules with lots of I/O. Case in point: we have a simple memory module failing synthesis, presumably because Yosys doesn't like BRAM code with conditional reads. The small module in question (embedded in the bigger design) has, maybe, 8 lines of behavioral code but 60+ bits of I/O.
In Vivado there is a Tcl directive that says, essentially: "Don't complain about unmapped I/O" so that you can quickly synthesize such modules.
Does f4pga-examples have any way to do this? It would make providing examples of modules that are failing the front end tools much easier... I do realize that at some point you need to have mapped I/O for the remainder of the tool flow to complete, but when the problem is a synthesis/techmapping problem having such a capability would be quite useful...
The text was updated successfully, but these errors were encountered: