-
Notifications
You must be signed in to change notification settings - Fork 412
[STA] Generating SDC Commands Post-Implementation #3016
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
[STA] Generating SDC Commands Post-Implementation #3016
Conversation
e79415e
to
bb690a5
Compare
@vaughnbetz This is the PR which adds the ability to generate a post-implementation SDC file, as I presented at the meeting this afternoon. Based on the feedback, I have modified it to always set (non-virtual) clocks to propagated; even when the clock model is set to ideal. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few nits, but looks good.
|
||
// Ideal and routed clocks are handled by the code below. Other clock models | ||
// like dedicated routing are not supported yet. | ||
if (clock_modeling != e_clock_modeling::ROUTED_CLOCK && clock_modeling != e_clock_modeling::IDEAL_CLOCK) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should work. We should already extract the delays and your code path presumably already writes those out as propagated clock delays.
Mustafa Abbas has some tests for routing dedicated clocks; you could find one of those and use it to test this functionality. If it works, remove the if.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, I tried this and it mostly worked by the CPD was off by 0.003 ns for the test circuit I used (the CLMA example with an H-tree clock network).
I am not sure where this discrepancy is coming from, the timing graph in open STA seems sounds; I think it may be an issue with the API calls used to parse the timing data from Tatum into the SDF file. Left a TODO to look into this so that this does not block this PR from getting merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. I'd enable it then. For the small difference: I agree it's not a blocking issue. I'd look closely at the clock path delays. Perhaps we have a min/max spread and openSTA is doing some clock pessimism removal or some such? If you get listings of the critical paths (including clock delays) in both flows I can go over it with you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood. I will raise an issue today to track this. The issue seemed to be caused by the edge delays of clocks reported by Tatum not matching what was written in the SDF file. All paths reported by OpenSTA were off by 0.003 ns.
bb690a5
to
2ef5f6c
Compare
Added an option to have VPR generate an SDC file containing the timing commands required for an external timing analysis of the post- implementation netlist to match VPR's timing analysis.
2ef5f6c
to
0b1a577
Compare
369623f
into
verilog-to-routing:master
Added an option to have VPR generate an SDC file containing the timing commands required for an external timing analysis of the post- implementation netlist to match VPR's timing analysis.