-
Notifications
You must be signed in to change notification settings - Fork 9
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
[Branch] carry-rework #40
Comments
|
The CARRY4 we use with VPR is different than the vendor one due to a limitation in how VPR models carry chains. VPR had (and probably still has) has limitation on how carry chains are defined. Specifically if the carry chain can both reach the dedicated fabric and the general routing fabric, it doesn't work correctly. Because of this limitation, the There is also the fact that unregistered In the long run, these limitations will be removed, but they are not a priority right now as this branch modifies the |
Sorry, my impression from #43 is that we wanted to work towards driving this delta down to zero @mithro? If so, let me study the problem some more and see if there's a more elegant way of achieving this, now that the flow has evolved some more... |
Yosys currently already has a custom CARRY4 for VPR, this branch updates it based on the |
Why did we need this? (what does this change enable us to do)
VPR uses a different model for how the CARRY4 works.
This is needed because "chain" pack patterns must only have one root pin.
See
What did it change?
Combines the 4 * CARRY modules found in a slice into a CARRY4 module.
Should it be merged upstream - if not, when can we delete it?
When VPR supports generic tree style pack patterns for carry chains.
The text was updated successfully, but these errors were encountered: