GTF, GTYp & GTM PRBS test case description

The goal of this test case is to allow verification of GTF, GTYp & GTM transceivers on Alveo™ cards. The 4 lanes of the GT transceiver are tested simultaneously.

For the different GT types supported, the main cores of the functionalities are common (xbtSW & xbtest hardware IP (xbtIP)). xbtIP differs only for some GT setting configuration options. The content of xbtIP varies based on the GT tested.

• GTF: 10GbE; xbtIP uses the GTF wizard configured in 10GbE Raw mode (16 bits data).

• GTYp: 32Gb/s; xbtIP uses the Versal Transceivers Bridge IP in Aurora 64B/66B mode (66 bits data).

• GTM: 56GbE; xbtIP uses the Versal Transceivers Bridge IP PAM4 Ethernet 56G mode (128 bits data).

This xbtIP is composed by PRBS-31 generator & checker which sends & verifies data at expected rate. The PRBS checker compares the incoming data to a newly created reference data PRBS based on the previous data received.

The xbtIP counts the quantity of correct and erroneous bit received every second. The xbtSW computes BER based on these info. The BER is compared to a programmable threshold and the test is failing if the ratio is above the threshold.

To increase robustness to error, the PRBS checker, once in lock, uses a reference PRBS and compare incoming data with this free-running generated reference PRBS. This reference PRBS is synced with the incoming data if there are less than 10% of error during the comparison. If there are more than 10% errors between the reference PRBS and the received data, the reference PRBS is resynced to the data. The xbtSW can disable the usage the reference PRBS. The xbtSW is also capable of injecting a single error on any lane.

GT PRBS xbtest hardware IP block diagram

GT test set up

GT testing can be achieved by using one of the following methods:

• The use of a QSFP passive electrical loopback module. This is the preferred method.

  • GTF: The module must be compliant to 40GbE (10GbE per lane) and have 0 dB insertion loss. The GTs having been validated using a QSFP-DD module provided by MultiLane (ML4062_SLB_V4).

  • GTYp: Amphenol PCIe MCIO x4 & x8 loopback cable, respectively RMC38-0728 AX2 and RMC74-6757 AX3.

  • GTM: The module must be compliant to 200GbE (56GbE per lane) and have 0 dB insertion loss. The GTs having been validated using a QSFP-DD module provided by MultiLane (ML4002-56-15W-0dB).

  Note

  The QSFP modules also have the capability of providing a QSFP temperature reading and a programmable power dissipation. However, these are not required to pass the GT tests.

• The use of a QSFP optical module with suitably connected fiber loopback. The module must be compatible with the traffic rate being tested.

  Note

  This is an active component the electrical interface between the GTFs and the module will need to be validated to ensure optimum performance.

In addition, GT testing can be achieved by:

• The use of a protocol analyzer with a compatible electrical or optical interface. This is the most complex method of connection as not only will the interfaces require validation with the GTs, the RX and TX paths will be independent.

GT settings

As there are multiple ways to connect to the GTs, two default configurations have been defined:

• module: For loopback module and active optical cable. Loopback module is an electrical track from TX to RX. It’s the shortest path you can get between Tx and Rx (and still going out of the FPGA). An active optical cable terminates the electrical TX track at the optic module input. It also has the electric RX track from the optic module output. Resulting in electrical track length twice the size compared to the loopback module. From experience, it has no major impact and GT settings can be common for these 2 types (loopback module or active optical cable).

• cable: For copper cable.

The selection is made using the gt_settings member, by default module settings are selected.

Each mode defines values for the following GT transceiver settings (see UltraScale Architecture GTY Transceivers User Guide (UG578)):

• tx_differential_swing_control

• tx_main_cursor

• tx_pre_emphasis

• tx_post_emphasis

• gt_tx_polarity

• gt_loopback

• rx_equaliser

The actual values are defined in the Card definition JSON file and are also displayed in the xbtest.log file with message ID CMN_021. It’s possible to overwrite these settings for all lanes (included into global_config) or selectively for some lanes (part of lane_config).

Warning

When connected to switch, using a wrong setting for one single lane might result in traffic interruption on all lanes. The switch might try to reset its whole module because it sees that a link is down.

Main test steps

A test is generally composed of four steps and a definition of the hardware environment (see GT PRBS test JSON members). The following are typical test steps:

1. Configuration.

2. Reset.

3. Clear status.

4. Run.

5. Report/check status.

Test parameters

The mandatory test configuration parameters are listed below. For more information, see GT PRBS test JSON members.

• duration: The duration of the test, measured in seconds.

• mode: Mode of the xbtIP.

Reset & Power

Warning

