-
Notifications
You must be signed in to change notification settings - Fork 33
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
Some DFFRAM configurations have hold violations #139
Comments
@shalan Can you update the handcrafted netlist? |
@donn share with me the timing report(s) to investigate the cause of thes hold vios. |
@shalan I'll have to harvest them- @antonblanchard do you have them on hand? |
Here's an example when building a
|
The hold vio is due to a bad constraint for this input-to-reg timing path. To get this fixed we need to adjust the driving cell constraint for input ports; it should be realistic; e.g., clkbuf_4 instead of inv_1. This would reduce the clock latency and slew at the input. Also, I noticed a few minor issues in the clock tree; fixing them would make it more robust. I discussed the fixes with @donn and they should be out soon. |
Should be fixed now |
Note that the DFFRAM issue has not been fixed: AUCOHL/DFFRAM#139
Okay, so everything but 8x* and the register file should be good now. @antonblanchard Mind testing? |
Thank you @donn, the cache RAMs (32x64_1RW1R) have no hold violations. My main RAM (512x64) still have hold violations unfortunately:
|
|
gosh. @shalan weigh in? |
Note that the DFFRAM issue has not been fixed: AUCOHL/DFFRAM#139
Running STA across the entire design (including the 512x64 DFFRAM):
|
After updating to the latest openlane (which changes STA from using an ideal clock to an actual clock), DFFRAM is seeing hold violations. A simple test:
shows:
The two DFFRAMs in Microwatt I'm using are (that both have hold violations):
The text was updated successfully, but these errors were encountered: