VIP Smartsearch

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

  • How to download VIP smartsearch?

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

  • How to install VIP Smartsearch?

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

  • Customer Support

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

AMBA SVT UVM Documentation - Sequence Page

Comprehensive Inheritance diagram for sequence classes:

Summary of Sequences defined in AMBA SVT UVM Documentation:

Product Base Group
amba_svt CHI_SYS_OUTSTANDING
CHI_SYS_FLOW_CTRL
CHI_SYS_SINGLE_RN
CHI_RN
CHI_RN_BASE
AXI_SERVICE_SEQ
CHI_SYS_EXCLUSIVE_ACCESS
CHI_SYS_HAZARD
CHI_SYS_BASE
CHI_LINK_SVC
CHI_LINK_SVC_BASE
CHI_PROTOCOL_SERVICE
CHI_PROTOCOL_SERVICE_BASE
CHI_IC_SN_MEM
CHI_IC_SN_BASE
CHI_SN_MEM
CHI_SN_NULL
CHI_SN_BASE
CHI_IC_SNP
CHI_IC_SNP_BASE
CHI_SNP
CHI_SNP_BASE
CHI_RN_NULL
Ungrouped Sequences

Product: amba_svt - Sequence Details:

Sequence Group Sequence Subgroup Sequences Sequences Description
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two different HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected two different HN's.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected different HN's in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the RN receives the responses for all the outstanding transactions from
different HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the different HN responds properly for all outstanding Read type
transactions and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of MakeReadUnique type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected HN in non blocking mode.
#- The addresses of these MakeReadUnique transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the HN responds properly for all outstanding MakeReadUnique type
transactions and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_makereadunique_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of MakeReadUnique type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these MakeReadUnique transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding MakeReadUnique type transactions
and these are completed successfully.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_read_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two different HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected two different HN's.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected different HN's in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the RN receives the responses for all the outstanding transactions from
different HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the different HN responds properly for all outstanding Read type
transactions and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_read_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from two initiating RN's to randomly
selected HN in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from different RN.
#- Check that the HN responds properly for all outstanding Read type
transactions and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_read_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these Read transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding Read type transactions
and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_e_system_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HNs. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HNs in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .		 txn_is_non_secure_access
Description-Unavailable
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_chi_e_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_chi_e_protocol_flow_ctrl_combined_noncopyback_write_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_write_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect. #- This sequence requires two initiating active and participating RNs. #- If another active and participating RN-F exists, perform cache initialization to two randomly selected HNs. #- Initiate Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 each from both the initiating RNs, 128 each to randomly selected two HNs from each of the RN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting both the HNs
#- Once the RNs receive the responses for all the outstanding transactions from both of the HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from the RNs. #- Check that both of the HNs respond properly for all outstanding write type transactions and these are completed successfully. .		 txn_is_non_secure_access
Description-Unavailable
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_write_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_write_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these write transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding write type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_e_system_protocol_flow_ctrl_combined_copyback_write_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN nodes to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of combined write copyback cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these combined write copyback cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these combined write copyback cmo transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HNs responds properly for all outstanding combined write copyback cmo type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_e_system_protocol_flow_ctrl_combined_copyback_write_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Initiate maximum number of MAKEUNIQUE transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of combined copyback write cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
#- The addresses of these combined copyback write cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-F of these combined copyback write cmo transactions are such that:
  • Same as RN-F from which cache initialization is performed
#- Once the RN-F receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-F. #- Check that the HN responds properly for all outstanding combined copyback write cmo type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_e_system_protocol_flow_ctrl_combined_write_copyback_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of combined write copyback cmo type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these combined write copyback cmo transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these combined write copyback cmo transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding combined write copyback cmo type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_copyback_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN nodes to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HNs responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires atleast two HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected different HNs. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-Fs to randomly selected HNs in non blocking mode.
#- The addresses of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, attribute svt_chi_rn_transaction :: suspend_wr_data or svt_chi_rn_transaction :: suspend_comp_ack whichever is applicable is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData or Compack for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding Writesoptionaldata COPYBACK type transactions and these are completed successfully. . #- This sequence generates Writesoptionaldata COPYBACK type WRITEEVICTOREVICT transactions. .

This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.

 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_copyback_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating different RN-Fs, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast two initiating active and participating RN-Fs. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-Fs to randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-Fs of these COPYBACK transactions are such that:
  • Same as RN-Fs from which cache initialization is performed
#- Once the RN-Fs receives the responses for all the outstanding transactions from the HN, attribute svt_chi_rn_transaction :: suspend_wr_data or svt_chi_rn_transaction :: suspend_comp_ack whichever is applicable is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData or Compack for these transactions can be resumed from RN-Fs. #- Check that the HN responds properly for all outstanding Writesoptionaldata COPYBACK type transactions and these are completed successfully. . #- This sequence gemerates Writesoptionaldata COPYBACK type WRITEEVICTOREVICT transactions. .

This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.

 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_copyback_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Inititate maximum number of MAKEUNIQUE transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
#- The addresses of these COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-F of these COPYBACK transactions are such that:
  • Same as RN-F from which cache initialization is performed
#- Once the RN-F receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData for these transactions can be resumed from RN-F. #- Check that the HN responds properly for all outstanding COPYBACK type transactions and these are completed successfully. . #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_writesoptionaldata_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires atleast one HN node to be present in the Interconnect. #- This sequence requires atleast one initiating active and participating RN-F. #- Inititate maximum number of MAKEUNIQUE followed by WRITEBACKFULL followed by READCLEAN transactions from existing active and participating RN-F, to perform cache initialization to a randomly selected HN. #- Initiate maximum number of Writesoptionaldata COPYBACK type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 and svt_chi_rn_transaction :: suspend_comp_ack set to 1 from the initiating RN-F to the randomly selected HN in non blocking mode.
#- The addresses of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
#- The RN-F of these Writesoptionaldata COPYBACK transactions are such that:
  • Same as RN-F from which cache initialization is performed
#- Once the RN-F receives the responses for all the outstanding transactions from HN, attribute svt_chi_rn_transaction :: suspend_wr_data or svt_chi_rn_transaction :: suspend_comp_ack whichever is applicable is set to 0 for all the outstanding transactions.
This ensures that the CopyBackWrData or Compack for these transactions can be resumed from RN-F. #- Check that the HN responds properly for all outstanding Writesoptionaldata COPYBACK type transactions and these are completed successfully. . #- This sequence generates Writesoptionaldata COPYBACK type WRITEEVICTOREVICT transactions. .

This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.

 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CMO_TYPE
* CMO type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_cmo_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected different HN's.
#- Initiate maximum number of CMO type transactions with svt_chi_rn_transaction::
suspend_comp_ack set to 1 from selected initiating RN to randomly selected
different HN's in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the different HN's
#- Once the selected RN receives the responses for all the outstanding transactions
from selected HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the
outstanding transactions.
This ensures that the CompAck for these transactions can be resumed
from selected RN.
#- Check that the selected HN responds properly for all outstanding CMO type
transactions and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CMO_TYPE
* CMO type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_cmo_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires two initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate max_num_outstanding_cmo_xacts_at_hn/2 or max_num_outstanding_xacts_at_hn/2 number of CMO type transactions with svt_chi_rn_transaction::
suspend_comp_ack set to 1 from selected initiating RN to randomly selected HN
in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the selected RN receives the responses for all the outstanding transactions
from HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the
outstanding transactions.
This ensures that the CompAck for these transactions can be resumed
from selected RN.
#- Check that the HN responds properly for all outstanding CMO type transactions
and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_CMO_TYPE
* CMO type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_cmo_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- If another active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Initiate maximum number of CMO type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly
selected HN in non blocking mode.
#- The addresses of these CMO transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from
HN, svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for all the outstanding
transactions.
This ensures that the CompAck for these transactions can be resumed
from RN.
#- Check that the HN responds properly for all outstanding CMO type transactions
and these are completed successfully.
.		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_ATOMIC_TYPE
* Atomic type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_atomic_outstanding_diff_rn_diff_hn_virtual_sequence #- This sequence requires at least two HN nodes to be present in the Interconnect. #- This sequence requires two initiating active and participating RNs. #- If another active and participating RN-F exists, perform cache initialization to two randomly selected HNs. #- Initiate Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 each from both the initiating RNs, 128 each to randomly selected two HNs from each of the RN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting both the HNs
#- Once the RNs receive the responses for all the outstanding transactions from both of the HNs, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from the RNs. #- Check that both of the HNs respond properly for all outstanding atomic type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_ATOMIC_TYPE
* Atomic type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_atomic_outstanding_diff_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires two initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate 128 Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from each of the two initiating RNs to the randomly selected HN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RNs receive the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from both the RNs. #- Check that the HN responds properly for all outstanding atomic type transactions and these are completed successfully. .		 --
CHI_SYS_OUTSTANDING
* Outstanding transactions feature virtual sequences generate transactions from RN agents to verify the maximum outstanding transaction capability of a home node within the interconnect. Controls to specify the outstanding transaction limits of the targeted home node are provided in these sequences. The categories of transaction types covered include: Reads, Writes, Copyback, CMOs, Atomics.
CHI_OUTSTANDING_ATOMIC_TYPE
* Atomic type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_atomic_outstanding_same_rn_same_hn_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate maximum number of Atomic type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- The addresses of these atomic transactions are such that:
  • Same as initialized cache line addresses if cache initialization is performed
  • Otherwise, random addresses targeting the same HN
#- Once the RN receives the responses for all the outstanding transactions from HN, svt_chi_rn_transaction :: suspend_wr_data is set to 0 for all the outstanding transactions.
This ensures that the NonCopyBackWrData for these transactions can be resumed from RN. #- Check that the HN responds properly for all outstanding atomic type transactions and these are completed successfully. .		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_read_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Optionally program a randomly selected RN to send two MAKEUNIQUE transaction targeted to
randomly selected different target IDs when number of RN-F is 3 or more incase of RN-F test
or number of RN-F is atleast 1 incase of RN-I test.
#- Program other two randomly selected RNs to send a read type coherent transaction
with same TxnID simultaneously to above selected different target IDs of MAKEUNIQUE transactions if MAKEQNIQUE transaction is sent for initilization.
#- If MAKEQNIQUE transaction is not sent for initilization program two randomly
selected different RNs to send a read type coherent transaction with same TxnID simultaneously
to randomly selected different target IDs.
#- Check that the HN's responds with same TxnId to respective RNs.
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_RD_TYPE
* Read type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_read_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Optionally program a randomly selected RN to send two MAKEUNIQUE transaction targeted to
randomly selected same target IDs when number of RN_F is 3 or more incase of RN_F test
or number of RN_F is atleast 1 incase of RN_I test.
#- Program other two randomly selected RNs to send a read type coherent transaction
with same TxnID simultaneously to above selected same target IDs of MAKEUNIQUE transactions if MAKEQNIQUE transaction is sent for initilization.
#- If MAKEQNIQUE transaction is not sent for initilization program two randomly
selected different RNs to send a read type coherent transaction with same TxnID simultaneously
to randomly selected same target IDs.
#- Check that the HN's responds with same TxnId to respective RNs.
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_write_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program two MAKEUNIQUE transaction from one randomly selected RN targeted to different HN.
#- Program two randomly selected different RN VIP to drive a write transaction with same
Txnid simultaneously to randomly selected different HN Nodes of
MAKEUNIQUE transactions.
#- Check the HN responds with same Txnid to respective RN's.
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_write_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program two MAKEUNIQUE transaction from one randomly selected RN targeted to same HN.
#- Program two randomly selected different RN VIP to drive a write transaction with same
Txnid simultaneously to randomly selected same HN Nodes of
MAKEUNIQUE transactions.
#- Check the HN responds with same Txnid to respective RN's.
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_WR_TYPE
* Write type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_writeunique_suspend_compack_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect.
#- This sequence requires one initiating active and participating RN.
#- Initiate WRITEUNIQUEFULL/WRITEUNIQUEPTL type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN.
#- Wait for the Initiating RN to transmit the DATA flits without waiting for Compack
#- Resume the suspended Compack after the DATA flits are transmitted.
  • This ensures that the expcompack s sent after all the DATA flits are transmitted on to interface.
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_copyback_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program the any two randomly selected RNs to drive a MakeUnique transaction targeted
to randomly selected different HN.
#- Program the above selected RNs to drive a CopyBack transactions simultaneously with
same TxnId and address same as of MakeUnique transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- Program a randomly selected RN to drive a ReadShared transaction to verify CopyBack
transaction.
. #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_CPBK_TYPE
* CopyBack type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_copyback_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program the any two randomly selected RNs to drive a MakeUnique transaction targeted
to randomly selected same HN.
#- Program the above selected RNs to drive a CopyBack transactions simultaneously with
same TxnId and address same as of MakeUnique transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- Program a randomly selected RN to drive a ReadShared transaction to verify CopyBack
transaction.
. #- This sequence does not support EVICT and WRITEEVICTFULL transactions.
 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_CMO_TYPE
* CMO type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_cmo_resp_same_txnid_diff_rn_diff_hn_virtual_sequence #- Program two MakeUnique transactions from one randomly selected RN_F targeted to
different HN Nodes.
#- Program two randomly selected different RN VIP to drive any CMO type transaction
with same Txnid simultaneously to above selected same HN Nodes of
MakeUnique transactions.
#- Check the HN's respond with same Txnid to respective RN's.
#- For CleanShared, CleanInvalid transactions, Program Read transactions from
above first selected RN_F to compare Read data with data of above MakeUnique
transactions
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_CMO_TYPE
* CMO type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_cmo_resp_same_txnid_diff_rn_same_hn_virtual_sequence #- Program two MakeUnique transactions from one randomly selected RN_F targeted to
same HN Node.
#- Program two randomly selected different RN VIP to drive any CMO type transaction
with same Txnid simultaneously to above selected same HN Node of MakeUnique
transactions.
#- Check the HN responds with same Txnid to respective RN's.
#- For CleanShared, CleanInvalid transactions, Program Read transactions from
above first selected RN_F to compare Read data with data of above MakeUnique
transactions
.		 --
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_PREFETCHTGT_TYPE
* PREFETCHTGT type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_prefetchtgt_read_outstanding_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate a Read type transactions with
svt_chi_rn_transaction :: suspend_comp_ack set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- Initiate a PREFETCHTGT type transaction to the same address of read transaction address.
  • Txn_id of a PREFETCHTGT transaction is set to below values based on sel_txnid_type_enum, which can be controlled through config DB or random value by default
    • when sel_txnid_type_enum == TXNID_SAME_AS_PREFETCHTGT i.e txn_id is same as read transaction txn_id
    • when sel_txnid_type_enum == TXNID_NOT_SAME_AS_PREFETCHTGT i.e txn_id is not same as read transaction txn_id
#- Wait for the PREFETCHTGT transaction to end, Once it ends svt_chi_rn_transaction :: suspend_comp_ack is set to 0 for the outstanding read transaction.
This ensures that the CompAck for the above Read transaction can be resumed
from RN.

#- Check that the HN responds properly for PREFETCHTGT and Read transactions and these are completed successfully. .

 sel_txnid_type
Description-Unavailable
CHI_SYS_FLOW_CTRL
* Flow control feature virtual sequences generate transactions with same Transaction ID from one or more RN agents to verify flow control protocol requirements of a home node within the interconnect. Transaction types covered include: Reads, Writes, Copyback, CMOs. Also PrefetchTarget transaction type mixed with reads and writes are generated with controllable aspects for Transaction ID values.
CHI_FLOW_CTRL_PREFETCHTGT_TYPE
* PREFETCHTGT type transaction specific flow control feature virtual sequences
 svt_chi_system_protocol_flow_ctrl_prefetchtgt_write_outstanding_virtual_sequence #- This sequence requires at least one HN node to be present in the Interconnect. #- This sequence requires one initiating active and participating RN. #- If another active and participating RN-F exists, perform cache initialization to a randomly selected HN. #- Initiate a Write type transactions with svt_chi_rn_transaction :: suspend_wr_data set to 1 from initiating RN to randomly selected HN in non blocking mode.
#- Initiate a PREFETCHTGT type transaction to the same address of write transaction address.
  • Txn_id of a PREFETCHTGT transaction is set to below values based on sel_txnid_type_enum, which can be controlled through config DB or random value by default
    • when sel_txnid_type_enum == TXNID_SAME_AS_PREFETCHTGT i.e txn_id is same as Write transaction txn_id
    • when sel_txnid_type_enum == TXNID_NOT_SAME_AS_PREFETCHTGT i.e txn_id is not same as Write transaction txn_id
#- Wait for the PREFETCHTGT transaction to end, Once it ends svt_chi_rn_transaction :: suspend_wr_data is set to 0 for the outstanding write transaction.
This ensures that the NonCopyBackWrData for the above write transaction can be resumed from RN.

#- Check that the HN responds properly for PREFETCHTGT and Write transactions and these are completed successfully. .

 sel_txnid_type
Description-Unavailable
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_BASE
* Base sequence for transaction specific single node virtual sequences
 svt_chi_system_single_node_rn_coherent_transaction_base_virtual_sequence Base sequence for all the single node RN coherent transaction type derived virtual sequences.
If node_index is programmed through config DB, the value of node_index gets priority over the results of the below settings. If a given derived RN coherent transaction virtual sequence can be initiated from either RN-F or RN-I or both types of nodes as per CHI specification, the following controls can be used from the test through config DB programming.
  • select_rn_f_node: When set to 1, randomly one of the active and participating RN-F nodes will be the initiator.
  • select_rn_i_node: When set to 1, randomly one of the active and participating RN-I nodes will be the initiator.
  • select_rn_d_node: When set to 1, randomly one of the active and participating RN-D nodes will be the initiator.
  • If select_rn_f_node, select_rn_d_node and select_rn_i_node are together 1 or 0: randomly one of the active and participating RN-F/RN-I nodes will be the initiator.
Following is the user interface for programming the address ranges. This is supported currently only for single non coherent transaction type sequences. Note that both these attributes need to be programmed together through config DB. The address generated will be in the range [start_addr:end_addr]. It is required to ensure that start_addr <= end_addr. Typically, this can be used to target the address ranges that correspond to HN-I. Note that when hn_index is programmed using config DB, the start_addr and end_addr values will be ignored. Refer to documentation of hn_index.
  • start_addr: Start address for the address range
  • end_addr: End address range for the address range
Following is the user interface to generate transactions to a given Home Node index. This is supported currently only for single non coherent transaction type sequences. Note that when this attribute is programmed through config DB, values of start_addr and end_addr will be ignored.
  • hn_index: Index of home node to which transactions should be generated to
node_index
Represents the RN from which the sequence will be initiated. This can be controlled through config DB.

CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_cleanunique_virtual_sequence This sequence initiates CleanUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanUnique transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_makereadunique_virtual_sequence This sequence initiates MakeReadUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeReadUnique transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_makeunique_virtual_sequence This sequence initiates MakeUique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeUnique transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readclean_virtual_sequence This sequence initiates ReadClean transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readnosnp_virtual_sequence This sequence initiates ReadNoSnp transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadNoSnp transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readonce_virtual_sequence This sequence initiates ReadOnce transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnce transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readpreferunique_virtual_sequence This sequence initiates ReadPreferUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadPreferUnique transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readshared_virtual_sequence This sequence initiates ReadShared transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_RD_TYPE
* Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readunique_virtual_sequence This sequence initiates ReadUnique transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadUnique transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_PFT_TYPE
* CHI-B PrefetchTarget type transaction specific single node virtual sequences
 svt_chi_system_single_node_prefetchtgt_virtual_sequence This sequence initiates prefetchtgt transactions from specified node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_B_SINGLE_RN_RD_TYPE
* CHI-B Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readnotshareddirty_virtual_sequence This sequence initiates ReadNotSharedDirty transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadShard transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_B_SINGLE_RN_RD_TYPE
* CHI-B Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readoncecleaninvalid_virtual_sequence This sequence initiates ReadOnceCleanInvalid transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnceCleanInvalid transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_B_SINGLE_RN_RD_TYPE
* CHI-B Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readoncemakeinvalid_virtual_sequence This sequence initiates ReadOnceMakeInvalid transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadOnceMakeInvalid transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_B_SINGLE_RN_RD_TYPE
* CHI-B Read type transaction specific single node virtual sequences
 svt_chi_system_single_node_readspec_virtual_sequence This sequence initiates ReadSpec transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each ReadSpec transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_B_SINGLE_RN_CMO_TYPE
* CHI-B CMO type transaction specific single node virtual sequences
 svt_chi_system_single_node_cleansharedpersist_virtual_sequence This sequence initiates CleanSharedPersist transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanSharedPersist transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ATOMICSTORE_TYPE
* CHI-B AtomicStore type transaction specific single node virtual sequence
 svt_chi_system_single_node_atomicstore_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Store transaction from randomly selected RN_F.
.		 --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ATOMICSTORE_TYPE
* CHI-B AtomicStore type transaction specific single node virtual sequence
 svt_chi_system_single_node_rn_atomic_transaction_ordering_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic transaction from randomly selected RN_F
with order_type set to REQ_ORDERING_REQUIRED.
.		 selected_atomic_xact_type
Description-Unavailable
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ATOMICLOAD_TYPE
* CHI-B AtomicLoad type transaction specific single node virtual sequence
 svt_chi_system_single_node_atomicload_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Load transaction from randomly selected RN_F.
.		 --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ATOMICSWAP_TYPE
* CHI-B AtomicSwap type transaction specific single node virtual sequence
 svt_chi_system_single_node_atomicswap_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Swap transaction from randomly selected RN_F.
.		 --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ATOMICCOMPARE_TYPE
* CHI-B AtomicCompare type transaction specific single node virtual sequence
 svt_chi_system_single_node_atomiccompare_transaction_virtual_sequence #- This sequence requires one initiating active and participating RN-F.
#- If one or more active and participating RN-F exists, perform cache
initialization to a randomly selected HN.
#- Program the RN to initiate random Atomic Compare transaction from randomly selected RN_F.
.		 --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_combined_write_cmo_base_virtual_sequence This sequence serves as a base sequence for single node Combined write and cmo transactions. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writebackfull_cleaninvalid_virtual_sequence This sequence initiates Writebackfull_CleanInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writebackfull_cleanshared_virtual_sequence This sequence initiates Writebackfull_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writebackfull_cleansharedpersistsep_virtual_sequence This sequence initiates Writebackfull_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writecleanfull_cleanshared_virtual_sequence This sequence initiates Writecleanfull_Cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writecleanfull_cleansharedpersistsep_virtual_sequence This sequence initiates Writecleanfull_Cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpfull_cleaninvalid_virtual_sequence This sequence initiates WriteNoSnpFull_cleaninvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpfull_cleanshared_virtual_sequence This sequence initiates WriteNoSnpFull_cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpfull_cleansharedpersistsep_virtual_sequence This sequence initiates writenosnpfull_cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpptl_cleaninvalid_virtual_sequence This sequence initiates WriteNoSnpptl_cleaninvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpptl_cleanshared_virtual_sequence This sequence initiates WriteNoSnpptl_cleanshared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpptl_cleansharedpersistsep_virtual_sequence This sequence initiates WriteNoSnpptl_cleansharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniquefull_cleanshared_virtual_sequence This sequence initiates WriteUniqueFull_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniquefull_cleansharedpersistsep_virtual_sequence This sequence initiates WriteUniqueFull_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniqueptl_cleanshared_virtual_sequence This sequence initiates WriteUniquePtl_CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniqueptl_cleansharedpersistsep_virtual_sequence This sequence initiates WriteUniquePtl_CleanSharedpersistsep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_stashonceshared_virtual_sequence This sequence initiates StashOnceShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_stashonceunique_virtual_sequence This sequence initiates StashOnceUnique transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_write_followed_by_cmo_virtual_sequence This sequence initiates Write transaction followed by CMO targeting the same address from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. The transactions will be targeted to a random address that is serviced by the target HN specfied with target_hn_node_idx_0. If the target_hn_node_idx_0 is not configured by the user, it will be set to its default value '0'. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpfull_virtual_sequence This sequence initiates WriteNoSnpFull transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpptl_virtual_sequence This sequence initiates WriteNoSnpPtl transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writenosnpzero_virtual_sequence This sequence initiates WriteNoSnpZero transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniquefull_virtual_sequence This sequence initiates WriteUniqueFull transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniquefullstash_virtual_sequence This sequence initiates WriteUniqueFullStash transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniqueptlstash_virtual_sequence This sequence initiates WriteUniquePtlStash transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniqueptl_virtual_sequence This sequence initiates WriteUniquePtl transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_WR_TYPE
* Write type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeuniquezero_virtual_sequence This sequence initiates WriteUniqueZero transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_evict_virtual_sequence This sequence initiates Evict transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each Evict transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writebackfull_virtual_sequence This sequence initiates WriteBackFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteBackFull transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writebackptl_virtual_sequence This sequence initiates WriteBackPlt transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteBackPlt transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writecleanfull_virtual_sequence This sequence initiates WriteCleanFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteCleanFull transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writecleanptl_virtual_sequence This sequence initiates WriteCleanPtl transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteCleanPtl transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeevictfull_virtual_sequence This sequence initiates WriteEvictFull transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteEvictFull transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CPBK_TYPE
* CopyBack type transaction specific single node virtual sequences
 svt_chi_system_single_node_writeevictorevict_virtual_sequence This sequence initiates WriteEvictorEvict transaction from the RN-F node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each WriteEvictorEvict transaction, cachelines of peer node are initialized to random, valid states. This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CMO_TYPE
* CMO type transaction specific single node virtual sequences
 svt_chi_system_single_node_cleaninvalid_virtual_sequence This sequence initiates CleanInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanInvalid transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CMO_TYPE
* CMO type transaction specific single node virtual sequences
 svt_chi_system_single_node_cleanshared_virtual_sequence This sequence initiates CleanShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanShared transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_CMO_TYPE
* CMO type transaction specific single node virtual sequences
 svt_chi_system_single_node_makeinvalid_virtual_sequence This sequence initiates MakeInvalid transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each MakeInvalid transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_DVM_TYPE
* DVM type transaction specific single node virtual sequences
 svt_chi_system_single_node_dvm_virtual_sequence This sequence initiates DVM operations followed by a DVM sync from the RN node specified with node_index, which can be a random node or a specific node configured by the user.The above sequence is repeated for sequence_length. The sequence terminates only when each of the DVM syncs sent out from a port are received from the interconnect. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_BARRIER_TYPE
* BARRIER type transaction specific single node virtual sequences
 chi_rn_barrier_directed_virtual_sequence chi_rn_barrier_directed_virtual_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This class defines a sequence in which pre barrier transactions, followed by barrier transactions, followed by post barrier transactiosn are generated. sequence_length
Parameter that controls the number of transactions that will be generated

CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_BARRIER_TYPE
* BARRIER type transaction specific single node virtual sequences
 svt_chi_system_barrier_sequence svt_chi_system_barrier_sequence The sequence sends number of pre-barrier store transaction, controlled by num_pre_barrier_stores knobe from RN Node followed by ECBARRIER or EOBARRIER transaction. After sending Barrier transaction initiating node send a post barrier store to user controlled address (post_barrier_store_address) with a specific value (post_barrier_store_data).

User can configure the number of nodes that observe (poll) post_barrier_store_address to be updated with post_barrier_store_data. When the observing node find expected data at post_barrier_store_address, mean the post-barrier store transaction has reached the endpoint, which implies all the pre-barrier store must have finish.

As a check the observing nodes initiate load transaction corresponging to all the pre-barrier store transaction, and check for data integrity between the pre-barrier store and post-barrier load.

num_pre_barrier_stores
Description-Unavailable
initiating_node_index
Description-Unavailable
num_observers
Description-Unavailable
barrier_xact
Description-Unavailable
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_SINGLE_RN_ORDERED_NONCOHERENT_TYPE
* Ordered Non-Coherent transaction specific single node virtual sequences
 svt_chi_system_req_order_noncoherent_xact_directed_virtual_sequence svt_chi_system_req_order_noncoherent_xact_directed_virtual_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This sequence generates an Ordered CHI WRITENOSNP followed by an Ordered CHI READNOSNP If the number of request order streams > 1, READs are sent with stream ID 0, while the WRITEs are sent with stream ID 1. Users can configure the number of streams by programming the parameter svt_chi_node_configuration :: num_req_order_streams for the RN. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_D_SINGLE_RN_CMO_TYPE
* CHI-D CMO type transaction specific single node virtual sequences
 svt_chi_system_single_node_cleansharedpersistsep_virtual_sequence This sequence initiates CleanSharedPersistSep transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. Before sending each CleanSharedPersistSep transaction, cachelines of peer node are initialized to random, valid states. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_E_SINGLE_RN_STASH_TYPE
* CHI_E Stash type transaction specific single node virtual sequences
 svt_chi_system_single_node_stashoncesepshared_virtual_sequence This sequence initiates StashOnceSepShared transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_SYS_SINGLE_RN
* Transaction specific single node virtual sequences generates a given transaction type from a single RN agent. All the transaction types are covered, with controllable aspects such as selecting the initiating RN, addressing mode.
CHI_E_SINGLE_RN_STASH_TYPE
* CHI_E Stash type transaction specific single node virtual sequences
 svt_chi_system_single_node_stashoncesepunique_virtual_sequence This sequence initiates StashOnceSepUnique transaction from the RN node specified with node_index, which can be a random node or a specific node configured by the user. --
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_atomic_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Atomic type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate an Atomic Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate an Atomic Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_cmo_type_transaction_directed_sequence Abstract: This class defines a sequence that sends CMO type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • seq_suspend_comp_ack: Control suspend_comp_ack response from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls   a) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a CMO Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_snp_attr_is_snoopable ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a CMO Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_copyback_type_transaction_directed_sequence Abstract: This class defines a sequence that sends CopyBack type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_suspend_wr_data: Control suspend_wr_data response from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) seq_copyback_req_order_enable:

  • '0'  // Do Not Enable Ordering
  • '1'  // Enable Ordering

  c) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a CopyBack Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a CopyBack Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_e_rn_writesoptionaldata_type_transaction_directed_sequence Abstract: This class defines a sequence that sends WRITEEVICTOREVICT CopyBack type transaction. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_suspend_wr_data: Control to suspend_wr_data response from sequences is supported for these transactions.
  • seq_suspend_comp_ack: Control suspend_comp_ack response from sequences is supported for these transactions.
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) seq_copyback_req_order_enable:

  • '0'  // Do Not Enable Ordering
  • '1'  // Enable Ordering
  c) use_seq_is_non_secure_access:
  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a WRITEEVICTOREVICT CopyBack Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a WRITEEVICTOREVICT CopyBack Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


--
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_makereadunique_type_transaction_directed_sequence Abstract: This class defines a sequence that sends MakeReadUnique type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) by_pass_read_data_check:

  • '0'  // Perform Read Data Integrity Check
  • '1'  // Bypass Read Data Integrity Check

  c) use_seq_req_tag_op (Applicable when Memory Tagging is enabled):

  • '0'  // Do Not consider seq_req_tag_op for MakeReadUnique transaction TagOp value
  • '1'  // Consider seq_req_tag_op for MakeReadUnique transaction TagOp value
  d) use_seq_is_non_secure_access:
  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a MakeReadUnique Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a MakeReadUnique Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:

[4] When Memory Tagging is enabled, based on the prior transactions targeting a specific cache line, Request TagOp field in MakeReadUnique Transaction can be controlled by setting use_seq_req_tag_op to 1 and programming seq_req_tag_op field appropriately:

  • use_seq_req_tag_op ----> To be set to 1
  • seq_req_tag_op ----> program appropriately based on the prior executed transaction

sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_makeunique_cache_initialization_directed_sequence Abstract: Sends MAKEUNIQUE transactions from an RN Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • seq_suspend_comp_ack: Control Suspend CompAck bit of the transaction
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls   a) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a MakeUnique Cache Initialization Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

[3] To generate a MakeUnique Cache Initialization Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:

  If there is requirement to generate unique address, then additionaly below sequence's property to programmed as per below:
  • set_unique_addr_value == 1

sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_prefetchtgt_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Prefetchtgt type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] To generate a PrefetchTgt Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

[2] To generate a PrefetchTgt Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


[3] To generate a PrefetchTgt Transaction targeting with respect to prior Write/Read Transaction's Address, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_read_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Read type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • seq_suspend_wr_data: Control suspend_wr_data response from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) by_pass_read_data_check:

  • '0'  // Perform Read Data Integrity Check
  • '1'  // Bypass Read Data Integrity Check

  c) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a CHI RN Read Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a CHI RN Read Transaction targeting a specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DIRECTED
* Directed sequences for RN transaction
 svt_chi_rn_write_type_transaction_directed_sequence Abstract: This class defines a sequence that sends Write type transactions. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • seq_suspend_wr_data: Control suspend_wr_data response from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_order_type:

  b) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate a CHI RN Write Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction


[3] To generate a CHI RN Write Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Parameter that controls the number of transactions that will be generated

CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_COHERENT
* Coherent sequences for RN transaction
 svt_chi_rn_coherent_transaction_base_sequence svt_chi_rn_coherent_transaction_base_sequence start_addr
defines start address of the supported address range of current RN

end_addr
defines end address of the supported address range of current RN

seq_order_type
defines the order_type field that is to be set in the transactions generated by this sequence
seq_data_size
defines the data_size field that is to be set in the transactions generated by this sequence This is applicable only when use_seq_data_size is set to 1. It is required to ensure that this is constrained from test such that data_size is valid for the given transaction type.

seq_p_crd_return_on_retry_ack
Indicates the p_crd_return_on_retry_ack of the transactions generated by this sequence
use_directed_addr
Indicates that the addresses provided in directed_addr_mailbox should be used for the transactions generated by this sequence
generate_unique_txn_id
Indicates whether unique txn_id should be generated for each transaction.
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DVM
* DVM sequences for RN transaction
 svt_chi_rn_transaction_dvm_sync_sequence svt_chi_rn_transaction_dvm_sync_sequence

This sequence will use svt_chi_rn_transaction_dvm_write_semantic_sequence to generate a random number of DVMOP write semantic transcations followed by a DVMOP sync.

 dvm_lpid_pattern
Description-Unavailable
dvm_lpid
Description-Unavailable
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_DVM
* DVM sequences for RN transaction
 svt_chi_rn_transaction_dvm_write_semantic_sequence svt_chi_rn_transaction_dvm_write_semantic_sequence

This sequence creates a random DVM write semantic request with control over the dvm_message_type field. User can control the number of DVMOP write semantic transcations to generate by constraining the dvm_write_semantic_length field from the test.

 --
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_BARRIER
* BARRIER sequences for RN transaction
 svt_chi_rn_ecbarrier_sequence RN transaction ECBARRIER sequence --
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_BARRIER
* BARRIER sequences for RN transaction
 svt_chi_rn_eobarrier_sequence RN transaction EOBARRIER sequence --
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_ORDERING
* ORDERING sequences for RN transaction
 svt_chi_rn_go_noncoherent_sequence RN transaction non-coherent transaction type sequence that exercises global observability for pre-barrier transactions --
CHI_RN
* CHI RN transaction sequences generate various types of CHI RN transactions (Reads, Writes, DVM, Atomics, CMOs, Exclusive access pairs), with configurable aspects such as targeting a specific address range, targeting a home node. These sequences are also invoked by various system level virtual sequences. These sequences need to be executed on RN agent transaction sequencer.
CHI_RN_EXCLUSIVE
* Exclusive sequences for RN transaction
 svt_chi_rn_exclusive_access_sequence Abstract: This class defines a sequence for exclusive access support. Execution phase: main_phase Sequencer: RN agent sequencer

This sequence also provides the following attributes which can be controlled through config DB:

  • sequence_length: Length of the sequence
  • seq_exp_comp_ack: Control Expect CompAck bit of the transaction from sequences
  • enable_outstanding: Control outstanding transactions from sequences


Usage Guidance::
======================================================================
[1] General Controls
  a) seq_xact_type_excl:

  b) seq_order_type:

  c) by_pass_read_data_check:

  • '0'  // Perform Read Data Integrity Check
  • '1'  // Bypass Read Data Integrity Check

  d) use_seq_is_non_secure_access:

  • '0'  // Do Not consider seq_is_non_secure_access attribute/i>
  • '1'  // Consider seq_is_non_secure_access attribute for transaction physical address spaces


[2] To generate Exclusive Transaction targeting specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

  If there are any prior transactions targeting a specific cache line, ensure subsequent transactions have same attributes wherever required

  • min_addr ----> Address of prior executed transaction
  • max_addr ----> Address of prior executed transaction
  • seq_snp_attr_snp_domain_type ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_is_non_secure_access ----> Same property value from prior executed transaction

  For NON-COHERENT Exclusive, the Load-Store pair MUST have same control signals that is memory and snoop attributes

  • seq_mem_attr_is_early_wr_ack_allowed ----> Same property value from prior executed transaction
  • seq_mem_attr_mem_type ----> Same property value from prior executed transaction
  • seq_mem_attr_is_cacheable ----> Same property value from prior executed transaction
  • seq_mem_attr_allocate_hint ----> Same property value from prior executed transaction
  • seq_snp_attr_is_snoopable ----> Same property value from prior executed transaction

[3] To generate Exclusive Transaction targeting specific HN Node, the below sequence's properties MUST be programmed:


[4] Based on communication nodes, below sequence's properties MUST be programmed:
  For RN-F Node and COHERENT Transaction
  a) For any CHI ISSUE version:

  b) Additional Constraint for CHI ISSUE 'A':

  c) Additional Constraint for CHI ISSUE 'D' or Lower:

  For RN-F Node and NON-COHERENT Transaction

  For RN-I or RN-D Node


seq_xact_type_excl
Description-Unavailable
sequence_length
Parameter that controls the number of transactions that will be generated

byte_enable
Defines the byte enable

data_in_cache
Stores the data written in Cache

seq_mem_attr_is_early_wr_ack_allowed
This field defines the 'Early Write Acknowldege' field for the transaction.
  • Value of 1 indicates that Early Write Acknowledge is allowed
  • Value of 0 indicates that Early Write Acknowledge is disallowed

seq_mem_attr_mem_type
This field indictes the memory type associated with the transaction.

seq_mem_attr_is_cacheable
This field defines the cacheable field of transaction.
When set, it indicates a cacheable transaction for which the system cache, when present, must be looked up in servicing this transaction.
seq_mem_attr_allocate_hint
This field defines Allocate hint for the transaction.
When set, it indicates that the transaction may allocate in the system cache, when present.
seq_snp_attr_is_snoopable
This field defines if the transaction is snoopable or non-snoopable.

seq_snp_attr_snp_domain_type
This field defines the snoop domain of the transaction.

seq_is_non_secure_access
This field defines the is non secure attribute of the transaction.

use_seq_is_non_secure_access
This field determines if seq_is_non_secure_access is used to constrain transaction's is_non_secure_access field

seq_lpid
lpid

seq_data_size
data_size

by_pass_read_data_check
Flag used to bypass read data check

seq_order_type
Order type for transaction is no_ordering_required

seq_xact_type_read
Parameter that controls the type of transaction that will be generated

seq_xact_type_write
Description-Unavailable
CHI_RN_BASE
* Base sequences for RN transaction sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended RN transaction sequences. In general, users are not expected to use these base sequences directly.
CHI_RN_BASE_RDM
* Base sequence for all CHI RN transaction sequences
 svt_chi_rn_transaction_random_sequence svt_chi_rn_transaction_random_sequence

This sequence creates a random svt_chi_rn_transaction request.

 sequence_length
Controls the number of random transactions that will be generated

is_sni_interface
Controls whether the generated transactions are only for SN node

CHI_RN_BASE
* Base sequences for RN transaction sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended RN transaction sequences. In general, users are not expected to use these base sequences directly.
CHI_RN_BASE_RDM
* Base sequence for all CHI RN transaction sequences
 svt_chi_rn_transaction_xact_type_sequence svt_chi_rn_transaction_xact_type_sequence

This sequence creates a random svt_chi_rn_transaction request with control over the xact_type field.

 xact_type
Controls the transaction type of the generated transactions

CHI_RN_BASE
* Base sequences for RN transaction sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended RN transaction sequences. In general, users are not expected to use these base sequences directly.
-- svt_chi_rn_transaction_base_sequence svt_chi_rn_transaction_base_sequence: This is the base class for svt_chi_rn_transaction sequences. All other svt_chi_rn_transaction sequences are extended from this sequence.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.


Usage Guidance::
======================================================================
[1] To generate a CHI RN Transaction targeting a specific address range, the below sequence's properties MUST be programmed:

  In case of targeting a specific address, min_addr and max_addr must be programmed to same value

[2] To generate a CHI RN Transaction targeting a specific HN Node, the below sequence's properties MUST be programmed:


sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

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:
  • This sequence generates Coherency Exit service requests.
  • Number of Coherency Exit service requests to be generated will be inferred from the attribute sequence_length which can be set to zero or greater than zero.
  • sequence_length set to zero causes the sequence to run throughout the simulation.
  • This sequence does not raise and drop objections, so will not block simulation exit directly.
  • Delay attributes to control the number of clock cycles before sequence initiates subsequent coherency exit service request from the sequence, which can be set through config DB:
    • Minimum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_min_delay.
    • Maximum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_max_delay.
  • The above mentioned attributes (sequence_length, coherency_exit_svc_req_min_delay, coherency_exit_svc_req_min_delay) can be set through config DB.
  • Functionality: (following steps will be in a loop of sequence_length or forever loop if sequence_length is set to 0)
    • Wait for coherency state to be COHERENCY_ENABLED_STATE
      • Note that entry to coherency enabled state is expected to happen due to master transaction sequencer sending a cacheable transaction to driver, which causes the driver to initiate Coherency entry.
    • Apply random delay between the programmed min and max delays
    • Initiate Coherency Exit service request
  • This sequence will run on the svt_axi_service_sequencer.
  • Default Values: (Note: Required values can be programmed through config DB)
    • sequence_length set to value between 1 and 10 upon randomization
    • coherency_exit_svc_req_min_delay set to 1000
    • coherency_exit_svc_req_max_delay set to 2000
--
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.

 sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

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.

 sequence_length
Controls the number of random transactions that will be generated

CHI_SYS_EXCLUSIVE_ACCESS
* Exclusive access feature virtual sequences generate scenarios from RN agents to verify various Exclusive Access requirements of a home node within interconnect.
-- svt_chi_system_protocol_flow_ctrl_exclusive_access_virtual_sequence Abstract:
This sequence generates traffic to test the exclusive access feature support.
#- Program a randomly selected RN1 to send an exclusive load type transaction
with an LPID followed by an exclusive store transaction with the same LPID and address
set to same value as that of exclusive load transaction.
#- Optionally program to send MAKEUNIQUE transaction targeted to
randomly selected RN with address of randomly selected first HN Node. #- Optionally program a randomly selected RN2 to intervene the exclusive sequence from RN1.
#- Supports both coherent and non coherent transactions.
.		 target_hn_i_node_index_0
Represents the HN-I node to which the transaction will be sent

CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_combined_write_cmo_hazard_base_sequence Abstract: svt_chi_e_protocol_flow_ctrl_combined_write_cmo_hazard_base_sequence acts as a base sequence for various combined_write_cmo hazard sequences. --
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_noncopyback_write_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_noncopyback_write_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent copyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent copyback combined write CMO type of transaction to the same address from RN 3. Send noncopyback write transaction to same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_read_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_read_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent copyback write CMO transaction to the address from an RN 3. Send READ type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_standalone_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_copyback_write_cmo_with_standalone_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent copyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent copyback write CMO transaction to the address from an RN 3. Send standalone CMO type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions between noncopyback combined write cmo transaction and standalone noncopyback writes or combined write cmo transaction 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent noncopyback combined write CMO type of transaction to the same address RN 3. Send standalone noncopyback transaction or noncopyback combined write cmo transaction to same address to from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_copyback_write_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_copyback_write_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo and copyback write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send coherent noncopyback combined write CMO type of transaction to the same address from RN $ 3. Send copyback write transaction to same address from different RN. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_read_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_read_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent noncopyback write CMO transaction to the address from an RN 3. Send READ type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_standalone_cmo_hazard_sequence Abstract: svt_chi_e_protocol_flow_ctrl_hn_combined_coherent_noncopyback_write_cmo_with_standalone_cmo_hazard_sequence provides a sequence to test how components handle various hazard conditions applicable for coherent noncopyback combined write cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send Combined coherent noncopyback write CMO transaction to the address from an RN 3. Send standalone CMO type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_invalidating_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_invalidating_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for WRITEEVICTOREVICT and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send WRITEBACKFULL transaction to the same address from same RN 3. Send READCLEAN transaction to the same address from different RN so that initial Cache state will move to either UC/SC 4. Below 2 transactions are initiated parallelly from different RN-F nodes. #- Send CLEANINVALID/MAKEINVALID type of transaction to the same address from different RN #- Send WRITEEVICTOREVICT type of transaction to the same address from the same RN from which READCLEAN transaction is initiated. . 5. Check the order in which the two requests are processed by HN. .

This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.

 sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_noninvalidating_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_e_system_protocol_flow_ctrl_hn_writesoptionaldata_noninvalidating_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for WRITEEVICTOREVICT and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send WRITEBACKFULL transaction to the same address from same RN 3. Send READCLEAN transaction to the same address from different RN so that initial Cache state will move to either UC/SC 4. Below 2 transactions are initiated parallelly from different RN-F nodes. #- Send READCLEAN transaction to the same address from different RN #- Send WRITEEVICTOREVICT type of transaction to the same address from the same RN from which READCLEAN transaction is initiated. . 5. Check the order in which the two requests are processed by HN. .

This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.

 sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_atomic_atomic_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_atomic_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transactions to the above same address from two different RN's. 3. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_atomic_cmo_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_cmo_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and cmo transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send cmo type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_atomic_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and copyback transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN 2. Send atomic type of transaction to the same address from different RN. 3. Send Copyback type of transaction to the same address from same RN from which the MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_atomic_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and read transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send read type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_atomic_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_atomic_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for atomic and write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send atomic type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_cmo_cmo_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_cmo_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO transactions 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send different types of cmo transactions to the same address from RN0 and RN1. 3. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_cmo_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send CMO type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_cmo_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO and read transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN to the random address. 2. Send cmo type of transaction to the same address from different RN 3. Send read type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_cmo_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_cmo_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for CMO and write transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN to the random address. 2. Send cmo type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_copyback_snoop_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_copyback_snoop_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_makereadunique_copyback_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for copyback and makereadunique transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- Send READSHARED transaction to the same address from differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send WRITEEVICTFULL Copyback transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_makereadunique_read_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for read and write transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send Read type of transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_makereadunique_write_hazard_directed_virtual_sequence #- This sequence provides a scenario to test how components handle various hazard conditions applicable for read and write transactions.
#- Send MAKEUNIQUE transaction to random address from random RN.
#- Send WRITEBACKFULL transaction to the same address from same RN.
#- Send READSHARED transaction to the same address from same or differnet RN so the cacheline state is moved to SC state.
#- After the cache initialization we can program the RN's to initiate the hazard transactions accordingly.
#- Send MAKEREADUNIQUE type of transaction to the same address from the RN having the cachelinestate in SC state.
#- Send Write type of transaction to the same address from a different RN.
#- Check the order in which the two requests are processed by HN.
#- This sequence requires SVT_CHI_ISSUE_E_ENABLE macro to be defined and svt_chi_node_configuration :: chi_spec_revision is set to svt_chi_node_configuration :: ISSUE_E or later.
.		 sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_makeunique_makeunique_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_makeunique_makeunique_hazard_directed_virtual_sequence provides a sequence to test the ability of components to handle hazard conditions: 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send a MAKEUNIQUE transaction from both RN0 and RN1 to the same address. The interconnect should sequence these transactions correctly 3. Check the order in which the two requests are processed by HN. 4. If sequenced correctly, both RNs should not be in UD state; only one RN should be in UD state. This is checked in the sequence. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_read_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for copyback and snoop transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send copyback type of transaction to the same address from the same RN from which MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_read_read_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_read_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transactions to the above same address from two different RN's. 3. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_read_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_read_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read and write transactions 1. Send MAKEUNIQUE transaction to random address from random RN 2. Send read type of transaction to the same address from different RN 3. Send write type of transaction to the same address from different RN 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_write_copyback_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_write_copyback_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for write and copyback transactions 1. Initialize the cacheline using MAKEUNIQUE transaction from RN 2. Send write type of transaction to the same address from different RN. 3. Send Copyback type of transaction to the same address from same RN from which the MAKEUNIQUE transaction initiated. 4. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_HAZARD
* Hazard feature virtual sequences generate various address hazard scenarios from RN agents to verify related hazard resolution aspects of a home node within the interconnect.
-- svt_chi_system_protocol_flow_ctrl_hn_write_write_hazard_directed_virtual_sequence Abstract: svt_chi_system_protocol_flow_ctrl_hn_write_write_hazard_directed_virtual_sequence provides a sequence to test how components handle various hazard conditions applicable for read transactions 1. Initialize the cacheline using MAKEUNIQUE followed by WRITEBACKFULL transaction from RN to the random address. 2. Send different types of write transactions to the same address from different RN's. 3. Check the order in which the two requests are processed by HN. . sequence_length
Parameter that controls the number of transactions that will be generated

enable_outstanding
Description-Unavailable
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_base_virtual_sequence This sequence creates a reporter reference.
This sequence setups up configuraion awareness related infrastructure to the derived sequences.
This sequence also provides the following attributes which can be controlled through config DB:
  • sequence_length: Length of the sequence
  • silent: Control the messages from sequences
--
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_protocol_flow_ctrl_xact_hazard_virtual_sequence This sequence allows to initiate transactions to achieve hazard sceanrios. This sequence cannot be used directly, however, the derived sequences need to be used. --
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_rn_coherent_transaction_base_virtual_sequence This is the base sequence for: --
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_cacheline_initialization_virtual_sequence This sequence initializes the cache line of all masters.
  • The rn_xact for which cache is to be initialized must be input to this sequence.
  • The sequence checks if the cache line is already one of the spec permitted states for the rn_xact type. If legal, nothing is done by this sequence. If not legal, then the next steps are performed.
  • invalidate_all_cachelines: send makeunique from initiating RN-F; send invalidate xact (writeback if current state is dirty, evict if current state is clean)
  • get_random_initial_cachestate: get the random legal initial cacheline state for the xact type. Based on this, the next steps are performed.
    • If get_random_initial_cachestate returns 'Invalid' state: send readshared from the peer RN-Fs.).
    • If get_random_initial_cachestate returns a Unique state: send makeunique from initiating RN-F.
    • If get_random_initial_cachestate returns a Shared state: send makeunique from initiating RN-F; send readshared from the peer RN-Fs; If the initiating rn-f cacheline state is not valid, send makeunique from initiating RN-F. If bypass_silent_cache_line_state_transition is set to 0: update status of cacheline silently to shared.
  • If clean cache line is required for the coherent xact, send writeclean xact from the initiating RN-F.
--
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_cacheline_invalidation_virtual_sequence This sequence invalidates the cache line of a RN F node. It checks the state of the cache line and initiaties the appropriate transaction If the cacheline state is dirty, a WRITEBACK is initiated. If the cacheline state is clean, an EVICT is initiated. --
CHI_SYS_BASE
* Base system virtual sequences have infrastructure, configurable aspects, utilities that are required for the extended system virtual sequences, as well as some of the RN transaction sequences. In general, users are not expected to use these base sequences directly. This grouping include cache initialization and invalidation virtual sequences as well.
 -- svt_chi_system_single_node_rn_atomic_transaction_base_virtual_sequence This sequence setups the basic attributes and methods which are used by the derived sequences to initiate atomic tranasctions.
 atomic_xact_type
Description-Unavailable
selected_atomic_xact_type
Description-Unavailable
CHI_LINK_SVC
* CHI Link service transaction sequences are executed on agent's Link service sequencer. These sequences generate service requests to Link layer driver to exercise Link activation, deactivation scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_link_service_activate_sequence svt_chi_link_service_active_sequence

This sequence creates an activate svt_chi_link_service request.

 --
CHI_LINK_SVC
* CHI Link service transaction sequences are executed on agent's Link service sequencer. These sequences generate service requests to Link layer driver to exercise Link activation, deactivation scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_link_service_deactivate_sequence svt_chi_link_service_deactivate_sequence

This sequence creates a deactivate svt_chi_link_service request.

 min_cycles_in_deactive
Controls the number of cycles that the sequence will be in the deactive state

CHI_LINK_SVC
* CHI Link service transaction sequences are executed on agent's Link service sequencer. These sequences generate service requests to Link layer driver to exercise Link activation, deactivation scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_link_service_random_sequence svt_chi_link_service_random_sequence

This sequence creates a random svt_chi_link_service request.

 --
CHI_LINK_SVC_BASE
* Base sequences for CHI link service transaction sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended Link service sequences. In general, users are not expected to use these base sequences directly.
-- svt_chi_link_service_base_sequence svt_chi_link_service_base_sequence: CHI Link Service Base sequences Base sequences have infrastructure, configurable aspects, utilities that are required for the extended Link service sequences. In general, users are not expected to use these base sequences directly.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.

 sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

