How to download VIP smartsearch?
DESIGNWARE_HOMEto required designware home location where VIP Smartsearch should be downloaded.
vip_smartsearch_<version>.runfile.
$DESIGNWARE_HOME/vip/svt/vip_smartsearch/<version>
How to install VIP Smartsearch?
Please refer to the fileVIP_Smartsearch_installation_and_usage_guide.pdfin
$DESIGNWARE_HOME/vip/svt/vip_smartsearch/<version>for installation steps.
Customer Support
For more details about VIP smartsearch tool, contact support_center@synopsys.com.Comprehensive Inheritance diagram for sequence classes:
Summary of Sequences defined in AXI SVT UVM Documentation:
| Product Base | Group |
|---|---|
| amba_svt | AXI_SERVICE_SEQ |
| Ungrouped Sequences |
| Sequence Group | Sequences | Sequences Description |
|---|---|---|
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | svt_axi_service_coherency_entry_sequence |
svt_axi_service_coherency_entry_sequence
This sequence creates a coherency_entry svt_axi_service request. |
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | svt_axi_service_coherency_exit_sequence | svt_axi_service_coherency_exit_sequence This sequence creates a coherency_exit svt_axi_service request. |
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | svt_axi_service_random_coherency_exit_sequence |
svt_axi_service_random_coherency_exit_sequence:
|
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | 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.
The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1. |
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | 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. |
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | 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. |
| AXI_SERVICE_SEQ * AXI Master service sequences that run on axi service sequencer | svt_axi_slave_service_random_sequence |
svt_axi_slave_service_random_sequence
This sequence creates a random svt_axi_service request. |
| default | 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. |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | axi_master_atomic_compare_xact_base_sequence | This sequence generates atomic compare transactions. |
| default | axi_master_atomic_load_xact_base_sequence | This sequence generates atomic load transactions. |
| default | axi_master_atomic_store_xact_base_sequence | This sequence generates atomic store transactions. |
| default | axi_master_atomic_swap_xact_base_sequence | This sequence generates atomic swap transactions. |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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. |
| default | 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 . |
| default | 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. |
| default | 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. |
| default | 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 |
| default | svt_axi_ace_barrier_pair_sequence | Sends a barrier pair |
| default | 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 |
| default | 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
Please note, for generation of exclusive access transactions, svt_axi_port_configuration :: exclusive_access_enable should be set for the targeted master. |
| default | 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. |
| default | svt_axi_basic_writeback_full_cacheline | This sequence generates a writeback transaction for a full cacheline. |
| default | svt_axi_basic_writeclean_full_cacheline | This sequence generates a writeclean transaction for a full cacheline. |
| default | 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 |
| default | 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. |
| default | svt_axi_ace_master_read_xact_sequence | This sequence generates a single random ACE read transaction. |
| default | svt_axi_ace_master_write_xact_sequence | This sequence generates a single random ACE write transaction. |
| default | svt_axi_exclusive_id_addr_test_sequence | This sequence follows id_addr's transactions parallelly and other configurations set from the test. |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | svt_axi_master_aligned_addr_sequence | This sequence generates the transactions whose address is always aligned with respect to burst size. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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 |
| default | 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. |
| default | 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. |
| default | 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) |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | svt_axi_master_random_sequence | This sequence generates random master transactions. |
| default | svt_axi_master_read_xact_sequence | This sequence generates a single random read transaction. |
| default | 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. |
| default | 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. |
| default | svt_axi_master_write_xact_sequence | This sequence generates a single random write transaction. |
| default | 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. |
| default | svt_axi4_lite_master_random_sequence | This sequence generates random master transactions for axi4_lite. |
| default | 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. |
| default | 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 . |
| default | 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.
Execution phase: main_phase Sequencer: Virtual sequencer in AXI System ENV |
| default | 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. |
| default | 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. |
| default | 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 . |
| default | 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 . |
| default | 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 . |
| default | 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 . |
| default | 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 . |
| default | 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 . |
| default | 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. |
| default | 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. |
| default | 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 |
| default | 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 |
| default | 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 |
| default | svt_axi_master_sanity_test_sequence | This sequence performs reads and writes in parallel |
| default | svt_axi_master_snoop_base_sequence | AXI ACE base master snoop response reactive sequence |
| default | 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.
If data is available in the cache, that data is populated into the snoop transaction. |
| default | 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.
Execution phase: run_phase Sequencer: Slave agent sequencer |
| default | 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. |
| default | 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. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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 |
| default | 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.
Execution phase: main_phase Sequencer: Slave agent sequencer |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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. |
| default | 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.
This sequence runs forever, and so is not registered with the slave sequence library. |
| default | 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.
Automatically configured as the run_phase default sequence for every instance of the svt_axi_slave_sequencer if the use_pv_socket property in the port configuration is TRUE |
| default | 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 . |
| default | svt_axi_system_base_sequence | This sequence creates a reporter reference |
| default | 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. |
| default | 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
NOTE: Continuous polling may need adding interval between two consecutive transactions. See poll_barrier_flag_and_check_post_barrier_contents task for details. |
| default | 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. |
| default | 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 |
| default | 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.
NOTE: Continuous polling may need adding interval between two consecutive transactions. See poll_barrier_flag_and_check_post_barrier_contents task for details. This task is part of class svt_axi_ace_master_barrier_base_virtual_sequence from which current class is derived. |
| default | 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 |
| default | 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::
|
| default | svt_axi_ace_master_single_port_base_virtual_sequence | Base class from which all ACE basic level sequences will be extended. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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
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 |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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. |
| default | 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: |
| default | svt_axi_ace_master_two_port_base_virtual_sequence | Base class from which all ACE intermediate level sequences will be extended. |
| default | 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. |
| default | 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 |
| default | 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
|
| default | svt_axi_ace_master_two_master_concurrent_write_sequence | This sequence sends cocurrent write transactions from two ports after initializing cache lines |
| default | 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 |
| default | 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:
|
| default | 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:
|
| default | 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:
|
| default | 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. |
| default | 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 |
| default | 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. |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. |
| default | svt_axi_cov_corner_cases_wstrb_sequence | #- Program the Master VIP to drive multiple transaction with more probability for wstrb corner scenarios. |
| default | 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. . |
| default | 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. |
| default | 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. . |
| default | 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. . |
| default | svt_axi_master_atomic_compare_xact_base_virtual_sequence | This sequence serves as a base sequence to create atomic compare type transactions |
| default | svt_axi_master_atomic_load_xact_base_virtual_sequence | This sequence serves as a base sequence to create atomic load type transactions |
| default | svt_axi_master_atomic_store_xact_base_virtual_sequence | This sequence serves as a base sequence to create atomic store type transactions |
| default | svt_axi_master_atomic_swap_xact_base_virtual_sequence | This sequence serves as a base sequence to create atomic swap type transactions |
| default | 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. . |
| default | svt_axi_random_ictest_sequence | #- Program the Master VIP to drive multiple random transaction. . |
| default | 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. . |
| default | svt_axi_system_random_sequence | This sequence allows unconstrained random traffic for all ports |
| default | 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 . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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 . |
| default | 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 . |
| default | 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. . |
| default | 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 . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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. . |
| default | 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 . |
| default | 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. . |
| default | 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 . |
| default | 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. . |
| default | 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 |
| default | 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 |