commit 5220e2275b3bae33225cc77dbc48b839ebd3ef29
author Timothy Chen <timothytim@google.com> Tue Oct 04 17:40:19 2022 -0700
committer tjaychen <timothytim@google.com> Wed Oct 05 08:19:31 2022 -0700
tree 1ab52c43b33764994be051f650042e0c41170011
parent 3cb0a370b38584dae4310ba425732749d6f356b7

[top/dv] Fix rstmgr info test

Previously, this test assumed that escalation would always happen
within a fixed amount of time.  However, that is not necessarily
the case for ping timeouts.  The ping mechanism randomly selects a
peripheral to check.  However, since the selection vector is larger
than the number of peripherals we have, it does not always select a valid
peripheral. When the alert handler does not select a valid peripheral,
it simply moves on to the test the next ping. However the max wait time
until the next ping is checked is in the mS range.
Therefore, the test should not make that assumption and just wait in
place.

Signed-off-by: Timothy Chen <timothytim@google.com>

hw/top_earlgrey/dv/chip_sim_cfg.hjson

diff --git a/hw/top_earlgrey/dv/chip_sim_cfg.hjson b/hw/top_earlgrey/dv/chip_sim_cfg.hjson
index 84795e2..fba86da 100644
--- a/hw/top_earlgrey/dv/chip_sim_cfg.hjson
+++ b/hw/top_earlgrey/dv/chip_sim_cfg.hjson
@@ -594,9 +594,9 @@
       uvm_test_seq: chip_sw_rstmgr_alert_info_vseq
       sw_images: ["//sw/device/tests:rstmgr_alert_info_test:1"]
       en_run_modes: ["sw_test_mode_test_rom"]
-      run_opts: ["+sw_test_timeout_ns=15_500_000", "+en_scb_tl_err_chk=0",
+      run_opts: ["+sw_test_timeout_ns=30_000_000", "+en_scb_tl_err_chk=0",
                  "+en_scb_ping_chk=0"]
-      run_timeout_mins: 60
+      run_timeout_mins: 120
     }
     {
       name: chip_sw_rstmgr_cpu_info

sw/device/tests/rstmgr_alert_info_test.c

diff --git a/sw/device/tests/rstmgr_alert_info_test.c b/sw/device/tests/rstmgr_alert_info_test.c
index ee62831..de3fe4e 100644
--- a/sw/device/tests/rstmgr_alert_info_test.c
+++ b/sw/device/tests/rstmgr_alert_info_test.c
@@ -82,8 +82,7 @@
   kEscalationPhase2Micros = 100,  // us
   kRoundOneDelay = 100,           // us
   kRoundTwoDelay = 100,           // us
-  kRoundThreeDelay = 1000,        // us
-  kRoundFourDelay = 2800,         // us
+  kRoundThreeDelay = 1000         // us
 };
 
 static const uint32_t kPlicTarget = kTopEarlgreyPlicTargetIbex0;
@@ -875,8 +874,17 @@
     collect_alert_dump_and_compare(kRound3);
     global_test_round = kRound4;
     prgm_alert_handler_round4();
-    busy_spin_micros(kRoundFourDelay);
-    CHECK(false, "Should have reset before this line");
+    // Previously, this test assumed that escalation would always happen
+    // within a fixed amount of time.  However, that is not necessarily
+    // the case for ping timeouts.  The ping mechanism randomly selects a
+    // peripheral to check.  However, since the selection vector is larger
+    // than the number of peripherals we have, it does not always select a valid
+    // peripheral. When the alert handler does not select a valid peripheral,
+    // it simply moves on to the test the next ping. However the max wait time
+    // until the next ping is checked is in the mS range.
+    // Therefore, the test should not make that assumption and just wait in
+    // place.
+    wait_for_interrupt();
   } else if (rst_info == kDifRstmgrResetInfoEscalation && event_idx == 4) {
     collect_alert_dump_and_compare(kRound4);