CHI_PROTOCOL_SERVICE
* CHI Protocol service sequences are executed on agent's Protocol service sequencer. These sequences generate service requests to Protocol layer driver to exercise System Coherency entry & exit scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_protocol_service_coherency_entry_sequence svt_chi_protocol_service_coherency_entry_sequence This sequence creates a coherency_entry svt_chi_protocol_service request. --
CHI_PROTOCOL_SERVICE
* CHI Protocol service sequences are executed on agent's Protocol service sequencer. These sequences generate service requests to Protocol layer driver to exercise System Coherency entry & exit scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_protocol_service_coherency_exit_sequence svt_chi_protocol_service_coherency_exit_sequence This sequence creates a coherency_exit svt_chi_protocol_service request. --
CHI_PROTOCOL_SERVICE
* CHI Protocol service sequences are executed on agent's Protocol service sequencer. These sequences generate service requests to Protocol layer driver to exercise System Coherency entry & exit scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_protocol_service_random_coherency_exit_sequence svt_chi_protocol_service_random_coherency_exit_sequence:
  • This sequence generates Coherency Exit service requests.
  • Number of Coherency Exit service requests to be generated will be inferred from the attribute sequence_length which can be set to zero or greater than zero.
  • sequence_length set to zero causes the sequence to run throughout the simulation.
  • This sequence does not raise and drop objections, so will not block simulation exit directly.
  • Delay attributes to control the number of clock cycles before sequence initiates subsequent coherency exit service request from the sequence, which can be set through config DB:
    • Minimum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_min_delay.
    • Maximum delay in clock cycles to initiate a Coherency Exit request from the point where the Sysco interface enters COHERENCY_ENABLED_STATE is inferred from the attribute coherency_exit_svc_req_max_delay.
  • The above mentioned attributes (sequence_length, coherency_exit_svc_req_min_delay, coherency_exit_svc_req_min_delay) can be set through config DB.
  • Functionality: (following steps will be in a loop of sequence_length or forever loop if sequence_length is set to 0)
    • Wait for coherency state to be COHERENCY_ENABLED_STATE
      • Note that entry to coherency enabled state is expected to happen due to RN transaction sequencer sending a cacheable transaction to RN protocol driver, which causes the driver to initiate Coherency entry.
    • Apply random delay between the programmed min and max delays
    • Initiate Coherency Exit service request
  • This sequence will run on the svt_chi_protocol_service_sequencer.
  • Default Values: (Note: Required values can be programmed through config DB)
    • sequence_length set to value between 1 and 10 upon randomization
    • coherency_exit_svc_req_min_delay set to 1000
    • coherency_exit_svc_req_max_delay set to 2000
--
CHI_PROTOCOL_SERVICE
* CHI Protocol service sequences are executed on agent's Protocol service sequencer. These sequences generate service requests to Protocol layer driver to exercise System Coherency entry & exit scenarios, to verify related aspects of the link partner DUT.
 -- svt_chi_protocol_service_random_sequence svt_chi_protocol_service_random_sequence

This sequence creates a random svt_chi_protocol_service request.

 sequence_length
Controls the number of random transactions that will be generated

CHI_PROTOCOL_SERVICE_BASE
* Base sequences for CHI protocol service transaction sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended Protocol service sequences. In general, users are not expected to use these base sequences directly.
-- svt_chi_protocol_service_base_sequence svt_chi_protocol_service_base_sequence: This is the base class for svt_chi_protocol_service based sequences. All other svt_chi_protocol_service sequences are extended from this sequence.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.

 sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_read_data_interleave_response_sequence Class svt_chi_ic_sn_read_data_interleave_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
The test that is registering this sequence is expected to configure the CHI ICN FS VIP appropriately to exercise read data interlaving feature.
The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the received read transactions, and enables the interleaving of read data for those transactions. Once required number of transactions are suspended, the sequence resumes these transactions by resetting suspend_response field. The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env. The CHI ICN FS VIP driver applies the interleaving of the read transactions accordingly.		 --
CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_reordering_response_sequence Class svt_chi_ic_sn_reordering_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.
The test that is registering this sequence is expected to configure the CHI ICN FS VIP appropriately to exercise the reordering feature.
The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the received transactions. Once required number of transactiosn are suspended, the sequence resumes these transactions by resetting suspend_response field. The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env. The CHI ICN FS VIP driver applies the reordering of the transaction responses accordingly.		 --
CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_suspend_response_resume_after_delay_sequence Class svt_chi_ic_sn_suspend_response_resume_after_delay_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.

The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the very first request recieved and resumes it back by resetting suspend_response field after certain number of clock cycle delays. . The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env.

--
CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_suspend_response_sequence Class svt_chi_ic_sn_suspend_response_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.

The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the very first request recieved and resumes it back by resetting suspend_response field after certain number of clock cycle delays. . The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env.

--
CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_dvm_outstanding_suspend_response_resume_after_delay_sequence Class svt_chi_ic_sn_suspend_response_resume_after_delay_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.

The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. It suspends the response of the very first request recieved and resumes it back by resetting suspend_response field after certain number of clock cycle delays. . The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env.

--
CHI_IC_SN_MEM
* CHI IC SN transaction memory response sequences set up the ICN Full Subordinate (ICN FS) VIP transaction response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to ICN FS VIP memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on IC SN transaction sequencer.
 -- svt_chi_ic_sn_transaction_memory_sequence Class svt_chi_ic_sn_transaction_memory_sequence defines a reactive sequence that will be used by the CHI ICN FS VIP Driver and IC SN XACT sequencer.

The sequence receives a response request of type svt_chi_ic_sn_transaction from the IC SN xact sequencer. . The updated transaction is provided to the CHI Interconnect driver within the CHI Interconnect env.

--
CHI_IC_SN_BASE
* Base sequences for CHI IC SN transaction response sequences, relevant only for Interconnect Full Subordinate(ICN FS) VIP component. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended IC SN transaction response sequences. In general, users are not expected to use these base sequences directly.
-- svt_chi_ic_sn_transaction_base_sequence svt_chi_ic_sn_transaction_base_sequence: This is the base class for svt_chi_ic_sn_transaction sequences. All other svt_chi_ic_sn_transaction sequences are extended from this sequence. svt_chi_ic_sn_transaction sequences will be used by CHI ICN FS VIP driver, CHI IC SN XACT sequencer.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.

 --
CHI_SN_MEM
* CHI SN transaction memory response sequences set up the SN response related attributes (delays, flows etc.), by referring to the dependent aspects such as reading from and write to SN memory contents (data, tags, poison etc.), agent status. These sequences need to be executed on SN transaction sequencer.
 -- svt_chi_sn_transaction_memory_sequence Class svt_chi_sn_transaction_memory_sequence defines a reactive sequence that a testbench may use to make use of CHI memory within the CHI SN agent.

The sequence receives a response request of type svt_chi_sn_transaction from the SN sequencer. It then:

  • updates the response fields
  • In case of WriteNoSnp*, updates the SN memory with data in the transaction
  • IN case of ReadNoSnp, updates the data in the transaction with the data in SN memory
The updated transaction is provided to the SN protocol layer driver within the SN agent. IN case of WriteNoSnp*, the data is updated into the memory only when the transaction is complete successfully without any errors.		 --
CHI_SN_NULL
* Null sequence for SN transaction, that does not process and send any transaction
 -- svt_chi_sn_transaction_null_sequence svt_chi_sn_transaction_null_sequence

This class creates a null sequence which can be associated with a sequencer but generates no traffic.

 --
CHI_IC_SNP
* CHI IC Snoop transaction sequences generate various types of CHI IC Snoop transactions (including Stash, Fwd, DVM snoops), with configurable aspects such as addressing mode.
 -- svt_chi_ic_dvm_snoop_transaction_random_sequence Class svt_chi_ic_dvm_snoop_transaction_random_sequence defines a snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.

The sequence generates a DVM request of type svt_chi_ic_snoop_transaction from the IC SNOOP xact sequencer within interconnect env.

 sequence_length
Parameter that controls the number of transactions that will be generated

CHI_IC_SNP
* CHI IC Snoop transaction sequences generate various types of CHI IC Snoop transactions (including Stash, Fwd, DVM snoops), with configurable aspects such as addressing mode.
 -- svt_chi_ic_snoop_transaction_directed_sequence Class svt_chi_ic_snoop_transaction_directed_sequence defines a directed snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.

The sequence generates a request of type svt_chi_ic_snoop_transaction from the IC SNOOP xact sequencer within interconnect env.

 snp_addr_mode
Snoop address mode

base_addr
Base address: used as it is for FIXED mode, used as base for INCR mode

snp_txn_id_pattern
Snoop txn_id pattern

base_txn_id
Base txn_id: used as it is for FIXED pattern, used as base for INCR pattern

sequence_length
Parameter that controls the number of transactions that will be generated

CHI_IC_SNP
* CHI IC Snoop transaction sequences generate various types of CHI IC Snoop transactions (including Stash, Fwd, DVM snoops), with configurable aspects such as addressing mode.
 -- svt_chi_ic_snoop_transaction_random_sequence Class svt_chi_ic_snoop_transaction_random_sequence defines a snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.

The sequence generates a request of type svt_chi_ic_snoop_transaction from the IC SNOOP xact sequencer within interconnect env.

 sequence_length
Parameter that controls the number of transactions that will be generated

CHI_IC_SNP
* CHI IC Snoop transaction sequences generate various types of CHI IC Snoop transactions (including Stash, Fwd, DVM snoops), with configurable aspects such as addressing mode.
 -- svt_chi_ic_stash_snoop_transaction_directed_sequence Class svt_chi_ic_stash_snoop_transaction_directed_sequence defines a directed stash snoop sequence that will be used by the CHI ICN VIP Driver and IC SNOOP XACT sequencer.

The sequence generates a request of type svt_chi_ic_snoop_transaction from the IC SNOOP xact sequencer within interconnect env.

 sequence_length
Parameter that controls the number of transactions that will be generated

CHI_IC_SNP_BASE
* Base sequences for CHI IC Snoop transaction sequences, relevant only for Interconnect Full Subordinate(ICN FS) VIP component. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended IC Snoop transaction sequences. In general, users are not expected to use these base sequences directly.
-- svt_chi_ic_snoop_transaction_base_sequence svt_chi_ic_snoop_transaction_base_sequence: This is the base class for svt_chi_ic_snoop_transaction sequences. All other svt_chi_ic_snoop_transaction sequences are extended from this sequence. svt_chi_ic_snoop_transaction sequences will be used by CHI ICN VIP component. CHI IC SN Snoop xact sequencer and the Interconnect driver will be using it.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.

 --
CHI_SNP
* CHI Snoop transaction response sequences set up the delays and snoop response related attributes, by referring to the other dependent aspects such as cache state and contents (data, tags, poison etc.), agent status. These sequences need to be executed on RN agent snoop transaction sequencer.
 -- svt_chi_rn_directed_snoop_response_sequence Abstract:
Class svt_chi_rn_directed_snoop_response_sequence defines a sequence class that the testbench uses to provide snoop response to the RN agent present in the System agent.
The sequence receives a response object of type svt_chi_rn_snoop_transaction from RN snoop sequencer. The sequence class then sets up the snoop response attributes and provides it to the RN driver within the RN agent.
Execution phase: main_phase
Sequencer: RN agent snoop sequencer

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

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

datatransfer Data includes
0 no
1 yes

passdirty PD
0 no
1 yes

isshared final_state
0 I
1 anything other than I

Following are the attributes of the snoop resonse that are set accordingly, based on the Snp Request type:

Wherever there are more than one possible values for setting of these response attributes, the response attribute values are set randomly.

 --
CHI_SNP
* CHI Snoop transaction response sequences set up the delays and snoop response related attributes, by referring to the other dependent aspects such as cache state and contents (data, tags, poison etc.), agent status. These sequences need to be executed on RN agent snoop transaction sequencer.
 -- svt_chi_rn_snoop_response_sequence svt_chi_rn_snoop_response_sequence:
  • Provide a coherent response based on the local cache in the RN instance.
  • This is the default snoop response sequence registered by active RN agent.
  • Class svt_chi_rn_snoop_response_sequence defines a sequence class that the testbench uses to provide snoop response to the RN agent present in the System agent.
  • Execution phase: main_phase
  • Sequencer: RN agent snoop sequencer
  • The basis for setting up the snoop response based on snoop request type is as per ARM-IHI0050A 5.0: 4.7.5 Table 4-11
  • Following are the attributes of the snoop resonse that are set accordingly, based on the Snp Request type: ARM-IHI0050A 5.0: 4.7.5 Table 4-11

snp_rsp_datatransfer Data includes
0 no
1 yes

resp_pass_dirty PD
0 no
1 yes

snp_rsp_isshared final_state
0 I
1 anything other than I

Wherever there are more than one possible values for setting of these response attributes, the response attribute values are set randomly.

 --
CHI_SNP_BASE
* Base sequences for CHI Snoop transaction response sequences. Base sequences have infrastructure, configurable aspects, utilities that are required for the extended snoop transaction response sequences. In general, users are not expected to use these base sequences directly.
 -- svt_chi_snoop_transaction_base_sequence svt_chi_snoop_transaction_base_sequence: This is the base class for svt_chi_snoop_transaction sequences. All other svt_chi_snoop_transaction sequences are extended from this sequence.

The base sequence takes care of managing objections if extended classes or sequence clients set the manage_objection bit to 1.

 --
CHI_RN_NULL
* Null sequence for RN transaction, that does not generate any transactions
 -- svt_chi_rn_transaction_null_sequence svt_chi_rn_transaction_null_sequence

This class creates a null sequence which can be associated with a sequencer but generates no traffic.

 --
default -- svt_ahb_master_transaction_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other svt_ahb_master sequences in the collection extend from this base sequence. sequence_length
Number of Transactions in a sequence.

seq_xact_type
Parameter that controls the type of transaction that will be generated

seq_burst_type
Parameter that controls the burst_type of transaction that will be generated

seq_lock
Parameter that controls lock bit of the transaction

seq_num_busy_cycles
Parameter that controls the num_busy_cycles of the transaction

seq_wait_for_xact_ended
Parameter that controls waiting of transaction to end

slv_num
Slave number used to constrain it

default -- svt_ahb_master_transaction_alternate_write_read_sequence This sequence generates alternate write and read transaction. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_busy_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions with busy cycles inserted for every beat of the burst. All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_distributed_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions with distribution on the following fields:

Number of busy cycles lock or normal transfer length of undefined length incrementing burst

