Generation of crosstalk in a multi-lane link during lane testing

Abstract

A port of a computing device includes a plurality of receiver-transmitter pairs, and each of the receiver-transmitter pairs includes a respective receiver and a respective transmitter. The device also includes state machine logic that detects a training sequence received by a particular receiver-transmitter pair of the receiver-transmitter pairs from a tester device on a particular lane. The training sequence includes a value to indicate a test by the tester device on the particular receiver-transmitter pair. The particular receiver-transmitter pair enters a first link state in association with the test; and one or more other receiver-transmitter pairs of the port enter a second link state different from the first link state in association with the test to cause generation of crosstalk on the particular lane during the test.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 614,874, filed January 8, 2018, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to computing systems, and particularly (but not exclusively) to test systems for point-to-point interconnection. Background Technology

[0004] Advances in semiconductor processing and logic design have allowed for an increase in the amount of logic that can reside on integrated circuit devices. As a result, computer system configurations have evolved from a single or multiple integrated circuits in a system to multiple cores, multiple hardware threads, and multiple logic processors on a single integrated circuit, along with other interfaces integrated within such processors. A processor or integrated circuit typically comprises a single physical processor die, which can include any number of cores, hardware threads, logic processors, interfaces, memory, controller cores, etc.

[0005] Smaller computing devices are becoming increasingly prevalent due to the ability to pack more processing power into smaller packages. Smartphones, tablets, ultra-thin laptops, and other user devices are growing exponentially. However, these smaller devices rely on servers for data storage and complex processing that goes beyond the form factor. Consequently, demand in the high-performance computing market (i.e., server space) is also increasing. For example, modern servers typically contain not only a single processor with multiple cores, but also multiple physical processors (also known as multiple sockets) to increase computing power. Servers can also be implemented using distributed computing in rack-scale architectures, as well as other alternative implementations. As processing power grows with the number of devices in a computing system, communication between sockets and other devices becomes increasingly critical.

[0006] In fact, interconnects have evolved from more traditional multi-point buses that primarily handled electrical communications to fully interconnected architectures that facilitate rapid communication. Unfortunately, the corresponding demands of future processors consuming power at even higher speeds have placed pressure on the capabilities of existing interconnect architectures. Attached Figure Description

[0007] Figure 1 An embodiment of a computing system including an interconnect architecture is shown.

[0008] Figure 2 An embodiment of an interconnect architecture including a layered stack is shown.

[0009] Figure 3An example of a request or packet to be generated or received within an interconnect architecture is shown.

[0010] Figure 4 An embodiment of a transmitter and receiver pair for an interconnect architecture is shown.

[0011] Figure 5 This is a diagram illustrating the example link training state machine.

[0012] Figures 6A-6B This is a diagram showing an example device connected to a tester device for testing a specific channel of the link.

[0013] Figure 7 This is a diagram showing a portion of an example link training state machine that includes dedicated test link states.

[0014] Figure 8 This is a block diagram illustrating an example device connected to the tester device using an example conformity fixing device.

[0015] Figures 9A-9E This is a block diagram illustrating signaling within an example test link state.

[0016] Figure 10 An embodiment of a computing system including a multi-core processor is shown in the block diagram.

[0017] Figure 11 An embodiment of a block diagram of a computing system including multiple processors is shown. Detailed Implementation

[0018] Numerous specific details are set forth in the following description, such as examples of specific types of processors and system configurations, specific hardware architectures, specific architectural and microarchitectural details, specific register configurations, specific instruction types, specific system components, specific measurements / heights, specific processor pipeline stages and operations, etc., in order to provide a thorough understanding of the invention. However, it will be apparent to those skilled in the art that these specific details are not necessarily required to practice the invention. In other instances, the following well-known components or methods have not been described in detail to avoid unnecessarily obscuring the invention: for example, specific and alternative processor architectures, specific logic circuitry / code for the described algorithm, specific firmware code, specific interconnect operations, specific logic configurations, specific manufacturing techniques and materials, specific compiler implementations, specific algorithmic expressions in code form, specific power-down and gating techniques / logic, and other specific operational details of the computer system.

[0019] While the following embodiments (e.g., in a computing platform or microprocessor) may be described with reference to energy savings and energy efficiency in a particular integrated circuit, other embodiments are also applicable to other types of integrated circuits and logic devices. Similar techniques and teachings of the embodiments described herein can be applied to other types of circuits or semiconductor devices that can equally benefit from better energy efficiency and energy savings. For example, the disclosed embodiments are not limited to desktop computer systems or Ultrabooks. TM Furthermore, these methods can also be used in other devices, such as handheld devices, tablet computers, other thin-and-white notebook computers, system-on-a-chip (SoC) devices, and embedded applications. Some examples of handheld devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and handheld PCs. Embedded applications typically include microcontrollers, digital signal processors (DSPs), SoCs, network computers (NetPCs), set-top boxes, network centers, wide area network (WAN) switches, or any other system capable of performing the functions and operations taught below. Moreover, the apparatuses, methods, and systems described herein are not limited to physical computing devices and can also relate to software optimizations for energy conservation and efficiency. As will become apparent in the following description, embodiments of the methods, apparatuses, and systems described herein (whether referring to hardware, firmware, software, or combinations thereof) are essential for a future of “green technology” that balances performance considerations.

[0020] As computing systems evolve, their components become increasingly complex. Consequently, the complexity of the interconnect architectures used for coupling and communication between components also increases to ensure optimal bandwidth requirements for component operation. Furthermore, different market segments require different aspects of interconnect architectures to meet market demands. For example, servers demand higher performance, while the mobile ecosystem sometimes sacrifices overall performance for power savings. However, the single objective of most architectures is to provide the highest possible performance and maximum power savings. Many interconnects are discussed below that will potentially benefit from aspects of the invention described herein.

[0021] One interconnect architecture includes the Fast Peripheral Component Interconnect (PCIe) architecture. The primary goal of PCIe is to enable interoperability between components and devices from different vendors in an open architecture, spanning multiple market segments: clients (desktop and mobile), servers (standard, rack-scale, cloud, fog, enterprise, etc.), and embedded and communication devices. Fast PCI is a high-performance, general-purpose I / O interconnect defined for a variety of future computing and communication platforms. Some PCI properties (e.g., its usage model, load-memory architecture, and software interface) have been maintained through revisions, while previous parallel bus implementations have been replaced by highly scalable, fully serial interfaces. Recent versions of Fast PCI leverage improvements in point-to-point interconnects, switch-based technologies, and packetized protocols to achieve new levels of performance and features. Some of the advanced features supported by Fast PCI include power management, Quality of Service (QoS), hot-plug / hot-swap support, data integrity, and error handling.

[0022] refer to Figure 1 This illustrates an embodiment of a structure consisting of point-to-point links interconnecting a set of components. System 100 includes a processor 105 and system memory 110 coupled to a controller center 115. Processor 105 includes any processing element, such as a microprocessor, host processor, embedded processor, coprocessor, or other processor. Processor 105 is coupled to controller center 115 via a front-side bus (FSB) 106. In one embodiment, FSB 106 is a serial point-to-point interconnect as described below. In another embodiment, link 106 includes a serial differential interconnect architecture conforming to different interconnect standards. In some implementations, the system may include logic for implementing multiple protocol stacks and additional logic for negotiating alternative protocols to run on top of a common physical layer, among other example features.

[0023] System memory 110 includes any memory device, such as random access memory (RAM), non-volatile (NV) memory, or other memory accessible to devices in system 100. System memory 110 is coupled to controller center 115 via memory interface 116. Examples of memory interfaces include double data rate (DDR) memory interfaces, dual-channel DDR memory interfaces, and dynamic RAM (DRAM) memory interfaces.

[0024] In one embodiment, controller center 115 is a root center, root complex, or root controller in a Fast Peripheral Component Interconnect (PCIe or PCIE) interconnect hierarchy. Examples of controller center 115 include chipsets, memory controller centers (MCH), northbridges, interconnect controller centers (ICH), southbridges, and root controllers / centers. Often, the term chipset refers to two physically separate controller centers, namely, the memory controller center (MCH) coupled to the interconnect controller center (ICH). Note that current systems often include an MCH integrated with processor 105, while controller 115 communicates with I / O devices in a manner similar to that described below. In some embodiments, peer-to-peer routing may optionally be supported via root complex 115.

[0025] Here, the controller center 115 is coupled to the switch / bridge 120 via a serial link 119. Input / output modules 117 and 121 (also referred to as interfaces / ports 117 and 121) include / implement a layered protocol stack to provide communication between the controller center 115 and the switch 120. In one embodiment, multiple devices can be coupled to the switch 120.

[0026] Switch / bridge 120 routes packets / messages from device 125 upstream (i.e., hierarchically upwards towards the root complex) to controller center 115, and downstream (i.e., hierarchically downwards away from the root controller) from processor 105 or system memory 110 to device 125. In one embodiment, switch 120 is referred to as a logical component of a plurality of virtual PCI to PCI bridge devices. Device 125 includes any internal or external devices or components to be coupled to an electronic system, such as I / O devices, network interface controllers (NICs), insert cards, audio processors, network processors, hard drives, storage devices, CD / DVD ROMs, monitors, printers, mice, keyboards, routers, portable storage devices, Firewire devices, Universal Serial Bus (USB) devices, scanners, and other input / output devices. Often in PCIe, terms such as device are referred to as endpoints. Although not specifically shown, device 125 may include a PCIe to PCI / PCI-X bridge to support legacy or other versions of PCI devices. Endpoint devices in PCIe are often classified as traditional, PCIe, or root complex integrated endpoints.

[0027] The graphics accelerator 130 is also coupled to the controller center 115 via serial link 132. In one embodiment, the graphics accelerator 130 is coupled to the MCH, which in turn is coupled to the ICH. The switch 120, and therefore the I / O device 125, is then coupled to the ICH. I / O modules 131 and 118 are also used to implement a layered protocol stack for communication between the graphics accelerator 130 and the controller center 115. Similar to the MCH discussed above, the graphics controller or graphics accelerator 130 itself may be integrated into the processor 105. Furthermore, one or more links in the system (e.g., 123) may include one or more extension devices (e.g., 150), such as retimers, repeaters, etc.

