[top,sw/dv] Clk pwr rst smoke tests#460
Conversation
2dbcd22 to
7adf270
Compare
marnovandermaas
left a comment
There was a problem hiding this comment.
Some initial comments from my end.
| DEV_WRITE(rstmgr + RSTMGR_RESET_REQ_REG, RSTMGR_RESET_REQ_TRUE); | ||
| } | ||
|
|
||
| bool rstmgr_software_reset_info_get(rstmgr_t rstmgr) |
There was a problem hiding this comment.
I think we can now remove this function. I think it was only used in the software_reset test.
There was a problem hiding this comment.
Good point. The test now reads and clears the reset reason directly, so this function is not needed anymore. I will remove it from the HAL source and header.
| static uint32_t clkmgr_read(clkmgr_t clkmgr, uintptr_t reg) | ||
| { | ||
| return DEV_READ(clkmgr + reg); | ||
| } | ||
|
|
||
| static void clkmgr_write(clkmgr_t clkmgr, uintptr_t reg, uint32_t value) | ||
| { | ||
| DEV_WRITE(clkmgr + reg, value); | ||
| } | ||
|
|
||
| static uint32_t clkmgr_bit(size_t clock) | ||
| { | ||
| return 1u << clock; | ||
| } | ||
|
|
There was a problem hiding this comment.
These don't look like clock manager specific functions. Do they already exist elsewhere in the repo?
There was a problem hiding this comment.
I did not find another helper for this, only the DEV_READ and DEV_WRITE macros. I added these local helpers to avoid repeating the same code in this file. I can also remove them and use DEV_READ/DEV_WRITE directly if you prefer.
There was a problem hiding this comment.
Probably best to use DEV_READ and DEV_WRITE.
| bool toggled = !initial; | ||
|
|
||
| clkmgr_gateable_clock_set_enabled(clkmgr, CLKMGR_GATEABLE_CLOCK_IO_PERI, toggled); | ||
| if (clkmgr_gateable_clock_get_enabled(clkmgr, CLKMGR_GATEABLE_CLOCK_IO_PERI) != toggled) { |
There was a problem hiding this comment.
Is there any way that we can confirm that the peripherals are actually stopped? I'm not sure whether reading a register will cause a bus error or just hang the design.
There was a problem hiding this comment.
I don't think this software smoke test can safely check that. If we read from a peripheral after stopping its clock, it may hang the design. This test only checks that the clkmgr registers can be written and read back correctly. I think checking that the clock really stops should be done in DV, where we can observe the clock signals directly.
There was a problem hiding this comment.
Ok, this is fine. Thanks for confirming.
| static uint32_t pwrmgr_read(pwrmgr_t pwrmgr, uintptr_t reg) | ||
| { | ||
| return DEV_READ(pwrmgr + reg); | ||
| } | ||
|
|
||
| static void pwrmgr_write(pwrmgr_t pwrmgr, uintptr_t reg, uint32_t value) | ||
| { | ||
| DEV_WRITE(pwrmgr + reg, value); | ||
| } | ||
|
|
||
| uint32_t pwrmgr_control_get(pwrmgr_t pwrmgr) | ||
| { | ||
| return pwrmgr_read(pwrmgr, PWRMGR_CONTROL_REG); | ||
| } |
There was a problem hiding this comment.
Replicated from clock manager.
There was a problem hiding this comment.
Yes, I copied the same style from clkmgr. I can keep both files like this, or I can remove these helpers and use DEV_READ/DEV_WRITE directly in both files.
There was a problem hiding this comment.
Yes please use DEV_READ and DEV_WRITE.
ziuziakowska
left a comment
There was a problem hiding this comment.
Software side looks good. Just a small nit
There was a problem hiding this comment.
The convention for tests seems to be smoketest instead of smoke_test.
There was a problem hiding this comment.
(likewise for the clkmgr test).
5f1c44d to
9b76a67
Compare
3ef6837 to
c8ae72c
Compare
| #include <stddef.h> | ||
| #include <stdint.h> | ||
|
|
||
| static uint32_t clkmgr_read(clkmgr_t clkmgr, uintptr_t reg) |
Signed-off-by: Csaba Kiss <csaba.kiss@semify-eda.com>
Signed-off-by: Csaba Kiss <csaba.kiss@semify-eda.com>
Signed-off-by: Csaba Kiss <csaba.kiss@semify-eda.com>
…ests to top level smoke regression and top level sim config Signed-off-by: Csaba Kiss <csaba.kiss@semify-eda.com>
c8ae72c to
7364ed3
Compare
|
I have checked out the branch and ran the UVM based top-level regression: Test Results
|
martin-velay
left a comment
There was a problem hiding this comment.
According to the regression mentioned above, results LGTM. Thanks Csaba
I can see the conflicts, even if I just finished the rebase. However, I am opening this PR to start the review process. I will fix the further conflicts just before the merge.