VIP Smartsearch

X
  • VIP Smartsearch is a framework that supports search within VIP reference documents using query in natural language. It facilitates reordering of search results and keeps record of user’s decision for the ordering of result display and applies that in search of same query on subsequent usage.

  • How to download VIP smartsearch?

    1. Get VIP Smartsearch (Available as a seperate run file).
    2. Set environment variable 
      DESIGNWARE_HOME
      to required designware home location where VIP Smartsearch should be downloaded.
    3. Run 
      vip_smartsearch_<version>.run
      file.
      VIP Smartsearch will be downloaded to the location 
      $DESIGNWARE_HOME/vip/svt/vip_smartsearch/<version>

  • How to install VIP Smartsearch?

    Please refer to the file 
    VIP_Smartsearch_installation_and_usage_guide.pdf
    in 
    $DESIGNWARE_HOME/vip/svt/vip_smartsearch/<version>
    for installation steps.

  • Customer Support

    For more details about VIP smartsearch tool, contact support_center@synopsys.com.
    Mention your queries along with below details and send email to above email id.
    Product: Verification IP
    Sub Product: <vip_title>
    Tool: VIP Smartsearch
13 August 2024, Copyright © 2024 Synopsys, Inc.

AMBA SVT UVM Documentation - Sequence Class List

Here are the Sequence classes with brief descriptions:
svt_amba_system_random_sequence This sequence allows unconstrained random traffic for all ports
svt_amba_system_base_sequence This sequence creates a reporter reference
svt_apb_random_slave_write_transfer_with_random_pstrb_sequence Abstract: svt_apb_random_slave_write_transfer_with_random_pstrb_sequence defines a sequence in which a APB WRITE is followed by a APB READ to the same address and data integrity check is performed.
svt_apb_master_random_transfer_sequence Abstract: svt_apb_master_random_transfer_sequence defines a sequence in which random APB transactions are issued and based on config_db flags and other values performs the self checks and necessary operations. Sequence is generated using `svt_xvm_do_on_with macros.
svt_apb_system_base_sequence This sequence creates a reporter reference
svt_apb_slave_tlm_response_sequence This sequence is used as Reactive seuqnce which translates slave transactions into corresponding AMBA-PV extended TLM Generic Payload Transactions and forwards it via the resp_socket socket for fulfillment by an AMBA-PV Slave. The response returned by the socket is then sent back to the driver.
svt_apb_slave_memory_sequence This sequence generates memory responses to slave requests. This sequence gets the slave request from slave sequencer, randomizes the response, and then either updates the internal memory for write transations or updates the transaction with memory data for read transactions. If the requested address is outside of the configured bounds for the memory then the slave will return with a pslverr response.
svt_apb_slave_random_response_sequence Abstract: class svt_apb_slave_random_response_sequence defines a sequence class that provides random slave response. The sequence receives a response object of type svt_apb_slave_transaction, from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent.
svt_apb_slave_base_sequence This base sequence obtains the configuration from the sequencer during the pre_body callback. It does not raise or drop objections because slave sequences are reactive, and so are always running.
svt_apb_directed_tlm_generic_payload_sequence This sequence executes the UVM TLM Generic Payload Transaction in its ~m_gp~ property and returns once the response has been received.
svt_apb_tlm_gp_to_apb_sequence This layering sequence converts TLM GP transactions into APB transaction(s) and sends them out on the driver. The sequence gets TLM GP transactions from the tlm_gp_seq_item_port on the parent sequencer.
svt_apb_master_read_xact_sequence This sequence generates a single random read transaction.
svt_apb_master_write_xact_sequence This sequence generates a single random write transaction.
svt_apb_master_transaction_sequence_library APB VIP provides a pre-defined APB Master sequence library svt_apb_master_transaction_sequence_library, which can hold the APB Master sequences. The library by default has no registered sequences. You are expected to call svt_apb_master_transaction_sequence_library :: populate_library method to populate the sequence library with master sequences provided with the VIP. The system configuration is provided to the populate_library method as an argument. Based on the configuration, appropriate sequences are added to the sequence library. You can then load the sequence library in the sequencer within the master agent.
apb_master_unalinged_write_read_data_compare_sequence This sequence generates alternate write and read transactions, with address, data and pstrb not randomized for read. This sequence can also be used for 64Bit address and Data width
apb_master_write_read_data_compare_sequence This sequence generates alternate write and read transactions, with address, data and pstrb not randomized for read. This sequence can also be used for 64Bit address and Data width
svt_apb_master_blocking_write_read_addr_sequence This sequence generates alternate write and read transactions for minimum, middle and maximum address values to traverse the addr range.
svt_apb_master_blocking_write_read_all_slave_data_sequence This sequence generates alternate write and read transactions for all existing slaves. The min, mid and max data values are written and read for each slave .
svt_apb_master_random_sequence This sequence generates random master transactions.
svt_apb_master_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other master sequences in the collection extend from this base sequence.
svt_ahb_v6_unaligned_transfer_virtual_sequence Applicable for AHB_V6 enabled AHB systems
In AHBv6, capability to drive unaligned transfers is added.
This sequence is used to implement following.
#- Program a master VIP to drive unaligned bursts with unaligned address on to the bus
and routed to a slave.
#- Program the sequence to generate an unaligned address based on the burst size of the transfer
#- Check if the data values are correctly driven on the bus
#- Check if the data values are correctly sampled by slave and passive components
.
svt_ahb_lock_split_retry_resp_same_master_same_slave_virtual_sequence #- Program a master VIP to drive locked or unlocked burst on to the bus
and routed to a slave.
#- Program above selected slave VIP such that it should response with RETRY or
SPLIT for any transfer of the burst.
#- Check AHB bus arbiter behaves properly when RETRY or SPLIT response was
received for locked or unlocked burst from same slave.
#- For unlocked bursts, Check AHB bus arbiter will grant to higher-priority master
when received RETRY response or another master when received SPLIT response
from same slave and finishes with OKAY transfer response when re-attempt it.
#- For locked bursts, Check AHB bus arbiter should give grant access to dummy master
when received SPLIT response or higher-priority master when received RETRY response.
.
svt_ahb_split_retry_resp_diff_master_diff_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program another master VIP to drive write or read burst on the
bus and forwards the burst to another slave.
#- Program above two selected slaves VIP such that it should response with RETRY or
SPLIT for any transfer of the burst.
#- Check AHB bus arbiter behaves properly when RETRY or SPLIT response was
received from different slaves.
#- Check AHB bus arbiter will grant to higher-priority master when received RETRY
response or another master when received SPLIT response from different slaves
and finishes with OKAY transfer response when re-attempt it.
.
svt_ahb_split_resp_all_master_same_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program all other masters VIP to drive write or read burst on the
bus and forwards the burst to above selected slave.
#- Program above selected slave VIP such that it should response with SPLIT for any
transfer of each master burst and assert HSPILT signal after certain clock cycles.
#- Check the above masters are not continuing the transfers after receving SPLIT
response.
#- Make sure all masters have received SPLIT transfer response.
#- Check AHB bus arbiter will grant to the default master.
#- After certain clock cycles, Check AHB bus arbiter will grant the particular master
based on HSPLITx signals,so it can re-attempt the transfer and finishes with OKAY
transfer response.
.
svt_ahb_split_resp_all_master_diff_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program all other masters VIP to drive write or read burst on the
bus and forwards the burst to different slaves.
#- Program above selected slaves VIP such that it should response with SPLIT for any
transfer of the burst and assert HSPILT signal after certain clock cycles.
#- Check the above masters are not continuing the transfers after receving SPLIT
response.
#- Make sure all masters have received SPLIT transfer response.
#- Check AHB bus arbiter will grant to the default master.
#- After certain clock cycles, Check AHB bus arbiter will grant the particular master
based on HSPLITx signals,so it can re-attempt the transfer and finishes with OKAY
transfer response.
.
svt_ahb_retry_resp_reached_max_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Check AHB bus should behave correctly when maximum number of rebuild attempts
on RETRY response was reached for a given transaction and master aborts the
transaction under such condition.
.
svt_ahb_idle_transfer_virtual_sequence #- Program the Master VIP to drive idle burst on the bus.
#- AHB bus forwards this transfer to a slave.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_arb_reset_original_xact_in_progress_virtual_sequence #- Program the Master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Check AHB bus should response properly when reset was inserted in the original
transaction in progress.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_arb_narrow_transfer_virtual_sequence #- Program the Master VIP to drive write or read burst with narrow transfers on the
bus.
#- Check AHB bus arbiter forwards narrow transfers with appropriate byte lanes.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_system_ebt_virtual_sequence #- Program the Master VIP to drive write or read transaction.
#- Program the bus for EBT during any transfer of the transaction.
#- Program the Master VIP to regains the access of bus.
#- Once it gains the bus, Program the Master to rebuild the transcation
#- with burst type as INCR or SINGLE.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the Bus.
.
svt_ahb_system_burst_transfer_virtual_sequence #- Program the Master VIP to drive write or read transaction.
#- Program the Slave VIP to assert HREADY signal low for few cycles
during transfers and then accordingly assert HREADY to 1.
#- Check the bus Master holds the data stable throughout the extended
cycles of transfer for which HREADY was de-asserted.
#- Check the bus forwards the appropriate OKAY response with wait state to the master.
.
svt_ahb_arb_abort_on_error_resp_virtual_sequence #- Program a master VIP to drive write or read burst with 'n' number of transfers on to the bus.
#- Program a slave VIP to respond with ERROR response during any transfer.
#- Program the master VIP to abort remaining transfers when ERROR response is received
and shouldn't rebuild the transcation.
#- Check that AHB bus doesn't continues the remaining transfers in the burst.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the BUS.
.
svt_ahb_busy_transfer_virtual_sequence #- Program a master VIP to drive write or read burst with transfer type of BUSY to be
inserted in between the transfers.
#- Check AHB bus forwards OKAY response to BUSY transfers, when a master sends write
or read burst with BUSY transfer type.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_arb_undefined_length_hbusreq_virtual_sequence #- Program the master VIP to drive write or read burst of undefined length on to the bus
and routed to the slave.
#- Check AHB bus should behave correctly for undefined length bursts, the master
should continue to assert the request until it has started the last transfer.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_lock_fixed_length_virtual_sequence #- Program the master VIP to drive write or read locked transaction of fixed length
routed to the slave.
#- Check AHB bus should behave correctly for locked.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_locked_diff_master_same_slave_rd_wr_virtual_sequence #- Program the two master VIP to drive write or read burst with one always
driving locked transfers the other driving either locked or unlocked transfers
routed to same slave.
#- Check AHB bus should behave correctly for mixtures of locked and normal bursts
when transfer driven by two masters to the slave.
.
svt_ahb_arb_fixed_length_hbusreq_virtual_sequence #- Program a master VIP to drive write or read burst of fixed length on to the bus and
routed to a slave.
#- Check AHB bus should behave correctly for fixed length bursts when master
de-assert hbusreq once it is granted the bus and burst should complete succesfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.
svt_ahb_system_random_sequence This sequence allows unconstrained random traffic for all ports
svt_ahb_system_base_sequence This sequence creates a reporter reference
svt_ahb_slave_transaction_sequence_library AHB VIP provides a pre-defined sequence library svt_ahb_slave_transaction_sequence_library, which can hold the AHB sequences. The library by default has no registered sequences. You are expected to call svt_ahb_slave_transaction_sequence_library :: populate_library method to populate the sequence library with svt_ahb_slave sequences provided with the VIP. The system configuration is provided to the populate_library method as an argument. Based on the configuration, appropriate sequences are added to the sequence library. You can then load the sequence library in the sequencer within the svt_ahb_slave agent.
svt_ahb_slave_tlm_response_sequence This sequence is used as Reactive seuqnce which translates slave transactions into corresponding AMBA-PV extended TLM Generic Payload Transactions and forwards it via the resp_socket socket for fulfillment by an AMBA-PV Slave. The response returned by the socket is then sent back to the driver.
svt_ahb_slave_transaction_memory_sequence This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights such that the sum of all the weights is 100. Also the sequence provides additional level of control interms of maximum number of non-OKAY responses to be allowed on per full AHB transaction. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_ahb_slave_transaction_retry_sequence This sequence generates RETRY responses.
svt_ahb_slave_transaction_split_sequence This sequence generates SPLIT responses.
svt_ahb_slave_transaction_error_sequence This sequence generates ERROR responses.
svt_ahb_slave_transaction_okay_sequence This sequence generates OKAY responses.
svt_ahb_slave_transaction_distributed_random_sequence This sequence generates distributed random svt_ahb_slave transactions.
svt_ahb_slave_transaction_random_sequence This sequence generates random svt_ahb_slave transactions.
svt_ahb_slave_controlled_split_response_sequence Abstract: class svt_ahb_slave_controlled_split_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory.
svt_ahb_slave_controlled_response_sequence Abstract: class svt_ahb_slave_controlled_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory.
svt_ahb_slave_memory_response_sequence Abstract: Class svt_ahb_slave_memory_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with OKAY response and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory.
svt_ahb_slave_transaction_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other svt_ahb_slave sequences in the collection extend from this base sequence.
svt_ahb_tlm_generic_payload_sequence This sequence generates UVM TLM Generic Payload Transactions. A WRITE transaction is followed by a READ transaction to the same address. At the end of the READ transaction we check that the contents of the READ transaction are same as the WRITE transaction
svt_axi_ordering_write_same_id_device_non_bufferable_memory_diff_masters_response_ictest_sequence #- Program the Master M0 VIP to drive multiple write transactions with same ID.
#- Simultaneously program the Master M1 VIP to drive multiple write transactions
with same ID and it should be equal to ID used by M0.
#- Program the Slave VIP to respond out-of-order.
#- Program the Slave VIP to respond with OKAY for transactions addressed by M0 and
SLVERR for transactions addressed by M1. The transactions coming from M0 and M1
can be differentiated based on address.
#- Check the BRESP forwarded by interconnect to M0 are OKAY and for M1 are SLVERR.
This check will be performed within the virtual sequence running on AXI System
Sequencer.
.
svt_axi3_ordering_write_diff_id_no_interleave_at_slave_ictest_sequence #- Configure Master VIP to interleaving depth >1.
#- Program AXI3 Master VIP to drive a sequence of write transactions with write
data interleaving.
#- Configure the AXI3 Slave VIP to interleaving depth of 1
#- Check that the Interconnect is forwarding the transactions to the AXI3 Slave
VIP without write data interleaving
.
svt_axi3_ordering_write_diff_id_interleave_with_repeating_id_ictest_sequence #- Program all AXI3 Master VIPs to simultaneously drive a sequence of write
transactions with repeating AWID's (1,2,1,2,1). In case of master being
configured as AXI3 write data with interleaving (with write interleaving
depth >1).Transaction address will be randomly selected based on system
address map.
#- Configure the AXI3 Slave VIP interleaving depth >1.
#- Check that the Interconnect is forwarding the correct write data with
respect to address issued.
.
svt_axi3_ordering_write_diff_id_interleave_ictest_sequence #- Program all AXI3 Master VIPs to simultaneously drive a sequence of write
transactions with interleaved write data(with write interleaving depth >1 )
with random AWID's.
Transaction address will be randomly selected based on system address map.
#- Configure the AXI3 Slave VIP interleaving depth >1.
#- Check that the Interconnect is forwarding the correct write data with respect
to address issued
.
svt_axi_ordering_write_same_id_from_diff_masters_ictest_sequence #- Program a randomly selected Master M0 VIP to drive a write transaction to
the Slave VIP .
#- Program the Slave VIP to suspend the response of write transaction from
Master M0 VIP.
Use svt_axi_transaction :: suspend_response member to suspend the response.
Use it in slave response sequence.
#- Program another randomly selected Master M1 VIP to drive a write transaction
to the same Slave VIP.Wait for transaction from M1 to end.
#- Release the suspended response from Slave VIP for write transaction from Master
M0 VIP.
.
svt_axi_ordering_read_same_id_from_diff_masters_ictest_sequence #- Program a randomly selected Master M0 VIP to drive a read transaction
to the Slave VIP .
#- Program the Slave VIP to suspend the response of read transaction from Master
M0 VIP.Use svt_axi_transaction :: suspend_response member to suspend the response.
Use it in slave response sequence.
#- Program another randomly selected Master M1 VIP to drive a read transaction to
the same Slave VIP.Wait for transaction from M1 to end.
#- Release the suspended response from Slave VIP for read transaction from Master
M0 VIP.
.
svt_axi_ordering_write_read_same_id_ictest_sequence #- Program the Master VIP to drive write transaction.
#- After few clock cycles, program the Master VIP to drive read transaction to
Slave VIP with ARID same as AWID.
#- Program the Slave VIP to delay the response of previous write transaction.
#- Check interconnect forwards the response of read transaction and then response
of write transaction.This will get tested through system configuration
bus_inactivity_timeout.
.
svt_axi_ordering_read_write_same_id_ictest_sequence #- Program the Master VIP to drive read transaction.
#- After few clock cycles, program the Master VIP to drive write transaction
to Slave VIP with AWID same as ARID.
#- Program the Slave VIP to delay the response of previous read transaction.
#- Check interconnect forwards the response of write transaction and then response
of read transaction.
.
svt_axi_ordering_write_read_without_wait_ictest_sequence #- Program the Master VIP to drive write transaction to Slave VIP.
#- Program the Slave VIP to delay the response of previous write transaction
until further intimation.
#- Program the Master VIP to drive read transaction to the same Slave VIP before
getting response to above write transaction.
#- Check that the Interconnect is forwarding the read transaction before receiving
response from Slave VIP.This will get tested through system configuration
bus_inactivity_timeout.
#- Program the Slave VIP to respond to both read and write transactions.
.
svt_axi_ordering_same_id_xact_from_diff_masters_ictest_sequence #- Drive a sequence of Write transactions with same AWID to the same Slave VIP
from all masters simultaneously.
#- Wait for all Write transactions to complete.
#- Drive a sequence of Read transactions with same ARID to the same Slave VIP
from all masters simultaneously.
#- Program the Slave VIP to interleave read data.
#- Check that the Interconnect is forwarding the correct read data with respect to
address issued,to the appropriate Master.
.
svt_axi_ordering_write_read_same_id_sequence_diff_masters_ictest_sequence #- Drive a sequence of Write transactions with a set of different AWID's to the
same Slave VIP(e.g sequence of IDs 1,2,3,4,5 from each Master) from all
masters simultaneously.
Note that the set of AWIDs used must remain same for all Masters.
#- Wait for all Write transactions to complete.
#- Drive a sequence of Read transactions with a set of different ARID's to the
same Slave VIP(e.g sequence of IDs 1,2,3,4,5 from each Master) from all
masters simultaneously.
Note that the set of ARIDs used must remain same for all Masters.
#- Program the Slave VIP to interleave read data.
#- Check that the Interconnect is forwarding the correct read data with respect to
address issued,to the appropriate Master.
.
svt_axi4_ordering_read_overlap_addr_same_id_device_memory_ictest_sequence #- Program a randomly selected AXI4 Master VIP to drive two Read transactions to
same Slave VIP with same ID and overlapping address (not same address).
Select the address of first Read transaction randomly. Calculate the address
for second Read transaction such that it is overlapping with address of first
Read transaction. ARCACHE[1] should be set to 0, to indicate non-modifiable
transactions(to device memory).
#- Within the sequence, wait for xact_request_received_event event issued by Slave VIP Port monitor.
Check if the address of the transaction which triggered this event is same as
address of the first read transaction. This validates that the read addresses
arrived at the Slave VIP in the same order in which they were issuesd by the
Master VIP.
.
svt_axi4_ordering_read_overlap_addr_diff_id_device_memory_ictest_sequence #- Program a randomly selected AXI4 Master VIP to drive two Read transactions to
same Slave VIP with different ID and overlapping address (not same address).
Select the address of first Read transaction randomly. Calculate the address
for second Read transaction such that it is overlapping with address of first
Read transaction. ARCACHE[1] should be set to 0, to indicate non-modifiable
transactions(to device memory).
#- Within the sequence, wait for xact_request_received_event event issued by Slave VIP Port monitor.
Check if the address of the transaction which triggered this event is same as
address of the first read transaction. This validates that the read addresses
arrived at the Slave VIP in the same order in which they were issuesd by the
Master VIP.
.
svt_axi4_ordering_read_overlap_addr_diff_id_normal_memory_ictest_sequence #- Program a randomly selected AXI4 Master VIP to drive two Read transactions to
same Slave VIP with different ID and overlapping address (not same address).
Select the address of first Read transaction randomly. Calculate the address
for second Read transaction such that it is overlapping with address of first
Read transaction. ARCACHE[1] should be set to 1, to indicate modifiable transactions
#- Within the sequence, wait for xact_request_received_event event issued by Slave VIP Port monitor.
Check if the address of the transaction which triggered this event is same as
address of the first read transaction. This validates that the read addresses
arrived at the Slave VIP in the same order in which they were issued by the Master VIP.
.
svt_axi4_ordering_read_overlap_addr_same_id_normal_memory_ictest_sequence #- Program a randomly selected AXI4 Master VIP to drive two Read transactions to
same Slave VIP with same ID and overlapping address (not same address).
Select the address of first Read transaction randomly. Calculate the address
for second Read transaction such that it is overlapping with address of first
Read transaction. ARCACHE[1] should be set to 1, to indicate modifiable transactions
#- Within the sequence, wait for xact_request_received_event event issued by Slave VIP Port monitor.
Check if the address of the transaction which triggered this event is same as
address of the first read transaction. This validates that the read addresses
arrived at the Slave VIP in the same order in which they were issued by the Master VIP.
.
svt_axi4_ordering_write_overlap_addr_diff_id_normal_memory_ictest_sequence #- Program the AXI Master VIP to drive multiple (4) write transactions for
same Slave VIP with different ID, different (but overlapping) AWADDR to
Normal memory.
#- Make sure addresses in the transactions are overlapping. This will help to
validate that ordering is preserved for overlapping addresses for Normal Memory.
#- Check the write transactions are in same order at the Interconnect Master Port
and Interconnect Slave Port.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves_connected to the Interconnect DUT.
.
svt_axi4_ordering_write_overlap_addr_diff_id_device_memory_ictest_sequence #- Program the AXI Master VIP to drive multiple (4) write transactions for
same Slave VIP with different ID, different (but overlapping) AWADDR to
Device memory.
#- Make sure addresses in the transactions are overlapping.This will help to
validate that ordering is preserved for overlapping addresses for Device
Memory.
#- Check the write transactions are in same order at the Interconnect Master Port
and Interconnect Slave Port.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT
.
svt_axi_ordering_write_overlap_addr_same_id_device_memory_ictest_sequence #- Program the AXI Master VIP to drive multiple (4) write transactions for same
Slave VIP with same ID, different (but overlapping) AWADDR to Device memory.
#- Make sure addresses in the transactions are overlapping. This will help to
validate that ordering is preserved for overlapping addresses for Device Memory.
#- Check the write transactions are in same order at the Interconnect Master Port
and Interconnect Slave Port. Also check the IDs of all transactions at the
Interconnect Master port are same.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT.
.
svt_axi_ordering_write_read_same_id_device_memory_diff_slave_response_ictest_sequence #- Program the Master VIP to drive two write transactions to two randomly selected
slave, with non-repetitive data (incremental, random)
#- Program the Master VIP to drive two read transactions to same randomly selected
Slave VIPs, with same ARID. Use the same address for read transactions as used
by write transactions.
#- Check the RDATA are in same order at Interconnect Slave Port. This will be
checked by data_integrity check in AXI System Monitor.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT
.
svt_axi_ordering_write_read_same_id_device_memory_same_slave_response_ictest_sequence #- Program the Master VIP to drive two write transactions to the same slave,
with non-repetitive data (incremental, random)
#- Program the Master VIP to drive two read transactions for same Slave with
same ARID. Use the same address for read transactions as used by write
transactions.
#- Check the RDATA are in same order at Interconnect Slave Port. This will be
checked by data_integrity check in AXI System Monitor.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT
.
svt_axi4_ordering_write_overlap_addr_same_id_normal_memory_ictest_sequence #- Program a randomly selected AXI4 Master VIP to drive two write transactions to
same Slave VIP with same ID and overlapping address (not same address).
Select the address of first write transaction randomly. Calculate the address
for second write transaction such that it is overlapping with address of first
write transaction. AWCACHE[1] should be set to 1, to indicate modifiable
transactions.
#- Wait for both the write transactions to end.
#- Program the AXI4 Master VIP to drive a read transaction to the same address as
the second write transaction.
#- Compare the read data with data of second write transaction, which is the
expected data.
#- Disable the data_integrity check as this check can falsely fire in case of
outstanding transactions to same or overlapping address.
svt_axi_ordering_write_read_same_id_device_memory_ictest_sequence #- Program the AXI Master VIP to drive multiple write transactions for same Slave
VIP with same ID to Device memory. Make sure address of the write transactions
are non-overlapping.
#- Program the same Master VIP to drive multiple read transactions for same Slave
VIP with same ID and ARADDR same as previous AWADDR to device memory.
#- Wait for the transaction to reach the Slave.
#- Check the read data is same as write data and in same order at the Interconnect
Master Port and Interconnect Slave Port.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards the same
Slaves connected to the Interconnect DUT.
.
svt_axi_ordering_write_same_id_device_memory_ictest_sequence #- Program the AXI Master VIP to drive multiple (4) write transactions
for same Slave VIP with same ID, different AWADDR to Device memory.
#- Make sure addresses in the transactions are non-overlapping. This will
help to validate that ordering is preserved even for non-overlapping addresses
for Device Memory.
#- Check the write transactions are in same order at the Interconnect Master Port
and Interconnect Slave Port. Also check the IDs of all transactions at the
Interconnect Master port are same.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT.
.
svt_axi_ordering_write_same_id_device_non_bufferable_memory_diff_slave_response_ictest_sequence #- Program a Master VIP to drive two normal write transactions to two different
randomly selected Slave VIPs and with same AWID.Program AWCACHE[1:0] to 2'b00,
to indicate non-modifiable, non-bufferable. This ensures that both write
transactions reach the Slave VIP.
#- Program the Slave VIP to respond to first transaction with OKAY and second
transaction with SLVERR. Program the delays such that response to second write
transaction is sent first, that is, before response for first write transaction.
#- Check the BRESP are in same order at Interconnect Master Port. This will be
checked in the master sequence itself. Check that the response of the first
completed transaction is OKAY. Check that the response of second transaction
is SLVERR.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT.
.
svt_axi_ordering_write_same_id_device_non_bufferable_memory_same_slave_response_ictest_sequence #- Program a Master VIP to drive two normal write transactions to same Slave VIP
and with same AWID.Program AWCACHE[1:0] to 2'b00, to indicate non-modifiable,
non-bufferable. This ensures that both Write transactions reach the Slave VIP.
#- Program the Slave VIP to respond to first transaction with OKAY and second
transaction with SLVERR. Program random delays in the slave responses.
#- Check the BRESP are in same order at Interconnect Master Port. This will be
checked in the master sequence itself. Check that the response of the first
completed transaction is OKAY. Check that the response of second transaction
is SLVERR.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the Interconnect DUT.
svt_axi_ordering_write_read_bufferable_memory_ictest_sequence #- Program the Master VIP to drive write transaction with AWCACHE[0]=1'b1.
Rest bits can be random.
#- After receiving write response, program the AXI Master VIP to drive read
transaction with same address as previous write with ARCACHE[3:0] as random.
#- Wait for the transaction to complete successfully.
#- Compare read data with write data.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the Interconnect DUT.
.
svt_axi_ordering_write_device_non_bufferable_memory_ictest_sequence #- Program the Master VIP to drive write transaction with AWCACHE[1:0]=2'b00.
#- Check the transaction is not modified at the Interconnect Master Port.
#- Check Interconnect is not responding to the write transaction until Slave VIP
responds.
#- Wait for the transaction to complete successfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the Interconnect DUT.
.
svt_axi3_cov_corner_cases_exclusive_cache_type_sequence #- Program the Master VIP to drive multiple transaction of Exclusive transaction
Program the Master VIP to wait for previous Exclusive
This sequece is for cover corner scenarios of exclusive transactions
.
svt_axi_cov_corner_cases_addr_min_sequence #- Program the Master VIP to drive multiple transaction with min address range
selected atomic type of Normal read or write transaction
All other control fields are generated randomly.
svt_axi_cov_corner_cases_wstrb_sequence #- Program the Master VIP to drive multiple transaction with more probability
for wstrb corner scenarios.
svt_axi3_random_read_write_locked_sequence #- Program the Master VIP to drive random locked transaction
Send Exclusive transaction with same xact_type and addr as of locked transaction
to unlock the locked sequence and all other control fields generated randomly.
.
svt_axi_exclusive_normal_random_virtual_sequence #- Program the Master VIP to drive multiple transaction with randomly selected atomic type of Exclusive or Normal read transaction Program the Master VIP to wait for previous Exclusive or Normal transaction to end All other control fields are generated randomly.
svt_axi_slave_ordering_memory_suspend_response_sequence This sequence suspends the response of write transaction ,resumes it after after read transactions reaches the slave. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_ordering_programmed_response_sequence This sequence gets the slave response sequence item from slave sequencer. User can modify these responses. The sequence uses the built-in slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_locked_read_followed_by_excl_sequence #- Program the Master VIP to drive Locked read transaction followed by
Exclusive read transaction with same control fields as previous
lock read and all other control fields generated randomly.
.
svt_axi_exclusive_read_write_ictest_sequence #- Program the Master VIP to drive Exclusive read transaction followed by
Exclusive write transaction with same control fields as previous
Exclusive read and all other control fields generated randomly.
.
svt_axi_burst_unaligned_addr_narrow_transfers_random_ictest_sequence #- Program the Master VIP to drive random transactions with narrow transfers,
unaligned address and all other control fields generated randomly.
.
svt_axi_burst_aligned_addr_narrow_transfers_random_ictest_sequence #- Program the Master VIP to drive random transactions with narrow transfers,
aligned address and all other control fields generated randomly.
.
svt_axi_burst_unaligned_addr_full_data_width_random_ictest_sequence #- Program the Master VIP to drive random transactions with burst size
(AxSIZE) equal to data width of AXI bus, unaligned address and all other
control fields generated randomly.
.
svt_axi_burst_aligned_addr_full_data_width_random_ictest_sequence #- Program the Master VIP to drive random transactions with burst size
(AxSIZE) equal to data width of AXI bus, aligned address and all other control
fields generated randomly.
.
svt_axi_random_ictest_sequence #- Program the Master VIP to drive multiple random transaction.
.
svt_axi_random_all_master_to_all_slave_sequence #- Program the Master VIP to drive multiple random transaction to each Slave.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the IC DUT.
.
svt_axi_decode_error_response_ictest_sequence #- Program the Master VIP to drive Write/Read transaction. Configure the
Master transaction such that it should fire a transaction having address
which doesn't fall in any of the slaves. To determine an address which
would issue DECERR, address map in system configuration will need to be
referred.
#- Check Interconnect responds with DECERR.
#- Initiate the above stimulus from all Master VIPs.
.
svt_axi_burst_write_with_strobe_deasserted_ictest_sequence #- Program the Master VIP to drive write transcation with all strobes = 1.
This will initialize the memory to a known value.
#- Program the Master VIP to drive write transcation to the same location
of previous write transaction with all strobe bits = 0 for certain transfers.
#- Program the Master VIP to drive Read transaction.
#- Check the read data and compare it with write data (expected data).
#- Initiate the above stimulus from all Master VIPs towards all the Slaves
connected to the IC DUT.
.
svt_axi_burst_write_data_before_address_ictest_sequence #- Program the Master VIP to drive Write transaction with Write data in
Write Data Channel first, followed by Address on the Write Adderss
Channel.
#- Check Interconnect forwards the Write transaction to Slave VIP properly.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the IC DUT.
.
svt_axi_burst_write_read_with_zero_delay_ictest_sequence #- Program the testbench to drive ARESETn from LOW to HIGH
#- Program the Master VIP to drive Write/Read transaction in Write/Read
Address/Data channel on the immediate active edge of ACLK after ARESETn
becoming HIGH
#- Wait for the transaction to complete successfully.
.
svt_axi_signal_timing_write_read_default_ready_ictest_sequence #- Program the Master VIP to drive Write and read transactions.
#- Configure the Master and Slave VIP default values of READY signal from the test.
#- Check the Interconnect Master Port is driving VALID irrespective of READY
from Slave. This will get tested through system configuration
bus_inactivity_timeout.
#- Initiate the above stimulus from all Master VIPs towards all the Slaves
connected to the IC DUT.
.
svt_axi_ace_master_transaction_sequence_library AXI VIP provides a pre-defined AXI ACE Master sequence library svt_axi_ace_master_transaction_sequence_library, which can hold the AXI ACE Master sequences. The library by default has no registered sequences. You are expected to call svt_axi_ace_master_transaction_sequence_library :: populate_library method to populate the sequence library with master sequences provided with the VIP. The system configuration is provided to the populate_library method as an argument. Based on the system configuration, appropriate sequences are added to the sequence library. You can then load the sequence library in the system sequencer.
svt_axi_ace_master_readoncemakeinvalid_sequential_sequence #- Send a sequence of READONCEMAKEINVALID transactions to consecutive address locations #- The port from which the transactions are sent out are determined by port_id which can be passed via config_db. The port should be an ACE-Lite port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_readoncemakeinvalid_sequence This sequence initiates ReadOnceMakeInvalid transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadOnceMakeInvalid transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending ReadOnceMakeInvalid transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readoncecleaninvalid_sequence This sequence initiates ReadOnceCleanInvalid transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadOnceCleanInvalid transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending ReadOnceCleanInvalid transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readoncecleaninvalid_sequential_sequence #- Send a sequence of READONCECLEANINVALID transactions to consecutive address locations #- The port from which the transactions are sent out are determined by port_id which can be passed via config_db. The port should be an ACE-Lite port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_multipart_dvm_virtual_sequence Sends Multi-Part DVM Transaction from randomly selected ports. While sending multipart dvm transactions it also sends dvm transactions from same port along with coherent shareable and non-shareable transactions from same and other ports. Multipart and singlepart DVM transactions are sent simulataneously from one or more randomly selected ports in parallel. Scenarios Covered::
  • independent write channel transaction progress along with dvm transactions
  • independency of ID usage between write channel transactions and DVM transactions
  • independent read channel transaction progress along with dvm transactions
  • ID usage restrictions between read channel non-dvm transactions and DVM transactions
  • multi-part DVM transactions
  • multi-part DVM transactions with second part having DVM Sync and other opcodes
  • multi-part DVM Sync transactions with second part having DVM Sync and other opcodes
  • time overlapped multi-part dvm and non-multi-part dvm transactions
  • time overlapped coherent write, coherent read and multi-part dvm and non-multi-part dvm transactions
svt_axi_ace_master_dvm_virtual_sequence This sequence sends DVM operations followed by a DVM sync from one port or multiple ports of a given domain. Prior to sending DVM operations and DVM sync a few normal transactions as specified in num_pre_dvm_xacts is sent. The above sequence is repeated for sequence_length. The sequence also triggers another sequence that sends DVM Complete transactions from ports that receive DVM Syncs. The sequence terminates only when DVM completes for each of the DVM syncs sent out from a port are received from the interconnect This sequence is not added to the library (except for documentation) because it kills any snoop response sequences supplied by the testbench to run a dvm specific snoop response. Adding it to the library and running it may cause undesirable results and therefore this sequence must be run in a separate test
svt_axi_ace_master_load_barrier_sequence This sequence does the following: Send a number of transactions to load . The number of transactions sent is based on num_pre_barrier_loads. Send a barrier pair Send a post barrier transaction that is associated to the barrier pair. This transaction will be send out only after the response to the barrier pair is received When the post barrier transaction ends, check that all pre barrier transactions have also ended.
svt_axi_ace_master_nonshareable_store_barrier_load_sequence This sequence does the following: Sends a number of pre barrier write transactions based on num_pre_barrier_stores Sends a barrier pair Sends post barrier read transaction to the same address. Since the reads are post barrier transactions, all the previous writes should be observable to the reads All write transactions sends are WRITENOSNOOP transaction and read transactions are READNOSNOOP transactions
svt_axi_ace_master_shareable_store_barrier_load_sequence This sequence does the following: Sends a number of pre barrier store transactions based on num_pre_barrier_stores Sends a barrier pair Sends a post barrier flag transaction. Any master that can observe this flag should be able to observe the transactions before the barrier From another port in the same domain, the location written through the flag transaction is continously read (load). When the value set through the flag transaction is read back, the loop terminates. The flag transaction is a post-barrier transaction, so if its value is observable, It then reads back all the locations written through the pre barrier store transactions and checks that all the data that was written is read back correctly. Thus, this sequence is self-checking. Note that this step is not done if pre_barrier_xact_type is PRE_BARRIER_CACHE_MAINTENANCE since the data is not available in cache maintenance transactions. Instead, the sequence checks that when a post-barrier transaction completes all pre-barrier cache maintenance transactions should have completed. The ports on which the pre barrier stores and the loads are sent are randomly chosen based on configuration. The type of store transaction is based on the setting in pre_barrier_xact_type. Loads can be READSHARED,READONCE,READCLEAN or READNOTSHAREDDIRTY. Some interesting scenarios that can be exercised using this sequence are. Each of these scenarios is repeated for sequence_length: 1. num_pre_barrier_stores=1,num_observers=1 : A single pre-barrier store followed by a post barrier flag with one observer reading the post barrier flag and later reading the location addressed by pre_barrier store. 2. num_pre_barrier_stores=1,num_observers>1 : A single pre-barrier store followed by a post barrier flag with many observers reading the post barrier flag and later reading the location addressed by pre_barrier store. 3. num_pre_barrier_stores>1,num_observers=1 : Many pre-barrier stores followed by a post barrier flag with one observer reading the post barrier flag and later reading the locations addressed by pre_barrier store. 4. num_pre_barrier_stores>1,num_observers>1 : Many pre-barrier stores followed by a post barrier flag with many observers reading the post barrier flag and later reading the locations addressed by pre_barrier store.
svt_axi_ace_master_two_master_concurrent_write_sequence This sequence sends cocurrent write transactions from two ports after initializing cache lines
svt_axi_ace_master_read_during_coherent_write_sequence This sequence sends coherent read transactions while sending coherent write transactions to the same address from another port. In most cases, the interconnect will have to refetch data from the memory, if none of the snoops returned data. This is because the first read may return data that is not being written through the coherent write transaction depending on whether the data reached the slave. Hence a second read will have to be issued to ensure that the latest data is available. The sequence creates a scenario where the interconnect is forced to refetch data from memory
svt_axi_ace_master_overlapping_addr_sequence This sequence attempts to create a scenario where random coherent transactions targetting the same address are initiated from two different masters in which one is an ACE master specified with first_port_id and another one is an ACE/ACE_LITE master specified through second_port_id. If second_port_xact_type is svt_axi_transaction :: WRITENOSNOOP then the transactions will not be sent to same addresses as transactions from first_port_id, but the transactions will be fired concurrently from the masters.
svt_axi_ace_master_snoop_during_memory_update_sequence This sequence attempts to create a scenario where an initiating master (given by first_port_id) receives a snoop to the same cacheline while transmitting a WRITEBACK, WRITECLEAN, WRITEEVICT or EVICT (referred to as memory update transactions). The relative weights of WRITEBACK,WRITECLEAN,WRITEEVICT or EVICT can be set by passing writeback_wt,writeclean_wt,writeevict_wt and evict_wt respectively, through the UVM/OVM configuration infrastructure. By default, WRITEBACK and WRITECLEAN transactions have a weight of 1 while the other transactions have a weight of 0. The scenario first initializes cachelines to valid states before sending memory update transactions. Based on the kind of transaction sent, the following initial states are reached after cacheline initialization. WRITEBACK,WRITECLEAN: Unique Dirty. WRITEEVICT, EVICT: Unique Clean. . The coherent transactions that can be sent from second_port_id are
  • CMO : MAKEINVALID, CLEANINVALID or CLEANSHARED STORE : MAKEUNIQUE, CLEANUNIQUE, READUNIQUE, WRITEUNIQUE or WRITELINEUNIQUE LOAD : READONCE, READSHARED, READCLEAN or READNOTSHAREDDIRTY. In case of CLEANUNIQUE the initial state must be shared state.(if cleanunique_wt is 1) After completing initialisation for memory update, readshared will be sent from second_port_id to initialize the states to shared, for the cleanunique addresses.
If addr_mode_select is set from test, the sequence will fire memory update transactions from first_port_id and coherent transactions from second_port_id to the same set of sequential addresses at the same time. If addr_mode_select is low, the sequence will fire memory update transactions from first_port_id and coherent transactions from second_port_id to the same set of random addresses at the same time. . The combination of WRITEEVICT and CLEANUNIQUE cant be exercised because Initial state of WRITEEVICT must be Unique Clean,for CLEANUNIQUE any shared state so at the same time the states cant be in unique and shared.
svt_axi_ace_random_exclusive_access_virtual_sequence Creates system wide random exclusive access sequence on ACE ports. Scenarios which are covered are as follows:
svt_axi_ace_master_exclusive_access_virtual_sequence Basic Exclusive access sequeance This Sequence provides ACE Exclusive access at system level and can be used in any AXI_ACE master port to initiate Exclusive access transaction sequence using this.
Transaction Sequences Used: Exclusive Load followed by Exclusive store
  • Initialize cache lines if initialize_cachelines bit is set
  • Issue READCLEAN or READSHARED to load location and wait for the transaction to end
  • Check the cache line state
    • if in Shared state issue CLEANUNIQUE
    • if in Invalid state then restart Exclusive Access
    • else do nothing as Master can store directly to the cacheline no need to inform Interconnect
  • Stored data is updated to memory through WRITEBACK transaction

Please note, for generation of exclusive access transactions, svt_axi_port_configuration :: exclusive_access_enable should be set for the targeted master and svt_axi_port_configuration :: speculative_read_enable should be set to zero for that master as well

svt_axi_ace_master_evict_sequential_sequence #- Send a sequence of EVICT transactions to consecutive address locations #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. #- A sequence of MAKEUNIQUE and WRITECLEAN transactions are sent prior to sending the EVICT transactions so that the cachelines are in Unique Clean State. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_writeevict_sequential_sequence #- Send a sequence of WRITEEVICT transactions to consecutive address locations #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. The port must be an ACE port and must have svt_axi_port_configuration :: writeevict_enable set. #- A sequence of MAKEUNIQUE and WRITECLEAN transactions are sent prior to sending the WRITEEVICT transactions so that the cachelines are in Unique Clean State. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_makeunique_sequential_sequence #- Send a sequence of MAKEUNIQUE transactions to consecutive address locations #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. The port should be an ACE port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_cmo_shareable_txn_sequence #- Send a sequence of shareable allocating Readclean transactions followed by #- cache maintenance transactions to same address locations #- cache maintenance transactions can be MAKEINVALID, CLEANSHARED or CLEANINVALID #- transactions. #- The weights for these transactions can be passed through uvm_config_db. #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. The port can be ACE or ACE-Lite port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_cachemaintenance_sequential_sequence #- Send a sequence of cache maintenance transactions to consecutive address locations #- Cache maintenance transactions can be MAKEINVALID, CLEANSHARED or CLEANINVALID transactions. #- The weights for these transactions can be passed through uvm_config_db. #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. The port can be ACE or ACE-Lite port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_writeunique_writelineunique_sequential_sequence #- Send a sequence of WRITEUNIQUE/WRITELINEUNIQUE transactions to consecutive address locations #- The weights for these transactions can be passed through uvm_config_db. #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. The port can be ACE or ACE-Lite port. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_cleanunique_sequential_sequence #- Send a sequence of CLEANUNIQUE transactions to consecutive address locations #- The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_writeback_writeclean_sequential_sequence #- Send a sequence of WRITEBACK/WRITECLEAN transactions to consecutive address locations #- The weights for these transactions can be passed through uvm_config_db. The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. #- A sequence of MAKEUNIQUE transactions are sent prior to sending the WRITEBACK transactions so that the cachelines are in Unique Dirty State. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_read_type_shareable_region_sequential_sequence #- Send a sequence of shareable read transactions to consecutive address locations #- Shareable read transactions can be READONCE, READCLEAN, READNOTSHAREDDIRTY, READSHARED or READUNIQUE. The weights for these transactions can be passed through uvm_config_db. The port on which the transactions are sent sent are determined by port_id which can be passed via config_db. If the port is an ACE-Lite port, only READONCE transactions are sent. All transactions sent are cacheline size transactions. #- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_writenosnoop_readnosnoop_sequential_sequence #- Send a sequence of writenosnoop transactions to consecutive address locations #- Wait for all writenosnoop transactions to complete.
#- Send a sequence of readnosnoop transactions to the same set of addresses targetted by the writenosnoop transactions.
#- The start address of the sequence can be passed through a uvm_config_db for 'start_addr' If no start_addr is passed, the address of the first transaction randomized in the sequence is taken as the start address of the sequence.
svt_axi_ace_master_writeevict_sequence This sequence initiates WriteEvict transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteEvict transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending WriteEvict transactions, cachelines of masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_evict_sequence This sequence initiates Evict transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. Evict transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending Evict transactions, cachelines of masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writeclean_sequence This sequence initiates WriteClean transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteClean transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending WriteClean transactions, cachelines of masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writeback_sequence This sequence initiates WriteBack transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteBack transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending WriteBack transactions, cachelines of masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writedeferrable_sequence This sequence initiates Writdeferrable transaction from the ACE5-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. Writedeferrable transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: writedeferrable_transaction is set to svt_axi_port_configuration :: WDT_TRUE.
svt_axi_ace_master_writeuniquefullstash_sequence This sequence initiates writeuniquefullstash transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. writeuniquefullstash transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: ace_version is set to svt_axi_port_configuration :: ACE_VERSION_2_0 and svt_axi_port_configuration :: cache_stashing_enable is set to 1. Before sending writeuniquefullstash transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_stashtranslation_sequence This sequence initiates stashtranslation transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. stashtranslation transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: ace_version is set to svt_axi_port_configuration :: ACE_VERSION_2_0 and svt_axi_port_configuration :: cache_stashing_enable is set to 1. Before sending stashtranslation transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_stashonceshared_sequence This sequence initiates stashonceshared transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. stashonceshared transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: ace_version is set to svt_axi_port_configuration :: ACE_VERSION_2_0 and svt_axi_port_configuration :: cache_stashing_enable is set to 1. Before sending stashonceshared transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_stashonceunique_sequence This sequence initiates stashonceunique transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. stashonceunique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: ace_version is set to svt_axi_port_configuration :: ACE_VERSION_2_0 and svt_axi_port_configuration :: cache_stashing_enable is set to 1. Before sending stashonceunique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writeuniqueptlstash_sequence This sequence initiates WriteUniqueptlstash transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. writeuniqueptlstash transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE and svt_axi_port_configuration :: ace_version is set to svt_axi_port_configuration :: ACE_VERSION_2_0 and svt_axi_port_configuration :: cache_stashing_enable is set to 1. Before sending writeuniqueptlstash transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writelineunique_sequence This sequence initiates WriteLineUnique transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteLineUnique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending WriteLineUnique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writeunique_sequence This sequence initiates WriteUnique transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteUnique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending WriteUnique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writenosnoop_sequence This sequence initiates WriteNoSnoop transaction from the ACE/ACE_Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db.
svt_axi_ace_master_makeinvalid_sequence This sequence initiates MakeInvalid transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. MakeInvalid transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending MakeInvalid transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleaninvalid_sequence This sequence initiates CleanInvalid transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. CleanInvalid transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending CleanInvalid transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_concurent_non_dvm_xacts_with_dvm_xacts_sequence This sequence initiates concurrent random non-dvm transactions from first_port_id and dvm transactions from dvm_port_id. These ports can be a random port or a specifc port configured by user through uvm_config_db. Based on the interface type of first_port_id, a transction type as set in first_port_xact_type is sent from first_port_id. Before sending the transactions, cachelines of peer masters are initialized to random valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to first_port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleansharedpersist_sequence This sequence initiates CleanSharedPersist transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. CleanSharedPersist transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending CleanSharedPersist transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleanshared_sequence This sequence initiates CleanShared transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. CleanShared transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending CleanShared transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writefull_with_cmo_on_write_sequence This sequence initiates WRITEFULLCMO where cmo_on_write_xact_type transaction can be a random transaction configured by user through uvm_config_db, from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteplusCMO transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleanshared_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_writeptl_with_cmo_on_write_sequence This sequence initiates WRITEPTLCMO where cmo_on_write_xact_type transaction can be a random transaction configured by user through uvm_config_db, from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. WriteplusCMO transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleanshared_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleanshareddeeppersist_on_write_sequence This sequence initiates cleanshareddeeppersist_on_write transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. cleanshareddeeppersist_on_write transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleanshareddeeppersist_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleansharedpersist_on_write_sequence This sequence initiates cleansharedpersist_on_write transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. cleansharedpersist_on_write transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleansharedpersist_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleaninvalid_on_write_sequence This sequence initiates cleaninvalid_on_write transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. cleaninvalid_on_write transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleaninvalid_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleaninvalidpopa_on_write_sequence This sequence initiates cleaninvalidpopa_on_write transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. cleaninvalidpopa_on_write transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleaninvalidpopa_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleanshared_on_write_sequence This sequence initiates CleanShared_on_write transaction from the ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. cleanshared_on_write transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: ACE_LITE. Before sending cleanshared_on_write transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_cleanunique_sequence This sequence initiates CleanUnique transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. CleanUnique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending CleanUnique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readunique_sequence This sequence initiates ReadUnique transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadUnique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending ReadUnique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readnotshareddirty_sequence This sequence initiates ReadNotSharedDirty transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadNotSharedDirty transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending ReadNotSharedDirty transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readonce_sequence This sequence initiates ReadOnce transaction from the ACE/ACE-Lite master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadOnce transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE or svt_axi_port_configuration :: ACE_LITE. Before sending ReadOnce transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readnosnoop_sequence This sequence initiates ReadNoSnoop transaction from the ACE/ACE_LITE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db.
svt_axi_ace_master_readclean_sequence This sequence initiates ReadClean transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadClean transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending ReadClean transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_readshared_sequence This sequence initiates Readshared transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. ReadShared transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending Readshared transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_makeunique_sequence This sequence initiates MakeUnique transaction from the ACE master specified with port_id , which can be a random port or a specific port configured by the user through uvm_config_db. MakeUnique transactions can be sent only when the svt_axi_port_configuration :: axi_interface_type of the master corresponding to port_id is set to svt_axi_port_configuration :: AXI_ACE. Before sending Makeunique transactions, cachelines of peer masters are initialized to random, valid states. Initialisation is done through front door access, by sending specific transactions from the initiating master (corresponding to port_id) and peer masters. Please look up the documentation of svt_axi_cacheline_initialization for details.
svt_axi_ace_master_barrier_base_virtual_sequence This sequence is a base class for all barier based sequences. This sequence cannot be run as such, but contains methods which are used by other barrier sequences
svt_axi_ace_master_two_port_overlapping_addr_cmo_and_store_sequential_sequence Sends a set of concurrent, sequential cmo accesses from first_port_id and store accesses from second_port_id to the same set of overlapping addresses. CMO type transactions can be MAKEINVALID, CLEANINVALID or CLEANSHARED.The store type transactions can be MAKEUNIQUE, READUNIQUE, CLEANUNIQUE, WRITEUNIQUE or WRITELINEUNIQUE based on the interface types of the ports and the weights. an initialisation procedure is invoked based on the following sequence, unless Prior to sending the cmo and store transaction bypass_cache_initialisation is set:
  • In order that the store transactions can be fired from various initial states.
  • If second_port_cleanunique_wt is not zero, cachelines are initialised, since CLEANUNIQUE can be sent only from a cacheline in shared state. Only cachelines from which CLEANUNIQUE needs to be sent are initialized. The number of CLEANUNIQUE transactions sent are determined by the formula sequence_length*first_port_cleanunique_wt/(sum of weights of all xact types in second port). Initialisation is done by sending MAKEUNIQUE transactions from one ACE port and READSHARED transactions from another ACE port to the same set of addresses. Snoop transactions for READSHARED type snoop are programmed (in the corresponding tests) to always assert svt_axi_snoop_transaction :: snoop_resp_datatransfer and svt_axi_snoop_transaction :: snoop_resp_isshared so that a shared state of the cacheline can be acheived in both masters. All shared cachelines in first_port_id are invalidated so that the cmo transactions can be sent on the interface.
After this initialisation, sequential cmo access from first_port_id and sequential store from second_port_id are sent. . Sometimes if the cmo transactions snoops the second_port firstly and second port transaction is CLEANUNIQUE transaction means, there is a chance of invalidation of the cache line of second_port. By the result of this scenario the second_port may drop the CLEANUNIQUE transactions, Because CLEANUNIQUE cant be sent from INVALID state.
svt_axi_ace_master_two_port_overlapping_addr_store_and_load_sequential_sequence Sends a set of concurrent, sequential store accesses from first_port_id and load accesses from second_port_id to the same set of overlapping addresses. The store type transactions can be MAKEUNIQUE, READUNIQUE, CLEANUNIQUE, WRITEUNIQUE or WRITELINEUNIQUE based on the interface types of the ports and the weights. Load type transactions can be READONCE, READCLEAN, READSHARED or READNOTSHAREDDIRTY. Prior to sending the store and load transaction an initialisation procedure is invoked based on the following sequence, unless bypass_cache_initialisation is set:
  • In order that the load transactions return some valid data, WRITELINEUNIQUE transactions are sent to update memory.
  • If first_port_cleanunique_wt is not zero, cachelines are initialised, since CLEANUNIQUE can be sent only from a cacheline in shared state. Only cachelines from which CLEANUNIQUE needs to be sent are initialized. The number of CLEANUNIQUE transactions sent are determined by the formula sequence_length*first_port_cleanunique_wt/(sum of weights of all xact types in first port). Initialisation is done by sending MAKEUNIQUE transactions from one ACE port and READSHARED transactions from another ACE port to the same set of addresses. Snoop transactions for READSHARED type snoop are programmed (in the corresponding tests) to always assert svt_axi_snoop_transaction :: snoop_resp_datatransfer and svt_axi_snoop_transaction :: snoop_resp_isshared so that a shared state of the cacheline can be acheived in both masters. All shared cachelines in second_port_id are invalidated so that the load transactions can be sent on the interface.
After this initialisation, sequential stores from first_port_id and sequential loads from second_port_id are sent.
svt_axi_ace_master_two_port_overlapping_addr_load_cmo_sequential_sequence Sends a set of concurrent, sequential load or cmo accesses from first_port_id and load or cmo accesses from second_port_id based on the interface types of the ports and the weights selected from corresponding tests to the same set of overlapping addresses. Load type transactions can be READONCE, READCLEAN, READSHARED or READNOTSHAREDDIRTY. cmo type transactions can be MAKEINVALID, CLEANINVALID and CLEANSHARED. Prior to sending the load transaction an initialisation procedure is invoked based on the following sequence, unless bypass_cache_initialisation is set:
  • In order that the load transactions return some valid data, incase of ACE port MAKEUNIQUE followed by WRITEBACK are sent to update memory. incase of ACE_LITE port WRITELINEUNIQUE transactions are sent to update memory.
After this initialisation, sequential load or sequential cmo from first_port_id and sequential load or sequential cmo from second_port_id are sent concurrently to the same set of addresses.
svt_axi_ace_master_two_port_overlapping_addr_store_sequential_sequence Sends a set of concurrent, sequential store accesses from two ports to the same set of overlapping addresses. The store type transactions can be MAKEUNIQUE, READUNIQUE, CLEANUNIQUE, WRITEUNIQUE or WRITELINEUNIQUE based on the interface types of the ports and the weights. If first_port_cleanunique_wt or second_port_cleanunique_wt is not zero, cachelines are initialised since CLEANUNIQUE can be sent only from a cacheline in shared state. Only cachelines from which CLEANUNIQUE needs to be sent are initialized. The number of CLEANUNIQUE transactions sent are determined by the formula sequence_length*cleanunique_wt/(sum of weights of all xact types). Initialisation is done by sending MAKEUNIQUE transactions from one ACE port and READSHARED transactions from another ACE port to the same set of addresses. Snoop transactions for READSHARED type snoop are programmed (in the corresponding tests) to always assert svt_axi_snoop_transaction :: snoop_resp_datatransfer and svt_axi_snoop_transaction :: snoop_resp_isshared so that a shared state of the cacheline can be acheived in both masters. Once cachelines are initialised, sequential stores from first_port_id and second_port_id are made.
svt_axi_ace_master_two_port_base_sequential_virtual_sequence Base class from which all virtual sequences for sequential accesses to overlapping addresses are extended
svt_axi_ace_master_two_port_base_virtual_sequence Base class from which all ACE intermediate level sequences will be extended.
svt_axi_ace_master_single_port_base_virtual_sequence Base class from which all ACE basic level sequences will be extended.
svt_axi_ace_exclusive_access_sequence This sequence is used to create Exclusive Access Transactions at Master port level

Transaction Sequences Used: Exclusive Load followed by Exclusive store
  • Initialize cache lines if initialize_cachelines bit is set
  • Issue READCLEAN or READSHARED to load location and wait for the transaction to end
  • Check the cache line state
    • if in Shared state issue CLEANUNIQUE
    • if in Invalid state then restart Exclusive Access
    • else do nothing as Master can store directly to the cacheline no need to inform Interconnect
  • Stored data is updated to memory through WRITEBACK transaction

Please note, for generation of exclusive access transactions, svt_axi_port_configuration :: exclusive_access_enable should be set for the targeted master.

svt_axi_ace_barrier_readnosnoop_sequence Sends a single READNOSNOOP transaction that reads from the same location as write_xact. Associates the READ to a barrier based on associate_barrier
svt_axi_ace_barrier_pair_sequence Sends a barrier pair
svt_axi_ace_barrier_flag_read_xact_sequence Sends a single READONCE transaction that writes into a location within the given domain type and address. The transaction addresses a single byte and is meant as one which reads a flag set by another transaction. Typically this is used to read a flag set through a post barrier transaction sent from another port.
svt_axi_ace_barrier_flag_write_xact_sequence Sends a single WRITEUNIQUE transaction that writes into a location within the given domain type. The transaction addresses a single byte and is meant as a flag which can later be read by other transactions. Typically this is used as a post barrier transaction to signal availability/observability of a number of pre barrier transactions
svt_axi_ace_master_dvm_complete_sequence This sequence sends DVM Complete transactions from ACE or ACE-Lite+DVM Master ports. It takes care of the ACE protocol requirement that DVM Sync handshake on the snoop address channel be observed before issuing DVM Complete transaction.
svt_axi_ace_master_dvm_base_sequence This sequence generates dvm transactions with all possible dvm message types from ACE or ACE-Lite+DVM master ports. This sequence is used as a base sequence for higher level sequences, with proper constraints for sequence members dvm_message_type and seq_xact_type
svt_axi_ace_master_generic_sequence Generic sequence that can be used to generate transactions of all types on a master sequencer. All controls are provided in the base class svt_axi_ace_master_base_sequence. Please refer documentation of svt_axi_ace_master_base_sequence for controls provided. This class only adds constraints to make sure that it can be directly used in a testcase outside of a virtual sequence.
svt_axi_cacheline_invalidation This sequence invalidates the cache line of a master. It checks the state of the cache line and initiaties the appropriate transaction If the cacheline state is dirty, a WRITEBACK is initiated. If the cacheline state is clean, an EVICT is initiated.
svt_axi_cacheline_initialization This sequence initializes the cache line of all masters. This is done by: Initiating MakeUnique from 'initiating masters sequencer' Initiating Writeclean for some cachelines of masters. Initiating ReadShared from rest of ports that are ACE. If use_parent_sequence_params is set, this sequence initializes all the addresses of transactions in the parent sequence. If not set, it initializes the address given in init_addr
svt_axi_basic_writeclean_full_cacheline This sequence generates a writeclean transaction for a full cacheline.
svt_axi_basic_writeback_full_cacheline This sequence generates a writeback transaction for a full cacheline.
svt_axi_ace_master_base_virtual_sequence This is a virtual sequence and is the base class for other virtual sequences in the sequence library. The sequence spawns off a thread that waits on an event before it starts a sequence to initialize cachelines of peer masters.
svt_axi_ace_master_base_sequence Base class from which all the ACE non-virtual sequences are extended. This class is the base class for sequences that run on multiple master sequencers. In addition to being extended to create new sequences, this sequence is also called within some virtual sequences like svt_axi_cacheline_initialization and svt_axi_cacheline_invalidation. This sequence cannot be used as is, but must be called from within a virtual sequence that is extended from svt_axi_ace_master_base_virtual_sequence.
svt_axi_master_atomic_swap_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic swap type transactions
svt_axi_master_atomic_compare_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic compare type transactions
svt_axi_master_atomic_load_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic load type transactions
svt_axi_master_atomic_store_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic store type transactions
svt_axi_system_random_sequence This sequence allows unconstrained random traffic for all ports
svt_axi_system_base_sequence This sequence creates a reporter reference
svt_axi_slave_service_qos_read_accept_update_sequence svt_axi_slave_service_qos_read_accept_update_sequence This sequence creates a qos read accept level update request.
svt_axi_slave_service_qos_write_accept_update_sequence svt_axi_slave_service_qos_write_accept_update_sequence This sequence creates a qos write accept level update request.
svt_axi_slave_service_random_sequence svt_axi_slave_service_random_sequence
svt_axi_slave_service_base_sequence svt_axi_slave_service_base_sequence: This is the base class for svt_axi_service based sequences. All other svt_axi_service sequences are extended from this sequence.
svt_axi_slave_reorder_chunk_response_sequence This sequence generates reordered chunk responses. This sequence gets transactions from master and sends the out of order chunk responses with valid rchunkstrb and rchunknum values. This sequence runs forever, and so is not registered with the slave sequence library.
svt_axi_slave_rchunkv_0_sequence Abstract: Class svt_axi_slave_reorder_chunk_response_sequence defines a sequence class that the testbench uses to provide slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_axi_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver which reorder based on the priority within the slave agent,when the active_wr_xact_queue and active_rd_xact_queue is full. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory.
svt_axi_slave_random_snoop_sequence This sequence generates random snoop requests. This sequence gets the snoop object from the interconnect, randomizes it and provides the randomized transaction to the slave port of the interconnect. This sequence runs forever, and so is not registered with the slave sequence library .
svt_axi_slave_tlm_response_sequence This sequence is used as Reactive seuqnce which translates slave transactions into corresponding AMBA-PV extended TLM Generic Payload Transactions and forwards it via the resp_socket socket for fulfillment by an AMBA-PV Slave. The response returned by the socket is then sent back to the driver.
axi_slave_wr_rd_memory_response_sequence Abstract: Class axi_slave_wr_rd_memory_response_sequence defines a sequence class that the testbench uses to provide slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_axi_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into the slave memory when the response randomized to OKAY when the xact_type is {WRITE, COHERENT} or reads from the memory.
svt_axi_slave_diff_write_resp_for_diff_masters_sequence This sequence responds out-of-order and issues OKAY response for multiple write transactions from master M0 and SLVERR response for multiple write transactions from master M1. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_get_xact_request_sequence This sequence trigger event(xact_request_received_event) when transaction request is received to communicate the other block. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_suspend_write_response_on_address_sequence This sequence suspends the response of write transaction and resumes it, after sending the response of immediate read transaction. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_suspend_read_response_on_address_sequence This sequence suspends the response of write transaction and resumes it, after sending the response of immediate read transaction. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_suspend_read_response_sequence This sequence suspends the response of write transaction and resumes it, after sending the response of immediate read transaction. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_suspend_write_response_sequence This sequence suspends the response of write transaction and resumes it, after sending the response of immediate read transaction. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_memory_suspend_response_sequence This sequence suspends the response of write transaction ,resumes it after after read transactions reaches the slave. This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_read_data_fixed_interleave_block_sequence This sequence generates read interleaved data with interleave size of each block equal to one by default. User can modify the interleave block size by setting interleave_block_size.
svt_axi_slave_programmed_response_sequence This sequence gets the slave response sequence item from slave sequencer. User can modify these responses. The sequence uses the built-in slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_okay_slverr_resp_sequence This sequence asserts slave response. This sequence gets the slave response sequence item from slave sequencer. The slave responds as OKAY response for first write transaction and SLVERR response for second write transaction. The sequence uses the built-in slave memory. For write transactions, it writes the data into slave memory. The programmed response is then provided to the slave driver.
svt_axi_slave_exclusive_sequence This sequence is used for the exclusive transactions. It gets the slave response sequence item from slave sequencer. F?or exclusive access transactions, response is not randomized as the response is pre-computed by the slave, based on exclusive access monitors. If the pre-computed response is modified, the response may not comply with exclusive access rules. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. For normal transactions, randomized response provided to the slave driver. This sequence runs forever, and so is not registered with the slave sequence library.
svt_axi_slave_traffic_profile_sequence This sequence is used by the VIP to map traffic profile properties to AXI transaction properties. Traffic profile attributes are modelled as properties of this sequence. These are mapped to transaction level properties in the body of the sequence. Users could potentially use this sequence even if traffic profiles are not used if the attributes of this sequence map to the requirements of modelling the response parameters of slaves in their system
svt_axi_slave_memory_sequence This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.
svt_axi_slave_response_sequence This sequence generates random responses to response requests. This sequence gets the slave response sequence item from slave sequencer, randomizes the response, and provides the randomized response to the slave driver.
svt_axi_slave_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other slave sequences in the collection extend from this base sequence.
svt_axi_tlm_generic_payload_pv_sequence This sequence generates UVM TLM Generic Payload Transactions. A WRITE transaction is followed by a READ transaction to the same address. At the end constraints and write and read data is compared are checked at the PV slave side
svt_axi_tlm_generic_payload_sequence This sequence generates UVM TLM Generic Payload Transactions. A WRITE transaction is followed by a READ transaction to the same address. At the end of the READ transaction we check that the contents of the READ transaction are same as the WRITE transaction
svt_axi_service_random_coherency_exit_sequence svt_axi_service_random_coherency_exit_sequence:
  • This sequence generates Coherency Exit service requests.
  • Number of Coherency Exit service requests to be generated will be inferred from the attribute sequence_length which can be set to zero or greater than zero.
  • sequence_length set to zero causes the sequence to run throughout the simulation.
  • This sequence does not raise and drop objections, so will not block simulation exit directly.
  • Delay attributes to control the number of clock cycles before sequence initiates subsequent coherency exit service request from the sequence, which can be set through config DB:
    • Minimum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_min_delay.
    • Maximum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_max_delay.
  • The above mentioned attributes (sequence_length, coherency_exit_svc_req_min_delay, coherency_exit_svc_req_min_delay) can be set through config DB.
  • Functionality: (following steps will be in a loop of sequence_length or forever loop if sequence_length is set to 0)
    • Wait for coherency state to be COHERENCY_ENABLED_STATE
      • Note that entry to coherency enabled state is expected to happen due to master transaction sequencer sending a cacheable transaction to driver, which causes the driver to initiate Coherency entry.
    • Apply random delay between the programmed min and max delays
    • Initiate Coherency Exit service request
  • This sequence will run on the svt_axi_service_sequencer.
  • Default Values: (Note: Required values can be programmed through config DB)
    • sequence_length set to value between 1 and 10 upon randomization
    • coherency_exit_svc_req_min_delay set to 1000
    • coherency_exit_svc_req_max_delay set to 2000
svt_axi_service_coherency_entry_sequence svt_axi_service_coherency_entry_sequence
svt_axi_service_coherency_exit_sequence svt_axi_service_coherency_exit_sequence This sequence creates a coherency_exit svt_axi_service request.
svt_axi_exclusive_id_addr_test_sequence This sequence follows id_addr's transactions parallelly and other configurations set from the test.
svt_axi_exclusive_sameid_outoforder_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 1 and address nonoverlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to second Exclusive read with ID 1 4) Exclusive write transaction matching to first Exclusive read with ID 1
svt_axi_exclusive_sameid_outoforder_overlapping_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 1 and address overlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to second Exclusive read with ID 1 4) Exclusive write transaction matching to first Exclusive read with ID 1
svt_axi_exclusive_outoforder_overlapping_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 2 and address overlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to Exclusive read with ID 2 4) Exclusive write transaction matching to Exclusive read with ID 1
svt_axi_exclusive_sameid_inorder_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 1 and address nonoverlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to first Exclusive read with ID 1 4) Exclusive write transaction matching to second Exclusive read with ID 2
svt_axi_exclusive_sameid_inorder_overlapping_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 1 and address overlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to first Exclusive read with ID 1 4) Exclusive write transaction matching to second Exclusive read with ID 1
svt_axi_exclusive_inorder_overlapping_test_sequence This sequence performs the following 1) Exclusive read transaction with ID 1 2) Exclusive read transaction with ID 2 and address overlapping to the address of previous Exclusive read 3) Exclusive write transaction matching to Exclusive read with ID 1 4) Exclusive write transaction matching to Exclusive read with ID 2
svt_axi_exclusive_read_without_write_test_sequence This sequence performs the following 1) Exclusive read transaction for which Exclusive write is not generated 2) Exclusive read transaction with different ID and address compared to previous Exclusive read 3) Exclusive write transaction with same ID, ADDR and other control fields as second Exclusive read
svt_axi_exclusive_sameid_overlapping_normalwr_test_sequence This sequence performs the following 1) Exclusive read transaction 2) Normal write transaction with same ID and overlapping ADDR 3) Exclusive write transaction with same ID, ADDR and other control fields as previous Exclusive read
svt_axi_exclusive_sameid_normalwr_test_sequence This sequence performs the following 1) Exclusive read transaction 2) Normal write transaction with same ID and nonoverlapping ADDR 3) Exclusive write transaction with same ID, ADDR and other control fields as previous Exclusive read
svt_axi_exclusive_max_req_test_sequence This sequence performs number of Exclusive read and write transactions more than max_num_exclusive_access i.e. maximum number of active exclusive access monitors supported by the slave.
svt_axi_exclusive_watchdog_timer_test_sequence This sequence performs the following 1) Exclusive read transaction 2) Normal read and write transactions 3) Exclusive write transaction
svt_axi_exclusive_read_write_mismatch_test_sequence This sequence performs Exclusive read transaction followed by Exclusive write transaction with different control fields as previous Exclusive read. Exclusive write commences only after response for Exclusive read is received by the master.
svt_axi_master_sanity_test_sequence This sequence performs reads and writes in parallel
axi_awakeup_same_wvalid_sequence Abstract: class axi_awakeup_same_wvalid_sequence defines a sequence that generates a WRITE transactions with awakeup signal and wvalid signal at same clock cycle. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_awakeup_same_axvalid_sequence Abstract: class axi_awakeup_same_axvalid_sequence defines a sequence that generates a READ/WRITE transactions with awakeup and awvalid signals at same clock cycle. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_awakeup_after_axvalid_sequence Abstract: class axi_awakeup_after_axvalid_sequence defines a sequence that generates a READ/WRITE transactions with awakeup signal after awvalid signal. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_awakeup_after_wvalid_sequence Abstract: class axi_awakeup_after_wvalid_sequence defines a sequence that generates a WRITE type of transactions with awakeup signal after wvalid signal . This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_awakeup_before_wvalid_sequence Abstract: class axi_awakeup_before_wvalid_sequence defines a sequence that generates a WRITE transactions with awakeup signals before wvalid signals. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_awakeup_before_axvalid_sequence Abstract: class axi_awakeup_before_axvalid_sequence defines a sequence that generates a transactions with awakeup signals before axvalid signals. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
svt_axi5_unique_id_different_id_all_unique_id_sequence This sequence will generate the write transactions followed by read transactions, where write/read unique ids are generated. All other transaction fields are randomized.The number of write and read transactions are defined by no_of_xacts, which is based on ID width and other configurations set from the tests are use_separate_rd_wr_chan_id_width=random and num_outstanding_xact=random .
svt_axi5_unique_id_same_id_all_unique_id_sequence This sequence will generate the parallel write_read transactions, where write/read unique same ids are generated. All other transaction fields are randomized.The other configurations set from the tests are use_separate_rd_wr_chan_id_width=random and num_outstanding_xact=random .
svt_axi5_unique_id_separate_id_separate_num_outstanding_wr_rd_sequence This sequence uses a sub-sequence "svt_axi5_unique_id_sequence" This sequence will generate random read and write type of transaction where id is generated from separate id channels and ids generated are random. unique_id is also set randomly for the transactions, other configurations set from the tests are use_separate_rd_wr_chan_id_width=1 and num_outstanding_xact =-1 .
svt_axi5_unique_id_same_id_directed_sequence This sequence generates first two write -read transactions pair with unique_id '1' and remaining other transaction with unique_id '0'. All the write and read transactions have id value as '0'. This write and read transaction pair is repeated for sequence_length .
svt_axi5_unique_id_sequence This sequence will generate random read and write type of transaction where id is generated from separate id channels and ids generated are random. unique_id is also set randomly for the transactions other configurations set from the tests are use_separate_rd_wr_chan_id_width=1 and num_outstanding_xact =-1 .
svt_axi5_unique_id_wr_rd_outstanding_sequence Sequence for the test This sequence will generate the write transaction followed by read transaction. Write transaction will have different IDs and Read transaction will use the same IDs used by writes. The number of Write and Read transaction is defined by no_of_xacts. which is equal to the outstanding queue size. ID width will be limited to size of the outstanding queue. Hence there will be a pattern if num_max_outstanding_xact=2 WR(ID0,ID1),RD(ID0,ID1),WR(ID0,ID1),RD(ID0,ID1) etc.. Unique_id is set to 1 for alternate writes transactions and similarly for reads transactions .
svt_axi_unique_id_random_sequence This sequence will generate random id based on enum of id_pattern as DIFF - Different id's SET_OF_SEQ_ID - Set of sequential id's SET_OF_REPT_ID - Set of repeated id's SET_OF_SAME_ID - Set of same id's RD_WR_CHAN_MIN_ID - Read or Write channel minimum id width range id's .
svt_axi_unique_id_wr_rd_sequence Abstract: class svt_axi_unique_id_wr_rd_sequence defines a sequence that generates a transactions with unique id signals. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
svt_axi_master_chunking_same_id_sequence Abstract: class svt_axi_master_chunking_same_id_sequence defines a sequence that generates a wr/rd transactions with same id for read data chunking. This sequence used to generate error scenario to validate read data chunking checker for arid cannot be same for outstanding transaction. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
svt_axi_master_chunk_reorder_sequence This sequence performs write transaction followed by read transaction of read data chunking for directed scenario. Using this sequence, generating wr/rd transaction with specific burst_length, burst_size and data so that we can generate out of order transaction using slave response sequence for read data chunking.
axi_master_rdata_chunk_err_sequence Abstract: class axi_master_rdata_chunk_err_sequence defines a sequence that generates a error transactions with read data chunking. This sequence used to generate error scenarios to validate checkers of red data chunking feature. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_master_rdata_chunk_wr_rd_sequence Abstract: class axi_master_rdata_chunk_wr_rd_sequence defines a sequence that generates a transactions with read data chunking signals. This sequence is used by the axi_master_random_discrete_virtual_sequence which is set up as the default sequence for this environment.
axi_master_atomic_swap_xact_base_sequence This sequence generates atomic swap transactions.
axi_master_atomic_compare_xact_base_sequence This sequence generates atomic compare transactions.
axi_master_atomic_load_xact_base_sequence This sequence generates atomic load transactions.
axi_master_atomic_store_xact_base_sequence This sequence generates atomic store transactions.
svt_axi3_master_random_read_write_locked_sequence This sequence performs locked accesses Each loop does the following: Send a random locked access transaction. Send the exclusive transaction with same xact_type and address as of locked transaction to unlock the locked sequence Each transcation waits for the previous transaction to be ended Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi_master_transaction_sequence_library AXI VIP provides a pre-defined AXI Master sequence library svt_axi_master_transaction_sequence_library, which can hold the AXI Master sequences. The library by default has no registered sequences. You are expected to call svt_axi_master_transaction_sequence_library :: populate_library method to populate the sequence library with master sequences provided with the VIP. The port configuration is provided to the populate_library method as an argument. Based on the port configuration, appropriate sequences are added to the sequence library. You can then load the sequence library in the sequencer within the master agent.
svt_axi_master_snoop_base_sequence AXI ACE base master snoop response reactive sequence
svt_axi_master_locked_read_followed_by_excl_sequence This sequence performs locked followed by exclusive accesses Each loop does the following: Send a locked access read transaction followed by a excluisve read transaction Send the exclusive read transactions with same id as of locked read transaction Each transcation waits for the previous transaction to be ended Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi_master_normal_exclusive_random_sequence This sequence performs the following send back to back four transactions The atomic type is randomized to exclusive or normal for each transaction Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi_master_locked_test_sequence This sequence performs locked accesses Each loop does the following: Send a normal transaction Send a locked access transaction that starts the locked sequeunce Send more locked access transactions Send a normal transactions that ends the locked sequence An intermediate loop sends only NORMAL transactions (represented by k == 5)
svt_axi_master_exclusive_normal_wrap_test_sequence This sequence performs the following 1) Exclusive read transaction with WRAP burst type 2) Normal write transaction with different ID and address overlapping to the address of previous exclusive read 3) Exclusive write transaction matching to the previous Exclusive read
svt_axi_master_exclusive_read_write_exhausing_the_fifo_depth_sequence This sequence performs the following 1) Series of Exclusive read transactions beyound the exclusive_monitor_fifo_depth 2) Series of Exclusive write transactions
svt_axi_master_exclusive_read_after_read_test_sequence This sequence performs the following 1) Series of Exclusive read transactions 2) Series of Exclusive write transactions
svt_axi_master_exclusive_memory_test_sequence This sequence performs the following 1) Exclusive read transaction 2) Normal write transaction with same ID, ADDR and other control fields as previous Exclusive read 3) Exclusive write transaction with same ID, ADDR and other control fields as previous Exclusive read
svt_axi_master_exclusive_random_test_sequence This sequence performs the following 1) Normal read and write transactions 2) Exclusive read and write transactions 3) Normal read and write transactions 4) Exclusive read and write transactions
svt_axi_master_exclusive_test_sequence This sequence performs Exclusive read transaction followed by Exclusive write transaction with same control fields as previous Exclusive read. Exclusive write commences only after response for Exclusive read is received by the master.
svt_axi_master_aligned_addr_sequence This sequence generates the transactions whose address is always aligned with respect to burst size.
svt_axi_master_write_data_before_addr_sequence This sequence generates write data before address. This is valid when svt_axi_port_configuration :: axi_interface_category = AXI_READ_WRITE or AXI_WRITE_ONLY.
svt_axi_master_write_data_fixed_interleave_block_sequence This sequence generates write interleaved data with interleave size of each block equal to one by default. User can modify the interleave block size by setting interleave_block_size. This is valid when svt_axi_port_configuration :: axi_interface_type = AXI3.
svt_axi_master_blocking_alternate_write_read_sequence This sequence generates alternate write and read transaction. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. This sequence is valid only when svt_axi_port_configuration :: axi_interface_category = AXI_READ_WRITE.
svt_axi_master_outstanding_snoop_xacts_sequence This sequence generates a sequence of coherent READONCE transactions. All other transaction fields are randomized. The sequence does not wait for transactions to complete before sending next transaction. This is required in order to generate outstanding snoop transactions. This sequence is targetted to hit the following covergroups. svt_axi_port_monitor_def_cov_callback :: trans_ace_num_outstanding_snoop_xacts This sequence requires svt_axi_port_configuration :: axi_interface_category is set to svt_axi_port_configuration :: AXI_READ_WRITE or svt_axi_port_configuration :: AXI_READ_ONLY and svt_axi_port_configuration :: axi_interface_type is set to AXI_ACE or ACE_LITE.
svt_axi_master_outstanding_dvm_tlb_invalidate_xacts_sequence This sequence generates a sequence of DVM TLB Invalidate transactions. All other transaction fields are randomized. The sequence does not wait for transactions to complete before sending next transaction. This is required in order to generate outstanding DVM TLBI transactions. This sequence is targetted to hit the following covergroups. svt_axi_port_monitor_def_cov_callback :: trans_ace_num_outstanding_dvm_tlb_invalidate_xacts_with_same_arid svt_axi_port_monitor_def_cov_callback :: trans_ace_num_outstanding_dvm_tlb_invalidate_xacts_with_diff_arid This sequence requires svt_axi_port_configuration :: axi_interface_category = svt_axi_port_configuration :: AXI_READ_WRITE and svt_axi_port_configuration :: axi_interface_type is either ACE or ACE-Lite.
svt_axi_master_outstanding_xact_id_sequence This sequence generates a sequence of coherent writenosnoop transactions, followed by coherent readnosnoop transactions. All other transaction fields are randomized. The sequence does not wait for transactions to complete before sending next transaction. This is required in order to generate outstanding transactions. This sequence is targetted to hit the following covergroups. svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_same_arid svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_diff_arid svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_same_awid svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_diff_awid svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_multiple_same_arid svt_axi_port_monitor_def_cov_callback :: trans_axi_num_outstanding_xacts_with_multiple_same_awid This sequence requires svt_axi_port_configuration :: axi_interface_category = svt_axi_port_configuration :: AXI_READ_WRITE and svt_axi_port_configuration :: axi_interface_type is either ACE or ACE-Lite.
axi_master_wr_rd_single_outstanding_per_id_sequence This sequence generates parallel write_read transactions, mainly with non_overlapping address and same ids. All other transaction fields are randomized. The sequence wait for write/read transactions to complete before sending next write/read transaction. This is required in order to generate outstanding transactions .
svt_axi_master_blocking_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. This sequence is valid only when svt_axi_port_configuration :: axi_interface_category = AXI_READ_WRITE.
axi_master_wr_rd_parallel_sequence This sequence generates parallel write_read transactions, mainly with non_overlapping address. All other transaction fields are randomized. The sequence initially sends 10 write transactions , waits for them to complete, then sends 10 read transactions waits for them to complete, then sends thousands of write and read transactions in parallel without waiting for them to complete. This is required in order to create different scenarios of outstanding transactions.
svt_axi_read_same_slave_sequence This sequence generates a Read transactions with overlapping addr/non overlapping addr/random addr to the same slave. Remaining fields are randomized. It generates the write followed by read transaction and waiting for write transaction to complete,then execute the read transaction with same write transaction accessing address. Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi_write_same_slave_sequence This sequence generates a Write transactions with overlapping addr/non overlapping addr/random addr to the same slave. Remaining fields are randomized. Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi_random_sequence This sequence generates a random sequences of write transaction or of read transaction. All other transaction fields are randomized. Note that user needs to constraint slv_num as targeted slave id, or set target_slv through uvm_config_db.
svt_axi4_lite_master_random_sequence This sequence generates random master transactions for axi4_lite.
svt_axi_master_random_sequence This sequence generates random master transactions.
svt_axi_ace_master_read_xact_sequence This sequence generates a single random ACE read transaction.
svt_axi_ace_master_write_xact_sequence This sequence generates a single random ACE write transaction.
svt_axi_master_read_xact_sequence This sequence generates a single random read transaction.
svt_axi_master_write_xact_sequence This sequence generates a single random write transaction.
svt_axi_master_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other master sequences in the collection extend from this base sequence.
svt_axi_ace_master_snoop_response_sequence Reactive response sequence that services snoop requests using the cache located in the parent svt_axi_master_snoop_sequencer. Automatically configured as the run_phase default sequence for every instance of the svt_axi_master_snoop_sequencer.
svt_chi_system_protocol_flow_ctrl_hn_makereadunique_copyback_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for copyback and makereadunique transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- Send READSHARED transaction to the same address from differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send WRITEEVICTFULL Copyback transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_hn_makereadunique_read_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for read and write transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send Read type of transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_hn_makereadunique_write_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for read and write transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send Write type of transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two different HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected two different HN's.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected different HN's in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the RN receives the responses for all the outstanding transactions from
different HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the different HN responds properly for all outstanding Read type
transactions and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of MakeReadUnique type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected HN in non blocking mode.
#- The addresses of these MakeReadUnique transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the HN responds properly for all outstanding MakeReadUnique type
transactions and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of MakeReadUnique type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these MakeReadUnique transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding MakeReadUnique type transactions
and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.
svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, attribute svt_chi_rn_transaction :: suspend_wr_data or svt_chi_rn_transaction :: suspend_comp_ack whichever is applicable is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData or Compack for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding Writesoptionaldata COPYBACK type transactions and these are completed successfully. . #- This sequence generates Writesoptionaldata COPYBACK type WRITEEVICTOREVICT transactions. .
svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, attribute svt_chi_rn_transaction :: suspend_wr_data or svt_chi_rn_transaction :: suspend_comp_ack whichever is applicable is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData or Compack for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding Writesoptionaldata COPYBACK type transactions and these are completed successfully. . #- This sequence gemerates Writesoptionaldata COPYBACK type WRITEEVICTOREVICT transactions. .
svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_invalidating_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_invalidating_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for WRITEEVICTOREVICT and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send WRITEBACKFULL transaction to the same address from same RN 3. Send READCLEAN transaction to the same address from different RN so that initial Cache state will move to either UC/SC 4. Below 2 transactions are initiated parallelly from different RN-F nodes. #- Send CLEANINVALID/MAKEINVALID type of transaction to the same address from different RN #- Send WRITEEVICTOREVICT type of transaction to the same address from the same RN from which READCLEAN transaction is initiated. . 5. Check the order in which the two requests are processed by HN. .
svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_noninvalidating_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_noninvalidating_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for WRITEEVICTOREVICT and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send WRITEBACKFULL transaction to the same address from same RN 3. Send READCLEAN transaction to the same address from different RN so that initial Cache state will move to either UC/SC 4. Below 2 transactions are initiated parallelly from different RN-F nodes. #- Send READCLEAN transaction to the same address from different RN #- Send WRITEEVICTOREVICT type of transaction to the same address from the same RN from which READCLEAN transaction is initiated. . 5. Check the order in which the two requests are processed by HN. .
svt_chi_system_single_node_writeevictorevict_virtual_sequence This sequence initiates WriteEvictorEvict transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteEvictorEvict transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
svt_chi_system_single_node_readpreferunique_virtual_sequence This sequence initiates ReadPreferUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadPreferUnique transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
svt_chi_system_single_node_makereadunique_virtual_sequence This sequence initiates MakeReadUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeReadUnique transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
svt_chi_system_protocol_flow_ctrl_prefetchtgt_read_outstanding_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate a Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- Initiate a PREFETCHTGT type transaction to the same address of read transaction address.
  • Txn_id of a PREFETCHTGT transaction is set to below values based on sel_txnid_type_enum, which can be controlled through config DB or random value by default
    • when sel_txnid_type_enum == TXNID_SAME_AS_PREFETCHTGT i.e txn_id is same as read transaction txn_id
    • when sel_txnid_type_enum == TXNID_NOT_SAME_AS_PREFETCHTGT i.e txn_id is not same as read transaction txn_id
#- Wait for the PREFETCHTGT transaction to end, Once it ends svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for the outstanding read transaction.
This ensures that the CompAck for the above Read transaction can be resumed
from RN.
svt_chi_system_protocol_flow_ctrl_prefetchtgt_write_outstanding_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate a Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- Initiate a PREFETCHTGT type transaction to the same address of write transaction address.
  • Txn_id of a PREFETCHTGT transaction is set to below values based on sel_txnid_type_enum, which can be controlled through config DB or random value by default
    • when sel_txnid_type_enum == TXNID_SAME_AS_PREFETCHTGT i.e txn_id is same as Write transaction txn_id
    • when sel_txnid_type_enum == TXNID_NOT_SAME_AS_PREFETCHTGT i.e txn_id is not same as Write transaction txn_id
#- Wait for the PREFETCHTGT transaction to end, Once it ends svt_chi_rn_transaction :: suspend_wr_data is set to 0 for the outstanding write transaction.
This ensures that the NonCopyBackWrData for the above write transaction can be resumed from RN.
svt_chi_system_protocol_flow_ctrl_writeunique_suspend_compack_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- Initiate WRITEUNIQUEFULL/WRITEUNIQUEPTL type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN.
#- Wait for the Initiating RN to transmit the DATA flits without waiting for Compack
#- Resume the suspended Compack after the DATA flits are transmitted.
  • This ensures that the expcompack s sent after all the DATA flits are transmitted on to interface.
.
svt_chi_system_protocol_flow_ctrl_atomic_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect. #- This sequence requires two initiating active and participating RNs. #- If another active and participating RN-F exists, perform cache initialization to two randomly selected HNs. #- Initiate Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 each from both the initiating RNs, 128 each to randomly selected two HNs from each of the RN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting both the HNs
#- Once the RNs receive the responses for all the outstanding transactions from both of the HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from the RNs. #- Check that both of the HNs respond properly for all outstanding atomic type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_atomic_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding atomic type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_atomic_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding atomic type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_hn_atomic_cmo_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_cmo_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send cmo type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_atomic_atomic_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_atomic_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transactions to the above same address from two different RN's. 3. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_atomic_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_atomic_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and copyback transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN 2. Send atomic type of transaction to the same address from different RN. 3. Send Copyback type of transaction to the same address from same RN from which the MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_atomic_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and read transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send read type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_single_node_rn_atomic_transaction_ordering_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic transaction from randomly selected RN_F
with order_type set to REQ_ORDERING_REQUIRED.
.
svt_chi_system_single_node_atomiccompare_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Compare transaction from randomly selected RN_F.
.
svt_chi_system_single_node_atomicswap_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Swap transaction from randomly selected RN_F.
.
svt_chi_system_single_node_atomicload_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Load transaction from randomly selected RN_F.
.
svt_chi_system_single_node_atomicstore_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Store transaction from randomly selected RN_F.
.
svt_chi_system_single_node_rn_atomic_transaction_base_virtual_sequence This sequence setups the basic attributes and methods which are used by the derived sequences to initiate atomic tranasctions.
svt_chi_system_req_order_noncoherent_xact_directed_virtual_sequence svt_chi_system_req_order_noncoherent_xact_directed_virtual_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This sequence generates an Ordered CHI WRITENOSNP followed by an Ordered CHI READNOSNP If the number of request order streams > 1, READs are sent with stream ID 0, while the WRITEs are sent with stream ID 1. Users can configure the number of streams by programming the parameter svt_chi_node_configuration :: num_req_order_streams for the RN.
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_read_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_read_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent copyback write CMO transaction to the address from an RN 3. Send READ type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_read_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_read_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent noncopyback write CMO transaction to the address from an RN 3. Send READ type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_standalone_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_standalone_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent noncopyback write CMO transaction to the address from an RN 3. Send standalone CMO type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_standalone_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_standalone_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent copyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent copyback write CMO transaction to the address from an RN 3. Send standalone CMO type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_copyback_write_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_copyback_write_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo and copyback write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent noncopyback combined write CMO type of transaction to the same address from RN $ 3. Send copyback write transaction to same address from different RN. 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_noncopyback_write_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_noncopyback_write_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent copyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent copyback combined write CMO type of transaction to the same address from RN 3. Send noncopyback write transaction to same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions between noncopyback combined write cmo transaction and standalone noncopyback writes or combined write cmo transaction 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent noncopyback combined write CMO type of transaction to the same address RN 3. Send standalone noncopyback transaction or noncopyback combined write cmo transaction to same address to from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_e_protocol_flow_ctrl_combined_write_cmo_hazard_base_sequence Abstract: svt_chi_e_protocol_flow_ctrl_combined_write_cmo_hazard_base_sequence acts as a base sequence for various combined_write_cmo hazard sequences.
svt_chi_system_protocol_flow_ctrl_hn_cmo_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send CMO type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_read_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_cmo_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO and read transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN to the random address. 2. Send cmo type of transaction to the same address from different RN 3. Send read type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_cmo_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO and write transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN to the random address. 2. Send cmo type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_cmo_cmo_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_cmo_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO transactions 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send different types of cmo transactions to the same address from RN0 and RN1. 3. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_read_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read and write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_write_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_write_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for write and copyback transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN 2. Send write type of transaction to the same address from different RN. 3. Send Copyback type of transaction to the same address from same RN from which the MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_write_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_write_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read transactions 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send different types of write transactions to the same address from different RN's. 3. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_copyback_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_copyback_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. .
svt_chi_system_protocol_flow_ctrl_hn_makeunique_makeunique_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_makeunique_makeunique_hazard_directed_virtual_sequence provides a sequence to test the ability of components to handle hazard conditions: 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send a MAKEUNIQUE transaction from both RN0 and RN1 to the same address. The interconnect should sequence these transactions correctly 3. Check the order in which the two requests are processed by HN. 4. If sequenced correctly, both RNs should not be in UD state; only one RN should be in UD state. This is checked in the sequence. .
svt_chi_system_protocol_flow_ctrl_hn_read_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transactions to the above same address from two different RN's. 3. Check the order in which the two requests are processed by HN. .
chi_rn_barrier_directed_virtual_sequence chi_rn_barrier_directed_virtual_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This class defines a sequence in which pre barrier transactions, followed by barrier transactions, followed by post barrier transactiosn are generated.
svt_chi_system_protocol_flow_ctrl_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected different HN's.
#- Initiate maximum number of CMO type transactions with svt_chi_rn_transaction::
suspend_comp_ack set to 1 from selected initiating RN to randomly selected
different HN's in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the selected RN receives the responses for all the outstanding transactions
from selected HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the
outstanding transactions.
This ensures that the CompAck for these transactions can be resumed
from selected RN.
#- Check that the selected HN responds properly for all outstanding CMO type
transactions and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate max_num_outstanding_cmo_xacts_at_hn/2 or max_num_outstanding_xacts_at_hn/2 number of CMO type transactions with svt_chi_rn_transaction::
suspend_comp_ack set to 1 from selected initiating RN to randomly selected HN
in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the selected RN receives the responses for all the outstanding transactions
from HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the
outstanding transactions.
This ensures that the CompAck for these transactions can be resumed
from selected RN.
#- Check that the HN responds properly for all outstanding CMO type transactions
and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of CMO type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding CMO type transactions
and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_copyback_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN nodes to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HNs responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
svt_chi_system_protocol_flow_ctrl_copyback_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
svt_chi_system_protocol_flow_ctrl_copyback_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-F of these COPYBACK transactions are such that:
  • Same as RN-F from which cache initialization is performed
#- Once the RN-F receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-F. #- Check that the HN responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
svt_chi_e_system_protocol_flow_ctrl_combined_copyback_write_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Initiate maximum number of MAKEUNIQUE transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of combined copyback write cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
#- The addresses of these combined copyback write cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-F of these combined copyback write cmo transactions are such that:
  • Same as RN-F from which cache initialization is performed
#- Once the RN-F receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-F. #- Check that the HN responds properly for all outstanding combined copyback write cmo type transactions and these are completed successfully. .
svt_chi_e_system_protocol_flow_ctrl_combined_write_copyback_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of combined write copyback cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these combined write copyback cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these combined write copyback cmo transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding combined write copyback cmo type transactions and these are completed successfully. .
svt_chi_e_system_protocol_flow_ctrl_combined_copyback_write_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN nodes to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of combined write copyback cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these combined write copyback cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these combined write copyback cmo transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HNs responds properly for all outstanding combined write copyback cmo type transactions and these are completed successfully. .
svt_chi_e_system_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HNs. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HNs in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_chi_e_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_chi_e_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_write_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect. #- This sequence requires two initiating active and participating RNs. #- If another active and participating RN-F exists, perform cache initialization to two randomly selected HNs. #- Initiate Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 each from both the initiating RNs, 128 each to randomly selected two HNs from each of the RN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting both the HNs
#- Once the RNs receive the responses for all the outstanding transactions from both of the HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from the RNs. #- Check that both of the HNs respond properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_write_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_write_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .
svt_chi_system_protocol_flow_ctrl_read_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two different HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected two different HN's.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected different HN's in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the RN receives the responses for all the outstanding transactions from
different HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the different HN responds properly for all outstanding Read type
transactions and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_read_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected HN in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the HN responds properly for all outstanding Read type
transactions and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_read_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding Read type transactions
and these are completed successfully.
.
svt_chi_system_protocol_flow_ctrl_cmo_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program two MakeUnique transactions from one randomly selected RN_F targeted to
same HN Node.
#- Program two randomly selected different RN VIP to drive any CMO type transaction
with same Txnid simultaneously to above selected same HN Node of MakeUnique
transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- For CleanShared, CleanInvalid transactions, Program Read transactions from
above first selected RN_F to compare Read data with data of above MakeUnique
transactions
.
svt_chi_system_protocol_flow_ctrl_cmo_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program two MakeUnique transactions from one randomly selected RN_F targeted to
different HN Nodes.
#- Program two randomly selected different RN VIP to drive any CMO type transaction
with same Txnid simultaneously to above selected same HN Nodes of
MakeUnique transactions.
#- Check the HN's respond with same Txnid to respective RN's.
#- For CleanShared, CleanInvalid transactions, Program Read transactions from
above first selected RN_F to compare Read data with data of above MakeUnique
transactions
.
svt_chi_system_protocol_flow_ctrl_copyback_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program the any two randomly selected RNs to drive a MakeUnique transaction targeted
to randomly selected same HN.
#- Program the above selected RNs to drive a CopyBack transactions simultaneously with
same TxnId and address same as of MakeUnique transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- Program a randomly selected RN to drive a ReadShared transaction to verify CopyBack
transaction.
. #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
svt_chi_system_protocol_flow_ctrl_copyback_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program the any two randomly selected RNs to drive a MakeUnique transaction targeted
to randomly selected different HN.
#- Program the above selected RNs to drive a CopyBack transactions simultaneously with
same TxnId and address same as of MakeUnique transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- Program a randomly selected RN to drive a ReadShared transaction to verify CopyBack
transaction.
. #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
svt_chi_system_protocol_flow_ctrl_write_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program two MAKEUNIQUE transaction from one randomly selected RN targeted to same HN.
#- Program two randomly selected different RN VIP to drive a write transaction with same
Txnid simultaneously to randomly selected same HN Nodes of
MAKEUNIQUE transactions.
#- Check the HN responds with same Txnid to respective RN's.
.
svt_chi_system_protocol_flow_ctrl_write_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program two MAKEUNIQUE transaction from one randomly selected RN targeted to different HN.
#- Program two randomly selected different RN VIP to drive a write transaction with same
Txnid simultaneously to randomly selected different HN Nodes of
MAKEUNIQUE transactions.
#- Check the HN responds with same Txnid to respective RN's.
.
svt_chi_system_protocol_flow_ctrl_read_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Optionally program a randomly selected RN to send two MAKEUNIQUE transaction targeted to
randomly selected same target IDs when number of RN_F is 3 or more incase of RN_F test
or number of RN_F is atleast 1 incase of RN_I test.
#- Program other two randomly selected RNs to send a read type coherent transaction
with same TxnID simultaneously to above selected same target IDs of MAKEUNIQUE transactions if MAKEQNIQUE transaction is sent for initilization.
#- If MAKEQNIQUE transaction is not sent for initilization program two randomly
selected different RNs to send a read type coherent transaction with same TxnID simultaneously
to randomly selected same target IDs.
#- Check that the HN's responds with same TxnId to respective RNs.
.
svt_chi_system_protocol_flow_ctrl_exclusive_access_virtual_sequence Abstract:
This sequence generates traffic to test the exclusive access feature support.
#- Program a randomly selected RN1 to send an exclusive load type transaction
with an LPID followed by an exclusive store transaction with the same LPID and address
set to same value as that of exclusive load transaction.
#- Optionally program to send MAKEUNIQUE transaction targeted to
randomly selected RN with address of randomly selected first HN Node. #- Optionally program a randomly selected RN2 to intervene the exclusive sequence from RN1.
#- Supports both coherent and non coherent transactions.
.
svt_chi_system_protocol_flow_ctrl_read_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Optionally program a randomly selected RN to send two MAKEUNIQUE transaction targeted to
randomly selected different target IDs when number of RN-F is 3 or more incase of RN-F test
or number of RN-F is atleast 1 incase of RN-I test.
#- Program other two randomly selected RNs to send a read type coherent transaction
with same TxnID simultaneously to above selected different target IDs of MAKEUNIQUE transactions if MAKEQNIQUE transaction is sent for initilization.
#- If MAKEQNIQUE transaction is not sent for initilization program two randomly
selected different RNs to send a read type coherent transaction with same TxnID simultaneously
to randomly selected different target IDs.
#- Check that the HN's responds with same TxnId to respective RNs.
.
svt_chi_system_coherent_virtual_sequence This sequence sends coherent transactions from multiple RN and provides mechanism to control following parameters.
  • transactions are sent from each RN only which are applicable to those RNs
  • specific transactions can be controlled seperately for each RN by setting corresponding weights
  • transaction can either be sent with random address or sequential address
  • transactions from different RNs can be set to send with overlapped addresses or completely seperate non-overlapped addresses. These are achieved by setting "addr_mode" along with "rn_start_addr[]" and "rn_end_addr[]" address array.
  • it allows user to send transactions in blocking or sequential manner
  • user can specify number of RN from which transactions will be sent as well as
  • specific RN indexes from which transactions will be sent
  • sequence takes care of cacheline initiallization in order to send transactions from correct initial state without getting dropped by RN driver layer
  • sequence provides necessary constraints to randomize above parameters
  • it also allows user to override sequence members
svt_chi_system_barrier_sequence svt_chi_system_barrier_sequence The sequence sends number of pre-barrier store transaction, controlled by num_pre_barrier_stores knobe from RN Node followed by ECBARRIER or EOBARRIER transaction. After sending Barrier transaction initiating node send a post barrier store to user controlled address (post_barrier_store_address) with a specific value (post_barrier_store_data).
svt_chi_system_single_node_dvm_virtual_sequence This sequence initiates DVM operations followed by a DVM sync from the RN node specified with node_index, which can be a random node or a specific node configured by the user.The above sequence is repeated for sequence_length. The sequence terminates only when each of the DVM syncs sent out from a port are received from the interconnect.
svt_chi_system_single_node_makeinvalid_virtual_sequence This sequence initiates MakeInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeInvalid transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_cleansharedpersistsep_virtual_sequence This sequence initiates CleanSharedPersistSep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanSharedPersistSep transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_cleaninvalid_virtual_sequence This sequence initiates CleanInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanInvalid transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_cleansharedpersist_virtual_sequence This sequence initiates CleanSharedPersist transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanSharedPersist transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_cleanshared_virtual_sequence This sequence initiates CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanShared transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writeuniqueptl_virtual_sequence This sequence initiates WriteUniquePtl transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_stashonceshared_virtual_sequence This sequence initiates StashOnceShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_stashonceunique_virtual_sequence This sequence initiates StashOnceUnique transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniqueptlstash_virtual_sequence This sequence initiates WriteUniquePtlStash transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniquefullstash_virtual_sequence This sequence initiates WriteUniqueFullStash transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_stashoncesepshared_virtual_sequence This sequence initiates StashOnceSepShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_stashoncesepunique_virtual_sequence This sequence initiates StashOnceSepUnique transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniquezero_virtual_sequence This sequence initiates WriteUniqueZero transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
svt_chi_system_single_node_writeuniquefull_virtual_sequence This sequence initiates WriteUniqueFull transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpptl_virtual_sequence This sequence initiates WriteNoSnpPtl transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writecleanfull_cleansharedpersistsep_virtual_sequence This sequence initiates Writecleanfull_Cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writecleanfull_cleanshared_virtual_sequence This sequence initiates Writecleanfull_Cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writebackfull_cleaninvalid_virtual_sequence This sequence initiates Writebackfull_CleanInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writebackfull_cleansharedpersistsep_virtual_sequence This sequence initiates Writebackfull_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writebackfull_cleanshared_virtual_sequence This sequence initiates Writebackfull_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniqueptl_cleansharedpersistsep_virtual_sequence This sequence initiates WriteUniquePtl_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniqueptl_cleanshared_virtual_sequence This sequence initiates WriteUniquePtl_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniquefull_cleansharedpersistsep_virtual_sequence This sequence initiates WriteUniqueFull_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writeuniquefull_cleanshared_virtual_sequence This sequence initiates WriteUniqueFull_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpptl_cleansharedpersistsep_virtual_sequence This sequence initiates WriteNoSnpptl_cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpptl_cleanshared_virtual_sequence This sequence initiates WriteNoSnpptl_cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpptl_cleaninvalid_virtual_sequence This sequence initiates WriteNoSnpptl_cleaninvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpfull_cleaninvalid_virtual_sequence This sequence initiates WriteNoSnpFull_cleaninvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpfull_cleansharedpersistsep_virtual_sequence This sequence initiates writenosnpfull_cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpfull_cleanshared_virtual_sequence This sequence initiates WriteNoSnpFull_cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_writenosnpzero_virtual_sequence This sequence initiates WriteNoSnpZero transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
svt_chi_system_single_node_combined_write_cmo_base_virtual_sequence This sequence serves as a base sequence for single node Combined write and cmo transactions.
svt_chi_system_single_node_writenosnpfull_virtual_sequence This sequence initiates WriteNoSnpFull transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_evict_virtual_sequence This sequence initiates Evict transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each Evict transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writecleanptl_virtual_sequence This sequence initiates WriteCleanPtl transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteCleanPtl transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writecleanfull_virtual_sequence This sequence initiates WriteCleanFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteCleanFull transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writeevictfull_virtual_sequence This sequence initiates WriteEvictFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteEvictFull transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writebackptl_virtual_sequence This sequence initiates WriteBackPlt transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteBackPlt transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_writebackfull_virtual_sequence This sequence initiates WriteBackFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteBackFull transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_makeunique_virtual_sequence This sequence initiates MakeUique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeUnique transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_cleanunique_virtual_sequence This sequence initiates CleanUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanUnique transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readunique_virtual_sequence This sequence initiates ReadUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadUnique transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readnotshareddirty_virtual_sequence This sequence initiates ReadNotSharedDirty transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readspec_virtual_sequence This sequence initiates ReadSpec transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadSpec transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readclean_virtual_sequence This sequence initiates ReadClean transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readnosnp_virtual_sequence This sequence initiates ReadNoSnp transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadNoSnp transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readoncemakeinvalid_virtual_sequence This sequence initiates ReadOnceMakeInvalid transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnceMakeInvalid transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readoncecleaninvalid_virtual_sequence This sequence initiates ReadOnceCleanInvalid transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnceCleanInvalid transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_readonce_virtual_sequence This sequence initiates ReadOnce transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnce transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_prefetchtgt_virtual_sequence This sequence initiates prefetchtgt transactions from specified node_index, which can be a random node or a specific node configured by the user.
svt_chi_system_single_node_readshared_virtual_sequence This sequence initiates ReadShared transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states.
svt_chi_system_single_node_write_followed_by_cmo_virtual_sequence This sequence initiates Write transaction followed by CMO targeting the same address from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. The transactions will be targeted to a random address that is serviced by the target HN specfied with target_hn_node_idx_0. If the target_hn_node_idx_0 is not configured by the user, it will be set to its default value '0'.
svt_chi_system_multi_node_random_virtual_sequence This sequence initiates Readshared transactions from multiple RN-F nodes.
svt_chi_system_single_node_rn_coherent_transaction_base_virtual_sequence Base sequence for all the single node RN coherent transaction type derived virtual sequences.
If node_index is programmed through config DB, the value of node_index gets priority over the results of the below settings. If a given derived RN coherent transaction virtual sequence can be initiated from either RN-F or RN-I or both types of nodes as per CHI specification, the following controls can be used from the test through config DB programming.
  • select_rn_f_node: When set to 1, randomly one of the active and participating RN-F nodes will be the initiator.
  • select_rn_i_node: When set to 1, randomly one of the active and participating RN-I nodes will be the initiator.
  • select_rn_d_node: When set to 1, randomly one of the active and participating RN-D nodes will be the initiator.
  • If select_rn_f_node, select_rn_d_node and select_rn_i_node are together 1 or 0: randomly one of the active and participating RN-F/RN-I nodes will be the initiator.
Following is the user interface for programming the address ranges. This is supported currently only for single non coherent transaction type sequences. Note that both these attributes need to be programmed together through config DB. The address generated will be in the range [start_addr:end_addr]. It is required to ensure that start_addr <= end_addr. Typically, this can be used to target the address ranges that correspond to HN-I. Note that when hn_index is programmed using config DB, the start_addr and end_addr values will be ignored. Refer to documentation of hn_index.
  • start_addr: Start address for the address range
  • end_addr: End address range for the address range
Following is the user interface to generate transactions to a given Home Node index. This is supported currently only for single non coherent transaction type sequences. Note that when this attribute is programmed through config DB, values of start_addr and end_addr will be ignored.
  • hn_index: Index of home node to which transactions should be generated to
svt_chi_system_protocol_flow_ctrl_xact_hazard_virtual_sequence This sequence allows to initiate transactions to achieve hazard sceanrios. This sequence cannot be used directly, however, the derived sequences need to be used.
svt_chi_system_base_virtual_sequence This sequence creates a reporter reference.
This sequence setups up configuraion awareness related infrastructure to the derived sequences.
This sequence also provides the following attributes which can be controlled through config DB:
  • sequence_length: Length of the sequence
  • silent: Control the messages from sequences
svt_chi_system_cacheline_invalidation_virtual_sequence This sequence invalidates the cache line of a RN F node. It checks the state of the cache line and initiaties the appropriate transaction If the cacheline state is dirty, a WRITEBACK is initiated. If the cacheline state is clean, an EVICT is initiated.
svt_chi_link_service_activate_sequence svt_chi_link_service_active_sequence
svt_chi_link_service_deactivate_sequence svt_chi_link_service_deactivate_sequence
svt_chi_link_service_random_sequence svt_chi_link_service_random_sequence
svt_chi_link_service_base_sequence svt_chi_link_service_base_sequence: CHI Link Service Base sequences Base sequences have infrastructure, configurable aspects, utilities that are required for the extended Link service sequences. In general, users are not expected to use these base sequences directly.
svt_chi_protocol_service_random_coherency_exit_sequence svt_chi_protocol_service_random_coherency_exit_sequence:
  • This sequence generates Coherency Exit service requests.
  • Number of Coherency Exit service requests to be generated will be inferred from the attribute sequence_length which can be set to zero or greater than zero.
  • sequence_length set to zero causes the sequence to run throughout the simulation.
  • This sequence does not raise and drop objections, so will not block simulation exit directly.
  • Delay attributes to control the number of clock cycles before sequence initiates subsequent coherency exit service request from the sequence, which can be set through config DB:
    • Minimum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_min_delay.
    • Maximum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_max_delay.
  • The above mentioned attributes (sequence_length, coherency_exit_svc_req_min_delay, coherency_exit_svc_req_min_delay) can be set through config DB.
  • Functionality: (following steps will be in a loop of sequence_length or forever loop if sequence_length is set to 0)
    • Wait for coherency state to be COHERENCY_ENABLED_STATE
      • Note that entry to coherency enabled state is expected to happen due to RN transaction sequencer sending a cacheable transaction to RN protocol driver, which causes the driver to initiate Coherency entry.
    • Apply random delay between the programmed min and max delays
    • Initiate Coherency Exit service request
  • This sequence will run on the svt_chi_protocol_service_sequencer.
  • Default Values: (Note: Required values can be programmed through config DB)
    • sequence_length set to value between 1 and 10 upon randomization
    • coherency_exit_svc_req_min_delay set to 1000
    • coherency_exit_svc_req_max_delay set to 2000
svt_chi_protocol_service_coherency_entry_sequence svt_chi_protocol_service_coherency_entry_sequence This sequence creates a coherency_entry svt_chi_protocol_service request.
svt_chi_protocol_service_coherency_exit_sequence svt_chi_protocol_service_coherency_exit_sequence This sequence creates a coherency_exit svt_chi_protocol_service request.
svt_chi_protocol_service_random_sequence svt_chi_protocol_service_random_sequence
svt_chi_protocol_service_base_sequence svt_chi_protocol_service_base_sequence: This is the base class for svt_chi_protocol_service based sequences. All other svt_chi_protocol_service sequences are extended from this sequence.
svt_chi_ic_sn_reordering_response_sequence Class svt_chi_ic_sn_reordering_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
The test that is registering this sequence is expected to configure the CHI ICN FS VIP appropriately to exercise the reordering feature.
The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the received transactions. Once required number of transactiosn are suspended, the sequence resumes these transactions by resetting suspend_response field. The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env. The CHI ICN FS VIP driver applies the reordering of the transaction responses accordingly.
svt_chi_ic_sn_random_response_sequence Description-Unavailable
svt_chi_ic_sn_dvm_outstanding_suspend_response_resume_after_delay_sequence Class svt_chi_ic_sn_suspend_response_resume_after_delay_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
svt_chi_ic_sn_read_data_interleave_response_sequence Class svt_chi_ic_sn_read_data_interleave_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
The test that is registering this sequence is expected to configure the CHI ICN FS VIP appropriately to exercise read data interlaving feature.
The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the received read transactions, and enables the interleaving of read data for those transactions. Once required number of transactions are suspended, the sequence resumes these transactions by resetting suspend_response field. The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env. The CHI ICN FS VIP driver applies the interleaving of the read transactions accordingly.
svt_chi_ic_sn_suspend_response_resume_after_delay_sequence Class svt_chi_ic_sn_suspend_response_resume_after_delay_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
svt_chi_ic_sn_suspend_response_sequence Class svt_chi_ic_sn_suspend_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
svt_chi_ic_sn_transaction_memory_sequence Class svt_chi_ic_sn_transaction_memory_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
svt_chi_sn_transaction_null_sequence svt_chi_sn_transaction_null_sequence
svt_chi_sn_transaction_memory_sequence Class svt_chi_sn_transaction_memory_sequence defines a reactive sequence that a testbench may use to make use of CHI memory within the CHI SN agent.
svt_chi_ic_stash_snoop_transaction_directed_sequence Class svt_chi_ic_stash_snoop_transaction_directed_sequence defines a directed stash snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.
svt_chi_ic_snoop_transaction_directed_sequence Class svt_chi_ic_snoop_transaction_directed_sequence defines a directed snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.
svt_chi_ic_dvm_snoop_transaction_random_sequence Class svt_chi_ic_dvm_snoop_transaction_random_sequence defines a snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.
svt_chi_ic_snoop_transaction_random_sequence Class svt_chi_ic_snoop_transaction_random_sequence defines a snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.
svt_chi_rn_directed_snoop_response_sequence Abstract:
Class svt_chi_rn_directed_snoop_response_sequence defines a sequence class that the testbench uses to provide snoop response to the RN agent present in the System agent.
The sequence receives a response object of type svt_chi_rn_snoop_transaction from RN snoop sequencer. The sequence class then sets up the snoop response attributes and provides it to the RN driver within the RN agent.
Execution phase: main_phase
Sequencer: RN agent snoop sequencer

The basis for setting up the snoop response based on snoop request type is as per "Table 6-2 Snooped cache response to snoop requests" of CHI Specification.

The handle to Cache of the RN agent is retrieved from the RN agent and following method is invoked to read the cache line corresponding to the received snoop request address: read_line_by_addr(req_resp.addr,index,data,byte_enable,is_unique,is_clean,age).
Then the output values from the above method is_unique, is_clean are used to know the state of the cacheline.
The state of cache line is used to setup the snoop response attributes based on the following information:
is_unique is_clean init_state read_status
0 0 I 0
0 0 SD 1
0 1 SC 1
1 0 UD 1
1 1 UC 1

datatransfer Data includes
0 no
1 yes

passdirty PD
0 no
1 yes

isshared final_state
0 I
1 anything other than I

Following are the attributes of the snoop resonse that are set accordingly, based on the Snp Request type:
svt_chi_rn_snoop_response_sequence svt_chi_rn_snoop_response_sequence:
  • Provide a coherent response based on the local cache in the RN instance.
  • This is the default snoop response sequence registered by active RN agent.
  • Class svt_chi_rn_snoop_response_sequence defines a sequence class that the testbench uses to provide snoop response to the RN agent present in the System agent.
  • Execution phase: main_phase
  • Sequencer: RN agent snoop sequencer
  • The basis for setting up the snoop response based on snoop request type is as per ARM-IHI0050A 5.0: 4.7.5 Table 4-11
  • Following are the attributes of the snoop resonse that are set accordingly, based on the Snp Request type: ARM-IHI0050A 5.0: 4.7.5 Table 4-11

snp_rsp_datatransfer Data includes
0 no
1 yes

resp_pass_dirty PD
0 no
1 yes

snp_rsp_isshared final_state
0 I
1 anything other than I

svt_chi_snoop_transaction_base_sequence svt_chi_snoop_transaction_base_sequence: This is the base class for svt_chi_snoop_transaction sequences. All other svt_chi_snoop_transaction sequences are extended from this sequence.
svt_chi_rn_makereadunique_type_transaction_directed_sequence Abstract: This class defines a sequence that sends MakeReadUnique type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_prefetchtgt_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Prefetchtgt type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_atomic_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Atomic type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
chi_rn_directed_noncoherent_xact_sequence Abstract: chi_rn_directed_noncoherent_xact_sequence defines a sequence through which non coherent transactions can be sent. Execution phase: main_phase Sequencer: Master agent sequencer
chi_rn_noncoherent_transaction_base_sequence Abstract: chi_rn_noncoherent_transaction_base_sequence defines a sequence through which non coherent transactions can be sent. Execution phase: main_phase Sequencer: Master agent sequencer
chi_rn_barrier_directed_sequence Abstract: chi_rn_barrier_directed_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This class defines a sequence in which a CHI WRITE followed by a CHI READ sequence is generated by assigning values to the transactions rather than randomization, and then transmitted using `uvm_send.
svt_chi_rn_makeunique_cache_initialization_directed_sequence Abstract: Sends MAKEUNIQUE transactions from an RN Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_cmo_type_transaction_directed_sequence Abstract: This class defines a sequence that sends CMO type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_e_rn_writesoptionaldata_type_transaction_directed_sequence Abstract: This class defines a sequence that sends WRITEEVICTOREVICT CopyBack type transaction. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_copyback_type_transaction_directed_sequence Abstract: This class defines a sequence that sends CopyBack type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_write_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Write type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_exclusive_access_sequence Abstract: This class defines a sequence for exclusive access support. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_read_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Read type transactions. Execution phase: main_phase Sequencer: RN agent sequencer
svt_chi_rn_go_noncoherent_sequence RN transaction non-coherent transaction type sequence that exercises global observability for pre-barrier transactions
svt_chi_rn_ecbarrier_sequence RN transaction ECBARRIER sequence
svt_chi_rn_eobarrier_sequence RN transaction EOBARRIER sequence
svt_chi_rn_transaction_dvm_sync_sequence svt_chi_rn_transaction_dvm_sync_sequence
svt_chi_rn_transaction_dvm_write_semantic_sequence svt_chi_rn_transaction_dvm_write_semantic_sequence
svt_chi_rn_coherent_transaction_base_sequence svt_chi_rn_coherent_transaction_base_sequence
svt_chi_rn_transaction_null_sequence svt_chi_rn_transaction_null_sequence
svt_chi_rn_transaction_xact_type_sequence svt_chi_rn_transaction_xact_type_sequence
svt_chi_rn_transaction_random_sequence svt_chi_rn_transaction_random_sequence
svt_chi_system_cacheline_initialization_virtual_sequence This sequence initializes the cache line of all masters.
  • The rn_xact for which cache is to be initialized must be input to this sequence.
  • The sequence checks if the cache line is already one of the spec permitted states for the rn_xact type. If legal, nothing is done by this sequence. If not legal, then the next steps are performed.
  • invalidate_all_cachelines: send makeunique from initiating RN-F; send invalidate xact (writeback if current state is dirty, evict if current state is clean)
  • get_random_initial_cachestate: get the random legal initial cacheline state for the xact type. Based on this, the next steps are performed.
    • If get_random_initial_cachestate returns 'Invalid' state: send readshared from the peer RN-Fs.).
    • If get_random_initial_cachestate returns a Unique state: send makeunique from initiating RN-F.
    • If get_random_initial_cachestate returns a Shared state: send makeunique from initiating RN-F; send readshared from the peer RN-Fs; If the initiating rn-f cacheline state is not valid, send makeunique from initiating RN-F. If bypass_silent_cache_line_state_transition is set to 0: update status of cacheline silently to shared.
  • If clean cache line is required for the coherent xact, send writeclean xact from the initiating RN-F.
