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.

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

timing: Move towards DelayPairs for timing analysis #1359

Merged
merged 1 commit into from
Sep 11, 2024

Conversation

rowanG077
Copy link
Contributor

@rowanG077 rowanG077 commented Sep 6, 2024

My plan is to first implement hold time violations report. This will happen in the next PR. This PR is only moving more things in the timing engine and the reporting to DelayPair. Once that is done I can use the DelayPairs to implement a hold time violation report.

After the hold time reports I will add false path min/max delay using the same mechanism.

TODO:

  • Run performance difference on realistic design.
  • Verify same timing output

@rowanG077
Copy link
Contributor Author

rowanG077 commented Sep 6, 2024

Ran a 20K lut design through it 5 times. There seems to be no runtime change or it is drowned out by measurement error.

Timing information reported was the same. I compared the detailed net timings in two json reports using the same seed. This PR does change the json report slightly as now it outputs both the min and max delay.

@rowanG077 rowanG077 marked this pull request as ready for review September 6, 2024 19:17
@rowanG077 rowanG077 changed the title timing: Move towards DelayPairs for timing reporting timing: Move towards DelayPairs for timing analysis Sep 6, 2024
@gatecat gatecat merged commit 8d0f52f into YosysHQ:master Sep 11, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants