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

Question: Possible to test tools without .xdc file? #271

Open
nelsobe opened this issue Mar 11, 2022 · 4 comments
Open

Question: Possible to test tools without .xdc file? #271

nelsobe opened this issue Mar 11, 2022 · 4 comments

Comments

@nelsobe
Copy link
Contributor

nelsobe commented Mar 11, 2022

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...

@acomodi
Copy link
Contributor

acomodi commented Mar 15, 2022

@nelsobe There should be no problem of leaving unmapped I/Os, if you are only interested in the synthesis step only.
In case the tools complain about missing XDC file, you may try and provide an empty one.

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.

@nelsobe
Copy link
Contributor Author

nelsobe commented Mar 17, 2022

@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?

@acomodi
Copy link
Contributor

acomodi commented Mar 18, 2022

@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.

@Pocketkid2
Copy link

Pocketkid2 commented May 10, 2022

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/)

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

No branches or pull requests

3 participants