All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction.

 sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_fixed_len_write_read_hsize_sequence This sequence generates alternate write and read transaction including: SINGLE and fixed length Burst types Transfer sizes including BYTE,HALF-WORD,FULL-WORD types The remaining transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_idle_sequence This sequence generates a sequence of idle transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_locked_write_read_sequence This sequence performs the following: A LOCKED WRITE transaction A NORMAL READ transaction A NORMAL WRITE transaction A LOCKED READ transaction The remaining transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_no_idle_write_read_sequence This sequence generates back-to-back write and read transaction with zero idle cycles between transactions.The remaining transaction fields are randomized. The sequence does not wait for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_random_sequence This sequence generates random master transactions. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_read_sequence This sequence generates a sequence of read transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_read_xact_sequence This sequence generates a single random read transaction. addr
Address to be written

default -- svt_ahb_master_transaction_write_read_sequence This sequence generates a sequence of write transactions, followed by a sequence of read transactions. All other transaction fields are randomized. The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_write_sequence This sequence generates a sequence of write transactions.All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction. sequence_length
Number of Transactions in a sequence.

default -- svt_ahb_master_transaction_write_xact_sequence This sequence generates a single random write transaction. addr
Address to be written

data
Data to be written

default -- svt_ahb_transaction_random_write_or_read_sequence This sequence generates a sequence of write or read transactions with busy cycles inserted to a value controlled by user for every beat of the burst. For INCR burst type num_incr_beats is controlled by user. All other transaction fields are randomized.The sequence waits for each transaction to complete, before sending the next transaction. --
default -- svt_ahb_slave_transaction_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other svt_ahb_slave sequences in the collection extend from this base sequence. --
default -- svt_ahb_slave_controlled_response_sequence Abstract: class svt_ahb_slave_controlled_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory. --
default -- svt_ahb_slave_controlled_split_response_sequence Abstract: class svt_ahb_slave_controlled_split_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory. --
default -- svt_ahb_slave_memory_response_sequence Abstract: Class svt_ahb_slave_memory_response_sequence defines a sequence class that provides slave response to the Slave agent present in the System agent. The sequence receives a response object of type svt_ahb_slave_transaction from slave sequencer. The sequence class then randomizes the response with OKAY response and provides it to the slave driver within the slave agent. The sequence also instantiates the slave built-in memory, and writes into or reads from the slave memory.

Execution phase: main_phase Sequencer: Slave agent sequencer

 --
default -- svt_ahb_slave_tlm_response_sequence This sequence is used as Reactive seuqnce which translates slave transactions into corresponding AMBA-PV extended TLM Generic Payload Transactions and forwards it via the resp_socket socket for fulfillment by an AMBA-PV Slave. The response returned by the socket is then sent back to the driver.

Automatically configured as the run_phase default sequence for every instance of the svt_ahb_slave_sequencer if the use_pv_socket property in the port configuration is TRUE

 --
default -- svt_ahb_slave_transaction_distributed_random_sequence This sequence generates distributed random svt_ahb_slave transactions. --
default -- svt_ahb_slave_transaction_error_sequence This sequence generates ERROR responses. --
default -- svt_ahb_slave_transaction_memory_sequence This sequence gets the slave response sequence item from slave sequencer. The slave response is then randomized based on certain weights. User can modify these weights such that the sum of all the weights is 100. Also the sequence provides additional level of control interms of maximum number of non-OKAY responses to be allowed on per full AHB transaction. The sequence uses the built-in slave memory. For read transactions, it reads the data from the slave memory. For write transactions, it writes the data into slave memory. The randomized response is then provided to the slave driver.

This sequence runs forever, and so is not registered with the slave sequence library.

 --
default -- svt_ahb_slave_transaction_okay_sequence This sequence generates OKAY responses. --
default -- svt_ahb_slave_transaction_random_sequence This sequence generates random svt_ahb_slave transactions. --
default -- svt_ahb_slave_transaction_retry_sequence This sequence generates RETRY responses. --
default -- svt_ahb_slave_transaction_split_sequence This sequence generates SPLIT responses. --
default -- svt_ahb_system_base_sequence This sequence creates a reporter reference initiating_master_index_0
Active Participating Master index

active_participating_slave_index_0
Active Participating Slave index

participating_slave_index_0
Participating Slave index

default -- svt_ahb_arb_abort_on_error_resp_virtual_sequence #- Program a master VIP to drive write or read burst with 'n' number of transfers on to the bus.
#- Program a slave VIP to respond with ERROR response during any transfer.
#- Program the master VIP to abort remaining transfers when ERROR response is received
and shouldn't rebuild the transcation.
#- Check that AHB bus doesn't continues the remaining transfers in the burst.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves connected to the BUS.
.		 --
default -- svt_ahb_arb_fixed_length_hbusreq_virtual_sequence #- Program a master VIP to drive write or read burst of fixed length on to the bus and
routed to a slave.
#- Check AHB bus should behave correctly for fixed length bursts when master
de-assert hbusreq once it is granted the bus and burst should complete succesfully.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_arb_narrow_transfer_virtual_sequence #- Program the Master VIP to drive write or read burst with narrow transfers on the
bus.
#- Check AHB bus arbiter forwards narrow transfers with appropriate byte lanes.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_arb_reset_original_xact_in_progress_virtual_sequence #- Program the Master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Check AHB bus should response properly when reset was inserted in the original
transaction in progress.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_arb_undefined_length_hbusreq_virtual_sequence #- Program the master VIP to drive write or read burst of undefined length on to the bus
and routed to the slave.
#- Check AHB bus should behave correctly for undefined length bursts, the master
should continue to assert the request until it has started the last transfer.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_busy_transfer_virtual_sequence #- Program a master VIP to drive write or read burst with transfer type of BUSY to be
inserted in between the transfers.
#- Check AHB bus forwards OKAY response to BUSY transfers, when a master sends write
or read burst with BUSY transfer type.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_idle_transfer_virtual_sequence #- Program the Master VIP to drive idle burst on the bus.
#- AHB bus forwards this transfer to a slave.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_locked_diff_master_same_slave_rd_wr_virtual_sequence #- Program the two master VIP to drive write or read burst with one always
driving locked transfers the other driving either locked or unlocked transfers
routed to same slave.
#- Check AHB bus should behave correctly for mixtures of locked and normal bursts
when transfer driven by two masters to the slave.
.		 initiating_master_index_1
Represents the Second Active Participating Master from which the sequence will be initiated.

default -- svt_ahb_lock_fixed_length_virtual_sequence #- Program the master VIP to drive write or read locked transaction of fixed length
routed to the slave.
#- Check AHB bus should behave correctly for locked.
#- Initiate the above stimulus from all Master VIPs sequentially towards all the
Slaves.
.		 --
default -- svt_ahb_lock_split_retry_resp_same_master_same_slave_virtual_sequence #- Program a master VIP to drive locked or unlocked burst on to the bus
and routed to a slave.
#- Program above selected slave VIP such that it should response with RETRY or
SPLIT for any transfer of the burst.
#- Check AHB bus arbiter behaves properly when RETRY or SPLIT response was
received for locked or unlocked burst from same slave.
#- For unlocked bursts, Check AHB bus arbiter will grant to higher-priority master
when received RETRY response or another master when received SPLIT response
from same slave and finishes with OKAY transfer response when re-attempt it.
#- For locked bursts, Check AHB bus arbiter should give grant access to dummy master
when received SPLIT response or higher-priority master when received RETRY response.
.		 --
default -- svt_ahb_retry_resp_reached_max_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Check AHB bus should behave correctly when maximum number of rebuild attempts
on RETRY response was reached for a given transaction and master aborts the
transaction under such condition.
.		 --
default -- svt_ahb_split_resp_all_master_diff_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program all other masters VIP to drive write or read burst on the
bus and forwards the burst to different slaves.
#- Program above selected slaves VIP such that it should response with SPLIT for any
transfer of the burst and assert HSPILT signal after certain clock cycles.
#- Check the above masters are not continuing the transfers after receving SPLIT
response.
#- Make sure all masters have received SPLIT transfer response.
#- Check AHB bus arbiter will grant to the default master.
#- After certain clock cycles, Check AHB bus arbiter will grant the particular master
based on HSPLITx signals,so it can re-attempt the transfer and finishes with OKAY
transfer response.
.		 --
default -- svt_ahb_split_resp_all_master_same_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program all other masters VIP to drive write or read burst on the
bus and forwards the burst to above selected slave.
#- Program above selected slave VIP such that it should response with SPLIT for any
transfer of each master burst and assert HSPILT signal after certain clock cycles.
#- Check the above masters are not continuing the transfers after receving SPLIT
response.
#- Make sure all masters have received SPLIT transfer response.
#- Check AHB bus arbiter will grant to the default master.
#- After certain clock cycles, Check AHB bus arbiter will grant the particular master
based on HSPLITx signals,so it can re-attempt the transfer and finishes with OKAY
transfer response.
.		 --
default -- svt_ahb_split_retry_resp_diff_master_diff_slave_virtual_sequence #- Program a master VIP to drive write or read burst on the bus.
#- AHB bus forwards this burst to a slave.
#- Simultaneously Program another master VIP to drive write or read burst on the
bus and forwards the burst to another slave.
#- Program above two selected slaves VIP such that it should response with RETRY or
SPLIT for any transfer of the burst.
#- Check AHB bus arbiter behaves properly when RETRY or SPLIT response was
received from different slaves.
#- Check AHB bus arbiter will grant to higher-priority master when received RETRY
response or another master when received SPLIT response from different slaves
and finishes with OKAY transfer response when re-attempt it.
.		 initiating_master_index_1
Represents the Second Active Participating Master from which the sequence will be initiated.

selected_slv_1
Represents the Randomly selected Second Slave.

default -- svt_ahb_system_burst_transfer_virtual_sequence #- Program the Master VIP to drive write or read transaction.
#- Program the Slave VIP to assert HREADY signal low for few cycles
during transfers and then accordingly assert HREADY to 1.
#- Check the bus Master holds the data stable throughout the extended
cycles of transfer for which HREADY was de-asserted.
#- Check the bus forwards the appropriate OKAY response with wait state to the master.
.		 --
default -- svt_ahb_system_ebt_virtual_sequence #- Program the Master VIP to drive write or read transaction.
#- Program the bus for EBT during any transfer of the transaction.
#- Program the Master VIP to regains the access of bus.
#- Once it gains the bus, Program the Master to rebuild the transcation
#- with burst type as INCR or SINGLE.
#- Initiate the above stimulus from all Master VIPs sequentially towards all
the Slaves connected to the Bus.
.		 --
default -- svt_ahb_system_random_sequence This sequence allows unconstrained random traffic for all ports --
default -- svt_ahb_v6_unaligned_transfer_virtual_sequence Applicable for AHB_V6 enabled AHB systems
In AHBv6, capability to drive unaligned transfers is added.
This sequence is used to implement following.
#- Program a master VIP to drive unaligned bursts with unaligned address on to the bus
and routed to a slave.
#- Program the sequence to generate an unaligned address based on the burst size of the transfer
#- Check if the data values are correctly driven on the bus
#- Check if the data values are correctly sampled by slave and passive components
.		 --
default -- svt_ahb_tlm_generic_payload_sequence This sequence generates UVM TLM Generic Payload Transactions. A WRITE transaction is followed by a READ transaction to the same address. At the end of the READ transaction we check that the contents of the READ transaction are same as the WRITE transaction sequence_length
Number of Transactions in a sequence.

default -- svt_amba_system_base_sequence This sequence creates a reporter reference --
default -- svt_amba_system_random_sequence This sequence allows unconstrained random traffic for all ports --
default -- svt_apb_directed_tlm_generic_payload_sequence This sequence executes the UVM TLM Generic Payload Transaction in its ~m_gp~ property and returns once the response has been received.

The GP instance is not randomized before being sent to the sequencer.

 --
default -- svt_apb_master_base_sequence This sequence raises/drops objections in the pre/post_body so that root sequences raise objections but subsequences do not. All other master sequences in the collection extend from this base sequence. --
default -- apb_master_unalinged_write_read_data_compare_sequence This sequence generates alternate write and read transactions, with address, data and pstrb not randomized for read. This sequence can also be used for 64Bit address and Data width --
default -- apb_master_write_read_data_compare_sequence This sequence generates alternate write and read transactions, with address, data and pstrb not randomized for read. This sequence can also be used for 64Bit address and Data width --
default -- svt_apb_master_blocking_write_read_addr_sequence This sequence generates alternate write and read transactions for minimum, middle and maximum address values to traverse the addr range. --
default -- svt_apb_master_blocking_write_read_all_slave_data_sequence This sequence generates alternate write and read transactions for all existing slaves. The min, mid and max data values are written and read for each slave . --
default -- svt_apb_master_random_sequence This sequence generates random master transactions. --
default -- svt_apb_master_read_xact_sequence This sequence generates a single random read transaction. addr
Address to be read

default -- svt_apb_master_write_xact_sequence This sequence generates a single random write transaction. addr
Address to be written

data
Data to be written

default -- svt_apb_tlm_gp_to_apb_sequence This layering sequence converts TLM GP transactions into APB transaction(s) and sends them out on the driver. The sequence gets TLM GP transactions from the tlm_gp_seq_item_port on the parent sequencer. --
default -- svt_apb_slave_base_sequence This base sequence obtains the configuration from the sequencer during the pre_body callback. It does not raise or drop objections because slave sequences are reactive, and so are always running.

Sequencer: Slave agent sequencer

 --
default -- svt_apb_slave_memory_sequence This sequence generates memory responses to slave requests. This sequence gets the slave request from slave sequencer, randomizes the response, and then either updates the internal memory for write transations or updates the transaction with memory data for read transactions. If the requested address is outside of the configured bounds for the memory then the slave will return with a pslverr response.

This sequence runs forever, and so is not registered with the slave sequence library.

 --
