-
Notifications
You must be signed in to change notification settings - Fork 950
ram: integrate OpenSTA for timing and power reporting #10784
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
base: master
Are you sure you want to change the base?
Changes from all commits
92994ab
697e11f
0c86fe4
2e81f71
6e58b6c
14269c4
83440a4
63c4cfb
025ef12
7f6271e
28fbd8d
c121752
af382e0
07a3ee1
06eb442
ae83037
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -30,6 +30,7 @@ cc_library( | |
| ], | ||
| deps = [ | ||
| "//:ord", | ||
| "//src/dbSta", | ||
| "//src/dbSta:dbNetwork", | ||
| "//src/dpl", | ||
| "//src/drt", | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -127,6 +127,12 @@ void ram_routing() | |
| ram_gen->ramRouting(thread_count); | ||
| } | ||
|
|
||
| void ram_report_timing_power() | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As a side note, I think a lot of this function naming is redundant. It is already inside the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I ran some tests in setting clocks to propagated by adding However If you do define a clock I notice that the power reporting will be impacted dramatically. I added a clock using Do you want to leave as is or add an arbitrary clock with period? |
||
| { | ||
| RamGen* ram_gen = ord::getRamGen(); | ||
| ram_gen->reportTimingAndPower(); | ||
| } | ||
|
|
||
| void set_behavioral_verilog_filename(const char* filename) | ||
| { | ||
| RamGen* ram_gen = ord::getRamGen(); | ||
|
|
@@ -135,4 +141,4 @@ void set_behavioral_verilog_filename(const char* filename) | |
|
|
||
| } //namespace_ram | ||
|
|
||
| %} // inline | ||
| %} // inline | ||
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.
With the unconstrained min-path query left unfiltered, designs with primary/clock startpoints at zero arrival can be selected as the “shortest” path; the new goldens all report
RAM minimum path delay: 0.000 ns, which is not a useful RAM min/cycle delay. Please constrain/filter the returned path to real data paths before logging it, otherwise users get a silently misleading minimum-delay report.Useful? React with 👍 / 👎.
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.
Did some investigation and found that because no
create_clockis defined in these automated RAM test the fastest min path appear to always be through the latch/flip-flop clock pins which will report a value of zero second which is misleading.I added in a check to restrict the pin search to only the functional endpoints (flip-flop/latch D pins and primary Q outputs) since this is more accurate of how the RAMs will perform. This should also works with any RAM sizes and configurations instead of trying to define a specific number of pins that we want to restrict the test to.
Update is made in c121752
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 the real solution is just that clock should be excluded and everything else should be included.
You may also need to set clocks to propagated? I'm not sure if that affects the datapath timing.