It’s strongly recommended to reset the GT once the Power xbtIP toggle rate is stable. GT could be sensitive to important power variation of the FPGA.

It’s also highly recommended to reset GT individually. A GT reset creates a load transient resulting in a temporary spike or dip in the power supply voltage. If the voltage doesn’t remain within the operating limits, resetting one GT could affect another GT. The operation limits are specified in the data sheets.

If Alveo Versal Example Design (AVED) contains multiple GT xbtIP, a staggering reset of each of them is automatically performed by xbtest. If multiple GT PRBS xbtIP requests a reset, each GT is reset at last 1 second after the previous one.

Note

The automatic staggering reset protection does not reset the GT PRBS xbtIP in any particular order. It just ensures that GTs are not reset simultaneously.

If you want control the reset order, you’ll have to stagger yourself the resets; e.g. by giving a different duration to the configuration phase of the test_sequence of each GT.

"gtm_prbs": {
  "0": {
    "global_config": {
      "test_sequence": [
        { "duration":  1, "mode": "conf_gt"}, { "duration":  1, "mode": "tx_rx_rst"}, { "duration":  1, "mode": "rx_datapath_rst"} ]
    },
  "1": {
    "global_config": {
      "test_sequence": [
        { "duration":  2, "mode": "conf_gt"}, { "duration":  1, "mode": "tx_rx_rst"}, { "duration":  1, "mode": "rx_datapath_rst"} ]
    },
  "2": {
    "global_config": {
      "test_sequence": [
        { "duration":  3, "mode": "conf_gt"}, { "duration":  1, "mode": "tx_rx_rst"}, { "duration":  1, "mode": "rx_datapath_rst"} ]
    }
  }
}

The GTF wizard includes its own GTF reset FSM. xbtest monitors various reset status (done signals) and re-triggers the reset FSM if reset is not successful. The reset FSM can be re-triggered up to 5 times.

Status

GT PRBS xbtest hardware IP (xbtIP) provides per lane the following status:

• PRBS error detected since the last clear.

• The quantity of bit received.

• The quantity of erroneous bit received.

• Null PRBS seed received.

• Null PRBS seed used during PRBS generation.

With these info, the xbtSW:

• Computes, every second, BER and reports error if it’s above the threshold (see prbs_error_threshold).

• Computes, every second, Rx data rate. It reports error if the rate is 0.5% away from the theoretical rate.

  • GTF: 10.3125 Gb/s.

  • GTYp: 32.00 Gb/s.

  • GTM: 56.42 Gb/s.

• Computes, for every check_status (see test_sequence), Tx data rate. It reports error if the rate is 0.5% away from the theoretical rate.

GT PRBS test JSON members

As Alveo Versal Example Design (AVED) can contain multiple GT PRBS xbtIP, there is a way to create a test case common to all GT PRBS xbtIP by using a default test definition.

Even if the default test case is used, it’s still possible:

• To overwrite the test case definition of a specific GT PRBS xbtIP.

• To overwrite the GT parameters for all lanes of all GT or for 1 specific lane/GT, via lane_config usage.

Here are some examples of GTF, GTYp and GTM PRBS test cases.

Examples of GTF, GTYp and GTM PRBS test cases.

default: Same test configuration applied to all GTF PRBS	default with GTYp PRBS[0] test case overwrite	default with: GTM PRBS[1] test case overwrite GTM PRBS[1] lane 3 disable All GTM lane 2 set in loopback
"gtf_prbs": { "default": { "global_config": { "test_sequence": [ { "duration": 1, "mode": "conf_gt" }, { "duration": 1, "mode": "tx_rx_rst" }, { "duration": 1, "mode": "rx_datapath_rst" }, { "duration": 1, "mode": "clear_status" }, { "duration": 60, "mode": "run" }, { "duration": 1, "mode": "check_status" } ] } } }	"gtyp_prbs": { "default": { "global_config": { "test_sequence": [ { "duration": 1, "mode": "conf_gt" }, { "duration": 1, "mode": "tx_rx_rst" }, { "duration": 1, "mode": "rx_datapath_rst" }, { "duration": 1, "mode": "clear_status" }, { "duration": 60, "mode": "run" }, { "duration": 1, "mode": "check_status" } ] } }, "0": { "global_config": { "ber_threshold": 1e-10, "test_sequence": [ { "duration": 1, "mode": "conf_gt" }, { "duration": 1, "mode": "tx_rx_rst" }, { "duration": 1, "mode": "rx_datapath_rst" }, { "duration": 1, "mode": "clear_status" }, { "duration": 5, "mode": "run" }, { "duration": 1, "mode": "check_status" }, { "duration": 1, "mode": "insert_error_lane_2" }, { "duration": 1, "mode": "check_status" } ] } } }	"gtm_prbs": { "default": { "global_config": { "test_sequence": [ { "duration": 1, "mode": "conf_gt" }, { "duration": 1, "mode": "tx_rx_rst" }, { "duration": 1, "mode": "rx_datapath_rst" }, { "duration": 1, "mode": "clear_status" }, { "duration": 60, "mode": "run" }, { "duration": 1, "mode": "check_status" } ] }, "lane_config": { "2": { "gt_loopback" : "near end pma" } } }, "1": { "global_config": { "ber_threshold": 1e-12, "test_sequence": [ { "duration": 1, "mode": "conf_gt" }, { "duration": 1, "mode": "tx_rx_rst" }, { "duration": 1, "mode": "rx_datapath_rst" }, { "duration": 1, "mode": "clear_status" }, { "duration": 10, "mode": "run" }, { "duration": 1, "mode": "check_status" } ] }, "lane_config": { "3": { "disable_lane" : true } } } }

Definition

The following table shows all members available for this test case. More details are provided for each member in the subsequent sections.

GTF PRBS test JSON members

Member	Lane override	Mandatory / Optional	Description
test_sequence	No	Mandatory	Describes the sequence of tests to perform.
prbs_error_threshold	No	Optional	Define BER threshold
disable_ref_prbs	No	Optional	Disable the usage of reference free running PRBS
gt_loopback	Yes	Optional	Select GT internal loopback. See GT JSON Member.
gt_settings	No	Optional	Selects the GT default configuration. See GT JSON Member.
gt_tx_diffctrl	Yes	Optional	Select the Driver Swing Control. See GT JSON Member.
gt_tx_main_cursor	Yes	Optional	Select Transmitter pre-cursor TX main control. See GT JSON Member.
gt_tx_pre_emph	Yes	Optional	Select Transmitter pre-cursor TX pre-emphasis control. See GT JSON Member.
gt_tx_post_emph	Yes	Optional	Select Transmitter post-cursor TX pre-emphasis control. See GT JSON Member.
gt_tx_polarity	Yes	Optional	Select TX Polarity. See GT JSON Member.
gt_rx_polarity	Yes	Optional	Select RX Polarity. See GT JSON Member.
gt_rx_use_lpm	Yes	Optional	Select RX Equalizer. See GT JSON Member.

test_sequence

Mandatory. Describes the sequence of tests to perform. Tests are performed serially, and a failure in one test does not stop the sequence (the next test will be launched). There is no limitation to the length of the test sequence.

This field contains a list of tests, each test being defined by an object of key value parameters pairs: [ {}, {}, {} ].

The following table defines the parameters supported in the GTF test sequence:

GTF PRBS test sequence parameters

Member	Mandatory / optional	Description
duration	Mandatory	The duration of the test in seconds; Range [1, 232-1].
mode	Mandatory	Mode of the xbtIP. See the following table.

mode possible values

Possible value	Description
conf_gt	Apply the settings specified in the configuration parameters to the GTF hardware.
clear_status	Read and clear the xbtest hardware IP (xbtIP) status registers, but ignore the values returned in the counters. It is intended to be used after a conf_gt operation to clear the status errors.
run	Enable the PRBS checker.
check_status	Read the xbtest hardware IP (xbtIP) status registers. Check for any error If an error is detected the overall test will be flagged as a fail. This mode also checks the Tx data rate since the last clear_status.
tx_rx_rst	Initiate a reset of the GT TX and RX paths.
rx_datapath_rst	Initiate a reset of the GT RX datapaths.
insert_error_lane_<idx>	Insert a single PRBS error for lane <idx>: e.g. insert_error_lane_0.

An example of a test_sequence is:

"test_sequence": [
  { "duration":  1, "mode": "conf_gt"         },
  { "duration":  1, "mode": "tx_rx_rst"       },
  { "duration":  1, "mode": "rx_datapath_rst" },
  { "duration":  1, "mode": "clear_status"    },
  { "duration": 60, "mode": "run"             },
  { "duration":  1, "mode": "check_status"    }
]

This will:

• Apply the configuration to the GTF, wait for 1 seconds.

• Trigger the GT global reset, wait for 1 seconds.

• Trigger the GT Rx datapath reset, wait for 1 seconds.

• Wait for 1 seconds then clear the status registers.

• Start the PRBS term and wait for 60 seconds.

• Wait for 1 second before reading the status registers and check the results. Then, clear the status registers.

prbs_error_threshold

Optional; Type : double; Possible values: from 0 to 100`; Default : 1e-9

This configuration will be applied to the four lanes simultaneously.

Define the BER threshold. The ratio quantity of correct / erroneous bit is computed every second. If it’s above the defined threshold, an error is reported.

disable_ref_prbs

Optional; Type : boolean; Possible values: true or false; Default : false

This configuration will be applied to the four lanes simultaneously.

When false the reference free running PRBS will be used to compare with incoming data (once locked and if error rate is below 10%).

When true the reference PRBS is never used and incomings data is always used to predict the next one.

gt_loopback

Optional; Type : string; Possible values: disable, near end pma or near end pcs; Default : disable.

This controls the GT internal loopback.

GT settings test JSON members

For the 3 types of GT test cases, the GT settings can be defined in a similar manner

• For the 4 lanes simultaneously: part of the global_config

  • Select one of the pre-defined configurations (gt_settings). The various configurations are stored in the Card definition JSON file (see Card definition).

  • Overwrite any settings of the selected configuration.

• For each lane individually: overwrite any settings of the selected configuration. Part of the lane_config

If required, these settings are simply added to your test JSON file within your test case definition. Here is an example with global selection, but it also includes global and per-lane specific overwrites.

"gt_mac": {
  "0": {
    "global_config": {
      "gt_settings": "module",
      "gt_rx_use_lpm": true
    },
    "lane_config": {
      "0": {
        "gt_rx_use_lpm": false,
        "gt_tx_diffctrl": 11
      },
      "1": {
        "gt_tx_main_cursor": 80
      },
      "2": {
        "gt_tx_pre_emph": 2,
      },
      "3": {
        "gt_tx_post_emph": 3,
      }
    }
  }
}

More info can be found here: GT Settings. Further details on each of settings can be found in:

• UltraScale+ GTF transceivers user guide (UG1549)

• Versal ACAP GTY and GTYP Transceivers Architecture Manual (AM002)

• Versal ACAP GTM Transceivers Architecture Manual (AM017)

gt_settings

Optional; Type : string; Possible values: module or cable; Default : module.

It selects the GT configuration from the Card definition JSON file (see Card definition). This configuration applies to all lanes of the GT.

gt_tx_diffctrl

Optional; Type : integer; Possible values: from 0 to 31; Default : defined in the Card definition JSON file (see Card definition).

This parameter sets the TXDIFFCTRL input to transmitter.

gt_tx_main_cursor

Optional; Type : integer; Possible values: from 0 to 127; Default : defined in the Card definition JSON file (see Card definition).

This parameter sets the TXMAINCURSOR input to transmitter.

gt_tx_pre_emph

Optional; Type : integer; Possible values: from 0 to 31 (GTF & GTYp) or 63 (GTM); Default : defined in the Card definition JSON file (see Card definition).

This parameter sets the TXPRECURSOR inputs to transmitter. It also set TXPRECURSOR2 and TXPRECURSOR3 of the GTM.

gt_tx_post_emph

Optional; Type : integer; Possible values: from 0 to 31 (GTF & GTYp) or 63 (GTM); Default : defined in the Card definition JSON file (see Card definition).

This parameter sets the TXPOSTCURSOR input to transmitter.

gt_tx_polarity

Optional; Type : string; Possible values: normal or inverted; Default : normal.

When set to normal, TXP is positive, and TXN is negative.

When set to inverted, TXP is negative, and TXN is positive.

gt_rx_polarity

Optional; Type : string; Possible values: normal or inverted; Default : normal.

When set to normal, RXP is positive, and RXN is negative.

When set to inverted, RXP is negative, and RXN is positive.

gt_rx_use_lpm

Optional; Type : boolean; Possible values: false or true; Default : defined in the Card definition JSON file (see Card definition).

When set to false, the GTY transceiver to use the DFE receive equalizer.

When set to true, the GTY transceiver to use the LPM receive equalizer.

Output file

All GT measurements are stored in an output CSV file generated in xbtest logging directory. The values are stored in CSV type format with one column for each information type.

Important

If the command line option -L is used while calling xbtest application software (xbtSW), no output file is generated.

For each GT PRBS xbtIP, one file is generated per lane with the suffix/extension _gt_<ip_index>.csv where:

• <ip_index> is the index of the GTF PRBS xbtIP.

Every second of run mode (see test_sequence), a new row containing measurements and test results for each lane is added in this file. Each lane has, at least, the following measurements and status stored every second:

• Test result: Set to FAIL if the current test fails per lane, otherwise set to PASS.

• Link Speed: in Gb/s.

• Bit Count: quantity of bit received.

• Bit Error Count: quantity of erroneous bit received.

• Acc Bit Count: quantity of bit received since the last clear_status (see test_sequence).

• Acc Bit Error Count: quantity of erroneous bit received since the last clear_status (see test_sequence).

• ber: BER computed since the last clear_status (see test_sequence).