You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The .net file may specify an "internal feedback" path in a CLB. This means an FLE output has been selected in a "mux" or "complete" construct all inside one block.
That FLE output also drives an OPIN. That OPIN may then connect through 1 or more SBs and then a CB to an IPIN on the same block.
In this case, the OpenFPGA repacker may alter the "mux" or "complete" to select the IPIN instead of the internal feedback.
This makes the path slower (due to the extra SB(s) and CB now in it). The original timing report may no longer apply.
Any of these would be preferable:
Never do this.
Have an option to follow .net exactly.
Write out a new .net to show what OpenFPGA did.
Due to the effect on timing, (3) is not really adequate in this case.
This observed strange behavior seems to imply that OpenFPGA repacking decisions are not costed, i.e., satisfaction of the constraints is the only goal. The result still works; it may have its timing significantly changed.
Thanks.
To Reproduce
Steps to reproduce the behavior:
Clone OpenFPGA repository and checkout commit id:
Execute OpenFPGA task or your own example:
See error
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Enviornment (please complete the following information):
OS:
Compiler:
Version:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered:
The .net file may specify an "internal feedback" path in a CLB. This means an FLE output has been selected in a "mux" or "complete" construct all inside one block.
That FLE output also drives an OPIN. That OPIN may then connect through 1 or more SBs and then a CB to an IPIN on the same block.
In this case, the OpenFPGA repacker may alter the "mux" or "complete" to select the IPIN instead of the internal feedback.
This makes the path slower (due to the extra SB(s) and CB now in it). The original timing report may no longer apply.
Any of these would be preferable:
Due to the effect on timing, (3) is not really adequate in this case.
This observed strange behavior seems to imply that OpenFPGA repacking decisions are not costed, i.e., satisfaction of the constraints is the only goal. The result still works; it may have its timing significantly changed.
Thanks.
The text was updated successfully, but these errors were encountered: