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.

Sign up for GitHub

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

Jump to bottom

Complex designs take long time to run through fasm2bels #1351

Closed
acomodi opened this issue Feb 27, 2020 · 3 comments
Closed

Complex designs take long time to run through fasm2bels #1351

acomodi opened this issue Feb 27, 2020 · 3 comments

Comments

@acomodi
Copy link
Contributor

acomodi commented Feb 27, 2020

There are complex designs such as the one introduced in #1320, that take a huge amount of time to get placed and routed using Vivado.

I need to gather more data on what is the bottleneck of the process, but from local runs I can say the various bottlenecks are the following:

  • parsing huge .tcl scripts in Vivado containing LOC and route constraints
  • running DRC checks for each step (place, route, bitstream generation) in Vivado
  • placing design in Vivado: even though everything is LOCed, Vivado placer still takes a huge amount of time to go through this step.
@acomodi acomodi changed the title Complex design take long time to run through fasm2bels Complex designs take long time to run through fasm2bels Feb 27, 2020
@litghost
Copy link
Contributor

So something I observed when debugging #1346 is that write_bitstream sometimes works without place_design and route_design. This is likely a result of the input being fully constrained. We could explore what it would take for a fully constrained design to always be provided to Vivado by commenting out the place_design and route_design options.

@acomodi
Copy link
Contributor Author

acomodi commented Feb 27, 2020

I will try to see if this solution works locally. If it is successful for the local runs, I can open a PR to remove place and route design from the runme.tcl

@litghost
Copy link
Contributor

This has been addressed both by improving the speed of Verilog/XDC and by adding interchange support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@litghost @acomodi