default -- svt_apb_slave_random_response_sequence Abstract: class svt_apb_slave_random_response_sequence defines a sequence class that provides random slave response. The sequence receives a response object of type svt_apb_slave_transaction, from slave sequencer. The sequence class then randomizes the response with constraints and provides it to the slave driver within the slave agent. --
default -- svt_apb_slave_tlm_response_sequence This sequence is used as Reactive seuqnce which translates slave transactions into corresponding AMBA-PV extended TLM Generic Payload Transactions and forwards it via the resp_socket socket for fulfillment by an AMBA-PV Slave. The response returned by the socket is then sent back to the driver.

Automatically configured as the run_phase default sequence for every instance of the svt_apb_slave_sequencer if the use_pv_socket property in the port configuration is TRUE

 --
default -- svt_apb_system_base_sequence This sequence creates a reporter reference active_participating_slave_index
Initiating Slave index *
participating_slave_index
Initiating Slave index *
default -- svt_apb_master_random_transfer_sequence Abstract: svt_apb_master_random_transfer_sequence defines a sequence in which random APB transactions are issued and based on config_db flags and other values performs the self checks and necessary operations. Sequence is generated using `svt_xvm_do_on_with macros.

Execution phase: main_phase Sequencer: System sequencer

 --
default -- svt_apb_random_slave_write_transfer_with_random_pstrb_sequence Abstract: svt_apb_random_slave_write_transfer_with_random_pstrb_sequence defines a sequence in which a APB WRITE is followed by a APB READ to the same address and data integrity check is performed.

Execution phase: main_phase Sequencer: System sequencer

 sequence_length
sequence_length

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. _read_xact_type
Following are the possible transaction types:
  • WRITE : Represent a WRITE transaction.
  • READ : Represents a READ transaction.
  • COHERENT : Represents a COHERENT transaction.

_write_xact_type
Description-Unavailable
_atomic_xact_type
Description-Unavailable
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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

default -- axi_master_atomic_compare_xact_base_sequence This sequence generates atomic compare transactions. sequence_length
Parameter that controls the number of transactions that will be generated

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
_addr
Description-Unavailable
default -- axi_master_atomic_load_xact_base_sequence This sequence generates atomic load transactions. sequence_length
Parameter that controls the number of transactions that will be generated

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
atomic_xact_load_type
Description-Unavailable
_addr
Description-Unavailable
default -- axi_master_atomic_store_xact_base_sequence This sequence generates atomic store transactions. sequence_length
Parameter that controls the number of transactions that will be generated

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
atomic_xact_store_type
Description-Unavailable
_addr
Description-Unavailable
default -- axi_master_atomic_swap_xact_base_sequence This sequence generates atomic swap transactions. sequence_length
Parameter that controls the number of transactions that will be generated

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
_addr
Description-Unavailable
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

 sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

_addr
Description-Unavailable
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. sequence_length
Parameter that controls the number of transactions that will be generated

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 . sequence_length
Parameter that controls the number of transactions that will be generated

is_same_id
Description-Unavailable
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. sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

use_directed_addr
Indicates that the addresses provided in directed_addr_mailbox should be used for the transactions generated by this 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. flag_domain_type
Description-Unavailable
flag_addr
Description-Unavailable
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 flag_domain_type
Description-Unavailable
default -- svt_axi_ace_barrier_pair_sequence Sends a barrier pair myDomain
Description-Unavailable
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
  • Initialize cache lines if initialize_cachelines bit is set
  • Issue READCLEAN or READSHARED to load location and wait for the transaction to end
  • Check the cache line state
    • if in Shared state issue CLEANUNIQUE
    • if in Invalid state then restart Exclusive Access
    • else do nothing as Master can store directly to the cacheline no need to inform Interconnect
  • Stored data is updated to memory through WRITEBACK transaction

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

exc_burst_length
Description-Unavailable
exc_burst_size
Description-Unavailable
exc_burst_type
Description-Unavailable
exc_domain
Description-Unavailable
exclusive_axi4_slave
Description-Unavailable
num_of_exclusive_seq_restart
Description-Unavailable
random_nonexclusive_store_overlap_with_exclusive_store_wt
represents percentage value of sending random non-exclusive store overlapping with exclusive store. Must set values between 0 to 100

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 seq_xact_type
Description-Unavailable
dvm_message_type
Description-Unavailable
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. addr
Address to be written

default -- svt_axi_ace_master_write_xact_sequence This sequence generates a single random ACE write transaction. addr
Address to be written

data
Data to be written

default -- svt_axi_exclusive_id_addr_test_sequence This sequence follows id_addr's transactions parallelly and other configurations set from the test. sequence_length
Number of Transactions in a sequence.

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_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_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_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_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_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_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_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_aligned_addr_sequence This sequence generates the transactions whose address is always aligned with respect to burst size. sequence_length
Number of Transactions in this sequence.

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. sequence_length
Number of Transactions in this sequence.

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. sequence_length
Parameter that controls the number of transactions that will be generated

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

 sequence_length
Parameter that controls the number of transactions that will be generated

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 sequence_length
Number of Transactions in this sequence.

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. sequence_length
Number of Transactions in this sequence.

slv_num
Indicates the slave number to be targetted

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. slv_num
Description-Unavailable
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) sequence_length
Number of Transactions in this sequence.

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. sequence_length
Number of Transactions in this sequence.

slv_num
Description-Unavailable
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. sequence_length
Number of Transactions in a sequence.

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. sequence_length
Number of Transactions in a sequence.

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. sequence_length
Number of Transactions in a sequence.

multi_same_id_select
If set, then the sequence will initiate WRITENOSNOOP and READNOSNOOP transactions with multiple same ids

default -- svt_axi_master_random_sequence This sequence generates random master transactions. sequence_length
Number of Transactions in a sequence.

default -- svt_axi_master_read_xact_sequence This sequence generates a single random read transaction. addr
Address to be written

default -- svt_axi_master_sanity_test_sequence This sequence performs reads and writes in parallel sequence_length
Number of Transactions in this sequence.

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. sequence_length
Number of Transactions in this sequence.

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. sequence_length
Number of Transactions in this sequence.

default -- svt_axi_master_write_xact_sequence This sequence generates a single random write transaction. addr
Address to be written

data
Address to be written

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. slv_num
Description-Unavailable
default -- svt_axi4_lite_master_random_sequence This sequence generates random master transactions for axi4_lite. sequence_length
Number of Transactions in a sequence.

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. sequence_length
Number of Transactions in a sequence.

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. sequence_length
Number of Transactions in a sequence.

slv_num
Description-Unavailable
xact_length
Description-Unavailable
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. sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

xact_length
Number of transaction used to constrain in sub-sequences

id
Description-Unavailable
min_id
Read Id width

rd_id
Description-Unavailable
slv_num
Slave number used to constrain

address
Description-Unavailable
memory_type
Description-Unavailable
do_write_before_read
Write before read used to constrain

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 . sequence_length
Parameter that controls the number of transactions that will be generated

num_of_xact
Number of Write transaction in used to constrain it in sub-sequences

id_pattern
Description-Unavailable
seq_xact_type
Description-Unavailable
min_id
Description-Unavailable
seq_id
Description-Unavailable
max_id_value
Description-Unavailable
slv_num
Slave number used to constrain it

no_of_unique_id
Description-Unavailable
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

 sequence_length
Parameter that controls the number of transactions that will be generated

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. sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

num_of_wr_xact
Number of Write transaction in used to constrain it in sub-sequences

id
Description-Unavailable
min_id
Description-Unavailable
wr_id
Description-Unavailable
slv_num
Slave number used to constrain it

address
Description-Unavailable
memory_type
Description-Unavailable
interleave
Description-Unavailable
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 . sequence_length
Parameter that controls the number of transactions that will be generated

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 . sequence_length
Parameter that controls the number of transactions that will be generated

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 . sequence_length
Description-Unavailable
no_of_xacts
Description-Unavailable
no_of_wr_xacts
Description-Unavailable
no_of_rd_xacts
Description-Unavailable
seq_id_pattern
Description-Unavailable
use_seq_id_pattern
Description-Unavailable
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 . sequence_length
Description-Unavailable
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 . sequence_length
Parameter that controls the number of transactions that will be generated

default -- svt_axi_system_base_sequence This sequence creates a reporter reference _read_xact_type
Following are the possible transaction types:
  • WRITE : Represent a WRITE transaction.
  • READ : Represents a READ transaction.
  • COHERENT : Represents a COHERENT transaction.

_write_xact_type
Description-Unavailable
initiating_master_index
Initiating Master index *
active_participating_slave_index
Initiating Slave index *
participating_slave_index
Initiating Slave index *
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.

 domain_type
Description-Unavailable
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. num_pre_barrier_loads
Number of pre-barrier stores to be issued before issuing a barrier and post-barrier transaction

num_ports
Number of ports from which the sequence needs to be executed

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 num_pre_barrier_stores
Number of pre-barrier stores to be issued before issuing a barrier and post-barrier transaction

num_ports
Number of ports from which the sequence must be executed

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.

 first_port_id
Represents the master port from which the sequence will be initiated.

second_port_id
Description-Unavailable
pre_barrier_xact_type
The kind of pre-barrier transactions

num_pre_barrier_stores
Number of pre-barrier stores to be issued before issuing a barrier and post-barrier transaction

num_observers
Number of ports that are observing the pre barrier stores. The location written through the flag transaction is read from this many ports that fall in the same domain
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 multi_port_type
Indicates if DVM transactions need to be sent from only one port in a given domain or from all ports in a domain Currently supports only ONE_MASTER
num_pre_dvm_xacts
Description-Unavailable
domain_type
The shareability domain of the DVM transactions to be sent
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::
  • independent write channel transaction progress along with dvm transactions
  • independency of ID usage between write channel transactions and DVM transactions
  • independent read channel transaction progress along with dvm transactions
  • ID usage restrictions between read channel non-dvm transactions and DVM transactions
  • multi-part DVM transactions
  • multi-part DVM transactions with second part having DVM Sync and other opcodes
  • multi-part DVM Sync transactions with second part having DVM Sync and other opcodes
  • time overlapped multi-part dvm and non-multi-part dvm transactions
  • time overlapped coherent write, coherent read and multi-part dvm and non-multi-part dvm transactions
--
default -- svt_axi_ace_master_single_port_base_virtual_sequence Base class from which all ACE basic level sequences will be extended. port_id
Represents the master port from which the sequence will be initiated.

sequence_length
Represents the length of the sequence.

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. first_port_id
Represents the port for sending non-DVM transactions. Valid only if send_non_dvm_xact_select is set. first_port_id may be the same as dvm_port_id1 or dvm_port_id2. However, if dvm_port1_multipart_select is set, first_port_id cannot be dvm_port_id1. The same applies to dvm_port2_multipart_select and dvm_port_id2. This is because non-DVM transactions cannot be sent between two multipart DVM transactions This property can be controlled via uvm_config_db.

dvm_port_id1
Represents the first dvm master port. This property can be controlled via uvm_config_db.

dvm_port_id2
Represents the second dvm master port. This property can be controlled via uvm_config_db.

dvm_port1_multipart_select
Represents the multipart dvm transaction selection for dvm_port_id1. Note that if the dvm_message_type selected is TLB_INVALIDATE, PHYSICAL_INSTRUCTION_CACHE_INVALIDATE or VIRTUAL_INSTRUCTION_CACHE_INVALIDATE, the randomized values of tlb_operation, physical_instruction_invalidate_operation and virtual_instruction_invalidate_operation determine whether a DVM transaction will be multipart or not. This property can be controlled via uvm_config_db.

dvm_port2_multipart_select
Represents the multipart dvm transaction selection for dvm_port_id2. Note that if the dvm_message_type selected is TLB_INVALIDATE, PHYSICAL_INSTRUCTION_CACHE_INVALIDATE or VIRTUAL_INSTRUCTION_CACHE_INVALIDATE, the randomized values of tlb_operation, physical_instruction_invalidate_operation and virtual_instruction_invalidate_operation determine whether a DVM transaction will be multipart or not. This property can be controlled via uvm_config_db.

send_non_dvm_xact_from_first_port_select
Sends non dvm transactions on first_port_id if set to 1, Sends only dvm messages without non dvm transactions if set to 0. This property can be controlled via uvm_config_db.
send_non_dvm_xact_from_dvm_port_select
Sends non-dvm transactions along with DVM transactions from dvm_port_id1 and dvm_port_id2. Only transactions which can be sent out without initializing the cacheline are used. These transactions are WRITENOSNOOP, READNOSNOOP, MAKEUNIQUE, READUNIQUE, READSHARED, READCLEAN, READNOTSHAREDDIRTY, CLEANINVALID, CLEANSHARED, MAKEINVALID, WRITEUNIQUE, WRITELINEUNIQUE.
num_non_dvm_xacts_from_dvm_port
Applicable when send_non_dvm_xact_from_dvm_port_select is set. Indicates the number of non dvm transactions to be sent after num_dvm_xacts_before_non_dvm_xact number of DVM transactions are sent Once the non-dvm transactions are sent, DVM transactions are represented by num_dvm_xacts_before_non_dvm_xact are sent again.

num_dvm_xacts_before_non_dvm_xact
Applicable when send_non_dvm_xact_from_dvm_port_select is set. Indicates the number of DVM transactions to be sent before non-DVM transactions are sent. Once the non-dvm transactions are sent, DVM transactions as represented by the this variable are sent before sending non-DVM transactions. Hence the sequence of DVM based on num_dvm_xacts_before_non_dvm_xact, non-DVM based on num_non_dvm_xacts_from_dvm_port is repeated.
tlb_operation
The tlb_operation represents the tlb sub operation to be sent from test

physical_instruction_invalidate_operation
The physical_instruction_invalidate_operation represents the physical instruction invalidate sub operation to be sent from test

virtual_instruction_invalidate_operation
The virtual_instruction_invalidate_operation represents the virtual instruction invalidate sub operation to be sent from test
dvm_message_type
The dvm_message_type represents the dvm message to be sent from test. This property can be controlled via uvm_config_db.

first_port_xact_type
Random coherent non-dvm transaction type for first_port_id This property can be controlled via uvm_config_db.
domain_type
The shareability domain of the DVM transactions to be sent
dvm_os_select
The dvm os type of the DVM transactions to be sent
dvm_security_select
The dvm security type of the DVM transactions to be sent
two_port_interface_type
Represents the interface types for the first port and dvm port, selected according to the number of AXI_ACE and ACE_LITE ports collected through find_dvm_ports function
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
  • Initialize cache lines if initialize_cachelines bit is set
  • Issue READCLEAN or READSHARED to load location and wait for the transaction to end
  • Check the cache line state
    • if in Shared state issue CLEANUNIQUE
    • if in Invalid state then restart Exclusive Access
    • else do nothing as Master can store directly to the cacheline no need to inform Interconnect
  • Stored data is updated to memory through WRITEBACK transaction

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

 init_cachelines
Description-Unavailable
ace_exclusive_select
Description-Unavailable
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_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_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_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: init_cachelines
Description-Unavailable
default -- svt_axi_ace_master_two_port_base_virtual_sequence Base class from which all ACE intermediate level sequences will be extended. first_port_id
Represents the first master port.

second_port_id
Represents the second master port.

two_port_interface_type
The interface types for the first port and second port

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. first_port_xact_type
Random coherent transaction type for coherent_seq_first_port

second_port_xact_type
Random coherent transaction type for coherent_seq_second_port

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 second_port_xact_type
Random coherent transaction type for coherent_seq_second_port

domain_type
Description-Unavailable
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
  • CMO : MAKEINVALID, CLEANINVALID or CLEANSHARED STORE : MAKEUNIQUE, CLEANUNIQUE, READUNIQUE, WRITEUNIQUE or WRITELINEUNIQUE LOAD : READONCE, READSHARED, READCLEAN or READNOTSHAREDDIRTY. In case of CLEANUNIQUE the initial state must be shared state.(if cleanunique_wt is 1) After completing initialisation for memory update, readshared will be sent from second_port_id to initialize the states to shared, for the cleanunique addresses.
If addr_mode_select is set from test, the sequence will fire memory update transactions from first_port_id and coherent transactions from second_port_id to the same set of sequential addresses at the same time. If addr_mode_select is low, the sequence will fire memory update transactions from first_port_id and coherent transactions from second_port_id to the same set of random addresses at the same time. . The combination of WRITEEVICT and CLEANUNIQUE cant be exercised because Initial state of WRITEEVICT must be Unique Clean,for CLEANUNIQUE any shared state so at the same time the states cant be in unique and shared. 		second_port_xact_type
Random coherent transaction type for second_port_id

default -- svt_axi_ace_master_two_master_concurrent_write_sequence This sequence sends cocurrent write transactions from two ports after initializing cache lines second_port_xact_type
Random coherent transaction type for coherent_seq_second_port

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 first_port_xact_category
The transaction category for the first port

second_port_xact_category
The transaction category for the second port

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:
  • In order that the store transactions can be fired from various initial states.
  • If second_port_cleanunique_wt is not zero, cachelines are initialised, since CLEANUNIQUE can be sent only from a cacheline in shared state. Only cachelines from which CLEANUNIQUE needs to be sent are initialized. The number of CLEANUNIQUE transactions sent are determined by the formula sequence_length*first_port_cleanunique_wt/(sum of weights of all xact types in second port). Initialisation is done by sending MAKEUNIQUE transactions from one ACE port and READSHARED transactions from another ACE port to the same set of addresses. Snoop transactions for READSHARED type snoop are programmed (in the corresponding tests) to always assert svt_axi_snoop_transaction :: snoop_resp_datatransfer and svt_axi_snoop_transaction :: snoop_resp_isshared so that a shared state of the cacheline can be acheived in both masters. All shared cachelines in first_port_id are invalidated so that the cmo transactions can be sent on the interface.
After this initialisation, sequential cmo access from first_port_id and sequential store from second_port_id are sent. . Sometimes if the cmo transactions snoops the second_port firstly and second port transaction is CLEANUNIQUE transaction means, there is a chance of invalidation of the cache line of second_port. By the result of this scenario the second_port may drop the CLEANUNIQUE transactions, Because CLEANUNIQUE cant be sent from INVALID state.		 --
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:
  • In order that the load transactions return some valid data, incase of ACE port MAKEUNIQUE followed by WRITEBACK are sent to update memory. incase of ACE_LITE port WRITELINEUNIQUE transactions are sent to update memory.
After this initialisation, sequential load or sequential cmo from first_port_id and sequential load or sequential cmo from second_port_id are sent concurrently to the same set of addresses.		 --
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:
  • In order that the load transactions return some valid data, WRITELINEUNIQUE transactions are sent to update memory.
  • If first_port_cleanunique_wt is not zero, cachelines are initialised, since CLEANUNIQUE can be sent only from a cacheline in shared state. Only cachelines from which CLEANUNIQUE needs to be sent are initialized. The number of CLEANUNIQUE transactions sent are determined by the formula sequence_length*first_port_cleanunique_wt/(sum of weights of all xact types in first port). Initialisation is done by sending MAKEUNIQUE transactions from one ACE port and READSHARED transactions from another ACE port to the same set of addresses. Snoop transactions for READSHARED type snoop are programmed (in the corresponding tests) to always assert svt_axi_snoop_transaction :: snoop_resp_datatransfer and svt_axi_snoop_transaction :: snoop_resp_isshared so that a shared state of the cacheline can be acheived in both masters. All shared cachelines in second_port_id are invalidated so that the load transactions can be sent on the interface.
After this initialisation, sequential stores from first_port_id and sequential loads from second_port_id are sent.		 --
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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constrain the sequence length in sub-sequences

dec_addr
Decode address in used to constrain the decode address in sub-sequences

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. sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

default -- svt_axi_master_atomic_compare_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic compare type transactions sequence_length_local
Sequence length in used to constsrain the sequence length in sub-sequences

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
default -- svt_axi_master_atomic_load_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic load type transactions sequence_length_local
Sequence length in used to constsrain the sequence length in sub-sequences

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
default -- svt_axi_master_atomic_store_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic store type transactions sequence_length_local
Sequence length in used to constsrain the sequence length in sub-sequences

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
default -- svt_axi_master_atomic_swap_xact_base_virtual_sequence This sequence serves as a base sequence to create atomic swap type transactions sequence_length_local
Sequence length in used to constsrain the sequence length in sub-sequences

start_addr
Parameter controls the addresses generated by transactions in this sequence

end_addr
Parameter controls the addresses generated by the transactions in this sequence
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.
.		 sequence_length
Description-Unavailable
default -- svt_axi_random_ictest_sequence #- Program the Master VIP to drive multiple random transaction.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

default -- svt_axi_cov_corner_cases_wstrb_sequence #- Program the Master VIP to drive multiple transaction with more probability
for wstrb corner scenarios.
sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
. 		sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

selected_mstr
Variables to select random Masters

initiating_master_index_2
Variables to select random Masters

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences.

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
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

participating_slave_index_2
Variable to select random slaves

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.
. 		sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
. 		sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

active_participating_slave_index_2
Variable to select random slaves

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.
 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
. 		sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

supporting_master_index
Supporting Master index *
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.
. 		sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

supporting_master_index
Supporting Master index *
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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

supporting_master_index
Supporting Master index *
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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

supporting_master_index
Supporting Master index *
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
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

supporting_master_index
Supporting Master index *
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.
. 		sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

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.
. 		sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
. 		sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

selected_mstr
Variables to select random Masters

initiating_master_index_2
Variables to select random Masters

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
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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
.		 sequence_length
Sequence length is used to constsrain the sequence length in sub-sequences

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.
.		 sequence_length
Sequence length in used to constsrain the sequence length in sub-sequences

initiating_master_index_2
Initiating second Master index

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 sequence_length
Number of Transactions in a sequence.

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 sequence_length
Number of Transactions in a sequence.

default -- svt_chi_ic_sn_random_response_sequence Description-Unavailable --
default -- chi_rn_barrier_directed_sequence Abstract: chi_rn_barrier_directed_sequence is used by test to provide initiator scenario information to the RN agent present in the System Env. This class defines a sequence in which a CHI WRITE followed by a CHI READ sequence is generated by assigning values to the transactions rather than randomization, and then transmitted using `uvm_send.

