[test] Add concurrency and power scenarios to chip-level tests
Signed-off-by: Michael Schaffner <msf@google.com>
diff --git a/hw/top_earlgrey/data/chip_testplan.hjson b/hw/top_earlgrey/data/chip_testplan.hjson
index dac5630..a9c823c 100644
--- a/hw/top_earlgrey/data/chip_testplan.hjson
+++ b/hw/top_earlgrey/data/chip_testplan.hjson
@@ -2983,5 +2983,118 @@
stage: V2
tests: []
}
+ {
+ name: chip_sw_power_max_load
+ desc: '''Concurrency test modeling maximum load conditions.
+
+ This concurrency test runs multiple blocks at the same time, to simulate
+ maximum load ("power virus test"). Should be combined with low power
+ entry and exit scenarios.
+
+ The test should be made configurable so that the type of power state and
+ the time spent in a particular power state can be configured via a
+ flag (or similar). This will make it easier to reuse the test for power
+ simulation and characterization later on.
+
+ The test should set a GPIO (mapped to the IOA2 pin) to high while the power
+ state of interest is active.
+
+ Blocks / functionality to run simulatenously in this test:
+
+ - The ADC is continuously sampling new data
+ - Staggered activation of OTBN, aes, KMAC/HMAC.
+ - KMAC / aes would need to take turns being fed data
+ - KMAC activation should be a combination of otp background, key
+ manager background and software
+ - for OTBN, any signature verification / signing event is sufficient
+ - Entropy complex ongoing
+ - reseed / update operation ongoing
+ - Flash scramble ongoing (ideally both instruction and data, but data should be sufficient
+ for now)
+ - instruction scrambling gated by script availability
+ - Simultaneous IO toggling as defined below
+ - ideally for digital activity, 3xUART / I2C modules should be activated
+ - for first pass simplicity can activate IO portion only for now through GPIO
+ - for dedicated pins, focus on SPI device quad activity
+ - USB activity should be activated
+ - for first pass simplicity activate IO portion only for now via pin forcing in usbdev.
+ - Ongoing cpu activity (icache / SRAM scrambling both activated)
+ - servicing ongoing threads and random read/write data to memory
+ - icache needs to be activated, otherwise the system may spend most of its time fetching
+ code
+ - Background checks enabled wherever possible
+ - rstmgr background checks
+ - alert_handler ping checks
+ - OTP background checks
+ - The test should be run both with / without external clock
+
+ This test should leverage the OTTF test framework for supporting
+ concurrency in a FreeRTOS environment. See also the design docs linked
+ in #14095 for more details on how to approach the implementation.
+ '''
+ stage: V2
+ tests: []
+ }
+ {
+ name: chip_sw_power_idle_load
+ desc: '''Concurrency test modeling load conditions in idle state
+
+ This concurrency test models an average idle scenarios.
+
+ The test should be made configurable so that the type of power state and
+ the time spent in a particular power state can be configured via a
+ flag (or similar). This will make it easier to reuse the test for power
+ simulation and characterization later on.
+
+ The test should set a GPIO (mapped to the IOA2 pin) to high while the power
+ state of interest is active.
+
+ The test should cover the following scenarios:
+
+ - Processor is in WFI state
+ - Background checks enabled wherever possible
+ - rstmgr background checks
+ - alert_handler ping checks
+ - OTP background checks
+ - Timers (regular and AON) are active
+ - TBD: check whether transactional clocks should be enabled or disabled.
+ - TBD: check whether PWM should be active.
+
+ This test should leverage the OTTF test framework for supporting
+ concurrency in a FreeRTOS environment. See also the design docs linked
+ in #14095 for more details on how to approach the implementation.
+ '''
+ stage: V2
+ tests: []
+ }
+ {
+ name: chip_sw_power_sleep_load
+ desc: '''Concurrency test modeling load conditions in idle state
+
+ This concurrency test models average sleep scenarios.
+
+ The test should be made configurable so that the type of power state and
+ the time spent in a particular power state can be configured via a
+ flag (or similar). This will make it easier to reuse the test for power
+ simulation and characterization later on.
+
+ The test should cover the following scenarios:
+
+ - System can be in deep or light sleep
+ - The system has the following AON / IO activity:
+ - aon_timer active
+ - adc_ctrl active in low power mode
+ - TBD: check whether sysrst_ctrl and pinmux wakeup detectors should be active
+ - TBD: check whether PWM should be active
+
+ This test should leverage the OTTF test framework for supporting
+ concurrency in a FreeRTOS environment. See also the design docs linked
+ in #14095 for more details on how to approach the implementation.
+
+ X'ref'ed with power manager sleep / wakeup test.
+ '''
+ stage: V2
+ tests: ["chip_sw_pwrmgr_deep_sleep_all_wake_ups"]
+ }
]
}
