GTYp & GTM PRBS test case description¶
The goal of this test case is to allow verification of 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.
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 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.
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.
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:
Configuration.
Reset.
Clear status.
Run.
Report/check status.
Test parameters¶
The mandatory test configuration parameters are listed below. For more information, see GT PRBS test JSON members.
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"} ]
}
}
}
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.
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 GTYp and GTM PRBS test cases.
|
|
---|---|
"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.
Member |
Lane override |
Mandatory / Optional |
Description |
---|---|---|---|
No |
Mandatory |
Describes the sequence of tests to perform. |
|
No |
Optional |
Define BER threshold |
|
No |
Optional |
Disable the usage of reference free running PRBS |
|
Yes |
Optional |
Select GT internal loopback. See GT JSON Member. |
|
No |
Optional |
Selects the GT default configuration. See GT JSON Member. |
|
Yes |
Optional |
Select the Driver Swing Control. See GT JSON Member. |
|
Yes |
Optional |
Select Transmitter pre-cursor TX main control. See GT JSON Member. |
|
Yes |
Optional |
Select Transmitter pre-cursor TX pre-emphasis control. See GT JSON Member. |
|
Yes |
Optional |
Select Transmitter post-cursor TX pre-emphasis control. See GT JSON Member. |
|
Yes |
Optional |
Select TX Polarity. See GT JSON Member. |
|
Yes |
Optional |
Select RX Polarity. See GT JSON Member. |
|
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 GT test sequence:
Member |
Mandatory / optional |
Description |
---|---|---|
|
Mandatory |
The duration of the test in seconds; Range [1, 232-1]. |
|
Mandatory |
Mode of the xbtIP. See the following table. |
Possible value |
Description |
---|---|
|
Apply the settings specified in the configuration parameters to the GT hardware. |
|
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 |
|
Enable the PRBS checker. |
|
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 |
|
Initiate a reset of the GT TX and RX paths. |
|
Initiate a reset of the GT RX datapaths. |
|
Insert a single PRBS error for lane <idx>: e.g. |
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 GT, 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:
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
(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
(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 GT 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 toPASS
.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).