// Copyright lowRISC contributors.
// Licensed under the Apache License, Version 2.0, see LICENSE for details.
// SPDX-License-Identifier: Apache-2.0
{
  name: "chip"

  // TODO: remove the common testplans if not applicable
  import_testplans: ["hw/dv/tools/dvsim/testplans/csr_testplan.hjson",
                     "hw/dv/tools/dvsim/testplans/enable_reg_testplan.hjson",
                     // TODO #5484, comment these 2 lines out because spi host memory is dummy
                     // "hw/dv/tools/dvsim/testplans/mem_testplan.hjson",
                     "hw/dv/tools/dvsim/testplans/tl_device_access_types_testplan.hjson",
                     "hw/ip/tlul/data/tlul_testplan.hjson"]

  testpoints: [
    ///////////////////////////////////////////////////////////////////////////
    // IO Peripherals                                                        //
    // UART, GPIO, I2C, SPIDEV, SPIHOST, USB, PINMUX & PADCTRL, PATTGEN, PWM //
    ///////////////////////////////////////////////////////////////////////////

    // UART (pre-verified IP) integration tests:
    {
      name: chip_sw_uart_tx_rx
      desc: '''Verify transmission of data over the TX and RX port.

            SW test sends a known payload over the TX port. The testbench, at the same time
            sends a known payload over RX. On reception, both payloads are checked for integrity.
            SW validates the reception of TX watermark, RX watermark, and the TX empty interrupts.
            Choosing the max supported baud rate for the UART is sufficient.

            Verify each UART instance at the chip level independently. Verify there is no aliasing
            on all UART ports across the instances.
            '''
      milestone: V1
      tests: ["chip_sw_uart_tx_rx"]
    }
    {
      name: chip_sw_uart_rx_overflow
      desc: '''Verify the RX overflow interrupt.

            The testbench sends a random payload of size greater than the RX fifo size (32). The SW
            ignores the received the data to allow the RX overflow interrupt to assert.

            Verify each UART instance at the chip level independently. Verify there is no aliasing
            on all UART ports across the instances.
            '''
      milestone: V1
      tests: ["chip_sw_uart_tx_rx", "chip_sw_uart_tx_rx_idx1", "chip_sw_uart_tx_rx_idx2",
              "chip_sw_uart_tx_rx_idx3"]
    }
    {
      name: chip_sw_uart_rand_baudrate
      desc: '''Verify UART transmission of data at various speeds.

            Randomly pick one of the UART instances and configure it to run with any of these baud
            rates - 9600bps, 115200bps, 230400bps, 128Kbps, 256Kbps, 1Mkbps, 1.5Mkbps.

            '''
      milestone: V1
      tests: ["chip_sw_uart_rand_baudrate"]
    }
    {
      name: chip_sw_uart_tx_rx_alt_clk_freq
      desc: '''Verify the transmission of UART while randomizing the core clock frequency.

            Run the chip_uart_tx_rx test with the core clock frequency randomized between known
            bounds.

            TODO: Find out what the range is for the core clock frequency randomization.
            '''
      milestone: V1
      tests: []
    }

    // GPIO (pre-verified IP) integration tests:
    {
      name: chip_sw_gpio_out
      desc: '''Verify GPIO outputs.

            SW test configures the GPIOs to be in the output mode. The test walks a 1 through the
            pins. The testbench checks the value for correctness and verifies that there is no
            aliasing between the pins.
            '''
      milestone: V1
      tests: ["chip_sw_gpio"]
    }
    {
      name: chip_sw_gpio_in
      desc: '''Verify GPIO inputs.

            The SW test configures the GPIOs to be in input mode. The testbench walks a 1 through
            the pins. SW test ensures that the GPIO values read from the CSR is correct.
            '''
      milestone: V1
      tests: ["chip_sw_gpio"]
    }
    {
      name: chip_sw_gpio_irq
      desc: '''Verify GPIO interrupts.

            The SW test configures the GPIOs to be in input mode and enables all of them to generate
            an interrupt. The testbench walks a 1 through the pins. SW test ensures that the
            interrupt corresponding to the right pin is seen.
            '''
      milestone: V1
      tests: ["chip_sw_gpio"]
    }

    // SPI_DEVICE (pre-verified IP) integration tests:
    {
      name: chip_sw_spi_device_tx_rx
      desc: '''Verify the transmission of data on the chip's SPI device port in firmware mode with
               single mode.

            - The testbench sends a known payload over the chip's SPI device input port.
            - The SW test, at the same time sends a known payload out over the chip's SPI device
              output port.
            - On reception, both payloads are checked for integrity.
            - SW validates the reception of RX fifo full, RX fifo over level, TX fifo under level,
              RX overflow and TX underflow interrupts.
            - Run with min (6MHz), typical (30-48Mhz) and max(48MHz) SPI clk frequencies.
              should use
            - Also, ensure that the spi_device does not receive transactions when the csb is high.
            - TODO, consider to test this mode with a real use case. The actual use case of this
              mdoe is not clear right now.
            '''
      milestone: V2
      tests: ["chip_sw_spi_device_tx_rx"]
    }
    {
      name: chip_sw_spi_device_flash_mode
      desc: '''Verify the SPI device in flash mode.

            - SW puts the SPI device in flash mode
            - Load a firmware image (bootstrap) through flash commands to the spi_device memory.
            - SW verifies the integrity of the image upon reception by reading the spi_device
              memory.
            - Ensure the image is executed correctly
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_spi_device_pass_through
      desc: '''Verify the pass through mode from an end-to-end perspective.

            - Configure the SPI device and host in pass through mode.
            - Configure and enable both spi_host0 and spi_host1
            - Send a random flash commands over the SPI device interface (chip IOs) from the
              testbench.
            - Verify the flash commands which pass through spi_host0, are received on chip IOs.
            - Verify spi_host1 doesn't send out any data from spi_device
            - Run with min (6MHz), typical (30-48Mhz) and max(48MHz) SPI clk frequencies.
            - Run with single, dual and quad SPI modes.
            - Testbench should test the following commands:
              - Read Normal, Fast Read, Fast Dual, Fast Quad, Chip Erase, Program

            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_spi_device_pass_through_filter
      desc: '''Verify the command filtering mechanism in passthrough mode.

            - Extend the chip_spi_device_pass_through test.
            - Program the cmd_filter_* CSRs to filter out certain commands. a one byte command (such
              as Chip Erase) and a multi-bytes command (such as Program or Sector/Block Erase) must
              be added to filter
            - Verify that only the payloads that are not filtered show up on the SPI host interface
              at chip IOs.
            '''
      milestone: V2
      tests: []
    }

    {
      name: chip_sw_spi_device_pass_through_flash_model
      desc: '''Verify the command filtering mechanism in passthrough mode.

            - Extend the chip_spi_device_pass_through and chip_spi_device_pass_through_filter
              tests.
            - Connect with a real flash model on spi_host
            - Verify that the flash commands are received and interpreted correctly in the flash
              model
            '''
      milestone: V2
      tests: []
    }

    {
      name: chip_spi_device_connectivity_with_ast
      desc: '''Verify the connectivity between spi_device and AST on scanmode and mbist

            This could be done through the connectivity test with FPV
            '''
      milestone: V2
      tests: []
    }

    {
      name: chip_sw_spi_device_pass_through_collision
      desc: '''Verify the collisions on driving spi_host is handled properly

            TODO, add detail testplan once we have a conclusion on #5134
            '''
      milestone: V2
      tests: []
    }

    // SPI_HOST (pre-verified IP) integration tests:
    {
      name: chip_sw_spi_host_tx_rx
      desc: '''Verify the transmission of data on the chip's SPI host port.

            - Program the SPI host to send a known payload out of the chip on the SPI host ports.
            - At the same time, the testbench transfers a known payload from device to host on the
              SPI host interface.
            - The SPI device monitor in the testbench grabs the host payload and verifies its
              integrity.
            - The SW verifies the device payload for integrity and services the SPI event interrupt.
            - Run with min and max SPI clk frequencies and with single, dual and quad SPI modes.

            Verify all SPI host instances in the chip.
            '''
      milestone: V2
      tests: []
    }

    // I2C (pre-verified IP) integration tests:
    {
      name: chip_sw_i2c_host_tx_rx
      desc: '''Verify the transmission of data over the chip's I2C host interface.

            - Program the I2C to be in host mode.
            - The SW test writes a known payload over the chip's I2C host interface, which is
              received and verified by the testbench for correctness.
            - SW validates the reception of FMT watermark and trans complete interrupts.
            - Verify the virtual / true open drain capability.

            Verify all instances of I2C in the chip.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_i2c_device_tx_rx
      desc: '''Verify the transmission of data over the chip's I2C device interface.

            - Program the I2C to be in device mode.
            - The testbench writes a known payload over the chip's I2C device interface, which is
              received and verified by the SW test for correctness.
            - SW validates the reception of RX watermark and trans complete interrupts.
            - Verify the virtual / true open drain capability.

            Verify all instances of I2C in the chip.
            '''
      milestone: V2
      tests: []
    }

    // USB (pre-verified IP) integration tests:
    {
      name: chip_usb_fs_tx_rx
      desc: '''Verify the transmission of single-ended data over the USB at full speed. As a part of
            this test, the enablement of USB pullup is also expected to be verified.

            - Set `tx_differential_mode` to single-ended and `rx_differential_mode` to
              differential. The other modes are not supported in OpenTitan.
            - configure Link state to `Active`.
            - Send and receive packets to fill the entire buffer. Ensure all the packets are
              correct.
            - Check interrupts (connected, pkt_received, pkt_sent, av_empty, rx_full) are triggered
              correcly.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_usb_ls_tx_rx
      desc: '''Verify the transmission of single-ended data over the USB at low speed.

            - Similar to `chip_usb_fs_df_tx_rx`, except testing USB at Low-Speed (1.5 Mbps).
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_usb_vbus
      desc: '''Verify that the USB device can detect the presence of VBUS from the USB host.

            - This test extends from `chip_usb_fs_df_tx_rx`, add below at the end of the sequence.
            - VBUS is controlled by SW, through programming CSRs (`override_pwr_sense_en` and
              `override_pwr_sense_val`) to connect / disconnect the USB.
            - Disconnect the USB to trigger `disconnected` interrupt.
            - Then reconnect it and check the `connected` interrupt.
            - Re-enable data transfer and ensure data correctness.
            - Observe valid reference pulse usb_ref_val/pulse_o.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_usb_suspend
      desc: '''Verify that the USB device can detect the presence of VBUS from the USB host.

            - This test extends from `chip_usb_fs_df_tx_rx`, add below at the end of the sequence.
            - Configure USB device to enter `Suspend` state and ensure `link_suspend` interrupt is
              triggered.
            - Test these 2 power modes.
              - Normal sleep:
                - Configure pwrmgr to enter normal sleep mode, then clocks are disable while powers
                  are kept on.
                - Resume the device through pinmux and check the `link_resume` interrupt.
                - Ensure that previously enumerated information is kept.
              - Deep sleep:
                - Before entering deep sleep, store previously enumerated information in retention
                  RAM. (optional)
                - Configure pwrmgr to enter deep sleep mode, and powers are turned off.
                - Resume the device through pinmux and check the `link_resume` interrupt.
                - Ensure that previously enumerated information and configuration (non-default
                  values) are wiped, as USB has been reset before wakeup.
                - Restore previously enumerated information (if it's stored) or re-enumerate the
                  USB.
            - Re-enable data transfer and ensure data correctness.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_usb_sof
      desc: '''Verify that USB can detect SOF and respond with `usb_ref_pulse_o` and
            `usb_ref_val_o`.

            - Configure to enable `usb_ref_disable`.
            - Send a frame with the same frame number as the USB device to trigger `frame`
              interrupt.
            - Ensure `usb_ref_pulse_o` and `usb_ref_val_o` behave correctly.
            - Stop sending any frame and check the `host_lost` interrupt. Ensure `use_ref_*` behave
              correctly.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_usb_wake_debug
      desc: '''Verify that `usb_state_debug_i` can be read from the CSR

            - Drive random value on `usb_state_debug_i`.
            - Ensure the CSR `wake_debug` returns correctly value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_usb_enumeration
      desc: '''Verify USB enumeration. Details are not clear.

            - TODO
            '''
      milestone: V2
      tests: []
    }

    // PINMUX (pre-verified IP) integration tests:
    {
      name: chip_sw_pin_mux
      desc: '''Verify the MIO muxing at input and output sides.

            SW programs MIO INSEL and OUTSEL CSRs to connect and verify each muxed source. At the
            moment, GPIOs are the only mux inputs.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sleep_pin_mio_dio_val
      desc: '''Verify the MIO output values in deep sleep state.

            SW programs the MIO OUTSEL CSRs to to ensure that in deep sleep it randomly picks
            between tie-0, tie-1 or hi-Z for all muxed outputs coming from non-AON IPs. If an AON
            peripheral output is muxed, then that peripheral's output is selected to ensure in deep
            sleep the peripheral can continue its signaling even in deep sleep. The testbench
            verifies the correctness of the reflected values once the chip goes into deep sleep.
            This is replicated for DIO pins as well.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sleep_pin_wake
      desc: '''Verify pin wake up from deep sleep state.

            Verify one of the 8 possible MIO or DIO pad inputs (randomly configured) can cause the
            chip to wake up from sleep state. Verifying wake on posedge is sufficient for the chip
            level integration testing. Upon wake up, SW reads the wake cause CSR to verify
            correctness.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_tap_strap_sampling
      desc: '''Verify tap accesses in different LC states.

            Verify pinmux can select the life_cycle, RISC-V, and DFT taps after reset.
            Verify that in TEST_UNLOCKED* and RMA states, pinmux can switch between the three TAPs
            without issuing reset.
            '''
      milestone: V2
      tests: []
    }

    // PADCTRL tests:
    {
      name: chip_sw_padctrl_attributes
      desc: '''Verify pad attribute settings for all MIO and DIO pads.
            '''
      milestone: V2
      tests: []
    }

    // PATTGEN (pre-verified IP) integration tests:
    {
      name: chip_sw_pattgen_ios
      desc: '''Verify pattern generation to chip output pads.

            - Program the pattgen to generate a known pattern in each lane.
            - Program the pinmux to route the chosen output to the chip IOs.
            - Verify that the correct pattern is seen on the IOs by hooking up the pattgen monitor.
            - Validate the reception of the done interrupt.
            - Verify both pattgen channels independently.
            '''
      milestone: V2
      tests: []
    }

    // PWM (pre-verified IP) integration tests:
    {
      name: chip_sw_sleep_pwm_pulses
      desc: '''Verify PWM signaling to chip output pads during deep sleep.

            - Program each PWM output to pulse in a known pattern.
            - Program the pinmux to route the chosen PWM output to the chip IOs.
            - Program the pwrmgr to go to deep sleep state, with AON timer wakeup.
            - Initiate the sleep state by issuing a WFI.
            - Verify that in the sleep state, the PWM signals are active and pulsing correctly, by
              hooking up the PWM monitor.
            - Repeat the steps for all 6 PWM signals.
            '''
      milestone: V2
      tests: []
    }

    //////////////////////////////////////////////////////////////////////////////////////
    // System Peripherals                                                               //
    // XBAR, RV_DM, RV_TIMER, AON_TIMER, PLIC, CLK/RST/PWR MGR, ALERT_HANDLER, LC_CTRL, //
    // ADC_CTRL, SYSRST_CTRL                                                            //
    //////////////////////////////////////////////////////////////////////////////////////

    // XBAR (pre-verified IP) tests:
    {
      name: chip_sw_data_integrity
      desc: '''
            Verify the alert signaling mechanism due to data integrity violation.

            An automated SW test which performs the following for each IP:
            - Pick a CSR to write.
            - Corrupt a random control / data / integrity bit at the CPU source using SV force.
            - Verify that the device detects the integrity violation causing an alert.
            - Verify the alert upto the NMI stage.
            - Now pick a CSR to read.
            - Corrupt a random control / data / integrity bit at the device using SV force.
            - Verify that the CPU detects the integrity violation causing an alert.
            - Verify the alert upto the NMI stage.
            '''
      milestone: V2
      tests: []
    }

    // RV_DM (JTAG) tests:
    {
      name: chip_sw_jtag_csr_rw
      desc: '''
            Verify accessibility of all the CSRs in the chip through jtag and also test RV_DM SBA
            functionality

            - Shuffle the list of CSRs first to remove the effect of ordering.
            - Write all CSRs via JTAG interface with a random value.
            - Shuffle the list of CSRs yet again.
            - Read all CSRs back and check their values for correctness while adhering to the CSR's
              access policies.
            - Accesses to CSRs external to `rv_dm` go through RV_DM SBA interface into the `xbar`.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_rv_dm_cpu_debug_mem_not_accessable
      desc: '''Verify that the debug mem can't be accessed from the CPU while not in the debug mode.

            TODO, add stimulus and checks
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_rv_dm_perform_debug
      desc: '''Verify that Ibex enters debug mode when triggered through JTAG

            - While Ibex is executing, trigger a debug request by programming `dmcontrol.haltreq`
              via JTAG.
            - Ibex steps into interactive debug to store a value in SRAM.
            - Program the program buffer through JTAG with code to store a value in SRAM and return
              back to normal program execution using dret.
            - After Ibex jumps back to the program execution, check the stored value in the SRAM.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_rv_dm_ndm_reset_req
      desc: '''Verify non-debug reset request initiated from RV_DM when the chip is awake.

            - Program some CSRs / mem that are under life cycle reset tree and system reset tree.
            - Configure RV_DM to send NDM reset request to reset sytem reset tree.
            - Read the programmed CSRs / mem to ensure that everything under system reset tree is
              reset to the original values, while values under life cycle reset will be preserved.
            - Read CSRs / mem in the debug domain to ensure that the values survive the reset.
            '''
      milestone: V2
      tests: []
    }
    // TODO, this could be a block-level test. Put it here since we don't have block-level testplan.
    {
      name: chip_rv_dm_ndm_reset_req_when_ibex_halted
      desc: '''Verify non-debug reset request initiated from RV_DM when ibex is in halted state.

            - Configure ibex in halted state (dmstatus.anyhalted/dmstatus.allhalted is asserted).
            - Configure RV_DM to send NDM reset request.
            - Check that halted state is clear (dmstatus.anyhalted/dmstatus.allhalted should be
              de-asserted).
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_rv_dm_access_after_wakeup
      desc: '''Verify RV_DM works after wakes up from sleep.

            - Put the chip into sleep mode and then wake up.
            - Access some RV_DM CSRs to ensure that RV_DM doesn't need a full reset to work.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rv_dm_jtag_tap_sel
      desc: '''Verify ability to select all available TAPs.

            - Put life cycle on Test or RMA state, so that TAPs can be selected between life cycle
              RV_DM and DFT.
            - Verify the TAP is selected correctly.
            - TODO, X-ref'ed with the LC tests.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rv_dm_lc_disabled
      desc: '''Verify that the debug capabilities are disabled in certain life cycle stages.

            - Put life cycle on states other than Test, RMA and DEV.
            - Verify that the rv_dm bus device is inaccessible from the CPU as well as external
              JTAG.
            - Verify that the JTAG TAP is unavailable.
            - X-ref'ed with `chip_tap_strap_sampling`
            '''
      milestone: V2
      tests: []
    }

    // RV_TIMER (pre-verified IP) integration tests:
    {
      name: chip_sw_timer
      desc: '''Verify the timeout interrupt assertion.

            - Configure the RV_TIMER to generate interrupt after a set timeout.
            - Issue a WFI to wait for the interrupt to trigger.
            - Service the interrupt when it triggers; verify that it came from rv_timer.
            - Verify that the interrupt triggered only after the timeout elapsed.
            '''
      milestone: V2
      tests: ["chip_sw_rv_timer_irq"]
    }

    // AON_TIMER (pre-verified IP) integration tests:
    {
      name: chip_sw_aon_timer_wakeup_irq
      desc: '''Verify the AON timer wake up interrupt in normal operating state.

            - Program the PLIC to let the AON timer wake up interrupt the CPU.
            - Program the AON timer to generate the wake up timeout interrupt after some time.
            - Issue a WFI to wait for the interrupt to trigger.
            - Service the interrupt when it triggers; verify that it came from AON timer.
            - Verify that the interrupt triggered only after the timeout elapsed.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_sleep_wakeup
      desc: '''Verify that AON timer can wake up the chip from a deep sleep state.

            - Read the reset cause register in rstmgr to confirm that the SW is in the POR reset
              phase.
            - Program the pwrmgr to go to deep sleep state (clocks off, power off).
            - Program the AON timer to wake up the chip in a reasonable amount of time.
            - Have the CPU issue WFI to signal the pwrmgr to go into sleep state.
            - Verify via assertion checks, the wake up request occurs after the timeout has elapsed.
            - After reset followed by AON timer wake up, read the reset cause register to confirm
              the AON timer wake up phase.
            - After the test sequence is complete, read the wake up threshold register - it should
              not be reset.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_smoketest"]
    }
    {
      name: chip_sw_aon_timer_clks_resets
      desc: '''Verify that the correct clocks and resets are connected to the AON timer.

            - The chip_aon_timer_deep_sleep_wakeup achieves this goal.
            - Verify via connectivity assertion checks, the right clocks and resets from clkmgr and
              rstmgr are connected to AON timer.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_wdog_bark_irq
      desc: '''Verify the watchdog bark reception in normal state.

            - Program the PLIC to let the wdog bark signal interrupt the CPU.
            - Program the AON timer wdog to 'bark' after some time and enable the bark interrupt.
            - Service the bark interrupt upon reception.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_wdog_lc_escalate
      desc: '''Verify that the LC escalation signal disables the AON timer wdog.

            - Program the AON timer wdog to 'bark' after some time and enable the bark interrupt.
            - Program the alert handler to escalate on alerts upto phase 1 (i.e. stop after wipe
              secrets).
            - Trigger an alert to cause an escalation condition before the wakeup signal asserts.
            - Wait for sufficiently long time to ensure that the bark interrupt does not trigger,
              to prove that the wdog was disabled.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_wdog_bite_reset
      desc: '''Verify the watchdog bite causing reset in the normal state.

            - Read the reset cause register in rstmgr to confirm that the SW is in the POR reset
              phase.
            - Program the AON timer wdog to 'bark' after some time.
            - Let the bark escalate to bite, which should result in a reset request.
            - After reset, read the reset cause register in rstmgr to confirm that the SW is now in
              the wdog reset phase.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_sleep_wdog_bite_reset
      desc: '''Verify the watchdog bite causing reset in sleep state.

            - Repeat the steps in chip_aon_timer_wdog_bite_reset test, but with following changes:
            - Program the pwrmgr to go to deep sleep state (clocks off, power off).
            - Issue a WFI after programming the wdog, so that the reset request due to bite occurs
              during deep sleep state.
            - After reset, read the reset cause register in rstmgr to confirm that the SW is now in
              the wdog reset phase.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aon_timer_sleep_wdog_sleep_pause
      desc: '''Verify that the wdog can be paused in sleep state.

            - Repeat the steps in chip_aon_timer_sleep_wakeup test, but with following changes:
            - Program the wdog to 'bite' a little sooner than the AON timer wake up.
            - Also, program the wdog to pause during sleep.
            - Issue a WFI after programming the wdog, so that the reset request occurs during deep
              sleep state.
            - After reset followed by AON timer wake up, read the reset cause register to confirm
              that the AON timer woke up the chip, not the wdog reset.
            - Un-pause the wdog and service the bark interrupt.
            '''
      milestone: V2
      tests: []
    }

    // PLIC (pre-verified IP) integration tests:
    {
      name: chip_sw_plic_all_irqs
      desc: '''Verify all interrupts from all peripherals aggregated at the PLIC.

            The automated SW test enables all interrupts at the PLIC to interrupt the core. It uses
            the `intr_test` CSR in each peripheral to mock assert an interrupt, looping through all
            available interrupts in that peripheral. The ISR verifies that the right interrupt
            occurred. This is used as a catch-all interrupt test for all peripheral integration
            testing within which functionally asserting an interrupt is hard to achieve or not of
            high value.
            '''
      milestone: V2
      tests: ["chip_plic_all_irqs"]
    }
    {
      name: chip_sw_plic_sw_irq
      desc: '''Verify the SW interrupt to the CPU.

            Enable all peripheral interrupts at PLIC. Enable all types of interrupt at the CPU core.
            Write to the MSIP CSR to generate a SW interrupt to the CPU. Verify that the only
            interrupt that is seen is the SW interrupt.
            '''
      milestone: V2
      tests: [""]
    }
    {
      name: chip_sw_plic_nmi_irq
      desc: '''Verify the NMI interrupt to the CPU and correctness of the cause.

            TBD if multiple NMI irqs are OR-ed into the CPU (example - NMI from alert handler and
            the watchdog bark), then map each test to this testpoint.
            '''
      milestone: V2
      tests: [""]
    }

    // CLKMGR tests:
    {
      name: chip_sw_clk_idle_trans
      desc: '''Verify the ability to turn off the transactional clock via SW.

            Ensure that the clock to transactional units can be turned off regardless of any
            activity in the transactional IP.  Verify it is off via spinwait in hints_status CSR.
            Verify that turning off this clock does not affect the other derived clocks.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_clk_off_trans
      desc: '''Verify the turned off transactional units.

            Verify CSR accesses do not complete in units that are off.  Using the watchdog timers,
            turn off a transactional unit's clock, issue a CSR access to that unit, verify a watchdog
            event results, and verify the rstmgr crash dump info records the CSR address.

            A stretch goal is to check the PC corresponds to the code performing
            the CSR access (stretch since it could be difficult to maintain this
            check).
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_clk_off_peri
      desc: '''Verify the ability to turn off the peripheral clock via SW.

            Verify CSR accesses do not complete in peripherals that are off.  Using the watchdog
            timers, turn off a peripheral's clock, issue a CSR access to that peripheral, verify a
            watchdog event results, and verify the rstmgr crash dump info records the CSR address.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_clk_div
      desc: '''Verify clk division logic is working correctly.

            This can be easily verified if we implement clock cycle counters.
            The IP level checks the divided clocks via SVA, and these are also bound at chip level.

            Add formal connectivity tests to check peripherals are connected to the clock they
            expect.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_clkmgr_external_clk_src_for_lc
      desc: '''Verify the clkmgr requests ext clk src during certain LC states.

            On POR lc asserts lc_clk_byp_req on some LC states, and de-asserts
            it when lc_program completes. This also triggers divided clocks to step down. It may be
            best to verify this via SVA, unless we implement clock cycle counters.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_clkmgr_external_clk_src_for_sw
      desc: '''Verify SW causes the clkmgr requests ext clk src during certain LC states.

            In RMA and TEST_UNLOCKED lc states the external clock is enabled in response to
            `extclk_ctrl.sel` CSR writes. In addition `extclk_ctrl.step_down` CSR causes the divided
            clocks to step down. It may be best to verify this via SVA, unless we implement clock
            cycle counters. X-ref with chip_sw_uart_tx_rx_alt_clk_freq, which needs to deal with
            this as well.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_clkmgr_jitter_enable
      desc: '''Verify the chip operates correctly when clock jitter is enabled.

            Enable main clock jitter setting the clkmgr `jitter_enable` CSR high. This causes the
            jitter_o clkmgr output to toggle. Verify this output is connected to AST's
            clk_src_sys_jen_i input using formal.
            '''
      milestone: V2
      tests: []
    }

    // PWRMGR tests:
    {
      name: chip_sw_pwrmgr_external_full_reset
      desc: '''Verify the cold boot sequence by wiggling of chip's `POR_N`.

            This ensures that both FSMs are properly reset on the POR signal. The check  is that
            the processor ends up running. Also verify, the rstmgr records POR in `reset_info` CSR.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_full_aon_reset"]
    }
    {
      name: chip_sw_pwrmgr_sleep_all_wake_ups
      desc: '''Verify that the chip can go into normal sleep state and be woken up by ALL wake up
            sources.

            This verifies ALL wake up sources. This also verifies that the pwrmgr sequencing is
            working correctly as expected. X-ref'ed with all individual IP tests. For each wakeup
            source clear and enable `wake_info` CSR, enable the wakeup from that source with the
            `wakeup_en` CSR, bring the chip to low power, optionally disabling the source's clock,
            have the source issue a wakeup event and verify `wake_info` indicates the expected
            wakeup.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_sleep_all_reset_reqs
      desc: '''Verify that the chip can go into normal sleep state and be reset by ALL reset req
            sources.

            This verifies ALL reset sources. This also verifies that the pwrmgr sequencing is
            working correctly as expected. X-ref'ed with all individual IP tests. For each reset
            source, enable the source and bring the chip to low power, issue a reset, and verify the
            rstmgr's `reset_info` indicates the expected reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_deep_sleep_all_wake_ups
      desc: '''Verify that the chip can go into deep sleep state and be woken up by ALL wake up
            sources.

            This verifies ALL wake up sources. This also verifies that the pwrmgr sequencing is
            working correctly as expected. X-ref'ed with all individual IP tests. Similar to
            chip_pwrmgr_sleep_all_wake_ups, except `control.main_pd_n` is set to 0.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_smoketest",
              "chip_sw_pwrmgr_usbdev_wakeup"]
    }
    {
      name: chip_sw_pwrmgr_deep_sleep_all_reset_reqs
      desc: '''Verify that the chip can go into deep sleep state and be reset up by ALL reset req
            sources.

            This verifies ALL reset sources. This also verifies that the pwrmgr sequencing is
            working correctly as expected. X-ref'ed with all individual IP tests. Similar to
            chip_pwrmgr_sleep_all_reset_reqs, except `control.main_pd_n` is set to 0.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_all_reset_reqs
      desc: '''Verify that the chip can be reset by ALL available reset sources.

            This verifies ALL reset sources. This also verifies that the pwrmgr sequencing is
            working correctly as expected. X-ref'ed with all individual IP tests. Similar to
            chip_pwrmgr_sleep_all_reset_reqs, except the chip is not put in low power mode.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_aon_power_glitch_reset
      desc: '''Verify the cold boot sequence through an AON power glitch.


            Pulsing the AST vcaon_supp_i input causes an AON power glitch which becomes a POR.
            This ensures that both FSMs are properly reset on the POR signal. The check is that
            the processor ends up running. Also verify, the rstmgr records POR in `reset_info` CSR.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_full_aon_reset"]
    }
    {
      name: chip_sw_pwrmgr_main_power_glitch_reset
      desc: '''Verify the effect of a glitch in main power rail.

            The vcmain_supp_i AST input is forced to drop once the test is running. This triggers
            a MainPwr reset request, which is checked reading the reset_info CSR when the test
            restarts and the POR bit is not set.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_main_power_glitch_reset"]
    }
    {
      name: chip_sw_pwrmgr_sleep_power_glitch_reset
      desc: '''Verify the effect of a glitch in main power rail in deep sleep.

            The vcmain_supp_i AST input is forced to drop after putting the chip to sleep. This
            triggers a MainPwr reset request, which is checked reading the reset_info CSR when the
            test restarts and the POR bit is not set.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_b2b_sleep_reset_req
      desc: '''Verify that the pwrmgr sequences sleep_req and reset req coming in almost at the same
            time, one after the other.

            Verified at IP level.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_debug_sleep
      desc: '''Verify low power entry is prevented when the chip is in "debuggable" state.

            This is an open issue: https://github.com/lowRISC/opentitan/issues/7215
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_sleep_disabled
      desc: '''Verify that the chip does not go to sleep on WFI when low power hint is 0.
            '''
      milestone: V2
      tests: []
    }

    // RSTMGR tests:
    {
      name: chip_sw_rstrmgr_non_sys_reset_info
      desc: '''Verify the `reset_info` CSR register for lc or higher resets.

            Generate the 5 types of reset at `lc` level or higher, and check the `reset_info` CSR
            is as expected. This and other rstmgr testpoints that require different resets
            cross-reference the individual IP tests that generate those resets, and this testpoint
            merely adds reset checks in them. Those IP blocks are `pwrmgr`, `alert_handler`,
            `aon_timer`, and `sysrst_ctrl`.

            This should also check the reset's destination IP to make sure some reset side-effect
            is present. Setting some `intr_enable` CSR bit when the test starts and checking it
            after reset seems suitable. The `spi_host` and `usbdev` IPs receive multiple resets
            so they will need special consideration.
            TODO(maturana) Add specific tests once they are developed.
            '''
      milestone: V2
      tests: ["chip_sw_pwrmgr_smoketest"]
    }
    {
      name: chip_sw_rstrmgr_sys_reset_info
      desc: '''Verify the `reset_info` CSR register for sys reset.

            Generate reset triggered by `rv_dm`, which results in a sys level reset, and check the
            `reset_info` CSR is as expected. This testpoint cross-reference the `rv_dm` tests that
            generate this reset, and this testpoint merely adds reset checks in them.

            This should also check the reset's destination IP to make sure some reset side-effect
            is present. Setting some `intr_enable` CSR bit when the test starts and checking it
            after reset seems suitable. The `spi_host` and `usbdev` IPs receive multiple resets
            so they will need special consideration.
            TODO(maturana) Add specific tests once they are developed.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rstrmgr_cpu_info
      desc: '''Verify the expected values from the `cpu_info` CSR on reset.

            For some software induced resets we can predict the expected contents of `cpu_info`;
            reads of writes to unmapped addresses for example. Generate these resets and verify
            the `cpu_info` register contents when reset is handled.
            Refer to `chip_*sys_rstrmgr_reset_info`.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rstrmgr_sw_req_reset
      desc: '''Verify software requested device reset.

            Generate a reset request by directly writing the `reset_req` CSR.
            The reset created should be identical to those caused by hardware sources.
            After reset, the `reset_info` CSR should reflect that a software request was
            the reset cause.
            '''
      milestone: V2
      tests: ["chip_sw_rstmgr_sw_req"]
    }
    {
      name: chip_sw_rstrmgr_alert_info
      desc: '''Verify the expected values from the `alert_info` CSR on reset.

            Various alerts can be created, for example, timeouts, and integrity errors, and at
            least part of the `alert_info` CSR can be predicted. To cause some of these to
            cause a reset, mask the relevant processor interrupts. Trigger these resets and
            verify the `alert_info` register contents when reset is handled.
            Refer to `chip_*sys_rstrmgr_reset_info`.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rstrmgr_sw_rst
      desc: '''Verify `sw_rst_ctrl_n` CSR resets individual peripherals.

            Check the peripheral is reset via timeout accessing their CSRs while the corresponding
            reset is active. The per peripheral reset controls in increasing order by
            `sw_rst_ctrl_n` bit, are as follows: `spi_device`, `spi_host0`, `spi_host0_core`,
            `spi_host1`, `spi_host1_core`, `usb`, `usbif`, `i2c0`, `i2c1`, `i2c2`.

            Notice the two `spi_host` and `usbdev` IPs receive two different resets each,
            `spi_host*` and `spi_host*_core`, and `usb` and `usbif` respectively. This means
            the CSRs to be used for checking may not be obvious.
            '''
      milestone: V2
      tests: []
    }

    // ALERT_HANDLER (pre-verified IP) integration tests:
    {
      name: chip_sw_alert_handler_alerts
      desc: '''Verify all alerts coming into the alert_handler.

            An automated SW test, which does the following (applies to all alerts in all IPs):
            - Program the alert_test CSR in each block to trigger each alert one by one.
            - Ensure that all alerts are properly connected to the alert handler and cause the
              escalation paths to trigger.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_escalations
      desc: '''Verify all alert escalation paths.

            Verify all escalation paths triggered by an alert.
            - Verify the first escalation results in NMI interrupt serviced by the CPU.
            - Verify the second results in device secrets to be wiped - read via SW to confirm.
            - Verify the third results in device being put in scrap state, via the LC JTAG TAP.
            - Verify the fourth results in chip reset.
            - Ensure that all escalation handshakes complete without errors.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_irqs
      desc: '''Verify all classes of alert handler interrupts to the CPU.

            X-ref'ed with the automated PLIC test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_entropy
      desc: '''Verify the alert handler entropy input to ensure pseudo-random ping timer.

            - Force `alert_handler_ping_timer` input signal `wait_cyc_mask_i` to `4'bff` to shorten
              the simulation time.
            - Verify that the alert_handler can request EDN to provide entropy.
            - Ensure that the alert ping handshake to all alert sources and escalation receivers
              complete without errors.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_edn_reset
      desc: '''Verify that the EDN clock / reset is connected to alert_handler.

            - Ensure that the ping timer LFSR resets when the EDN logic is held in reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_crashdump
      desc: '''Verify the alert handler crashdump signal.

            When the chip resets due to alert escalating to cause the chip to reset, verify the
            reset cause to verify the alert crashdump.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_ping_timeout
      desc: '''Verify the alert senders' ping timeout.

            Set alert_handler's ping timeout cycle to 1 and enable alert_senders. Verify that
            alert_handler detects the ping timeout and reflects it on the `loc_alert_cause`
            register.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_lpg
      desc: '''Verify alert's low_power_group(lpg).

            Choose an always-on block and send alerts during deep sleep mode, check the
            alert_senders can recover after system comes out of the deep sleep mode.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_alert_handler_reverse_ping_in_deep_sleep
      desc: '''Verify escalation reverse ping timer disabled in sleep mode.

            Check that escalation receivers located inside always-on blocks do not auto-escalate
            due to the reverse ping feature while the system is in deep sleep.
            '''
      milestone: V2
      tests: []
    }

    // LC_CTRL (pre-verified IP) integration tests:
    {
      name: chip_sw_lc_ctrl_alert_handler_escalation
      desc: '''Verify that the escalation signals from the alert handler are connected to LC ctrl.

            - Trigger an alert to initiate the escalations.
            - Check that the escalation signals are connected to the LC ctrl:
              - First escalation has no effect on the LC ctrl
              - Second escalation should cause the `lc_escalation_en` output to be asserted. Read
                the LC_STATE CSR to confirm that it is in the escalate state.
                - Verify that the escalate_en and check_bypass_en signals are asserted. X-ref'ed
                  with the respective IP tests that consume these signals.
              - Third escalation should cause the LC ctrl to transition to the virtual scrap state.
                At this stage, the CPU is not operational. Read the LC_STATE CSR via backdoor and
                confirm that it is is in the scrap state.
                - Verify that all decoded outputs except for escalate_en and check_bypass_en are
                  disabled. X-ref'ed with the respective IP tests that consume these signals.

            X-ref'ed with chip_lc_ctrl_broadcast test, which verifies the connectivity of the LC
            decoded outputs to other IPs.
            X-ref'ed with alert_handler's escalation test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_jtag_access
      desc: '''Verify enable to access LC ctrl via JTAG.

            Using the JTAG agent, write and read LC ctrl CSRs, verify the read value for
            correctness.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_jtag_trst
      desc: '''Verify the JTAG test reset input connection to LC ctrl.

            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_otp_hw_cfg
      desc: '''Verify the device_ID and ID_state CSRs

            - Preload the hw_cfg partition in OTP ctrl with random data.
            - Read the device ID and the ID state CSRs to verify their correctness.
            - Reset the chip and repeat the first 2 steps to verify a different set of values.
            '''
      milestone: V2
      tests: ["chip_sw_lc_ctrl_otp_hw_cfg"]
    }
    {
      name: chip_sw_lc_ctrl_init
      desc: '''Verify the LC ctrl initialization on power up.

            Verify that the chip powers up correctly on POR.
            - The pwrmgr initiates a handshake with OTP ctrl and later, with LC ctrl in subsequent
              FSM states. Ensure that the whole power up sequence does not hang.
            - Verify with connectivity assertion checks, the handshake signals are connected.
            - Ensure that no interrupts or alerts are triggered.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_transitions
      desc: '''Verify the LC ctrl can transition from one state to another valid state.

            - Initiate an LC ctrl state transition.
            - Ensure that the LC program request is received by the OTP ctrl.
            - Verify the updated data output from OTP ctrl to LC ctrl is correct.
            - Ensure that there is no background or otp_init error.
            - Verify that the LC ctrl has transitioned to the programmed state after a reboot.

            X-ref'ed chip_otp_ctrl_program.
            '''
      milestone: V2
      tests: ["chip_sw_lc_ctrl_transition"]
    }
    {
      name: chip_sw_lc_ctrl_kmac_req
      desc: '''Verify the token requested from KMAC.

            - For conditional transition, the LC ctrl will send out a token request to KMAC.
            - Verify that the KMAC returns a hashed token, which should match one of the
              transition token CSRs.

            X-ref'ed with chip_kmac_lc_req.
            '''
      milestone: V2
      tests: ["chip_sw_lc_ctrl_transition"]
    }
    {
      name: chip_sw_lc_ctrl_kmac_reset
      desc: '''Verify the effect of putting the KMAC logic in reset.

            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_key_div
      desc: '''Verify the keymgr div output to keymgr.

            - Verify in different LC states, LC ctrl outputs the correct `key_div_o` to keymgr.
            - Verify that the keymgr uses the given `key_div_o` value to compute the keys.

            X-ref'ed with chip_keymgr_lc_key_div_o.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_ctrl_broadcast
      desc: '''Verify broadcast signals from lc_ctrl.

            - Preload the LC partition in the OTP ctrl with the following states: RMA, DEV,
              TEST_LOCKED[N] & SCRAP (tested in chip_lc_ctrl_escalation).
            - Verify that the following broadcast signals are having the right effect in the
              respective IPs that consume them:
              - lc_dft_en_o: impacts clkmgr, pinmux, OTP ctrl & AST
              - lc_nvm_debug_en_o: impacts flash ctrl
              - lc_hw_debug_en_o: impacts pinmux, SRAM ctrl (main and ret) & the debug module
              - lc_cpu_en_o: impacts the CPU
              - lc_keymgr_en: impacts keymgr
              - lc_escalate_en_o: impacts SRAM ctrl, AES & OTP ctrl
              - lc_clk_byp_req_o: impacts clkmgr (handshake with lc_clk_byp_ack_i)
              - lc_flash_rma_req_o: impacts flash ctrl (handshake with lc_flash_ram_ack_i)
              - lc_flash_rma_seed_o: impacts flash ctrl
              - lc_check_byp_en_o: impacts OTP ctrl
              - lc_creator_seed_sw_rw_en_o: impacts flash ctrl & OTP ctrl
              - lc_owner_seed_sw_rw_en_o: impacts flash ctrl
              - lc_iso_part_sw_rd_en_o: impacts flash ctrl
              - lc_iso_part_sw_wr_en_o: impacts flash ctrl
              - lc_seed_hw_rd_en_o: impacts flash ctrl & OTP ctrl
            - These outputs are enabled per the [life cycle architecture spec]({{< relref "doc/security/specs/device_life_cycle/#architecture" >}}).
            X-ref'ed with the respective IP tests that consume these signals.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_lc_ctrl_scanmode
      desc: '''Verify the connectivity of scanmode to LC ctrl.

            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_ctrl_scanmode_reset
      desc: '''Verify the connectivity of scanmode reset to LC ctrl.

            '''
      milestone: V2
      tests: []
    }

    // SYSRST_CTRL (pre-verified IP) integration tests:
    {
      name: chip_sw_sysrst_ctrl_inputs
      desc: '''Verify that the SYSRST ctrl input pin values can be read.

            - Drive a known value on ac_reset, ec_rst_l, flash_wp_l, pwrb, lid_open and key* pins at
              the chip inputs.
            - Read the pin_in_value CSR to check for correctness.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_outputs
      desc: '''Verify that the SYSRST ctrl output pin values can be set.

            - Drive a known value on ac_reset, ec_rst_l, flash_wp_l, pwrb, lid_open and key* pins
              at the chip inputs.
            - Verify that SYSRST ctrl correctly loops them back to the chip outputs.
            - Write the pin_allowed_ctl register to allow some of the pins to be overridden with
              either 0 or 1 or both.
            - Write the pin_out_ctl register to enable the override on some of the pins.
            - Write the pin_out_value register to set known values on those pins.
            - Verify that at the chip outputs, pins on which override should be active is
              reflecting the overridden values. All others should reflect the values driven on chip
              inputs.
            - Via assertion checks (or equivalent) verify that the transitions at the inputs
              immediately reflect at the outputs, if not intercepted / debounced by sysrst_ctrl.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_in_irq
      desc: '''Verify the SYSRST ctrl can detect an input combination to signal an interrupt.

            - Program a specific combination of transitions on pwrb, key*, ac_present and ec_reset_l
              pins to trigger an interrupt by writing to key_intr_ctl register.
            - Program the key_intr_debounce_ctl register to debounce an appropriate time.
            - Enable the interrupt at SYSRST ctrl as well as at the PLIC.
            - Glitch the inputs at the chip IOs before stabilizing on the programmed transitions.
            - SW services the interrupt when triggered, verifies the pin input value and
              key_intr_status for correctness and clears the interrupt status.
            - Verify separately, eack key combination sufccessfully generates an interrupt.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_sleep_gsc_wakeup
      desc: '''Verify the SYSRST ctrl can wake up the chip from deep sleep.

            - Read the reset cause register in rstmgr to confirm we are in POR reset phase.
            - Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as
              a low power wakeup signal for the pwrmgr.
            - Program the associated detection timer.
            - Program the detection outcome CSR's (com_out_ctl) interrupt bit to 1.
            - Program the pwrmgr to put the chip in deep sleep state and wake up on GSC wake up
              event.
            - Issue a WFI to bring the chip in low power state.
            - After the chip has entered low power mode, set the SYSRST ctrl inputs at the chip IOs
              to the programmed combination for the duration of the detection timer.
            - Read the reset cause register to confirm wake up from low power exit phase.
            - Read the pwrmgr wake up status register to confirm GSC wake up.
            - Read the pin input value and the combo_intr_status CSRs to verify the correct
              combination on inputs woke up the chip from sleep.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_gsc_reset
      desc: '''Verify the SYSRST ctrl can reset the chip from normal state.

            - Read the reset cause register in rstmgr to confirm we are in POR reset phase.
            - Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as
              the GSC reset signal.
            - Program the associated detection timer.
            - Program the detection outcome CSR's (com_out_ctl) GSC reset bit to 1.
            - After some time, set the SYSRST ctrl inputs at the chip IOs to the programmed
              combination for the duration of the detection timer.
            - The pwrmgr will power cycle the chip once it receives the GSC reset input.
            - Read the reset cause register after boot up to confirm peripheral reset phase.
            - Read the pwrmgr reset status register to confirm GSC reset.
            - Read the com_sel_ctl_* CSR in SYSRST ctrl we programmed earlier - it should have been
              reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_sleep_gsc_reset
      desc: '''Verify the SYSRST ctrl can reset the chip from deep sleep.

            - Read the reset cause register in rstmgr to confirm we are in POR reset phase.
            - Program one of the com_sel_ctl_* CSRs to choose a set of inputs to be detected as
              the GSC reset signal.
            - Program the associated detection timer.
            - Program the detection outcome CSR's (com_out_ctl) GSC reset bit to 1.
            - Program the pwrmgr to put the chip in deep sleep state and allow it to be reset by GSC
              reset bit.
            - Issue a WFI to bring the chip in low power state.
            - After the chip has entered low power mode, set the SYSRST ctrl inputs at the chip IOs
              to the programmed combination for the duration of the detection timer.
            - The pwrmgr will power cycle the chip from the deep sleep state once it receives the
              GSC reset input.
            - Read the reset cause register after boot up to confirm peripheral reset phase.
            - Read the pwrmgr reset status register to confirm GSC reset.
            - Read the com_sel_ctl_* CSR in SYSRST ctrl we programmed earlier - it should have been
              reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_ec_rst_l
      desc: '''Verify that the ec_rst_l stays asserted on power-on-reset until SW can control it.

            - Verify that ec_rst_l stays asserted as the chip is brought out of reset.
            - Verify that the pin continues to remain low until SW is alive.
            - Have the SW write to pin_allowed|out_ctrl CSRs to control the ec_rst_l value and
              verify the value at the chip output.
            - Optionally, also verify ec_rst_l pulse stretching by setting the ec_rst_ctl register
              with a suitable pulse width.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_flash_wp_l
      desc: '''Verify that the flash_wp_l stays asserted on power-on-reset until SW can control it.

            - Exactly the same as chip_sysrst_ctrl_ec_rst_l, but covers the flash_wp_l pin.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sysrst_ctrl_ulp_z3_wakeup
      desc: '''Verify the z3_wakeup signaling.

            - Start off with ac_present = 0, lid_open = 0 and pwrb = 0 at the chip inputs.
            - Program the ulp_ac|lid|pwrb_debounce_ctl registers to debounce these inputs for an
              appropriate time.
            - Enable the ULP wakeup feature by writing to the ulp_ctl register.
            - Read the ulp_wakeup register and verify that no wakeup event is detected, after some
              amount of delay.
            - Glitch the lid_open input at the chip IOs before stabilizing on value 1.
            - Read the ulp_wakeup register to verify that the wakeup event is detected this time.
            - Verify that the z3_wakeup output at the chip IOs is reflecting the value of 1.
            '''
      milestone: V2
      tests: []
    }

    // ADC_CTRL (pre-verified IP) integration tests:
    {
      name: chip_sw_adc_ctrl_debug_cable_irq
      desc: '''Verify that the ADC correctly detects the voltage level programmed for each channel.

            - Program both ADC channels to detect mutually exclusive range of voltages. Setting only
              one filter CSR is sufficient.
            - Program the ADC intr ctrl CSR to detect the selected filter on both channels.
              Enable the debug cable interrupt at ADC ctrl as well as PLIC.
            - Enable the ADC ctrl to run with defaults in normal mode (depending on simulation
              runtime).
            - Verify through assertion checks, the ADC with AST stays powered down periodically in
              slow scan mode.
            - After some time, force the ADC output of AST to be a value within the programmed range
              for each channel. Glitch it out of range for some time before stabilizing to ensure
              that debouce logic works.
            - Service the debug cable irq. Read the intr status register to verify that the selected
              filter caused the interrupt to fire. Read the ADC channel value register to verify the
              correctness of the detected value that was forced in the AST for each channel.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_adc_ctrl_sleep_debug_cable_wakeup
      desc: '''Verify that in deep sleep, ADC ctrl can signal the ADC within the AST to power down.

            - Read the reset cause register in rstmgr to confirm we are in POR reset phase.
            - Follow the same steps as chip_adc_ctrl_debug_cable_irq, but instead of programming the
              selected filter to interrupt, program it to wake up the chip from sleep.
            - Program the pwrmgr to put the chip in deep sleep state and wake up on debug cable
              detection.
            - Issue a WFI to bring the chip in low power state.
            - After some time, force the ADC output of AST to be a value within the programmed
              filter range. That should cause the pwrmgr to wake up.
            - Read the reset cause register to confirm wake up from low power exit phase.
            - Read the pwrmgr wake up status register to confirm wake up was due to debug cable
              detection.
            - Read the ADC channel value register to verify the correctness of the detected value
              that was forced in the AST.
            - Repeat for both ADC channels.
            '''
      milestone: V2
      tests: []
    }

    ///////////////////////////////////////////////////////
    // Security Peripherals                              //
    // AES, HMAC, KMAC, CSRNG, ENTROPY_SRC, KEYMGR, OTBN //
    ///////////////////////////////////////////////////////

    // AES (pre-verified IP) integration tests:
    {
      name: chip_sw_aes_enc
      desc: '''Verify the AES operation.

            Write a 32-byte key and a 16-byte plain text to the AES registers and trigger the AES
            computation to start. Wait for the AES operation to complete by polling the status
            register. Check the digest registers for correctness against the expected digest value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aes_entropy
      desc: '''Verify the AES entropy input used by the internal PRNGs.

            - Write the initial key share, IV and data in CSRs (known combinations).
            - Configure the entropy_src to generate entropy in LFSR mode.
            - Write the PRNG_RESEED bit to reseed the internal state of the PRNG.
            - Poll the status idle bit to ensure reseed operation is complete.
            - Trigger the AES operation to run and wait for it to complete.
            - Check the digest against the expected value.
            - Write the KEY_IV_DATA_IN_CLEAR and DATA_OUT_CLEAR trigger bits to 1 and wait for it to
              complete by polling the status idle bit.
            - Read back the data out CSRs - they should all read garbage values.
            - Assertion check verifies that the internal states (data_in, key share and IV are also
              garbage, i.e. different from the originally written values.
            - Assertion checks proves that all interfaces are connected across AST RNG, ES, CSRNG,
              EDN and AES.
            - Predict the generated entropy bits and check against the observed for correctness.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aes_edn_reset
      desc: '''Verify that the EDN clock / reset is connected to AES.

            - Ensure that the PRNG within AES resets when the EDN logic is held in reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aes_lc_escalate_en
      desc: '''Verify the effect of LC escalate en signal on AES.

            - Trigger an LC escalatation signal by writing to alert_test CSR (in some other IP).
            - Trigger an AES operation to run.
            - When the escalation kicks in, verify that the AES is in the error state.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aes_idle
      desc: '''Verify AES idle signaling to clkmgr.

            - Write the AES clk hint to 1 within clkmgr to indicate AES clk is ready to be gated.
              Verify that the AES clk hint status within clkmgr reads 0 (AES is idle).
            - Initiate an AES operation with a known key, plain text and digest.
              Verify that the AES clk hint status within clkmgr now reads 1 (AES is not idle),
              before the AES operation is complete.
            - After the AES operation is complete, verify the digest for correctness.
              Verify that the AES clk hint status within clkmgr now reads 0 again (AES is idle),
              after the AES operation is complete.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_aes_sideload
      desc: '''Verify the AES sideload mechanism.

            Details TBD, design updates pending.
            '''
      milestone: V2
      tests: []
    }

    // HMAC (pre-verified IP) integration tests:
    {
      name: chip_sw_hmac_enc
      desc: '''Verify HMAC operation.

            SW test verifies an HMAC operation with a known key, plain text and digest (pick one of
            the NIST vectors). SW test verifies the digest against the pre-computed value. Verify
            the HMAC done and FIFO empty interrupts as a part of this test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_hmac_idle
      desc: '''Verify the HMAC clk idle signal to clkmgr.

            - Write the HMAC clk hint to 1 within clkmgr to indicate HMAC clk is ready to be gated.
              Verify that the HMAC clk hint status within clkmgr reads 0 (HMAC is idle).
            - Initiate an HMAC operation with a known key, plain text and digest.
              Verify that the HMAC clk hint status within clkmgr now reads 1 (HMAC is not idle),
              before the HMAC operation is complete.
            - After the HMAC operation is complete, verify the digest for correctness.
              Verify that the HMAC clk hint status within clkmgr now reads 0 again (HMAC is idle),
              after the HMAC operation is complete.
            '''
      milestone: V2
      tests: []
    }

    // KMAC pre-verified IP) integration tests:
    {
      name: chip_sw_kmac_enc
      desc: '''Verify the SHA3 operation.

            SW test verifies SHA3 operation with a known key, plain text and digest (pick one of
            the NIST vectors). SW validates the reception of kmac done and fifo empty interrupts.
            '''
      milestone: V2
      tests: ["chip_sw_kmac_mode_cshake_test", "chip_sw_kmac_mode_kmac_test"]
    }
    {
      name: chip_sw_kmac_app_keymgr
      desc: '''Verify the keymgr interface to KMAC.

            - Configure the keymgr to start sending known message data to the KMAC.
            - Keymgr should transmit a sideloaded key to the KMAC as well.
            - KMAC should finish hashing successfully (not visible to SW) and return digest to
              keymgr.
            - This digest is compared against the known digest value for correctness.
            - Verify that the keymgr has received valid output from the KMAC.

            X-ref'ed with keymgr test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_kmac_app_lc
      desc: '''Verify the LC interface to KMAC.

            - Configure the LC_CTRL to start a token hash using KMAC interface.
            - KMAC should finish hashing successfully (not visible to SW) and return digest to
            LC_CTRL.

            X-ref'ed with LC_CTRL test/env.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_kmac_app_rom
      desc: '''Verify the ROM interface to KMAC.

            - Backdoor initialize ROM memory immediately out of reset.
            - ROM will send message to the KMAC containing its memory contents,
            - KMAC will hash and return the digest to the ROM.
            - ROM will compare received digest against its first 8 logical memory lines for
            correctness.

            X-ref'ed with ROM_CTRL test/env.
            '''
      milestone: V2
      tests: ["chip_sw_kmac_app_rom_test"]
    }
    {
      name: chip_sw_kmac_entropy
      desc: '''Verify the EDN interface to KMAC.

            Requires `EnMasking` parameter to be enabled.
            SW randomly configures the KMAC in any hashing mode/strength, and enable EDN mode.
            Randomly enable/disable the `entropy_refresh`.
            // TODO - error handling is not complete, do not enable `wait_timer` yet.
            KMAC should send request to EDN once `CmdStart` is written, and should send out another
            request to EDN when either:
              - kmac hash counter hits the configured threshold (assuming it is non-zero)
              - a hash operation is completed, KMAC will refresh its internal entropy state
            SW verifies that KMAC produces the correct digest value.

            TODO: This is pending security review discussion. It is unclear if this feature will be
            implemented.

            X-ref'ed with EDN test/env.
            '''
      milestone: V3
      tests: []
    }
    {
      name: chip_sw_kmac_edn_reset
      desc: '''Verify that the EDN clock / reset is connected to KMAC.

            // TODO: check if this can use connectivity test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_kmac_idle
      desc: '''Verify the KMAC idle signaling to clkmgr.

            - Write the KMAC clk hint to 1 within clkmgr to indicate KMAC clk is ready to be gated.
              Verify that the KMAC clk hint status within clkmgr reads 0 (KMAC is idle).
            - Initiate an KMAC operation with a known key, plain text and digest.
              Verify that the KMAC clk hint status within clkmgr now reads 1 (KMAC is not idle),
              before the KMAC operation is complete.
            - After the KMAC operation is complete, verify the digest for correctness.
              Verify that the KMAC clk hint status within clkmgr now reads 0 again (KMAC is idle),
              after the KMAC operation is complete.
            '''
      milestone: V2
      tests: []
    }

    // ENTROPY_SRC (pre-verified IP) integration tests:
    {
      name: chip_sw_entropy_src_ast_rng_req
      desc: '''Verify the RNG req to ast.

            - Program the entropy src in normal RNG mode.
            - Route the entropy data received from RNG to the FIFO.
            - Verify that the FIFO depth is non-zero via SW - indicating the reception of data over
              the AST RNG interface.
            - Verify the correctness of the received data with assertion based connectivity checks.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_entropy_src_ast_fips
      desc: '''Verify the connectivity of rng_fips_o feedback signal to RNG.

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_entropy_src_csrng
      desc: '''Verify the transfer of entropy bits to CSRNG.

            Verify the entropy valid interrupt.
            At the CSRNG, validate the reception of entropy req interrupt.
            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_entropy_src_cs_aes_halt
      desc: '''Verify the aes halt handshake with CSRNG.

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_entropy_src_fuse_en_fw_read
      desc: '''Verify the fuse input entropy_src.

            - Initialize the OTP with this fuse bit set to 1.
            - Perform an entropy request operation.
            - Read the entropy_data_fifo via SW; verify that it reads valid values.
            - Reset the chip, but this time, initialize the OTP with this fuse bit set to 0.
            - Perform an entropy request operation.
            - Read the internal state via SW; verify that it reads all zeros this time.
            '''
      milestone: V2
      tests: []
    }

    // CSRNG tests:
    {
      name: chip_sw_csrng_edn_cmd
      desc: '''Verify incoming command interface from EDN.

            - Have each EDN instance issue an instantiate command to CSRNG.
            - When done, verify the reception of cmd req done interrupt.
            - Check the data returned to EDN via connectivity assertion checks.
            - TODO: explore the ability to generate predictable data and verify the received value.
            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_csrng_fuse_en_sw_app_read
      desc: '''Verify the fuse input to CSRNG.

            - Initialize the OTP with this fuse bit set to 1.
            - Issue an instantiate command to request entropy.
            - Verify that SW can read the internal states.
            - Reset the chip and repeat the steps above, but this time, with OTP fuse bit set to 0.
            - Verify that the SW reads back all zeros when reading the internal states.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_csrng_lc_hw_debug_en
      desc: '''Verify the effect of LC HW debug enable on CSRNG.

            TODO: This is pending SCA security review and might be removed.
            '''
      milestone: V2
      tests: []
    }

    // EDN (pre-verified IP) integration tests:
    {
      name: chip_sw_edn_entropy_reqs
      desc: '''Verify the entropy requests from all peripherals.

            Verify that there are no misconnects between each peripheral requesting entropy.
            TODO: system level scenario: have all entropy sources request entropy in the same test
            one after to show boot to post boot load, cycling all entropy blocks off and on again.
            Ensure there are no deadlocks and everything works as expected.
            X'ref'ed with each IP test that requsts entropy from EDN.
            '''
      milestone: V2
      tests: []
    }

    // KEYMGR (pre-verified IP) integration tests:
    {
      name: chip_sw_keymgr_key_derivation
      desc: '''Verify the keymgr advances to all states and generate identity / SW output.

            - Backdoor load random value to OTP key, OTP device ID, creator and owner seeds in
              flash, and the ROM digest
            - For HardwareRevisionSecret and LC diversification, use the constant values in design.
            - Configure the keymgr and advance to `CreatorRootKey`.
            - Generate identity / SW output for both Attestation CDI and Sealing CDI.
            - KMAC should finish hashing successfully (not visible to SW) and return digest to
              keymgr.
            - Verify that the keymgr has received valid output from the KMAC.
            - Advance to `OwnerIntermediateKey` and `OwnerRootKey` to repeat the above sequences.
            - Generating identity / SW output in `OwnerRootKey` is optional as there is not
              additional interaction between keymgr and other blocks.
            - Advance to `Disabled` and verify keymgr enters the state successfully.
            - Generate identity / SW output and ensure these are neither all 1s/0s nor any valid
              key value, which proves secrets are wiped by entropy value from EDN.

            - For each operation, wait for the interrupt `op_done` to be triggered and check CSR
              `op_status` is `DONE_SUCCESS`.

            - Note: there are 3 ways of calculating the expected digest for comparison. Any of them
              is acceptable.
              - Use SW to calculate that, and it will also exercise the Ibex
              - SW sends all the keys through CSRs to KMAC to generate the degist data
              - DV calls C functions to generate and backdoor load to a specific memory location
                for SW

            X-ref'ed with kmac test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_keymgr_lc_disable
      desc: '''Verify that the keymgr is disabled on LC escalation.

            - Configure the keymgr and advance to `CreatorRootKey`.
            - Transition life cycle to `ESCALATION` state, which should disable keymgr.
            - Verify keymgr enters the `Disabled` state successfully.

            X-ref'ed with life cycle test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_keymgr_sideload_kmac
      desc: '''Verify the keymgr sideload interface to KMAC, similar to `chip_kmac_app_keymgr`.

            - Configure the keymgr and advance to `CreatorRootKey`.
            - Transmit a sideloaded key to the KMAC.
            - Configure KMAC to use the sideload key to generate digest data.
            - Verify the digest for correctness.
            - Advance to 2 other operational states and repeat the above sequences (optional).

            X-ref'ed with chip_kmac_app_keymgr test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_keymgr_sideload_aes
      desc: '''Verify the keymgr sideload interface to AES.

               Same as `chip_keymgr_sideload_kmac`, except, sideload to AES.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_keymgr_sideload_otbn
      desc: '''Verify the keymgr sideload interface to OTBN.

               Load OTBN binary image, the rest is similar to `chip_keymgr_sideload_kmac`, except
               sideloading to otbn.
            '''
      milestone: V2
      tests: []
    }

    // OTBN (pre-verified IP) integration tests:
    {
      name: chip_sw_otbn_op
      desc: '''Verify an OTBN operation.

            - SW test directs the OTBN engine to perform an ECDSA operation.
            - SW validates the reception of the otbn done interrupt once the operation is complete.
            - SW verifies the correctness of the result with the expected value which is
              pre-computed using a reference model.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otbn_rnd_entropy
      desc: '''Verify OTBN can fetch RND numbers from the entropy src.

            - SW initializes the entropy subsystem to generate randomness.
            - SW loads an OTBN app that executes instructions to read the RND bits.
            - The OTBN app ensures that the values when read consequtively do not match, and its not
              all 0s or all 1s, as a basic measure to ensure that the entropy subsystem is returning
              some data.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otbn_urnd_entropy
      desc: '''Verify OTBN can fetch URND numbers from the entropy src.

            - Similar to chip_otbn_rnd_entropy, but verifies the URND bits.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otbn_idle
      desc: '''Verify the OTBN idle signal to clkmgr.

            - Write the OTBN clk hint to 1 within clkmgr to indicate OTBN clk is ready to be gated.
              Verify that the OTBN clk hint status within clkmgr reads 0 (OTBN is idle).
            - Start an OTBN operation.
              Verify that the OTBN clk hint status within clkmgr now reads 1 (OTBN is not idle),
              before the operation is complete.
            - After the OTBN operation is complete, check the output for correctness.
              Verify that the OTBN clk hint status within clkmgr now reads 0 again (OTBN is idle),
              after the operation is complete.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_otbn_edn_reset
      desc: '''Verify that the EDN clock / reset is connected to OTBN.

            - Use connectivity assertion check to verify that the right clock and reset signals are
              connected for receiving the entropy data from EDN.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_otbn_ast_ram_cfg
      desc: '''Verify that the ram_cfg signal from AST is connected to OTBN.

            - In open source, this is verified by a simple connectivity assertion check.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otbn_mem_scramble
      desc: '''Verify the OTBN can receive keys from the OTP to scramble the OTBN imem and dmem.

            - Have OTBN fetch a new key and nonce from the OTP_CTRL.
            - Write and read-check OTBN and IMEM for consistency.
            - Fetch a new key from the OTP_CTRL and ensure that previous contents in the IMEM and
              DMEM cannot be read anymore.
            '''
      milestone: V2
      tests: []
    }

    /////////////////////////////////////////////////////
    // Memory & Controllers                            //
    // ROM_CTRL, RAM, FLASH, FLASH_CTRL, OTP, OTP_CTRL //
    /////////////////////////////////////////////////////

    // ROM_CTRL (pre-verified IP) integration tests:
    {
      name: chip_sw_rom_access
      desc: '''Verify that the CPU can access the rom contents.

            - Verify that the CPU can fetch instructions from the ROM.
            '''
      milestone: V2
      tests: ["chip_sw_rom_ctrl_integrity_check_test"]
    }
    {
      name: chip_rom_ctrl_ast_rom_cfg
      desc: '''Verify that the rom_cfg signal from AST is connected to ROM ctrl.

            - In open source, this is verified by a simple connectivity assertion check.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_rom_ctrl_integrity_check
      desc: '''Verify that the ROM ctrl performs the integrity check of the ROM on power up.

            - In non-PROD LC state, the computed digest does not have to match the top 8 words in
              the ROM. Verify that we can successfully power up the chip in this case.
            - In PROD LC state, verify that the pwrmgr does not fully power up if the computed
              digest does not match the top 8 words of the ROM.
            '''
      milestone: V2
      tests: ["chip_sw_rom_ctrl_integrity_check_test"]
    }
    {
      name: chip_sw_rom_ctrl_reset_glitch
      desc: '''Verify that a glitch on the ROM ctrl's reset input is triggered as a fatal alert.

            - In normal boot up from POR, the ROM contents are checked for validity using KMAC.
            - After boot up, read the reset cause register in rstmgr to confirm POR reset phase.
            - SW goes into idle state (nothing to do).
            - The testbench randomly glitches the ROM ctrl's reset input, which causes ROM ctrl to
              re-check the contents for validity.
            - Verify that the KMAC detects the repeat presentation of data from ROM ctrl as a fatal
              alert and the chip is rebooted via the alert escalation path.
            - After boot up, read the reset cause register in rstmgr to confirm reset due to alert
              phase.
            '''
      milestone: V2
      tests: []
    }

    // SRAM (pre-verified IP) integration tests:
    {
      name: chip_sw_sram_scrambled_access
      desc: '''Verify scrambled memory accesses to both main and retention SRAMs.

            - Trigger both SRAMs to fetch a new key and nonce from the OTP_CTRL
            - Drive the CPU to perform random accesses to both RAMs and verify these operations
              complete successfully by using the backdoor interface
            - Fetch a new key from the OTP_CTRL and ensure that the previous contents cannot be read
              anymore.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sleep_sram_ret_contents
      desc: '''Verify that the data within the retention SRAM survives low power entry-exit.

            Ensure that the data within the retention SRAM survives ALL low power entry-exit
            variations.

            TODO: how to deal with the scramble keys on low power exit?
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sram_execution
      desc: '''Verify that CPU can fetch instructions from SRAM if enabled.

            - Create the following combinations of 8 scenarios:
              - The fetch enable bit in the HW_CFG partition of OTP controller set and not set.
              - A life cycle state that enables (TEST_UNLOCKED, DEV or RMA) and disables (PROD)
                hardware debug.
              - The execution CSR programmed to be enabled and disabled.

            - For both, main and the retention SRAM in each of these 8 scenarios:
              - Load instruction data into the SRAMs.
              - If the instruction execution is enabled, verfy that the CPU can fetch and execute
                the instruction from the SRAM correctly.
              - If the instruction execution is not enabled, verfy that the SRAM throws an error
                response via an exception handler.

            The following table indicates in which of these scenarios should the instruction
            execution be enabled, for both, main and the retention SRAM instances.

              | OTP HW_CFG[IFETCH] | HW_DEBUG_EN via LC state | EXEC CSR | MAIN SRAM | RET SRAM |
              |:------------------:|:------------------------:|:--------:|:---------:|:--------:|
              |          0         |             0            |     0    |  disabled | disabled |
              |          0         |             0            |     1    |  disabled | disabled |
              |          0         |             1            |     0    |  enabled  | disabled |
              |          0         |             1            |     1    |  enabled  | disabled |
              |          1         |             0            |     0    |  disabled | disabled |
              |          1         |             0            |     1    |  enabled  | disabled |
              |          1         |             1            |     0    |  disabled | disabled |
              |          1         |             1            |     1    |  enabled  | disabled |

            For the retention SRAM, instruction fetch is completely disabled via design parameter.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sram_lc_escalation
      desc: '''Verify the LC escalation path to the SRAMs.

            - Configure the LC_CTRL to trigger an escalation request to the SRAMs.
            - Verify that the SRAMs stop accepting and responding to new memory requests.
            - Reset the system to exit the terminal escalation state.
            - Re-initialize the SRAMs and verify that they can now respond correctly to
              any further memory requests.
            '''
      milestone: V2
      tests: []
    }

    // OTP (pre-verified IP) integration tests:
    {
      name: chip_otp_ctrl_init
      desc: '''Verify the OTP ctrl initialization on chip power up.

            Verify that the chip powers up correctly on POR.
            - The pwrmgr initiates a handshake with OTP ctrl and later, with LC ctrl in subsequent
              FSM states. Ensure that the whole power up sequence does not hang.
            - Verify with connectivity assertion checks, the handshake signals are connected.
            - Ensure that no interrupts or alerts are triggered.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_keys
      desc: '''Verify the proliferation of keys to security peripherals.

            - Verify the correctness of keys provided to SRAM ctrl (main & ret), flash ctrl, keymgr,
              (note that keymgr does not have handshake), and OTBN.

            X-ref'ed with IP tests that consume these signals.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_entropy
      desc: '''Verify the entropy interface from OTP ctrl to EDN.

            This is X-ref'ed with the chip_otp_ctrl_keys test, which needs to handshake with the EDN
            to receive some entropy bits before the keys for SRAM ctrl and OTBN are computed.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_edn_reset
      desc: '''Verify the effect of putting the EDN domain in reset on OTP ctrl.

            Verify that the computed nonce for SRAM is reset?
            Verify all entropy data used for various things are reset.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_program
      desc: '''Verify the program request from lc_ctrl.

            - Verify that upon an LC state transition request, LC ctrl signals the OTP ctrl with a
              program request.
            - Verify that the OTP ctrl generates the LC data output correctly and is sent to the LC
              ctrl before it is reset.
            - Verify that the `lc_check_byp_en_i` from LC ctrl is set.
            - Ensure that the whole operation does not raise any interrupts or alerts or errors.
            - After reset, verify that the LC state transition completed successfully by reading the
              LC state and LC count CSRs.
            '''
      milestone: V2
      tests: ["chip_sw_lc_ctrl_transition"]
    }
    {
      name: chip_sw_otp_ctrl_program_error
      desc: '''Verify the otp program error.

            - Initiate an illegal program request from LC ctrl to OTP ctrl (example: issue program
            request when the lc_cnt is at max value).
            - Verify that the LC ctrl triggers an alert when the OTP ctrl responds back with a
              program error.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_hw_cfg
      desc: '''Verify the correctness of otp_hw_cfg bus in all peripherals that receive it.

            Preload the OTP ctrl's `hw_cfg` partition with random data and verify that all
            consumers of the hardware configuration bits are receiving the correct values.

            Xref'ed with corresponding IP tests that receive these bits.
            '''
      milestone: V2
      tests: ["chip_sw_lc_ctrl_otp_hw_cfg"]
    }
    {
      name: chip_sw_otp_ctrl_lc_signals
      desc: '''Verify the broadcast signals from LC ctrl.

            - `lc_escalate_en_i`: read the error code CSR and verify that it reflects an FSM error
              state due to the escalation signal triggering.
            - `lc_creator_seed_sw_rw_en_i`: verify that the secret2 partition is locked.
            - `lc_seed_hw_rd_en_i`: verify that the keymgr outputs a default value when enabled.
            - `lc_dft_en_i`: verify that the test interface within OTP ctrl is accessible.
            - `lc_check_byp_en_i`: verify that the background check during LC ctrl state
              programming passes when enabled.

            `X-ref'ed with chip_otp_ctrl_program.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_otp_ctrl_ast
      desc: '''Verify the power sequencing signals to AST, as well as the alert.

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_otp_ctrl_external_voltage
      desc: '''Verify the connectivity of the external voltage signal to OTP ctrl.

            Details TBD.
            TODO; This signal is not connected in the design yet.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_otp_ctrl_scan
      desc: '''Verify the connectivity of the scan signals to OTP ctrl.

            Details TBD.
            TODO; This signal is not connected in the design yet.
            '''
      milestone: V2
      tests: []
    }

    // FLASH (pre-verified IP) integration tests:
    {
      name: chip_sw_flash_init
      desc: '''Verify that flash initialization routine works correctly.

            - Initialize the flash ctrl by writing 1 to the INIT register.
            - Poll the status register for the initialization to complete.
            - Verify that during the init process, the flash ctrl requested keys from OTP. Verify
              with different sets of key values programmed in OTP.
            - Verify the flash ctrl can read seeds when lc_seed_hw_rd_en is set, otherwise all 1s.
            - Verify that the flash ctrl sent the creator and owner seeds to keymgr. Verify with
              different seed values.

            - This test needs to execute as a boot rom image.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_host_access
      desc: '''Verify that the flash memory contents can be read by the CPU.

            Nothing extra to do here - most SW based tests fetch code from flash.
            '''
      milestone: V2
      tests: ["chip_sw_flash_ctrl_access"]
    }
    {
      name: chip_sw_flash_ctrl_ops
      desc: '''Verify the SW can initiate flash operations via the controller.

            Verify that the CPU can read / program and erase the flash mem. Pick an operation on
            all data and info partitions. Erase both, bank and page. SW validates the reception of
            prog empty, prog level, rd full, rd level and op done interrupts.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_rma_unlocked
      desc: '''Verify the flash memory contents can be accessed after in RMA unlock.

            - Provision an RMA_UNLOCK token in OTP.
            - Reset the chip.
            - Enable RMA mode, and verify that the SW can access the flash. Ensure that the previous
              contents are inaccessible.

            - RMA entry can be on the C side as well. This should be done over C - The JTAG
              interface to flash ctrl is actually for the closed src.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_flash_jtag_conn
      desc: '''
            Verify that the JTAG interface for the closed source flash macro is connected from chip
            IOs.

            In open source, this JTAG interface is null-terminated, so we can only verify this
            through a connectivity test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_scramble
      desc: '''Verify flash scrambling via the controller.

            - Extends the chip_flash_init test.
            - Verify flash scrambling with different key values programmed in OTP.
            - Verify read of scrambled contents via both, controller and direct host read.

            - Program a new scramble key in OTP and reboot - this time we need to backdoor load the
              flash with new test image that is re-scrambled with the new key.
            - Need to understand the bootstrapping requirements.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_idle_low_power
      desc: '''Verify flash_idle signaling to pwrmgr.

            - Initiate flash program or erase over the controller.
            - Program the pwrmgr to go into deep sleep.
            - Issue a WFI.
            - Ensure that the low power entry is gated until the flash operation completes.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_keymgr_seeds
      desc: '''Verify the creator and owner seeds are read on flash init provided lc_hw_seed_rd_en
            is set.

            X-ref'ed with keymgr test.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_lc_creator_seed_sw_rw_en
      desc: '''Verify the lc_creator_seed_sw_rw_en signal from LC ctrl.

            - Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify
              that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW
              accessibility of the corresponding partition depending on the signal value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_creator_seed_wipe_on_rma
      desc: '''Verify that the creator seed is wiped by the flash ctrl on RMA entry.
            '''
      milestone: V2
      tests: []

    }
    {
      name: chip_sw_flash_lc_owner_seed_sw_rw_en
      desc: '''Verify the lc_owner_seed_sw_rw_en signal from LC ctrl.

            - Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify
              that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW
              accessibility of the corresponding partition depending on the signal value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_lc_iso_part_sw_rd_en
      desc: '''Verify the lc_iso_part_sw_rd_en signal from LC ctrl.

            - Transition from DEV to PROD to ESCALATION/SCRAP state via OTP and verify
              that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW
              accessibility of the corresponding partition depending on the signal value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_lc_iso_part_sw_wr_en
      desc: '''Verify the lc_creator_seed_sw_wr_en signal from LC ctrl.

            - Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify
              that this LC signal transitions from 0 to 1 and back to 0. Verify that the SW
              accessibility of the corresponding partition depending on the signal value.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_lc_seed_hw_rd_en
      desc: '''Verify the lc_seed_hw_rd_en signal from LC ctrl.

            - Transition from TEST_LOCKED to DEV/PROD to ESCALATION/SCRAP state via OTP and verify
              that this LC signal transitions from 0 to 1 and back to 0. Verify that the flash ctrl
              does (or does not) read the creator and owner partitions to fetch the seeds for the
              keymgr.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_flash_lc_escalate_en
      desc: '''Verify the lc_escalate_en signal from LC ctrl.

            - Trigger an LC escalatation signal by generating an alert.
            - Verify that all flash accesses are disabled when the escalation kicks in.
            - The CPU cannot read the flash either once escalation kicks in. This is unfortunately
              not possible because the CPU is also disabled when the escalation is triggered.
            - Use connectivity check to prove that this signal is connected to the flash ctrl.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_prim_tl_access
      desc: '''Verify that the SW can read / write the dummy memory in flash phy.

            - The dummy memory is a open source placeholder for the closed source CSRs that will be
              implemented in a translation 'shim'.
            - Verify that this region can be read / written to by the SW.

            - TODO: the existing CSR / mem tests may already handle this.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_flash_ast_conn
      desc: '''Verify the connectivity of AST / top level signals.

            - From AST to flash ctrl:
               flash_power_ready_h_i, flash_power_down_h_i, flash_bist_enable_i, scanmode_i,
               scan_en_i, scan_rst_ni.

            - From top level (chip IOs):
                flash_test_mode_a_io, flash_test_voltage_h_io.

            - From flash ctrl to AST:
                flash_alert_o.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_flash_ctrl_clock_freqs
      desc: '''Verify flash program and erase operations over the ctrl over a range of clock freqs.

            - The range of clock freqs to test is TBD.
            - Reuse chip_flash_ctrl_ops to also enable jitter on the clock as well as run with
              randomized clock frequencies.
            - This sets the test for closed source where the flash access timing matters.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_flash_lc_nvm_debug_en
      desc: '''Verify that the lc_nvm_debug_en signal from LC ctrl is connected to the flash ctrl.

            - Use connectivity test in the open source, since this signal is not used..
            '''
      milestone: V2
      tests: []
    }

    ////////////////////////
    // Analog Peripherals //
    // AST, SENSOR_CTRL   //
    ////////////////////////

    // AST (pre-verified IP) integration tests:
    {
      name: chip_sw_ast_clk_outputs
      desc: '''Verify that the AST generates the 4 clocks when requested by the clkmgr.

            Verify the clock frequencies are reasonably accurate. Verify that when the clkmgr
            deasserts the enable (on account of low power entry), the clocks are turned off. Verify
            that when turned on (low power exit), the clocks are glitch free.

            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_ast_clk_rst_inputs
      desc: '''Verify the clk and rst inputs to AST (from `clkmgr`).

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_ast_sys_clk_jitter
      desc: '''Verify that the AST sys clk jitter control.

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_ast_usb_clk_calib
      desc: '''Verify the USB clk calibration signaling.

            Details TBD.
            '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_ast_alerts
      desc: '''Verify the alerts from AST aggregating into the sensor_ctrl.

             X-ref'ed with `chip_sensor_ctrl_ast_alerts`.
             '''
      milestone: V2
      tests: []
    }

    // SENSOR_CTRL tests:
    {
      name: chip_sw_sensor_ctrl_ast_alerts
      desc: '''Verify the alerts from AST aggregating into the sensor_ctrl.

             Details TBD.
             '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sensor_ctrl_ast_status
      desc: '''Verify the io power ok status from AST.

             Details TBD.
             '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_pwrmgr_sleep_sensor_ctrl_alert_wakeup
      desc: '''Verify the sensor control is able to wake the device
               from sleep mode when an alert event is triggered from
               AST. X-ref'ed chip_sw_pwrmgr_sleep_all_wake_ups.
             '''
      milestone: V2
      tests: []
    }

    ////////////////////////////
    // System level scenarios //
    ////////////////////////////

    {
      name: chip_sw_smoketest
      desc: '''Run smoke tests developed for each IP.

            The smoke tests are developed by the SW team to test each IP is
            alive, and can be actuated by the DIF. We need to ensure that they
            work in DV as well.
            '''
      milestone: V2
      tests: ["chip_sw_aes_smoketest",
              "chip_sw_aon_timer_smoketest",
              "chip_sw_clkmgr_smoketest",
              // TODO(lowrisc/opentitan#7505): Debug CSRNG generate bits mismatch.
              // "chip_sw_csrng_smoketest",
              "chip_sw_entropy_src_smoketest",
              "chip_sw_gpio_smoketest",
              "chip_sw_hmac_smoketest",
              "chip_sw_kmac_smoketest",
              "chip_sw_otbn_smoketest",
              "chip_sw_otp_ctrl_smoketest",
              "chip_sw_rv_plic_smoketest",
              "chip_sw_pwrmgr_smoketest",
              "chip_sw_rv_timer_smoketest",
              "chip_sw_rstmgr_smoketest",
              "chip_sw_sram_ctrl_smoketest",
              "chip_sw_uart_smoketest",
            ]
    }
    {
      name: chip_sw_coremark
      desc: '''Run the coremark benchmark on the full chip.'''
      milestone: V2
      tests: ["chip_sw_coremark"]
    }
    {
      name: chip_sw_boot
      desc: '''Verify the full flash image download with bootstrap signal set.

            - SW puts the SPI device in firmware mode
            - Load a firmware image (bootstrap) through spi input pin to the spi_device memory.
            - SW verifies the integrity of the image upon reception by reading the spi_device
              memory.
            - Ensure the image is executed correctly

             Note: This flow will be replaced by using spi_device flash mode.
             For detail, refer to chip_spi_device_flash_mode
             '''
      milestone: V2
      tests: ["chip_sw_uart_tx_rx_bootstrap"]
    }
    {
      name: chip_sw_secure_boot
      desc: '''Verify the secure boot flow.

             Details TBD.
             '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_lc_walkthrough
      desc: '''Walk through the life cycle stages reseting the chip each time.

             Verify that the features that should indeed be disabled are indeed disabled.
             '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_device_ownership
      desc: '''Walk through device ownership stages and flows.

             Details TBD.
             '''
      milestone: V2
      tests: []
    }
    {
      name: chip_sw_sram_nmi_wipe
      desc: '''Verify SRAM behavior during an NMI escalation.

            - Trigger an NMI through the alert handler path to cause a system shutdown.
            - SW should trigger a memory "initialization", fully randomizing RAM contents
              and initiating another key request.
            - Verify that the RAMs are "wiped" once this operation completes.
            '''
      milestone: V2
      tests: []
    }
  ]
}