svt_chi_system_rn_coherent_transaction_base_virtual_sequence This is the base sequence for:
svt_chi_ic_snoop_transaction_base_sequence svt_chi_ic_snoop_transaction_base_sequence: This is the base class for svt_chi_ic_snoop_transaction sequences. All other svt_chi_ic_snoop_transaction sequences are extended from this sequence. svt_chi_ic_snoop_transaction sequences will be used by CHI ICN VIP component. CHI IC SN Snoop xact sequencer and the Interconnect driver will be using it.
svt_chi_ic_sn_transaction_base_sequence svt_chi_ic_sn_transaction_base_sequence: This is the base class for svt_chi_ic_sn_transaction sequences. All other svt_chi_ic_sn_transaction sequences are extended from this sequence. svt_chi_ic_sn_transaction sequences will be used by CHI ICN FS VIP driver, CHI IC SN XACT sequencer.
svt_chi_sn_transaction_base_sequence Description-Unavailable
svt_chi_rn_transaction_base_sequence svt_chi_rn_transaction_base_sequence: This is the base class for svt_chi_rn_transaction sequences. All other svt_chi_rn_transaction sequences are extended from this sequence.
svt_axi_slave_transaction_sequence_library Sequence library for svt_axi_slave_transaction transaction.
svt_ahb_master_transaction_sequence_library AHB VIP provides a pre-defined sequence library svt_ahb_master_transaction_sequence_library, which can hold the AHB sequences. The library by default has no registered sequences. You are expected to call svt_ahb_master_transaction_sequence_library :: populate_library method to populate the sequence library with svt_ahb_master sequences provided with the VIP. The system configuration is provided to the populate_library method as an argument. Based on the configuration, appropriate sequences are added to the sequence library. You can then load the sequence library in the sequencer within the svt_ahb_master agent.
svt_ahb_master_transaction_busy_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions with busy cycles inserted for every beat of the burst. All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_distributed_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions with distribution on the following fields:
svt_ahb_master_transaction_locked_write_read_sequence This sequence performs the following: A LOCKED WRITE transaction A NORMAL READ transaction A NORMAL WRITE transaction A LOCKED READ transaction The remaining transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_no_idle_write_read_sequence This sequence generates back-to-back write and read transaction with zero idle cycles between transactions.The remaining transaction fields are randomized. The sequence does not wait for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_fixed_len_write_read_hsize_sequence This sequence generates alternate write and read transaction including: SINGLE and fixed length Burst types Transfer sizes including BYTE,HALF-WORD,FULL-WORD types The remaining transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_alternate_write_read_sequence This sequence generates alternate write and read transaction. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_idle_sequence This sequence generates a sequence of idle transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_read_xact_sequence This sequence generates a single random read transaction.
svt_ahb_master_transaction_write_xact_sequence This sequence generates a single random write transaction.
svt_ahb_master_transaction_read_sequence This sequence generates a sequence of read transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_write_sequence This sequence generates a sequence of write transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_random_sequence This sequence generates random master transactions.
svt_ahb_transaction_random_write_or_read_sequence This sequence generates a sequence of write or read transactions with busy cycles inserted to a value controlled by user for every beat of the burst. For INCR burst type num_incr_beats is controlled by user. All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction.
svt_ahb_master_transaction_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other svt_ahb_master sequences in the collection extend from this base sequence.
13 August 2024, Copyright © 2024 Synopsys, Inc.