Execution phase: main_phase Sequencer: Master agent sequencer

 sequence_length
Parameter that controls the number of transactions that will be generated

txn_id
Transaction txn_id

xact_type
Description-Unavailable
default -- chi_rn_directed_noncoherent_xact_sequence Abstract: chi_rn_directed_noncoherent_xact_sequence defines a sequence through which non coherent transactions can be sent. Execution phase: main_phase Sequencer: Master agent sequencer sequence_length
Parameter that controls the number of transactions that will be generated

addr
Transaction address

txn_id
Transaction txn_id

xact_type
Description-Unavailable
mem_type
Description-Unavailable
is_cacheable
Description-Unavailable
requires_go_before_barrier
Description-Unavailable
is_barrier_associated
Description-Unavailable
seq_order_type
Description-Unavailable
seq_req_order_stream_id
Description-Unavailable
default -- chi_rn_noncoherent_transaction_base_sequence Abstract: chi_rn_noncoherent_transaction_base_sequence defines a sequence through which non coherent transactions can be sent. Execution phase: main_phase Sequencer: Master agent sequencer seq_req_order_stream_id
Description-Unavailable
default -- svt_chi_sn_transaction_base_sequence Description-Unavailable --
default -- svt_chi_system_coherent_virtual_sequence This sequence sends coherent transactions from multiple RN and provides mechanism to control following parameters.
  • transactions are sent from each RN only which are applicable to those RNs
  • specific transactions can be controlled seperately for each RN by setting corresponding weights
  • transaction can either be sent with random address or sequential address
  • transactions from different RNs can be set to send with overlapped addresses or completely seperate non-overlapped addresses. These are achieved by setting "addr_mode" along with "rn_start_addr[]" and "rn_end_addr[]" address array.
  • it allows user to send transactions in blocking or sequential manner
  • user can specify number of RN from which transactions will be sent as well as
  • specific RN indexes from which transactions will be sent
  • sequence takes care of cacheline initiallization in order to send transactions from correct initial state without getting dropped by RN driver layer
  • sequence provides necessary constraints to randomize above parameters
  • it also allows user to override sequence members

  • address ranges for each RN are specified through combination of "rn_start_addr" and "rn_end_addr"
  • index of rn_start_addr or rn_end_addr for a specific RN is determined by the position of that RN in the rn_index_list_for_sending_transaction[] array. Ex: rn_index_list_for_sending_transaction = {1, 3} and rn_start_addr = {32'h1000, 32'h2000} This means RN-1 and RN-3 will be used to send transactions to interconnect and RN-1 will have start address of its accessible address region as 32'h1000 and RN-3 as 32'h2000

  • even though sequence can be randomized to automatically create mutually exclusive or overlapped address regions for different RNs either random or sequential, user can also specifically set such address regions by means of configuration override
  • Failure severity of is_supported functionality of the sequence can be controlled by the attribute is_supported_failure_severity.
  • In case of addr_mode set to SEQUENTIAL_NONOVERLAPPED_ADDRESS or SEQUENTIAL_OVERLAPPED_ADDRESS, rn_end_addr is not required to be programmed as rn_end_addr will be calculated based on the rn_start_addr and the sequece_length. Even if rn_end_addr is programmed it will be overriden with the value calculated based on the rn_start_addr and the sequece_length.
  • Mix of coherent and non-coherent transactions within an RN is not allowed as there can be a possibility of mismatch attributes to the same address resulting into software error sceanrio.
  • When addr_mode is set to RANDOM_OVERLAPPED_ADDRESS or SEQUENTIAL_OVERLAPPED_ADDRESS, no 2 RN's should have transaction weights as one RN enabled with non-coherent transactions and the other with coherent transactions as ther can be mismatched memory attributes to the same address resulting into software error scenario.
  • Transaction weights for each RN should be configured through config_db setting. If not the default weights will be set wherein all the coherent transaction weights will be enabled.
  • For cache initialization, single attribute 'initialize_cachelines' which is applicable for all RN's can be programmed or 'rn_initialize_cachelines' attribute can be programmed per RN basis. When both are programmed, rn_initialize_cachelines will take the precedence.
  • For CMO transactions and atomic transactions from a particular node, the memory attributes (Cacheable, Device, EWA) and Snp_attr will be configured same as that of other coherent transactions if atleast one coherent transaction weights is programmed for that node. This behavior can be controlled through the attribute use_coherent_xacts_mem_attr_snp_attr_for_cmo_atomics per RN basis.
  • Currently this sequence doesn't factor in security bits for address calculation. i.e, tagged address

NOTE: sequence is currently supported in UVM or OVM methodology

 addr_mode
determines addresses for each transaction generated by this sequence. indicates whether random address will be chosen or if sequential addresses will be used for successive transactions.

send_blocking_transactions
determines if transactions are sent by this sequence sequentially as blocking transaction or as non-blocking outstanding transactions
num_rn_to_send_transaction
Indicates number of RNs to be used by this sequence for sending transactions
rn_index_list_for_sending_transaction
Holds RN indexes or port-id(s) to which this sequence will send transactions Total size of this list must be same as num_rn_to_send_transaction
rn_start_addr
holds start address of accessible address ranges of each RN

rn_end_addr
holds end address of accessible address ranges of each RN

default -- svt_chi_system_multi_node_random_virtual_sequence This sequence initiates Readshared transactions from multiple RN-F nodes. --


13 August 2024, Copyright © 2024 Synopsys, Inc.