// Copyright lowRISC contributors (OpenTitan project). // Licensed under the Apache License, Version 2.0, see LICENSE for details. // SPDX-License-Identifier: Apache-2.0 { name: “mbx” import_testplans: [ hw/dv/tools/dvsim/testplans/alert_test_testplan.hjson hw/dv/tools/dvsim/testplans/csr_testplan.hjson hw/dv/tools/dvsim/testplans/intr_test_testplan.hjson hw/dv/tools/dvsim/testplans/stress_all_with_reset_testplan.hjson hw/dv/tools/dvsim/testplans/tl_device_access_types_testplan.hjson mbx_sec_cm_testplan.hjson ] testpoints: [ { name: mbx_smoke desc: ‘’’ Smoke test that sends a request from the SoC to the ROT and retrieves the response.
Repeat the following sequence of steps a number of times:
- Send a randomized request message to the RoT.
- Await the receipt of the message on the RoT side, and then check the contents of the
Inbound mailbox against the request that was sent.
- Present a randomized response message in the Outbound mailbox of the RoT.
- Wait for the availability of the response message to be signaled to the SoC.
- Collect and check the response message.
'''
stage: V1
tests: ["mbx_smoke"]
}
{ name: mbx_stress
desc: '''
Stress test that repeatedly sends requests and responses to/from the RoT side as per `mbx_smoke` testpoint.
Additionally, the following abnormal stimuli shall be randomly generated during the test.
- Error reported by the RoT side.
- Abort request from the SoC side.
- Panic (abort clearing) from the RoT side.
'''
stage: V2
tests: ["mbx_stress"]
}
{
name: mbx_max_activity
desc: '''
Stress test as per `mbx_stress` but with all access and response delays to be configured to zero cycles.
Additionally, combinational responses shall be enabled on the mailbox SRAM model.
This testpoint aims to check the correct operation of the DUT logic at maximum throughput, minimum latency.
This may be important in ensuring that there are no race hazards.
'''
stage: V2
tests: ["mbx_stress_zero_delays"]
}
{ name: mbx_stress_all
desc: '''
Run the other tests in random order while injecting TL errors and running automated CSR tests in parallel.
'''
stage: V2
tests: ["mbx_stress_all"]
}
{ name: mbx_imbx_oob
desc: '''
Test accesses that are out of bounds for the inbound mailbox.
'''
stage: V2
tests: ["mbx_imbx_oob"]
}
{ name: mbx_range_lock
desc: '''
Attempt to modify the Inbound and Outbound memory limits whilst the DUT should have locked the memory ranges to prevent changes.
Also attempt to unlock the memory range whilst the DUT is operating.
- Set up memory ranges for the Inbound and Outbound message boxes, and mark them as valid.
- Randomly choose whether to lock the memory ranges.
- Attempt to change one or more of the memory range registers and/or the lock itself.
- Check that the registers value(s) change iff the memory range is unlocked.
'''
stage: V2
tests: [""]
}
{ name: mbx_doe_intr_msg
desc: '''
Exercise the DOE_INTR_MSG_ADDR and DOE_INTR_MSG_DATA registers on the RoT- and SoC sides.
These two registers simply convey read only data from the SoC to the RoT.
- Supply a stream of randomized data to SOC_DOE_INTR_MSG_ADDR/DATA at a sufficiently
low rate that they may be reliably sampled on the RoT side.
- Read and check the randomized data on the RoT side.
'''
stage: V2
tests: ["mbx_doe_intr_msg"]
}
] }