[0028] Go to Figure 2 This illustrates an embodiment of a layered protocol stack. The layered protocol stack 200 includes any form of layered communication stack, such as a Fast Path Interconnect (QPI) stack, a PCIe stack, a next-generation high-performance computing interconnect stack, or other layered stacks. (See the reference below.) Figure 1-4 The discussion relates to the PCIe stack, but the same concepts can be applied to other interconnect stacks. In one embodiment, protocol stack 200 is a PCIe protocol stack including transaction layer 205, link layer 210, and physical layer 220. Interfaces (e.g., Figure 1 Interfaces 117, 118, 121, 122, 126, and 131 in the code can be represented as communication protocol stack 200. A representation of a communication protocol stack can also be called a module or interface that implements / includes the protocol stack.

[0029] Fast PCI uses packets to transmit information between components. Packets are formed in transaction layer 205 and data link layer 210 to carry information from the sending component to the receiving component. As the transmitted packets flow through other layers, they are expanded with additional information necessary for processing the packets at those layers. On the receiving side, the reverse process occurs, and packets are transformed from their physical layer 220 representation to their data link layer 210 representation, and finally (for transaction layer packets) into a form that can be processed by the transaction layer 205 of the receiving device.

[0030] Transaction layer

[0031] In one embodiment, transaction layer 205 provides an interface between the device's processing core and the interconnect architecture (e.g., data link layer 210 and physical layer 220). In this regard, the primary responsibility of transaction layer 205 is the assembly and disassembly of packets (i.e., transaction layer packets or TLPs). Transaction layer 205 typically manages credit-based flow control for TLPs. PCIe implements decoupled transactions, i.e., requests and responses are time-separated transactions, allowing the link to carry other traffic while the target device collects data for the response.

[0032] Additionally, PCIe utilizes credit-based flow control. In this scheme, the device announces the initial credit amount for each receive buffer in the receive buffer at transaction layer 205. External devices at the opposite end of the link (e.g., Figure 1 The controller center (115) in the system counts the amount of credit consumed by each TLP. A transaction can be sent if it has not exceeded the credit limit. A certain amount of credit is restored upon receiving a response. The advantage of this credit scheme is that the delay in credit return does not impact performance if no credit limit is encountered.

[0033] In one embodiment, the four transaction address spaces include a configuration address space, a memory address space, an input / output address space, and a message address space. Memory space transactions include one or more read and write requests for transferring data to or from a memory-mapped location. In one embodiment, memory space transactions can use two different address formats, such as a short address format (e.g., a 32-bit address) or a long address format (e.g., a 64-bit address). Configuration space transactions are used to access the configuration space of a PCIe device. Configuration space transactions include read and write requests. Message space transactions (or simply messages) are defined as supporting in-band communication between PCIe agents.

[0034] Therefore, in one embodiment, transaction layer 205 assembles the packet header / payload 206. The format of the current packet header / payload can be found in the PCIe specification on the PCIe specification website.

[0035] Quick Reference Figure 3 The diagram illustrates an embodiment of a PCIe transaction descriptor. In one embodiment, transaction descriptor 300 is a mechanism for carrying transaction information. In this respect, transaction descriptor 300 supports the identification of transactions in the system. Other potential uses include tracking modifications to the default transaction ordering and associating transactions with channels.

[0036] Transaction descriptor 300 includes a global identifier field 302, an attribute field 304, and a channel identifier field 306. In the illustrated example, the global identifier field 302 is depicted as including a local transaction identifier field 308 and a source identifier field 310. In one embodiment, the global transaction identifier 302 is unique for all incomplete requests.

[0037] In one implementation, the local transaction identifier field 308 is a field generated by the request broker, and it is unique for all incomplete requests that the request broker is required to complete. Furthermore, in this example, the source identifier 310 uniquely identifies the requester broker within the PCIe tier. Therefore, together with the source ID 310, the local transaction identifier field 308 provides a global identifier for transactions within the tier domain.

[0038] Attribute field 304 specifies the characteristics and relationships of a transaction. In this respect, attribute field 304 can potentially be used to provide additional information that allows modification of the default processing of a transaction. In one embodiment, attribute field 304 includes a priority field 312, a reservation field 314, an ordering field 316, and a non-listening field 318. Here, the priority subfield 312 can be modified by the initiator to assign a priority to a transaction. The reserved attribute field 314 is reserved for future use or vendor-defined use. Reserved attribute fields can be used to implement possible use models that utilize priority or security attributes.

[0039] In this example, the sort attribute field 316 provides optional information conveying the sort type that can modify the default collation. According to one example implementation, sort attribute "0" indicates that the default collation should be applied, while sort attribute "1" indicates a non-strict sort, where writes can propagate in the same direction, and read completions can propagate writes in the same direction. The listen attribute field 318 determines whether a transaction is being listened to. As shown, the channel ID field 306 identifies the channel to which the transaction is associated.

[0040] Link layer

[0041] Link layer 210 (also referred to as data link layer 210) acts as an intermediate stage between transaction layer 205 and physical layer 220. In one embodiment, the responsibility of data link layer 210 is to provide a reliable mechanism for exchanging transaction layer packets (TLPs) between the two link components. One side of data link layer 210 receives a TLP packet assembled by transaction layer 205, applies a packet sequence identifier 211 (i.e., an identifier number or packet number), calculates and applies an error detection code (i.e., CRC 212), and submits the modified TLP to physical layer 220 for transmission across physical to external devices.

[0042] Physical layer

[0043] In one embodiment, physical layer 220 includes a logic subblock 221 and an electronic block 222 for physically transmitting packets to external devices. Here, logic subblock 221 is responsible for the "digital" functions of physical layer 220. In this respect, the logic subblock includes a transmitting portion for preparing outgoing information for transmission by physical subblock 222, and a receiving portion for identifying and preparing received information before passing it to link layer 210.

[0044] Physical block 222 includes a transmitter and a receiver. The transmitter, provided with symbols by logic subblock 221, serializes the symbols and transmits them to an external device. The receiver is provided with serialized symbols from the external device, and the receiver converts the received signals into a bit stream. The bit stream is deserialized and provided to logic subblock 221. In one embodiment, an 8b / 10b transmission code is used, where ten-bit symbols are transmitted / received. Here, special symbols are used to frame packets into frames 223. Additionally, in one example, the receiver also provides a symbol clock recovered from the incoming serial stream.

[0045] As stated above, while the transaction layer 205, link layer 210, and physical layer 220 have been discussed with reference to specific embodiments of the PCIe protocol stack, the layered protocol stack is not limited thereto. In fact, any layered protocol can be included / implemented. As an example, a port / interface represented as a layered protocol includes: (1) a first layer for assembling packets, i.e., the transaction layer; a second layer for ordering packets, i.e., the link layer; and a third layer for transmitting packets, i.e., the physical layer. As a specific example, the Common Standard Interface (CSI) layered protocol is used.

[0046] Next reference Figure 4 An embodiment of a PCIe serial point-to-point architecture is illustrated. While an embodiment of a PCIe serial point-to-point link is shown, the serial point-to-point link is not limited to this, as it includes any transmission path for transmitting serial data. In the illustrated embodiment, the basic PCIe link includes two low-voltage differential drive signal pairs: transmit pair 406 / 411 and receive pair 412 / 407. Therefore, device 405 includes transmit logic 406 for transmitting data to device 410 and receive logic 407 for receiving data from device 410. In other words, two transmit paths (i.e., paths 416 and 417) and two receive paths (i.e., paths 418 and 419) are included in the PCIe link.

[0047] A transmission path refers to any path used to transmit data, such as a transmission line, copper line, optical line, wireless communication channel, infrared communication link, or other communication path. A connection between two devices (e.g., device 405 and device 410) is called a link, such as link 415. A link can support a channel—each channel represents a set of differential signal pairs (one pair for transmitting and one pair for receiving). To extend bandwidth, a link can aggregate multiple channels represented by xN, where N is any supported link width, such as 1, 2, 4, 8, 12, 16, 32, 64, or wider.

[0048] A differential pair refers to two transmission paths, such as lines 416 and 417, used to transmit differential signals. As an example, when line 416 switches from a low voltage level to a high voltage level (i.e., rising edge), line 417 is driven from a high logic level to a low logic level (i.e., falling edge). Differential signals potentially exhibit better electrical characteristics, such as better signal integrity, i.e., less cross-coupling, voltage overshoot / undershoot, ringing, etc. This allows for better timing windows, enabling faster transmission frequencies.

[0049] In some implementations, a high-performance interconnect and corresponding interconnect protocol (e.g., a next-generation PCIe-based interconnect) can be provided, capable of operating at high speeds such as 25GT / s and / or 32GT / s. In one example, two speeds, 25GT / s and 32GT / s, can be defined for the high-performance interconnect based on channel-specific characteristics (e.g., during link training). In one implementation, the interconnect can be backward compatible with existing PCIe generations and the speeds offered for those generations (e.g., 8GT / s, 16GT / s, etc.).

[0050] Go to Figure 5 Figure 500 illustrates an example link training state machine, such as the PCIe Link Training and State Machine (LTSSM). Transitions between various link states can be defined, including signaling that occurs to notify another system on the link, or to complete a handshake between interconnected devices to request, negotiate, and / or acknowledge a transition from one state to the next, leading to an active transmit link state (e.g., L0(520)). For example, some state transitions can be defined as involving the transmission and reception of training set (TS) ordered sets (OS). In implementations utilizing PCIe as the PHY protocol, the TS ordered sets may include TS1 and TS2 ordered sets, as well as other example ordered sets. The ordered sets and training sequences transmitted during link training can be based on specific link training states, where various link training states are used to accomplish corresponding link training activities and objectives.

[0051] In one example, for instance, such as Figure 5As shown, the link training state machine 500 may include the following states: for example, a reset state, a detection state 505 (e.g., for detecting a remote terminal (e.g., another device connected to the channel)), a polling state 510 (e.g., for establishing symbol locks and configuring channel polarity), a configuration (or "Config") state 515 (e.g., for configuring the connected physical channel as a link with a specific channel width, channel number, etc., performing channel-to-channel deskipation, and other link configuration activities), a loopback state 535 (e.g., for performing tests, fault isolation, equalization, and other tasks), a recovery state 540 (e.g., for changing the data rate of operation, re-establishing bit locks, symbol locks, or block alignment, performing channel-to-channel deskipation, etc.), and other states that can be used to bring the link to an active link state (e.g., L0(520)) (e.g., low-power states L1(525) and L2(530)). In one example, a training sequence to be sent in a specific link training state (e.g., in Figure 5 (As shown in the example) can be defined as the negotiation of a specific support protocol in the support protocols for a particular device. For example, a specific training state can be a training state prior to entering an active link state (e.g., 520), or a training state in which the data rate can be increased (e.g., exceeding the data rate supported by at least one of the support protocols), such as a PCIe state where the data rate transitions from Gen1 speed to Gen3 and higher speeds, and other examples.

[0052] In some implementations, additional link states (and corresponding hardware circuitry and other logic implemented on devices compatible with the interconnect protocol) can be defined to support testing of ports on the device. For example, additional states can be defined that can be input to support testing of individual channels (i.e., the hardware and logic by which the device sends and receives data on a given bidirectional channel). In such instances, the link state machine can be extended (e.g., Figure 5 The example link state machine introduced in the example allows state transitions to deviate from the expected situation when the training link is to the default or standard operating state, so that the channel under test can transition to the first state, while other channels of the multi-channel link will transition to different states to support the testing of the channel under test.

[0053] In some instances, conventional tester devices (e.g., conventional BERTs) may only test a single channel, and the device may be programmed or designed (for various reasons) to limit the channels that can be tested. For example, a conventional PCIe BERT may only be able to test channel 0 of a PCIe device (e.g., due to other competing transmitter equalization considerations) and may be further restricted to only being able to use existing PCIe LTSSM conversions. For example, a conventional BERT might train the DUT to L0 (e.g., causing channel 0 correlation), perform equalization via recovery, convert from recovery to loopback (with the BERT as the master), and then continue testing the receiver.

[0054] Additionally, in some traditional implementations, the tester may not use or may cause real (near-end or far-end) crosstalk to be generated from other channels (not under test), but using approximations in BERT to artificially inject additional noise into the signal transmitted on the channel under test during testing can lead to model-assumed (and in many cases, worst-case) crosstalk (e.g., combined near-end and far-end crosstalk). However, when interconnects are designed to handle increased data rates (e.g., 32.0 GT / s (e.g., PCIe Gen4)), testing accurate encapsulation and channel-introduced crosstalk may be more critical by accurately capturing the actual crosstalk caused by the actual design of the packets rather than relying on approximations, as higher data rates allow for increasingly smaller margins of error. In some cases, multi-channel BERT can be provided, which can simplify the implementation of tests involving more than one channel at a time, but in some applications such systems may be too expensive. Alternatively, the link training state machine can be extended (e.g., Figure 5 (As shown in the example), and corresponding logic is provided in the compliant device to allow for a more cost-effective and accurate approach using traditional single-channel BERT designs. In fact, in some implementations, not only far-end crosstalk (FEXT) (e.g., crosstalk generated by transmissions from a remote device to the device under test) can be captured, but also near-end crosstalk (NEXT) (e.g., crosstalk generated by transmissions from channels other than the victim channel (e.g., the channel under test) on the device under test). For example, these new test-enabled link states can allow NEXT to be captured from other transmitters on the DUT and / or allow FEXT to be captured by allowing signals to be sent to receivers on other channels on other devices under test, while the channel under test remains in loopback and other states during BERT testing, among other example advantages and implementations.

[0055] In some implementations, the link state logic can be extended to support not only the default or standard link state machine and transitions between states defined in the standard link state machine, but also dedicated test states. This allows individual channels of a multi-channel link to be tested using test equipment (e.g., die-edge limit testers, independent bit error rate testers (BERT) devices, etc.), while other channels of the link generate far-end crosstalk (FEXT) and / or near-end crosstalk (NEXT). Using these dedicated states and state machine transitions, far-end crosstalk (or FEXT) and near-end crosstalk (or NEXT) can be generated on the untested channels to accommodate precise testing of the channel under test (or, in the case of a multi-channel tester, precise testing of multiple channels under test). While traditional channel testing involves injecting artificial or simulated noise into the data of the channel under test, this simulated noise is typically forced to model worst-case scenarios, which may ignore the actual characteristics of the port under test (e.g., it may be equipped with circuitry and components to help minimize crosstalk on the device (testing with simulated worst-case crosstalk is overly pessimistic and impractical)). Therefore, in some cases, dedicated test link status can provide more realistic boundary information at higher data rates (e.g., PCIe Gen 5 at 32.0 GT / s), which is the opposite of traditional methods that rely on simulated crosstalk.

[0056] In some implementations, the standard or default link training state machine defined for the interconnect can be extended to support dedicated test link states. This allows ports to train the link so that different channels of the link enter different states, allowing some channels to be tested (e.g., running channels through link training expected in default operation or defined for default operation and link state transitions), while other channels enter one of several potentially different states to provide real (rather than synthetic) crosstalk and implement multiple realistic test modes. In one example, the link training algorithm can be extended to identify and select one or more specific channels of the link to be tested by a test device (e.g., BERT). During testing, the selected channels can be driven by the test device. The remaining channels of the device under test (DUT) can be self-trained or can be placed in an idle or other quiet state, while BERT combines the test drive of the channel (or the channel under test (LUT)) with link training and state machine (LTSSM) changes on the channels it controls. In some implementations, the link can be placed in a loopback state initiated by the test device (e.g., by sending a dedicated ordered set of links to the DUT using the link by the test device). In such an example, when the link enters a loopback, based on the training information sent by the tester device on the channels connected to the tester device, the DUT can either drive the (modified) compliance mode in Loopback.Entry on all other channels, or remain in transmitter electrical idle on all other channels (i.e., other channels not being tested). In this way, the DUT itself can be used to generate the crosstalk expected to complete testing of one or more channels of the DUT (e.g., corresponding receiver-transmitter pairs), while the tester device manages the specific channels it wants to test. Furthermore, the DUT can also be trained with the tester device to a state where all other receivers on the DUT can receive traffic without affecting the loopback on the channels being tested by the tester device, and other examples, such as those discussed below.

[0057] Go to Figures 6A-6B Simplified block diagrams 600a-b are provided, and the example system is shown as including an example computing device (e.g., 605) and an example test device (e.g., 610a, b). Figure 6AIn the example, a single-channel bit error rate tester (BERT) device 610a is shown, which can be used to connect to a single channel (e.g., 630b) of a device under test (e.g., 605) and perform various boundary and other tests on the channel. In this example, computing device 605 may include one or more data processing cores (e.g., 615) and / or other data processing circuitry that can communicate with other devices via one or more interconnect links using a hierarchical interconnect stack 620 (e.g., PCIe, UPI, Ethernet, OpenCAPI, Gen-Z, or other hierarchical interconnect stacks). The interconnect stack 620 can be implemented using logic circuitry and other hardware (and, alternatively, using software-implemented logic and / or firmware-implemented logic) to support and implement each layer in the interconnect layers (e.g., physical layer, logical PHY, data link layer, transaction layer, protocol layer, etc.), including generating and transmitting data units defined for the interconnect (e.g., packets, frames, flits, phits, etc.). The interconnect stack 620 also enables the device(s) to enter and transition between various operation and link states defined for the interconnect, including link training and testing states with defined ordered sets, training sequences, handshakes, and other signaling defined to enable two interconnected devices to orchestrate the training and transmission of data on the link according to the corresponding interconnect protocol. This logic may include state machine logic implemented at least in part in the logic circuitry or other hardware of the computing device 605.

[0058] continue Figure 6A For example, interconnect stack logic 620 can be extended in some implementations to support additional test-specific link states and link state transitions, such as those described in the discussion above. For instance, interconnect stack logic 620 implemented on device 605 may include test mode support logic 625, which is implemented at least partially using hardware logic circuitry. Test mode logic 625 can implement additional test link states and manage transitions to these test states and coordination of how test link states are applied during testing on which channels (e.g., 630a-d). Within this disclosure, "channel" may alternatively refer to the physical channel that implements the link connecting two devices, or the corresponding receiver / transmitter pair and the support logic (e.g., 630a-d) on the device (e.g., 605) that couples the device to the corresponding physical channel of the link.

[0059] exist Figure 6AThe example illustrates a single-channel BERT 610a, which can be individually coupled to and tested on each of multiple different channels. Test mode logic 625 enables the identification of a specific channel under test (e.g., 630b) and, in conjunction with testing the channel, causes the channel under test (i.e., the receiver / transmitter pair of the port of device 605 connected to the bidirectional channel coupled to the device under test 605 to the BERT device 610a) to enter one of the test link states (e.g., loopback, active transmit link state, link training state, etc.). In some cases, the BERT 610a can direct the channel under test to enter which link state(s) during testing. During testing, test mode logic 625 can identify one or more other channels (i.e., those other than the channel under test) to enter other test link states to support the BERT device's testing of the channel under test. For example, test mode logic 625 can cause one or more (or all) channels (e.g., 630a, c, d) other than the channel under test (e.g., 630b) to enter a link state so that these channels can generate near-end and / or far-end crosstalk on the victim channel under test (e.g., 630b).

[0060] In some implementations, channels other than the channel under test can remain unconnected to the utility device (e.g., separate from BERT but supporting BERT), connected to the utility device, or connected to BERT itself. In some implementations, as illustrated in Figure 6, the tester device (e.g., a multi-channel BERT device (e.g., 605b)) can be configured with multiple channels (e.g., receiver / transmitter pairs) to connect to multiple channels of the device under test. A multi-channel tester (e.g., 610a-b) can connect to each of the channels (e.g., 630a-d) of the device under test (605). The multi-channel tester can continuously test each channel of the device under test without reconnecting the channels. Additionally, the multi-channel tester can work in conjunction with test mode logic 625 on the device under test 605 to use support test link states to help generate FEXT and NEXT on those channels that are not currently being tested, among other example implementations.

[0061] Go to Figure 7 Figure 700 shows a simplified block diagram of 700, which illustrates a portion of an expanded link state machine diagram. This portion shows dedicated test link states (e.g., 705, 710, 715, 720) that can be added to the state machine to facilitate testing of individual channels of the link. For example, in Figure 7 In the example, the extended state machine can be an extended version of the PCIe link state machine, for example, in Figure 5As illustrated in Figure 500. For example, standard link states defined for a state machine (e.g., according to the corresponding interconnection protocol) may include receiver detection states (e.g., 505), polling states (e.g., 510), configuration states (e.g., 515), and potentially other link training states that can be entered and used before transitioning to an active, transmitting, or operational link state (e.g., L0 state (not shown)), as well as other example states. During link training, various ordered sets (e.g., training sequences (e.g., PCIe TS1 or TS2 training sequences)) may be transmitted, which may include fields encoded to provide information specific to the link training state and define various aspects of the link (e.g., channel number, deskew, synchronization, bit locking, configuration, etc.). In some implementations, the link can be trained efficiently channel by channel, where each receiver-transmitter pair sends and receives its own instance of training sequences to configure and train each channel to the desired parameters, allowing the entire link to be trained reliably. As examples, symbol locking, bit locking, and block alignment can be performed on a per-channel basis, where the training sequence sent on each channel is adapted to achieve the correct configuration for that channel. In some cases, ordered sets of the same type can be sent synchronously on each channel in the link (but the values ​​in each ordered set can vary depending on the channel), and other examples exist.

[0062] exist Figure 7 In the examples, one or more fields of the training sequence transmitted during one or more link training states defined in the standard states of the link state machine can be extended to provide an indication that a device participating in the training will enter test mode. For example, bits in one or more symbols of the training sequence transmitted in a specific, defined state or substate of the state machine can be defined to convey that the device will be tested. Furthermore, one or more bits or fields in the training sequence can be defined to indicate that a tester device (e.g., BERT) is connected to one or more channels of the link and that these channels will be tested. Additionally, one or more bits or fields of the same (or different or subsequent instances thereof) training sequence can be encoded with information indicating that other untested channels should transition to other test link states to help facilitate testing of specific channels. Furthermore, in conjunction with the identification of a specific channel to be tested, the training sequence can be encoded to indicate that the specific channel to be tested will enter another link state, consistent with the type of test to be performed, and other examples.

[0063] In one example implementation, the tester device can encode a training sequence sent during a polling state (e.g., 510) (or another specific link training state as defined in the interconnection protocol) to indicate that a specific channel of the link will be tested, and that the remaining channels of the link will transition to another test link state to support testing of the specific channel. Therefore, instead of transitioning all channels together from polling state 510 to the next standard link training state (e.g., configuration state 515), an extended field of the training sequence allows the device under test to transition the channel under test to a specific link state for that channel (e.g., 705), while transitioning the remaining channels to another test link state (e.g., 710, 715, 720) to support testing of the channel under test, and in some cases, to generate real crosstalk on the channel under test for various tests of the channel under test (LUT) performed by the tester device (e.g., a single-channel or multi-channel BERT).

[0064] In some instances, test link states (e.g., 705, 710, 715, 720) may be based on or include one or more standard link states (e.g., active link states or loopback link states, and others). In practice, in some cases, the tester device may interact with a specific channel to simulate the operation of a receiver / transmitter connected to that channel as it transitions between states within a standard link state machine. For example, the tester device may act as a loopback master within a loopback state, or it may send signals during testing, as defined in a standard link training machine, to cause the channel under test to transition between standard link training states. Even where a LUT test state (e.g., 705) may mimic or include standard link states, the transitions to that link state or substate during testing may differ from those defined in the standard link training machine. For example, because LUT test state 705 involves testing only a single channel, the activities involved in training all channels into the state (during typical link training and state machine transitions) may be skipped. For example, activities such as channel numbering, channel-to-channel deskewing, and others can be skipped, which can even allow skipping the entire intermediate link training state. In other cases, apart from the differences in transitions to these test link states (e.g., from polling state 510), the activities and signaling within LUT test state 705 and test link states for the remaining (untested) channels (e.g., 710, 715, 720) can be completely different from the states defined in the standard link state machine. For example, LUT test state 705 can be entirely defined by the tester device (e.g., BERT), where the tester device is free to send any kind of signal to simulate various conditions, state transitions, states, etc., as combined with specific test expectations, while other test link states (e.g., 710, 715, 720) cause the remaining channels of the link to inject (or not inject) crosstalk into the channel under test.

[0065] exist Figure 7In the examples, some test link states may include states such as those shown in example Figure 700. For example, a test link state 710 may be adapted to generate near-end crosstalk (NEXT) on a channel different from the channel under test. In another example, a test link state (e.g., 715) may be adapted to generate only far-end crosstalk (FEXT) (while the transmitters of the receiver / transmitter pair of the untested channel remain silent). In yet another example, a test link state (e.g., 720) may generate both NEXT and FEXT using the untested channel, and other examples exist. For example, multiple versions of NEXT (e.g., 710), FEXT only (e.g., 715), and NEXT / FEXT test link states (e.g., 720) may be provided and supported by the internal hardware and / or software logic of the device under test. For example, different types of stress signals may be transmitted within different test link states to generate corresponding types of crosstalk, such as crosstalk of different severity (e.g., amplitude and frequency), intermittent or continuous crosstalk, and other examples exist.

[0066] In some instances, to achieve certain test link states, additional devices can be provided in conjunction with the tester device (e.g., 610), such as a signal generator (e.g., to generate far-end crosstalk), or as in... Figure 8 The example block diagram 800 shows the conformity fixing device 805, and other examples. Figure 8In the example, a conformance fixing device 805 is provided, which can allow connection to untested channels (i.e., corresponding receiver / transmitter pairs) in the case of a single-channel BERT 610. In addition to or in combination with a single-channel BERT 610, the example passive conformance fixing device 805 can be used to help facilitate one or more test modes. In one example, the conformance fixing device 805 can be connected to each channel in the link (i.e., including the channel to be tested by the BERT 610) and facilitate test modes involving the set of channels, and enable the tester device 610 to selectively connect to any one of the channels via mechanisms in the conformance fixing device 805 (e.g., via jumpers, DIP switches, or other circuitry). Thus, the conformance fixing device 805 can enable the tester device 610 to connect to any particular channel (e.g., to continuously perform single-channel testing of each channel in the DUT 605) while connecting the transmitter of each of the remaining channels of the DUT 605 to another endpoint (e.g., on the conformance fixing device 805). Additionally, in some implementations, the compliance fixing device 805 can be configured to operate in loopback mode for all channels except the channel under test (e.g., 810). In this way, the compliance fixing device 805 can efficiently connect the transmitter of each channel in the untested channel to the corresponding receiver of the same receiver / transmitter pair, placing any (or all) of these other channels in self-loopback (e.g., Figure 8 (as shown), and other example implementations. Among the other implementations, Figure 8 The functionality of the example conformance fixing device 805 shown can be integrated into a multi-channel BERT device or other tester device, as well as other alternative implementations.

[0067] Go to Figures 9A-9E The examples shown in block diagrams 900a-e illustrate various test modes for corresponding test link states utilizing standard link state machines with complementary interconnects. For example, in Figure 9A In the example, a computing device 605, including receiver / transmitter pairs (and supporting logic) for implementing a bidirectional channel in a multi-channel link (e.g., 630a-630), can be connected to a tester device 610. The tester device can be a standalone tester (e.g., a BERT used in verification testing), or a tester device implemented on a die or otherwise within the same computing system as device 605, among other examples. Figure 9AIn this example, the training sequence can be sent in a previous link state (e.g., a polling link state) to instruct device 605 to connect to the tester device and enter a specific test mode. In this example test mode, one channel (e.g., 630c) will be tested by tester device 610 and enter a state in which the normal operation of test simulation channel 630c will be combined. In this example, untested channels (e.g., 630a, b, d, e) will remain silent (e.g., to avoid generating crosstalk). Since the tested channel 630c is the only receiver connected to another device (e.g., 610) and receiving the training sequence, only the receiver / transmitter pair 630c receives the training sequence. The test mode support logic can identify the training sequence(s) requesting entry into a specific test mode and can cause receiver / transmitter pair 630c to enter the link-under-test state, while the remaining receiver / transmitter pairs (e.g., 630a, b, d, e) enter a different test link state according to the identified test mode. In this example, the remaining receiver / transmitter pairs (e.g., 630a, b, d, e) are put into a test link state, where no data is transmitted by the corresponding transmitters of the receiver / transmitter pairs (e.g., 630a, b, d, e), and all signals are ignored by the receivers of the remaining receiver / transmitter pairs (e.g., so that the protocol stack logic of the receiver / transmitter pairs (e.g., 630a, b, d, e) will not inadvertently interpret noise on their respective channels as legitimate signals as defined by the protocol stack).

[0068] In some implementations, the training sequence sent from tester device 610 to device under test 605 can identify not only the specific channel to be tested (e.g., the channel receiving the dedicated training sequence), but also a specific test mode from a set of test modes. For example, binary code can be injected into one or more fields of the dedicated training sequence (e.g., fields otherwise reserved in specific symbols sent in the training sequence within a specific link training state (e.g., a polling state)) to identify the specific test mode from a set of supported test modes. Based on this encoding, device under test 605 can identify that the specifically identified test mode maps to one of a set of test link states defined in an extended link state machine, and directs the remaining channels into that test link state to support the identified test mode. In other implementations, instead of explicitly identifying the defined test modes (e.g., by encoding in the dedicated training sequence), tester device 610 can implicitly identify the test modes by providing encoding to identify the test link states(s) that channels of device under test 605 will enter to support the tests requested by tester device 605. For example, in one example implementation, the training sequence can identify the LUT test link state that the channel under test will enter, and can also individually identify one of the supporting test link states that the remaining channels (not under test) will enter. In other implementations, the encoding within the training sequence can identify the specific channel to be tested, and can explicitly identify only the supporting test link states that the remaining channels (not under test) will enter, and so on. In fact, it should be understood that various signals (e.g., ordered sets, training sequences, etc.) can be used to send a request to the device under test to enter a specific test mode. Various encodings, including various information and encoded in various symbols, fields, time slots, etc., can be used in various implementations without departing from the more generalized concepts presented herein.

[0069] Go to Figure 9B The example illustrates another example test pattern. As in other examples, for instance, Figure 9A As shown, tester device 610 can send a signal to the receiver of a specific channel under test (e.g., 630c) and (explicitly or implicitly) identify the specific test mode (defined or undefined) to be entered. The receiver / transmitter pair of channel 630c can identify, based on the signal, the specific test link state among multiple test link states that the remaining channels (e.g., 630a, b, d, e) will enter, in order to support the test requested by tester device 610. Similarly, in Figure 9C-9EIn the example, device 605 can receive a corresponding signal from tester device 610 (at the channel under test) to enable device 605 to switch the remaining channels (untested) to the corresponding test link state (as will be described in more detail in the example below). Figure 9B In the example scenario, the remaining channels are forced to switch to test link state, causing the transmitters of the receiver / transmitter pairs on these remaining channels to generate near-end crosstalk (NEXT) on the victim channel 630c under test. This can be accomplished by the receiver / transmitter pairs on the remaining channels transmitting stress data on their transmitters. Furthermore, in this example (as in...), Figure 9A In the example test state), the receivers of these receiver / transmitter pairs can ignore all signals received in that test link state (e.g., to avoid misinterpreting noise that may be received at these receiver / transmitter pairs).

[0070] Go to Figure 9C The example provided can provide another example of test link status, which allows both NEXT and FEXT to be generated using an untested channel. In one example, this test link status can be achieved by looping back the stress data generated at the transmitter of a receiver / transmitter pair on an untested channel (e.g., 630a, b, d, e). Figure 9C In the example, compliance fixing device 805 can be used to facilitate loopback of stress data generated at the transmitter of the receiver / transmitter pair on the untested channel, resulting in both NEXT and FEXT being displayed on the tested channel. Because test link states can coexist with standard link states defined in the protocol's link state machine (e.g., allowing these channels to later exit test link states and transition between standard link states during normal (i.e., non-test) operation), there is a risk that stress data sent to the receiver of the untested channel's receiver / transmitter pair might inadvertently match other signals defined within the protocol that facilitate other (e.g., non-test) actions (e.g., transitioning to another (e.g., non-test) link state, performing specific link training functions, etc.) on a portion of the protocol stack logic of these receiver / transmitter pairs. Therefore, in the test link state where the receivers of the receiver / transmitter pairs in the untested channels will receive stress data, the protocol stack logic of these receiver / transmitter pairs can efficiently ignore the substance or content of these stress signals while in these test link states, so that the test link state will not unintentionally exit or otherwise interrupt.

[0071] Although Figure 9CThe example illustrates the use of compliance fixed device 805 to facilitate NEXT / FEXT loopback states, but other implementations can use other devices (including the tester device itself, e.g., in a multi-channel BERT) to facilitate loopback of stress data. In this example, the compliance fixed device can also be used as a retimer, re-driver, repeater, or other data forwarding device to simply forward data to and from the channel under test and the single-channel tester (e.g., 610). For example, the compliance fixed device can utilize switching or multiplexing circuitry to identify a specific channel (e.g., 630c) in the channel being tested by the tester, thereby enabling data forwarding for that channel while enabling loopback or transmission modes for the remaining channels of the compliance fixed device connected to the untested channel (i.e., the corresponding receiver of device 605 connected to the receiver / transmitter pair (e.g., 630a, b, d, e)).

[0072] In yet another example, such as Figure 9D As shown, other test link states may result in only far-end crosstalk being generated using the remaining untested channels. For example, a stress signal can be generated at another device, such as a signal generator device (e.g., 905), and sent to the receiver / transmitter pair of the untested channels (e.g., 630a, b, d, e). In this example test link state, the transmitter of the receiver / transmitter pair of the untested channel can be placed in idle mode, so that no data is intentionally sent to generate NEXT on the tested channel (e.g., 630c). Additionally, as in Figure 9CIn the example (and other test link states where pressure data is received by untested channels during testing of the channel under test), the receivers of untested receiver / transmitter pairs (e.g., 630a, b, d, e) can ignore the pressure data generated by signal generator 905. In some implementations, the signal generator (e.g., 905) used in testing a specific channel (e.g., 630c) can be coupled to and driven by tester device 610, allowing tester device 610 to select which pressure signals (e.g., multiple signal generators, e.g., 905) to transmit on which channels, at what time, and at what interval (e.g., to achieve a specific objective of the test managed by the tester device, which can be selected, programmed, and otherwise defined by a human user or other system using a software interface). In other instances, signal generators or other supplementary devices can be additionally used to support other test link states, such as NEXT / FEXT test link states, where pressure data will be transmitted and received by device 605 on untested channels. In such an instance, the signal generator may include a receiver to receive (e.g., and efficiently ignore and process) pressure signals transmitted by the transmitter of a receiver / transmitter pair that has never been tested (e.g., 630a, b, d, e), and other examples.

[0073] exist Figures 9A-9D The example shown depicts a single-channel tester device. However, in some implementations, a multi-channel tester device may be provided. Therefore, in addition to the test link states specific to a single-channel tester, the device (e.g., 605) can add and support additional test link states. In some cases, for example, Figure 9E As shown in the example, the same test link state used with a single-channel tester can be used to support testing using a multi-channel tester. In fact, multi-channel testers can simplify the implementation of various test modes (which would otherwise require supplementary devices such as compliance fixing devices (e.g., 805), signal generators (e.g., 905), etc.). For example, in Figure 9E In the example, a multi-channel BERT (e.g., 610) can locally provide the functionality offered by such a supplementary device. For example, in Figure 9E In the example, the multi-channel tester device can implement a NEXT / FEXT test link mode, where the tester device receives stress data generated and transmitted from the transmitter of the untested channel on device 605. In other implementations, the multi-channel tester device 610 can participate in a loopback-based NEXT / FEXT test link state (e.g., similar to...). Figure 9C(The example shows the test link states). In some cases, the multi-channel tester device can act as a master or slave in loopback-based NEXT / FEXT test link states, some of which are defined to cause the transmitter of the device under test to generate a stress signal to loop back through the tester device on a non-test channel, and alternatively, test link states are defined to cause the transmitter of the multi-channel tester to generate a stress signal to loop back through the corresponding receiver / transmitter pair of the device under test 605 on a non-test channel. The multi-channel tester device can also be used in FEXT-only test link states to generate stress signals for delivery to the receivers of receiver / transmitter pairs on non-test channels (e.g., instead of, for example, Figure 9D Examples include standalone dedicated signal generators (e.g., 905), and other example uses.

[0074] Although Figures 9A-9E The examples each illustrate the same channel (e.g., 630c) used as the channel under test; however, it should be understood that this is merely for illustrative purposes to show the variation between different test link state examples. In practice, any one of the multiple channels (i.e., receiver / transmitter pairs (e.g., 630a-e)) can be connected to a tester device (e.g., a single-channel BERT) and is the subject of the test. Furthermore, depending on the test, any one of the multiple channels can enter a LUT test link state (and be the channel under test) or enter a support test link state to generate crosstalk on the selected channel under test. Therefore, the protocol stack logic implemented at the respective receiver / transmitter pair (e.g., 630a-e) can support not only the standard link states defined for the protocol but also supplementary or added test link states to allow that channel to be tested as the channel under test or to support testing of another channel in the channel by generating crosstalk on the channel under test.

[0075] As described above, in some examples, the principles and aspects of standard link state machines and their corresponding logic can be leveraged to facilitate transitions to dedicated test link states, such as those described above. As an illustrative example, a test device (e.g., a BERT including protocol stack logic that allows the BERT to be at least partially aware of the protocol to send and interpret signals defined within the specific protocols supported by the device under test) can guide the device under test through various protocol-defined flows during testing. For example, within a LUT test state, the BERT can guide the device under test through active L0 link states (e.g., skipping configuration link states) to recovery link states (in some cases, including load balancing), to loopback link states, and so on, as programmed according to specific tests. In such instances, the BERT can leverage protocol-defined messaging to facilitate these test transitions between standard link states.

[0076] In a more detailed example, and returning to Figure 7 In Figure 700, a device being tested by a tester device can first bring one or more receiver / transmitter pairs in a receiver / transmitter pair corresponding to a multi-channel link into receiver detection state 505. All channels can detect another device (e.g., due to loopback, or connected to a BERT, or connected to a 50-ohm terminal, or other test equipment, or sourced from a 50-ohm terminal) to pass through the detection state. In other implementations, the device under test can simply detect exiting an electrically idle state (e.g., where the device is placed ready for testing) because the tester device drives the electrical mode to the channel under test. In some implementations, the requirements of the protocol definition for this transition can be further relaxed to force each channel not connected to the tester device in the channel to continue link training, even though no connected receiver is detected at the other end of the channel during detection state 505 (e.g., in the case of only NEXT test link state, e.g., in...). Figure 9C (as in the example).

[0077] Continuing this example, the port of the channel under test can exit detection state 505 to enter polling state 510. In this state, the tester device can send a modified training sequence (e.g., a TS1 / TS2 ordered set via Polling.Active and Polling.Configuration) where one or more bits (e.g., in symbol 5 of the training sequence) are set to indicate the test mode to enter, which involves the remaining channels entering a specific test link state. In one example, the detection receiver channel (during detection 505) can be trained while not connected to the tester device (e.g., utilizing its own (loopback) TS1 / TS2 ordered set). In other cases, the untested channel can be configured to simply ignore all traffic by default after a specific timeout period (e.g., a timeout based on failure to receive further training data on a channel not connected to the tester device), in the direction of the protocol stack logic across the link width (based on receiving a training sequence indicating that the link is in test mode on a BERT-connected channel), or after other examples. In some implementations, polling itself can be modified to accommodate transitions to test link states.

[0078] In an example using a single-channel tester device, the modified training sequence indicating the test mode will only be sent to the receiver of the receiver / transmitter pair under test. When the receiver / transmitter pair corresponding to the channel under test receives (e.g., an ordered set of TS1 / TS2 in polling state) of the modified training sequence(s), the receiver / transmitter pair logic can instruct the device link state machine logic (e.g., LTSSM logic) to transition the channel under test to the LUT link test state, and the remaining channels support the test link state. In one example, the LUT test link state may include or mimic the L0 state. Therefore, in such an example, the link state machine logic may skip intermediate states that would normally be entered before entering the L0 state (e.g., configuration state 515). For example, the configuration state can be skipped to enter the L0 state (e.g., 520) to begin operations within the LUT test state (e.g., upon receiving the modified ordered set of TS2, where bits are set to indicate the corresponding test mode). Aspects of the link trained during the skipped link training states can be set to default values ​​(e.g., channel number assignment can be the default channel number, and other examples).

[0079] Continuing this example, the LUT test state (or sequence of steps) can involve driving the channel under test into a loopback state. (See reference...) Figure 5 Entering loopback state 535 may involve first transitioning to recovery state 540. In one example of implementing a PCIe-based interconnect, if the device under test (DUT) is a downstream port (DSP), the DUT initiates a balanced transition from L0 520 to recovery 540 at all relevant data rates, followed by the tester device. If the DUT is an upstream port (USP), the tester device can initiate a balanced transition from L0 to recovery at all relevant data rates, followed by the DUT. Upon exiting recovery state 540, the tester device (in LUT test state) can initiate a transition to loopback 535 as the loopback master. The DUT then enters loopback 535 as a slave, where the loopback bit is set on one channel. From Loopback.Entry, all channels in slave mode that have not received a modified TS1 / TS2 ordered set during polling state 510 can issue a conformance mode (or a modified conformance mode), as well as other example implementations. Using the loopback channel under test, the tester device can then perform measurements on the channel under test and generate results describing the performance of the receiver / transmitter pair on the device under test corresponding to the channel under test.

[0080] The preceding disclosures have presented several example test link states that can supplement the standard link states defined in interconnect protocols. It should be understood that other test link states besides those identified above can be provided without departing from the more general principles contained herein. For example, while some of the example state machines and ordered sequences discussed herein are described with reference to PCIe or PCIe-based protocols, it should be understood that similar corresponding enhancements can be made to other interconnect protocols, such as OpenCAPI. TM Gen-Z TM UPI, Universal Serial Bus (USB), and Cache Coherent Interconnect for Accelerators (CCIX) TM Advanced Micro Device TM (AMD TM Infinity TM Common Communication Interface (CCI) or Qualcomm TM Centriq TM Interconnection, and others.

[0081] Note that the apparatus, methods, and systems described above can be implemented in any electronic device or system as foregoing. For specific illustration, the accompanying drawings provide exemplary systems utilizing the invention as described herein. Many different interconnects have been disclosed, described, and revisited from the above discussion due to the more detailed description of the following systems. It will be apparent that the advancements described above can be applied to any of these interconnects, structures, or architectures.

[0082] refer to Figure 10 This diagram depicts an embodiment of a computing system including a multi-core processor. Processor 1000 includes any processor or processing device, such as a microprocessor, embedded processor, digital signal processor (DSP), network processor, handheld processor, application processor, coprocessor, system-on-a-chip (SoC), or other device for executing code. In one embodiment, processor 1000 includes at least two cores—cores 1001 and 1002—which may include asymmetric or symmetric cores (as shown in the embodiment). However, processor 1000 may include any number of processing elements, which may be symmetric or asymmetric.

[0083] In one embodiment, a processing element refers to hardware or logic that supports software threads. Examples of hardware processing elements include: thread units, thread slots, threads, processing units, contexts, context units, logic processors, hardware threads, cores, and / or any other elements capable of maintaining the processor's state, such as execution state or architectural state. In other words, in one embodiment, a processing element refers to any hardware that can be independently associated with code (e.g., software threads, operating systems, applications, or other code). A physical processor (or processor socket) typically refers to an integrated circuit, which potentially includes any number of other processing elements, such as cores or hardware threads.

[0084] A kernel typically refers to logic residing on an integrated circuit capable of maintaining independent architectural states, each of which is associated with at least some dedicated execution resources. In contrast, a hardware thread typically refers to any logic residing on an integrated circuit capable of maintaining independent architectural states, where these independently maintained architectural states share access to execution resources. As can be seen, the boundary between the naming of hardware threads and kernels overlaps when specific resources are shared while others are dedicated to architectural states. However, often, operating systems treat kernels and hardware threads as individual logical processors, where the operating system can schedule operations independently on each logical processor.

[0085] like Figure 10 As shown, the physical processor 1000 includes two cores—cores 1001 and 1002. Here, cores 1001 and 1002 are considered symmetric cores, i.e., cores with the same configuration, functional units, and / or logic. In another embodiment, core 1001 includes unordered processor cores, while core 1002 includes ordered processor cores. However, cores 1001 and 1002 can be individually selected from any type of core: for example, native cores, software-managed cores, cores adapted to execute native instruction set architectures (ISAs), cores adapted to execute transformed instruction set architectures (ISAs), co-designed cores, or other known cores. In a heterogeneous core environment (i.e., asymmetric cores), some form of transformation (e.g., binary transformation) can be used to schedule or execute code on one or both cores. However, for further discussion, the functional units shown in core 1001 are described in further detail below, as the units in core 1002 operate in a similar manner in the depicted embodiment.

[0086] As depicted, core 1001 includes two hardware threads 1001a and 1001b, which may also be referred to as hardware thread slots 1001a and 1001b. Therefore, in one embodiment, a software entity such as an operating system may potentially view processor 1000 as four separate processors, i.e., four logical processors or processing elements capable of executing four software threads concurrently. As mentioned above, a first thread is associated with architecture state register 1001a, a second thread with architecture state register 1001b, a third thread may be associated with architecture state register 1002a, and a fourth thread may be associated with architecture state register 1002b. Here, each of the architecture state registers (1001a, 1001b, 1002a, and 1002b) may be referred to as a processing element, thread slot, or thread unit, as described above. As shown, architecture state register 1001a is copied in architecture state register 1001b, thus enabling the storage of individual architecture state / context for logical processors 1001a and 1001b. Within core 1001, other smaller resources can also be copied for threads 1001a and 1001b, such as the instruction pointer and renaming logic in allocator and renamer block 1030. Some resources can be shared through partitioning, such as the reorder buffer in reorder / exit unit 1035, ILTB 1020, load / store buffer, and queues. Other resources can potentially be fully shared, such as general-purpose internal registers, page table base registers(s), low-level data cache and data-TLB 1015, execution unit(s) 1040, and portions of out-of-order unit 1035.

[0087] Processor 1000 often includes other resources, which may be fully shared, shared via partitions, or dedicated to / specifically used by the processing element. Figure 10 The diagram illustrates a purely exemplary embodiment of a processor with illustrative logic units / resources for the processor. Note that the processor may include or omit any of these functional units, as well as any other known functional units, logic, or firmware not depicted. As shown, core 1001 includes a simplified, representative out-of-order (OOO) processor core. However, a sequential processor may be used in different embodiments. The OOO core includes a branch target buffer 1020 for predicting the branch to be executed / adopted, and an instruction translation buffer (I-TLB) 1020 for storing address translation entries for instructions.

[0088] Core 1001 also includes a decoding module 1025 coupled to the acquisition unit 1020 for decoding the acquired elements. In one embodiment, the acquisition logic includes individual sequencers associated with thread slots 1001a and 1001b, respectively. Typically, core 1001 is associated with a first ISA that defines / specifies instructions executable on processor 1000. Often, machine code instructions that are part of the first ISA include portions of instructions (called opcodes) that reference / specify instructions or operations to be performed. Decoding logic 1025 includes circuitry that identifies these instructions from their opcodes and passes the decoded instructions through a pipeline for processing as defined by the first ISA. For example, as discussed in more detail below, in one embodiment, decoder 1025 includes logic designed or adapted to identify specific instructions, such as transaction instructions. Due to the identification performed by decoder 1025, the architecture or core 1001 takes specific, predefined actions to perform tasks associated with the appropriate instructions. It is important to note that any of the tasks, blocks, operations, and methods described herein can be executed in response to single or multiple instructions; some of these instructions may be new or old. Note that in one embodiment, decoder 1026 recognizes the same ISA (or a subset thereof). Alternatively, in a heterogeneous kernel environment, decoder 1026 recognizes a second ISA (a subset of the first ISA or a different ISA).

[0089] In one example, allocator and renamer block 1030 includes an allocator for reserving resources (e.g., a register file for storing instruction processing results). However, threads 1001a and 1001b are potentially capable of out-of-order execution, where allocator and renamer block 1030 also reserves other resources, such as a reordering buffer for tracking instruction results. Unit 1030 may also include a register renamer for renaming the program / instruction reference register to other registers within processor 1000. Reordering / exit unit 1035 includes components such as the reordering buffer, load buffer, and store buffer mentioned above to support out-of-order execution and the later, sequential exit of out-of-order executed instructions.

[0090] In one embodiment, the scheduler and execution unit block 1040 includes a scheduler unit for scheduling instructions / operations on execution units. For example, floating-point instructions are scheduled on an execution unit port with available floating-point execution units. A register file associated with the execution unit is also included to store information about instruction processing results. Exemplary execution units include floating-point execution units, integer execution units, jump execution units, load execution units, store execution units, and other known execution units.

[0091] A lower-level data cache and data translation buffer (D-TLB) 1050 are coupled to execution unit(s) 1040. The data cache stores recently used / operated elements, such as data operands, which may remain in a memory coherence state. The D-TLB stores recent virtual / linear-to-physical address translations. As a specific example, the processor may include a page table structure to divide physical memory into multiple virtual pages.

[0092] Here, cores 1001 and 1002 share access to higher-level or more distant caches, such as the L2 cache associated with on-chip interface 1010. Note that "higher-level or more distant" refers to cache levels increasing or receding further from execution units(s). In one embodiment, a higher-level cache is the last-level data cache—the last-level cache in the memory hierarchy on processor 1000—e.g., a L2 or L3 data cache. However, higher-level caches are not limited to this, as they can be associated with or include an instruction cache. A trace cache—a type of instruction cache—can alternatively be coupled after decoder 1025 to store traces of recently decoded instructions. Here, instructions potentially refer to macro instructions (i.e., general instructions recognized by the decoder), which can be decoded into multiple microinstructions (micro-operations).

[0093] In the depicted configuration, processor 1000 also includes an on-chip interface module 1010. Historically, the memory controller, described in more detail below, is included in a computing system external to processor 1000. In this scenario, on-chip interface 1010 is used to communicate with devices external to processor 1000, such as system memory 1075, chipsets (often including a memory controller hub for connecting to memory 1075 and an I / O controller hub for connecting peripheral devices), memory controller hub, northbridge, or other integrated circuits. Furthermore, in this scenario, bus 1005 can include any known interconnect, such as multipoint bus, point-to-point interconnect, serial interconnect, parallel bus, coherent (e.g., cache coherent) bus, hierarchical protocol architecture, differential bus, and GTL bus.

[0094] Memory 1075 may be dedicated to processor 1000 or shared with other devices in the system. Common examples of memory types 1075 include DRAM, SRAM, non-volatile memory (NV memory), and other known storage devices. Note that device 1080 may include a graphics accelerator, a processor or card coupled to the memory controller, a data storage device coupled to the I / O controller, a wireless transceiver, a flash memory device, an audio controller, a network controller, or other known devices.

[0095] However, recently, with more logic and devices being integrated onto a single die such as a System-on-a-Chip (SoC), each of these devices can be combined onto the processor 1000. For example, in one embodiment, the memory controller is centrally located on the same package and / or die as the processor 1000. Here, a portion of the core (on-core portion) 1010 includes one or more controllers for interfacing with other devices such as the memory 1075 or the graphics device 1080. The configuration including interconnects and controllers for interfacing with such devices is often referred to as an on-core (or non-core configuration). As an example, the on-chip interface 1010 includes a ring interconnect for on-chip communication and a high-speed serial point-to-point link 1005 for off-chip communication. However, in an SoC environment, even more devices (e.g., network interfaces, coprocessors, memory 1075, graphics processor 1080, and any other known computer devices / interfaces) can be integrated onto a single die or integrated circuit to provide a small form factor with high functionality and low power consumption.

[0096] In one embodiment, processor 1000 is capable of executing compiler, optimizer, and / or transformer code 1077 to compile, transform, and / or optimize application code 1076 to support the apparatus and methods described herein or their interface. Compilers often include programs or assemblies that transform source text / code into target text / code. Typically, compiling program / application code with a compiler is done in multiple stages and progresses to transforming high-level programming language code into low-level machine or assembly language code. However, single-pass compilers can still be used for simple compilation. Compilers can utilize any known compilation techniques and perform any known compiler operations, such as lexical analysis, preprocessing, parsing, semantic analysis, code generation, code transformation, and code optimization.

[0097] Larger compilers often include multiple stages, but in most cases these stages are often encompassed within two general stages: (1) the front end, where syntactic processing, semantic processing, and some transformations / optimizations typically occur, and (2) the back end, where analysis, transformations, optimizations, and code generation typically occur. Some compilers refer to the middle, which describes the ambiguous area between the compiler's front and back ends. Thus, references to compiler insertions, associations, generation, or other operations can occur in any of the aforementioned stages or passes, as well as any other known stages or passes of the compiler. As an illustrative example, a compiler may potentially insert operations, calls, functions, etc., in one or more stages of compilation, for example, inserting calls / operations in the front-end stage of compilation and then transforming the calls / operations into lower-level code during the transformation stage. Note that during dynamic compilation, compiler code or dynamically optimized code can insert such operations / calls, as well as optimization code for execution during runtime. As a particular illustrative example, binary code (already compiled code) can be dynamically optimized during runtime. Here, program code can include dynamically optimized code, binary code, or a combination thereof.

[0098] Similar to compilers, transformers (e.g., binary transformers) transform code statically or dynamically to optimize and / or transform it. Therefore, references to executable code, application code, program code, or other software environments can refer to: (1) the dynamic or static execution of (multiple) compiler programs, code optimizers, or transformers to compile program code, maintain software structure, perform other operations, optimize code, or transform code; (2) the execution of main program code including operations / calls, such as already optimized / compiled application code; (3) the execution of other program code (e.g., libraries) associated with the main program code to maintain software structure, perform other software-related operations, or optimize code; or (4) combinations thereof.

[0099] Now for reference Figure 11 A block diagram of another system 1100 according to an embodiment of the present invention is shown. Figure 11 As shown, the multiprocessor system 1100 is a point-to-point interconnect system and includes a first processor 1170 and a second processor 1180 coupled via a point-to-point interconnect 1150. Each of processors 1170 and 1180 may be a version of a processor. In one embodiment, 1152 and 1154 are part of a serial point-to-point coherent interconnect structure, for example, a high-performance architecture. Therefore, the present invention can be implemented within a QPI architecture.

[0100] Although only two processors 1170 and 1180 are shown, it should be understood that the scope of the invention is not limited thereto. In other embodiments, one or more additional processors may be present in a given processor.

[0101] Processors 1170 and 1180 are shown as including integrated memory controller units 1172 and 1182, respectively. Processor 1170 also includes point-to-point (PP) interfaces 1176 and 1178 as part of its bus controller unit; similarly, the second processor 1180 includes PP interfaces 1186 and 1188. Processors 1170 and 1180 can exchange information via point-to-point (PP) interface 1150 using PP interface circuitry 1178 and 1188. Figure 11 As shown, IMC 1172 and 1182 couple the processor to the corresponding memory, namely memory 1132 and memory 1134, which may be portions of the main memory locally attached to the corresponding processor.

[0102] Processors 1170 and 1180 each use point-to-point interface circuits 1176, 1194, 1186, and 1198 to exchange information with chipset 1190 via individual PP interfaces 1152 and 1154. Chipset 1190 also exchanges information with high-performance graphics circuit 1138 via interface circuit 1192 along high-performance graphics interconnect 1139.

[0103] A shared cache (not shown) may be located in one or both processors; however, it is connected to the processor via a PP interconnect so that if the processor is in a low-power mode, the local cache information of either or both processors may be stored in the shared cache.

[0104] Chipset 1190 can be coupled to first bus 1116 via interface 1196. In one embodiment, first bus 1116 may be a peripheral component interconnect (PCI) bus, or a bus such as a fast PCI bus or another third-generation I / O interconnect bus, but the scope of the invention is not limited thereto.

[0105] like Figure 11 As shown, various I / O devices 1114, along with a bus bridge 1118, are coupled to a first bus 1116, which in turn couples the first bus 1116 to a second bus 1120. In one embodiment, the second bus 1120 includes a low pin count (LPC) bus. Various devices are coupled to the second bus 1120, including, for example, a keyboard and / or mouse 1122, a communication device 1127, and a storage unit 1128 (e.g., a disk drive or other mass storage device, which in one embodiment often includes instruction / code and data 1130). Additionally, audio I / O 1124 is shown coupled to the second bus 1120. Note that other architectures are possible, where the included components and interconnect architectures vary. For example, instead of... Figure 11 The point-to-point architecture allows the system to implement multi-point bus or other similar architectures.

[0106] Although the invention has been described with respect to a limited number of embodiments, many modifications and variations will be apparent to those skilled in the art. The appended claims are intended to cover all such modifications and variations that fall within the true spirit and scope of the invention.

[0107] Design can go through various stages from creation to simulation to manufacturing. Data representing a design can be presented in a variety of ways. First, hardware can be represented using a hardware description language or another functional description language, as is useful in simulation. Additionally, circuit-level models with logic and / or transistor gates can be generated at certain stages of the design process. Furthermore, most designs reach a data level at some stage representing the physical placement of various devices in the hardware model. In the case of using conventional semiconductor manufacturing techniques, data representing the hardware model can be data specifying the presence or absence of various features on different mask layers of the mask used to produce the integrated circuit. In any representation of the design, data can be stored in any form of machine-readable medium. Memory such as a disk or magnetic or optical storage devices can be machine-readable media for storing information transmitted via light or radio waves modulated or otherwise generated to transmit such information. When an electrical carrier carrying instructions or designs is transmitted, a new copy is made to the extent that the electrical signal is copied, buffered, or retransmitted. Therefore, communication providers or network providers can at least temporarily store items (e.g., information encoded as a carrier wave embodying embodiments of the invention) on a tangible machine-readable medium.

[0108] As used herein, a module refers to any combination of hardware, software, and / or firmware. As an example, a module includes hardware associated with a non-transitory medium, such as a microcontroller, for storing code suitable for execution by the microcontroller. Therefore, in one embodiment, a reference to a module refers to hardware specifically configured to identify and / or execute code to be retained on a non-transitory medium. Furthermore, in another embodiment, the use of "module" refers to a non-transitory medium comprising code specifically suitable for execution by a microcontroller to perform predetermined operations. And as can be inferred, in yet another embodiment, the term "module" (in this example) may refer to a combination of a microcontroller and a non-transitory medium. Module boundaries, often depicted as separate, typically vary and potentially overlap. For example, a first module and a second module may share hardware, software, firmware, or a combination thereof, while potentially retaining some independent hardware, software, or firmware. In one embodiment, the use of the term "logic" includes hardware such as transistors, registers, or other hardware (e.g., programmable logic devices).

[0109] In one embodiment, the phrase "configured to" refers to arranging, placing together, manufacturing, offering for sale, importing, and / or designing a device, hardware, logic, or element to perform a specified or defined task. In this example, if a device or element thereof is designed, coupled, and / or interconnected to perform the specified task, then a device or element thereof not in operation is still "configured to" perform the specified task. As a purely illustrative example, a logic gate may provide 0 or 1 during operation. However, the statement that a logic gate is "configured to" provide an enable signal to a clock does not imply that every potential logic gate may provide 1 or 0. Instead, the logic gate is coupled in a way that outputs 1 or 0 during operation to enable the clock. Again, note that the use of the term "configured to" does not require operation but focuses on the hidden state of a device, hardware, and / or element, in which the device, hardware, and / or element is designed to perform a specific task when the device, hardware, and / or element is in operation.

[0110] Furthermore, in one embodiment, the phrases “for,” “capable of / can be used for,” and / or “operable for” refer to devices, logic, hardware, and / or elements designed in such a way that they can be used in a specified manner. Note that, as described above in one embodiment, the use of “for,” “capable of,” or “operable for” refers to a hidden state of devices, logic, hardware, and / or elements, wherein the devices, logic, hardware, and / or elements are not operational but are designed in such a way that they can be used in a particular manner.

[0111] As used herein, values ​​include any known representation of numbers, states, logical states, or binary logical states. Often, the use of logic levels, logic values, or logical values ​​is also referred to as the use of 1 and 0, which simply represent binary logical states. For example, 1 indicates a high logic level, and 0 indicates a low logic level. In one embodiment, a storage unit such as a transistor or flash memory cell is capable of holding a single logic value or multiple logic values. However, other representations of values ​​are already used in computer systems. For example, a decimal tens can also be represented as the binary value 1010 and the hexadecimal letter A. Therefore, values ​​include any representation of information that a computer system can store.

[0112] Furthermore, a state can be represented by a value or a portion of a value. As an example, a first value (e.g., logic one) can represent a default or initial state, while a second value (e.g., logic zero) can represent a non-default state. Additionally, in one embodiment, the terms reset and set refer to a default value or state and an updated value or state, respectively. For example, a default value potentially includes a high logic value (i.e., reset), while an updated value potentially includes a low logic value (i.e., set). Note that any combination of values ​​can be used to represent any number of states.

[0113] The embodiments of the methods, hardware, software, firmware, or code described above can be implemented via instructions or code stored on a machine-accessible, machine-readable, computer-accessible, or computer-readable medium executable by a processing element. Non-transitory machine-accessible / readable media include any mechanism that provides (i.e., stores and / or transmits) information in a machine-readable form (e.g., a computer or electronic system). For example, non-transitory machine-accessible media include random access memory (RAM), such as static RAM (SRAM) or dynamic RAM (DRAM); ROM; magnetic or optical storage media; flash memory devices; electrical storage devices; optical storage devices; acoustic storage devices; other forms of storage devices for retaining information received from transient (propagating) signals (e.g., carrier waves, infrared signals, digital signals); and so on, as distinct from non-transitory media from which information can be received.

[0114] Instructions for programming logic to execute embodiments of the present invention may be stored in the system's memory (e.g., DRAM, cache, flash memory, or other storage devices). Furthermore, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, but are not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage devices for transmitting information via the Internet via electrical, optical, acoustic, or other forms of propagation signals (e.g., carrier waves, infrared signals, digital signals, etc.). Therefore, computer-readable media include any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0115] In some embodiments, an electronic device may be configured to perform one or more processes, techniques and / or methods, or portions thereof, as described herein. Figure X-2 The document describes such a process. For example, the process may include performing SKP adjustments during the first SKP ordered set (OS) by a first timer and a second timer; and performing SKP adjustments during the second SKP OS by a third timer and a fourth timer.

[0116] In some embodiments, the electronic device may be configured to perform one or more processes, techniques and / or methods, or portions thereof, as described herein. For example, the process may include enhancing the training ordered set (OS) to allow for Gen 5 speed; and setting configuration registers to indicate Gen 5 PCIe speed.

[0117] In some embodiments, the electronic device may be configured to perform one or more processes, techniques and / or methods, or portions thereof, as described herein. For example, the process may include identifying a channel type provided by the platform; identifying the presence of one or more re-timers; and selecting between 25 gigabits per second (GT / s) and 32 GT / s transmission based on the channel type and the presence of one or more re-timers.

[0118] In some embodiments, an electronic device may be configured to perform one or more processes, techniques and / or methods, or portions thereof, as described herein. For example, the process may include identifying a channel link width from a set of widths including x20, x24, x28, and x28; and communicating via a channel link based on the identified channel link width.

[0119] In some embodiments, the electronic device may be configured to perform one or more processes, techniques and / or methods, or portions thereof, as described herein. For example, the process may include identifying recovered clock data from clock data recovery (CDR); and transmitting (TX) data after initial training based on the recovered clock data.

[0120] In some embodiments, a method for communicating according to the PCIe standard may be provided, comprising: performing SKP adjustment during a first SKP ordered set (OS) by a first timer and a second timer, and performing SKP adjustment during a second SKP OS by a third timer and a fourth timer. The method may also include halving the SKP OS frequency. In some cases, the first SKP OS may be transmitted sequentially with the second SKP OS. The method may also include enhancing the training ordered set (OS) to allow Gen 5 speeds and setting configuration registers to indicate Gen 5 PCIe speeds. Furthermore, the channel type provided by the platform may be identified, the presence of one or more re-timers may be identified, and the channel speed (e.g., from 25 gigabit per second (GT / s) or 32 GT / s transmissions) may be selected based on the channel type and the presence of one or more re-timers. This selection may also be determined based on whether forward error correction (FEC) is implemented or supported. This speed selection may occur during link training. These example methods may additionally include identifying the channel link width from a set including speeds of x20, x24, x28, and x28, and communicating over the channel link based on the identified channel link width. Furthermore, recovered clock data from the clock data recovery component can be identified, and data can be transmitted based on the recovered clock data after the link has been trained.

[0121] In some embodiments, an apparatus for communicating according to a PCIe-based standard may be provided, the apparatus including an extended continuous-time linear equalizer (CTLE) and / or a minimum 8-tap decision feedback equalizer (DFE), and / or a T-coil or Pi-coil termination, and / or a data mode filter associated with clock data recovery (CDR), and / or a 4-way interleaved clock architecture, as well as other example features and components.

[0122] In some embodiments, an apparatus for communicating according to a Fast Peripheral Component Interconnect (PCIe) standard with channel loss characteristics may be provided, such as those discussed above. The PCIe standard may be a Gen 5 (or higher) PCIe standard.

[0123] The following examples relate to embodiments according to this specification. Example 1 is an apparatus comprising: an interface including a port, wherein the port includes a plurality of receiver-transmitter pairs, and each receiver-transmitter pair includes: a corresponding receiver for receiving data on a corresponding channel of a plurality of bidirectional channels; and a corresponding transmitter for transmitting data on the corresponding channel; and state machine logic including hardware circuitry. The state machine logic is configured to: detect a training sequence received from a tester device by a specific receiver of a particular receiver-transmitter pair on a particular channel of a plurality of bidirectional channels, wherein the training sequence includes values ​​for instructing the tester device to perform tests on the particular receiver-transmitter pair; transition the particular receiver-transmitter pair to a first link state associated with the test; and transition another receiver-transmitter pair of the plurality of receiver-transmitter pairs to a second link state different from the first link state associated with the test.

[0124] Example 2 may include the subject of Example 1, wherein the value indicates a specific test mode among a plurality of test modes to be applied in the test of a particular receiver-transmitter pair, the second link state corresponds to the specific test mode, and another receiver-transmitter pair enters the second link state based on the specific test mode.

[0125] Example 3 may include the subject of Example 2, wherein multiple test modes include at least a first test mode and at least a second test mode, the first test mode being used to test the channel in the presence of far-end crosstalk and the second test mode being used to test the channel in the presence of near-end crosstalk.

[0126] Example 4 may include the subject of Example 3, wherein a particular test mode includes a first test mode in which the transmitter of another receiver-transmitter pair remains idle in a first link state, the receiver of another receiver-transmitter pair receives a stress signal in the first link state, the stress signal causes crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received stress signal.

[0127] Example 5 may include the subject of Example 3, wherein a particular test mode includes a second test mode, and the transmitter of another receiver-transmitter pair transmits a signal in a second link state to induce crosstalk on a particular channel.

[0128] Example 6 may include the subject matter of Example 5, wherein the signal includes a first pressure signal, a second test mode tests the channel in the presence of both near-end crosstalk and far-end crosstalk, the receiver of another receiver-transmitter pair receives the second pressure signal in a second link state, the first pressure signal causes near-end crosstalk on a particular channel, the second pressure signal causes far-end crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received second pressure signal.

[0129] Example 7 may include the subject of Example 3, wherein the second pressure signal includes a looped version of the first pressure signal.

[0130] Example 8 may include the subject of any of Examples 1-7, wherein the first link state includes a loopback state in which the tester device acts as the master.

[0131] Example 9 may include the subject of any of Examples 1-8, wherein the training sequence is received during polling of the link state.

[0132] Example 10 may include the subject of Example 9, wherein polling the link state includes the link training state in a state machine compatible with a protocol based on Fast Peripheral Component Interconnect (PCIe).

[0133] Example 11 may include the subject of Example 9, wherein a particular receiver-transmitter pair transitions from a polling link state to a first link state, and another receiver-transmitter pair transitions from a polling link state to a second link state.

[0134] Example 12 may include the subject of any of Examples 1-11, wherein the tester device includes a Bit Error Rate Tester (BERT) device.

[0135] Example 13 may include the subject of Example 12, wherein the BERT device includes a single-channel BERT device for connecting to only one of multiple receiver-transmitter pairs during testing of the device.

[0136] Example 14 may include the subject of Example 12, wherein the BERT device includes a multi-channel BERT device for connecting to each of a plurality of receiver-transmitter pairs during testing of the device.

[0137] Example 15 may include the subject of any one of Examples 1-14, wherein the second link state includes one of a plurality of test states supported by state machine logic.

[0138] Example 16 may include the subject of Example 15, wherein multiple test states are separated from the states in the link state machine suitable for bringing the link to a standard active state.

[0139] Example 17 may include the topic of Example 16, where the standard activity states include the L0 state.

[0140] Example 18 may include the subject of any of Examples 1-17, wherein all receiver-transmitter pairs of a plurality of receiver-transmitter pairs except for a particular receiver-transmitter pair enter a second state for testing.

[0141] Example 19 may include the subject matter of Example 1, wherein, in a first link state, data is transmitted from a test device on a specific channel, and a second state includes one of the following: an idle state, wherein no data is transmitted by another receiver-transmitter pair on another channel of a plurality of channels; a loopback state, wherein data is continuously transmitted from the transmitter of another receiver-transmitter pair to another device on another channel during a specific test mode, and looped back to the receiver of another receiver-transmitter pair; and a transmit-only state, wherein, during a specific test mode, data is continuously transmitted by the transmitter of another receiver-transmitter pair on another channel, and the signal is ignored by the receiver of another receiver-transmitter pair on another channel.

[0142] Example 20 may include the subject of Example 19, wherein data transmitted by the transmitter of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel, and data transmitted from another device to the receiver of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel.

[0143] Example 21 is a method comprising: receiving a training sequence at a receiver of a particular receiver-transmitter pair among a plurality of receiver-transmitter pairs, wherein each of the plurality of receiver-transmitter pairs implements a corresponding channel among a plurality of channels in a link, the training sequence being received from a tester device on the particular channel among the plurality of channels, and the training sequence including values ​​for instructing the tester device to perform a test on the particular receiver-transmitter pair; transitioning the particular receiver-transmitter pair to a first link state in association with the test; and transitioning one or more other receiver-transmitter pairs among the plurality of receiver-transmitter pairs to a second link state different from the first link state in association with the test, wherein the second link state allows crosstalk to be generated on the particular channel during the test.

[0144] Example 22 may include the subject of Example 21, wherein the value indicates a specific test mode among a plurality of test modes to be applied in the test of a particular receiver-transmitter pair, the second link state corresponds to the specific test mode, and another receiver-transmitter pair enters the second link state based on the specific test mode.

[0145] Example 23 may include the subject of Example 22, wherein multiple test modes include at least a first test mode and at least a second test mode, the first test mode being used to test the channel in the presence of far-end crosstalk and the second test mode being used to test the channel in the presence of near-end crosstalk.

[0146] Example 24 may include the subject of Example 23, wherein a particular test mode includes a first test mode in which the transmitter of another receiver-transmitter pair remains idle in a first link state, the receiver of another receiver-transmitter pair receives a stress signal in the first link state, the stress signal causes crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received stress signal.

[0147] Example 25 may include the subject of Example 23, wherein a particular test mode includes a second test mode, and the transmitter of another receiver-transmitter pair transmits a signal in a second link state to induce crosstalk on a particular channel.

[0148] Example 26 may include the subject matter of Example 25, wherein the signal includes a first pressure signal, a second test mode tests the channel in the presence of both near-end crosstalk and far-end crosstalk, the receiver of another receiver-transmitter pair receives the second pressure signal in a second link state, the first pressure signal causes near-end crosstalk on a particular channel, the second pressure signal causes far-end crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received second pressure signal.

[0149] Example 27 may include the subject of Example 23, wherein the second pressure signal includes a looped version of the first pressure signal.

[0150] Example 28 may include the subject of any of Examples 21-27, wherein the first link state includes a loopback state in which the tester device acts as the master.

[0151] Example 29 may include the subject of any of Examples 21-28, wherein the training sequence is received during polling of the link state.

[0152] Example 30 may include the subject of Example 29, wherein polling the link state includes the link training state in a state machine compatible with a protocol based on Fast Peripheral Component Interconnect (PCIe).

[0153] Example 31 may include the subject of Example 29, wherein a particular receiver-transmitter pair transitions from a polling link state to a first link state, and another receiver-transmitter pair transitions from a polling link state to a second link state.

[0154] Example 32 may include the subject of any of Examples 21-31, wherein the tester device includes a Bit Error Rate Tester (BERT) device.

[0155] Example 33 may include the subject of Example 32, wherein the BERT device includes a single-channel BERT device for connecting to only one of multiple receiver-transmitter pairs during testing of the device.

[0156] Example 34 may include the subject of Example 32, wherein the BERT device includes a multi-channel BERT device for connecting to each of a plurality of receiver-transmitter pairs during testing of the device.

[0157] Example 35 may include the subject of any of Examples 21-34, wherein the second link state includes one of a plurality of test states supported by state machine logic.

[0158] Example 36 may include the subject of Example 35, wherein multiple test states are separated from the states in the link state machine that is suitable for bringing the link to a standard active state.

[0159] Example 37 may include the topic of Example 36, wherein the standard activity states include the L0 state.

[0160] Example 38 may include the subject of any of Examples 21-37, wherein all receiver-transmitter pairs of a plurality of receiver-transmitter pairs except for a particular receiver-transmitter pair enter a second state for testing.

[0161] Example 39 may include the subject matter of Example 21, wherein in a first link state, data is transmitted from a test device on a specific channel, and a second state includes one of the following: an idle state, wherein no data is transmitted by another receiver-transmitter pair on another channel of a plurality of channels; a loopback state, wherein data is continuously transmitted from the transmitter of another receiver-transmitter pair to another device on another channel during a specific test mode, and is looped back to the receiver of another receiver-transmitter pair; and a transmit-only state, wherein during a specific test mode, data is continuously transmitted by the transmitter of another receiver-transmitter pair on another channel, and the signal is ignored by the receiver of another receiver-transmitter pair on another channel.

[0162] Example 40 may include the subject of Example 39, wherein data transmitted by the transmitter of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel, and data transmitted from another device to the receiver of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel.

[0163] Example 41 is a system comprising units for performing methods of any one of Examples 21-40.

[0164] Example 42 may include the subject matter of Example 41, wherein the unit includes a computer-readable medium storing instructions executable to perform at least a portion of the method of any of Examples 21-40.

[0165] Example 43 is a system comprising: a device including: one or more processor cores; a port including a plurality of receiver-transmitter pairs, each receiver-transmitter pair including a respective receiver and transmitter and connected to a respective channel of a plurality of bidirectional channels; and state machine logic including hardware circuitry. The state machine logic is used to: detect a training sequence received from a tester device on a specific channel of a particular receiver-transmitter pair in the plurality of receiver-transmitter pairs, wherein the training sequence includes values ​​for instructing the tester device to perform tests on the particular receiver-transmitter pair; transition the particular receiver-transmitter pair to a first link state associated with the test; and transition one or more other receiver-transmitter pairs in the plurality of receiver-transmitter pairs to a second link state different from the first link state associated with the test.

[0166] Example 44 may include the subject of Example 43, and also include a tester device, wherein the tester generates test results based on the test.

[0167] Example 45 may include the subject of Example 44, wherein the tester device includes a Bit Error Rate Tester (BERT) device.

[0168] Example 46 may include the subject of Example 45, wherein the BERT device includes a single-channel BERT device for connecting to only one of multiple receiver-transmitter pairs during testing of the device.

[0169] Example 47 may include the subject of Example 45, wherein the BERT device includes a multi-channel BERT device for connecting to each of a plurality of receiver-transmitter pairs during testing of the device.

[0170] Example 48 may include the subject of Example 44, wherein the device includes the tester device.

[0171] Example 49 may include the subject matter of Example 43, and also includes conformance fixing equipment for: connecting to each of a plurality of receiver-transmitter pairs using multiple channels; forwarding data between a particular receiver-transmitter pair and a tester device; and looping back data received from the transmitter of one or more other receiver / transmitter pairs in a second link state so that both near-end crosstalk and far-end crosstalk are generated on the particular channel during testing.

[0172] Example 50 may include the subject of Example 43, wherein the value indicates a specific test mode among a plurality of test modes to be applied in the test of a particular receiver-transmitter pair, a second link state corresponding to the specific test mode, and another receiver-transmitter pair enters the second link state based on the specific test mode.

[0173] Example 51 may include the subject of Example 50, wherein multiple test modes include at least a first test mode and at least a second test mode, the first test mode being used to test the channel in the presence of far-end crosstalk and the second test mode being used to test the channel in the presence of near-end crosstalk.

[0174] Example 52 may include the subject matter of Example 51, wherein a particular test mode includes a first test mode in which the transmitter of another receiver-transmitter pair remains idle in a first link state, the receiver of another receiver-transmitter pair receives a stress signal in the first link state, the stress signal causes crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received stress signal.

[0175] Example 53 may include the subject of Example 51, wherein a particular test mode includes a second test mode, and the transmitter of another receiver-transmitter pair transmits a signal in a second link state to induce crosstalk on a particular channel.

[0176] Example 54 may include the subject matter of Example 53, wherein the signal includes a first pressure signal, a second test mode tests the channel in the presence of both near-end crosstalk and far-end crosstalk, the receiver of another receiver-transmitter pair receives the second pressure signal in a second link state, the first pressure signal causes near-end crosstalk on a particular channel, the second pressure signal causes far-end crosstalk on a particular channel, and the other receiver-transmitter pair ignores the contents of the received second pressure signal.

[0177] Example 55 may include the subject of Example 51, wherein the second pressure signal includes a looped version of the first pressure signal.

[0178] Example 56 may include the subject of any of Examples 43-55, wherein the first link state includes a loopback state in which the tester device acts as the master.

[0179] Example 57 may include the subject of any of Examples 43-56, wherein the training sequence is received during polling of the link state.

[0180] Example 58 may include the subject of Example 57, wherein polling the link state includes the link training state in a state machine compatible with a protocol based on Fast Peripheral Component Interconnect (PCIe).

[0181] Example 59 may include the subject of Example 57, wherein a particular receiver-transmitter pair transitions from a polling link state to a first link state, and another receiver-transmitter pair transitions from a polling link state to a second link state.

[0182] Example 60 may include the subject of any one of Examples 43-59, wherein the second link state includes one of a plurality of test states supported by state machine logic.

[0183] Example 61 may include the subject of Example 60, wherein multiple test states are separated from the states in a link state machine suitable for bringing the link to a standard active state.

[0184] Example 62 may include the topic of Example 61, wherein the standard activity states include the L0 state.

[0185] Example 63 may include the subject of any of Examples 43-62, wherein all receiver-transmitter pairs of a plurality of receiver-transmitter pairs except for a particular receiver-transmitter pair enter a second state for testing.

[0186] Example 64 may include the subject matter of Example 63, wherein, in a first link state, data is transmitted from a test device on a specific channel, and a second state includes one of the following: an idle state, wherein no data is transmitted by another receiver-transmitter pair on another channel of a plurality of channels; a loopback state, wherein data is continuously transmitted from the transmitter of another receiver-transmitter pair to another device on another channel during a specific test mode, and looped back to the receiver of another receiver-transmitter pair; and a transmit-only state, wherein, during a specific test mode, data is continuously transmitted by the transmitter of another receiver-transmitter pair on another channel, and the signal is ignored by the receiver of another receiver-transmitter pair on another channel.

[0187] Example 65 may include the subject of Example 64, wherein data transmitted by the transmitter of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel, and data transmitted from another device to the receiver of another receiver-transmitter pair is used to test for near-end crosstalk on a particular channel.

[0188] Throughout this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0189] In the foregoing description, specific exemplary embodiments have been given in detail. However, it will be apparent that various modifications and changes can be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive. Furthermore, the foregoing use of embodiments and other exemplary language do not necessarily refer to the same embodiments or the same examples, but may refer to different and dissimilar embodiments, as well as potentially identical embodiments.

Claims

1. An apparatus for data communication, the apparatus comprising: An interface including a port, wherein the port includes a plurality of receiver-transmitter pairs, and each receiver-transmitter pair includes: A corresponding receiver is used to receive data on the corresponding channel in a plurality of bidirectional channels; and A corresponding transmitter is used to transmit data on the corresponding channel; and A state machine logic, comprising hardware circuitry, wherein the state machine logic is used for: Detect a training sequence received from a tester device on a specific channel of a plurality of bidirectional channels by a specific receiver of a particular receiver-transmitter pair among the plurality of receiver-transmitter pairs, wherein the training sequence includes values ​​for instructing the tester device to perform tests on the particular receiver-transmitter pair; Cause the specific receiver-transmitter pair to transition to a first link state in association with the test; and Another receiver-transmitter pair among the plurality of receiver-transmitter pairs is brought into a second link state, different from the first link state, in association with the test, wherein the second link state allows crosstalk to be generated on the particular channel during the test.

2. The apparatus according to claim 1, wherein, The value indicates a specific test mode among a plurality of test modes to be applied in the test of the particular receiver-transmitter pair, the second link state corresponding to the specific test mode, and the other receiver-transmitter pair entering the second link state based on the specific test mode.

3. The apparatus according to claim 2, wherein, The plurality of test modes include at least a first test mode and at least a second test mode, wherein the first test mode is used to test the channel in the presence of far-end crosstalk, and the second test mode is used to test the channel in the presence of near-end crosstalk.

4. The apparatus according to claim 3, wherein, The specific test mode includes the first test mode, wherein the transmitter of the other receiver-transmitter pair remains idle in the first link state, the receiver of the other receiver-transmitter pair receives a stress signal in the first link state, the stress signal causes crosstalk on the specific channel, and the other receiver-transmitter pair ignores the content of the received stress signal.

5. The apparatus according to claim 3, wherein, The specific test mode includes the second test mode, and the transmitter of the other receiver-transmitter pair sends a signal in the second link state to induce crosstalk on the specific channel.

6. The apparatus according to claim 5, wherein, The signal includes a first pressure signal, the second test mode tests the channel in the presence of both near-end crosstalk and far-end crosstalk, the receiver of the other receiver-transmitter pair receives a second pressure signal in the second link state, the first pressure signal causes the near-end crosstalk on the specific channel, the second pressure signal causes the far-end crosstalk on the specific channel, and the other receiver-transmitter pair ignores the content of the received second pressure signal.

7. The apparatus according to claim 3, wherein, The second pressure signal is a loopback version of the first pressure signal.

8. The apparatus according to any one of claims 1-7, wherein, The first link state includes a loopback state, in which the tester device acts as the master.

9. The apparatus according to any one of claims 1-7, wherein, The training sequence is received during the polling of the link status.

10. The apparatus according to claim 9, wherein, The polling link state includes the link training state in a state machine compatible with protocols based on Fast Peripheral Component Interconnect (PCIe).

11. The apparatus according to claim 9, wherein, The specific receiver-transmitter pair transitions from the polling link state to the first link state, and the other receiver-transmitter pair transitions from the polling link state to the second link state.

12. The apparatus according to any one of claims 1-7, wherein, The tester equipment includes a Bit Error Rate Tester (BERT) device.

13. The apparatus according to claim 12, wherein, The BERT device includes a single-channel BERT device for connecting to only one of the plurality of receiver-transmitter pairs during testing of the device.

14. The apparatus according to claim 12, wherein, The BERT device includes a multi-channel BERT device for connecting to each of the plurality of receiver-transmitter pairs during testing of the device.

15. The apparatus according to any one of claims 1-7, wherein, The second link state includes one of a plurality of test states supported by the state machine logic.

16. The apparatus according to claim 15, wherein, The multiple test states are separated from the states in the link state machine that are suitable for bringing the link to a standard active state.

17. The apparatus according to claim 16, wherein, The standard activity states include the L0 state.

18. The apparatus according to any one of claims 1-7, wherein, All receiver-transmitter pairs of the plurality of receiver-transmitter pairs except for the specific receiver-transmitter pair enter the second link state for the test.

19. The apparatus according to claim 1, wherein, In the first link state, data is transmitted from the test device on the specific channel, and the second link state includes one of the following: Idle state, in which no data is transmitted by the other receiver-transmitter pair on another channel of the plurality of channels; Loopback state, wherein data is continuously transmitted from the transmitter of the other receiver-transmitter pair to another device on the other channel during a specific test mode, and is looped back to the receiver of the other receiver-transmitter pair; and Transmit-only state, wherein, during the specific test mode, data is continuously transmitted on the other channel by the transmitter of the other receiver-transmitter pair, and the signal is ignored on the other channel by the receiver of the other receiver-transmitter pair.

20. The apparatus according to claim 19, wherein, Data transmitted by the transmitter of the other receiver-transmitter pair is used to test for near-end crosstalk on the specific channel, and data transmitted from another device to the receiver of the other receiver-transmitter pair is used to test for near-end crosstalk on the specific channel.

21. A method for transmitting data during testing of a computing device, the method comprising: A training sequence is received at the receiver of a specific receiver-transmitter pair among a plurality of receiver-transmitter pairs, wherein each of the plurality of receiver-transmitter pairs implements a corresponding channel among a plurality of channels in a link, the training sequence is received from a tester device on the specific channel among the plurality of channels, and the training sequence includes values ​​for instructing the tester device to perform tests on the specific receiver-transmitter pair; Transition the specific receiver-transmitter pair to the first link state associated with the test; and One or more other receiver-transmitter pairs among the plurality of receiver-transmitter pairs are converted to a second link state, which is different from the first link state, in association with the test, wherein the second link state allows crosstalk to be generated on the particular channel during the test.

22. A system comprising units for performing the method according to claim 21.

23. A computing system, comprising: The equipment includes: One or more processor cores; A port comprising multiple receiver-transmitter pairs, wherein each receiver-transmitter pair comprises a corresponding receiver and a transmitter and is connected to a corresponding channel in a plurality of bidirectional channels; and A state machine logic, comprising hardware circuitry, wherein the state machine logic is used for: Detect a training sequence received from a tester device on a specific channel of a plurality of bidirectional channels by a specific receiver of a particular receiver-transmitter pair among the plurality of receiver-transmitter pairs, wherein the training sequence includes values ​​for instructing the tester device to perform tests on the particular receiver-transmitter pair; Cause the specific receiver-transmitter pair to transition to a first link state in association with the test; and One or more other receiver-transmitter pairs among the plurality of receiver-transmitter pairs are caused to enter a second link state, different from the first link state, in association with the test to generate crosstalk.

24. The computing system according to claim 23, further comprising the tester device, wherein, The tester generates test results based on the test.

25. The computing system according to any one of claims 23-24, further comprising conformance fixing equipment for: The plurality of channels are used to connect to each of the plurality of receiver-transmitter pairs; Data is forwarded between the specific receiver-transmitter pair and the tester device; Data received from the transmitter of the one or more other receiver / transmitter pairs in the second link state will be looped back so that both near-end crosstalk and far-end crosstalk are generated on the specific channel during the test.

Images