TWI383294B - System to identify components of a data communications architecture - Google Patents

Description

System for identifying components of a data communication architecture Mutual reference and inclusion reference

The present application is in whole or in part related to the following U.S. Patent Application Serial No. 10/756,441 (Attorney No.: 200313774-1/192667), 10/756,439 (Attorney No.: 20031780-1/192668), 10/756,685 ( Agent number: 20031378-1/192669), 10/756435 case (agent number: 20031784-1/192670), 10/756530 case (agent number: 200313948-1/192671), 10/756529 case (agent number: 200313969- 1/192673), 10/756667, (Agent No.: 200313971-2/192674), 10/756600 (Agent No.: 200313932-1/192678), 11/XXXXXX (Agent No.: 200314178-2/204285) , 11/XXXXXX (Attachment No.: 200313783-2/204283), and 11/XXXXXX (Attachment No.: 200313781-2/204282), the disclosure of each of which is hereby incorporated by reference.

Field of invention

The present invention relates to a data communication structure for a computer processor, and, more particularly, to a communication structure of a computer processor employing a serializer and a deserializer.

Background of the invention

A computational structure that can operate efficiently and quickly process data is generally more popular than its counterpart. When processing data, the speed at which these computational structures process data may be limited by factors such as structural design, operational conditions, the quality of the components employed, and the protocols, logic, and methods employed by the computer architecture. The data communication latency of the spanning components caused by the data communication structure and agreement of the computing structure may also impact the speed at which the data is processed.

Some data communication structures are currently employed to communicate data between mating components of a computer structure (eg, within a computing environment processing unit or a computer processor between a computer processor and peripheral components, such as data storage devices). . For example, both IDE/ATA (Integrated Drive Electronics/Advanced Technology Attachment) and SCSI (Small Computer System Interface) are common interfaces for hardware drives (and some other devices, such as CD-ROM and DVD drives), and each There are many versions. Other data communication structures include PCI (peripheral component interconnect), AGP (accelerated graphics interface), USB (universal serial bus), serial data communication, and parallel data communication.

While the above various data communication structures are effective in transmitting data between mating components, these structures each have disadvantages, performance limitations, and may not be reliable. Specifically, such data communication structures are not designed to handle large amounts of data communication, which are communicated at high clock frequencies (eg, billions of Hertz). In addition, when communications impact data on all data communication rates, PCI, IDE, and SCSI data communication structures typically require frequent management processing calculations. In other words, in addition to the required communication materials, the frequently managed processing data must be communicated. Therefore, less overall data is processed during each clock cycle.

In response to the need for higher bandwidth data communication structures, a SERDES (serulator/de-serial) data communication structure is generated. The SERDES operates in accordance with a predetermined mechanism (e.g., octet/tenset-8b10b encoding) to encode and decode the data. The encoded data is communicated from the serializer via a one or more communication channels to a corresponding deserializer for decoding. The SERDES data communication structure has been demonstrated to increase the bandwidth of data communication between the mating components. In this context, the SERDES data communication structure is deployed as a data bus that operates to carry data between the mating components.

Summary of invention

A data communication architecture is provided that employs a serializer and a deserializer for communicating data between computer processing components of a computing environment to reduce latency. In the illustrated embodiment, the data communication structure includes a data interface, a serializer, and a deserializer. During operation, data from the computer processing component is received using the serializer. The splicer coupled to the data interface encodes the data for communication to the deserializer in accordance with the selected coding protocol. In operation, the splicer and the deserializer (SERDES) cooperate to form a communication link or communication channel. The data interface allows for the collection of data transmitted across the link from the end of the link, provides link management and control information, code error protection, and provides logic for processing data across the communication channel.

In a further embodiment, the data communication structure shown further includes a data buffer, a training module, a debug module, an error introduction module, and an error detection module. These monitors and/or modules include a portion of the splicer and splicer. In operation, the monitors and/or modules are coupled to the data interface and the instruction set included in the serializer and the deserializer to implement (but are not limited to) processing debug information, processing link identification information, Introduces errors across communication links and performs error detection.

Further features of the invention are further described below.

Simple illustration

The data communication structure and method used will be further described with reference to the accompanying drawings, wherein: FIG. 1 is a block diagram showing an example of a computing environment according to the above system and method embodiment; FIG. 2 is a block diagram showing an example of a data communication structure. The block diagram of the example; the third diagram is a block diagram of the transmission core according to the implementation example of the data communication structure; the fourth diagram is a block diagram of the receiving core according to the implementation example of the data communication structure; and FIG. 5 is a diagram showing the communication core according to the implementation example; A flowchart of the processing of the data communication structure example; FIG. 6 is a flow chart showing the processing performed by the data communication structure example when processing the debugging information; and FIG. 7 is a diagram showing the data when processing the identification information. A flow chart for processing a communication structure example; FIG. 8 is a flow chart showing processing performed by an example of a data communication structure when an error is introduced as a partial link test; and FIG. 9 is a diagram showing processing error detection A flow chart that is processed by an example of a data communication structure.

Detailed description of the preferred embodiment Overview:

To provide the infrastructure bandwidth required for a computing environment, embodiments utilize a serial-to-point data communication architecture that operates at high frequencies with a serializer/deserializer (SERDES). There are some limitations when applying the SERDES data communication structure to the internal data communication infrastructure of the computing environment. In general, the non-essential incubation period in data communication arises from inefficient data communication structure management. Management of the SERDES data communication structure can be performed using the data interface, collecting information for communication along the SERDES communication link and providing error detection and processing instructions regarding the error data.

The present invention provides a data interface for use with the SERDES link channel that supports bidirectional operation between data communication fabric components. In the illustrated embodiment, an organization is provided to collect data transfers for each endpoint of the link across a SERDES link. Additionally, the mechanism is operable to provide coverage link management information, while encoding error detection, and encoding the data into an appropriate format. The data interface illustrated by the embodiments presented herein also maintains logic that instructs SERDES components to collect, generate, embed, and/or communicate specific types of data between SERDES link components (eg, error detection information, chains) Road identification information, error information, and debug information) for reliability testing and/or characterization, debugging, link training, and checking whether such data is properly collected and communicated.

The SERDES data communication structure shown can also use a data buffer to store data. In operation, the data buffer can be used to store data until it is properly received by the response from the receiving endpoint of the SERDES communication link. In this case, an approval can be embedded as part of the communication between the mating components of the SERDES data communication structure. When an error is detected by the SERDES component, the data buffer can be used to resend the data to correct the error.

Still further, the illustrated embodiment can coordinate the use of a plurality of parallel SERDES communication channels. The SERDES communication channel can include a logical communication link operating on a physical link (eg, a cable) between SERDES components (eg, a serializer and a deserializer). When performing error detection and other operations, the SERDES data communication structure shown may use an alternate channel. Additionally, this alternate channel can be used to maintain communication effectiveness even in the event of a hardware failure of one of the channels.

Display computing environment

FIG. 1 shows an example of a computing system 100 in accordance with the systems and methods described herein. Computing system 100 is capable of executing a variety of computing applications 180. The example computing system 100 is primarily controlled using computer readable instructions, which may be in the form of software where the software will be stored and retrieved. This software can be executed within central processing unit (CPU) 110 to cause data processing system 100 to function. In many conventional computer servers, workstations, and personal computers, central processing unit 110 is fabricated using a microelectronics chip CPU known as a microprocessor. Unlike the primary CPU 110, the secondary processor 115 is a selective processor that performs additional functions or assists the CPU 110. CPU 110 may be connected to auxiliary processor 115 via interconnect 112. One common type of auxiliary processor is the floating point auxiliary processor, also referred to as a numerical or mathematical auxiliary processor, which is designed to perform faster and better numerical calculations than the general purpose CPU 110.

It should be appreciated that while a computing environment shown is shown to include a single CPU 110, this description is merely illustrative, as computing environment 100 may include a number of CPUs 110. Additionally, computing environment 100 may utilize resources of a remote CPU (not shown) via communication network 160 or some other data communication device (not shown).

In operation, the CPU 110 retrieves, decodes, and executes the instructions and transmits the information to and from other resources via the primary data transfer channel of the computer (eg, system bus 105). This system bus bar connects the components in computing system 100 and defines the media for data exchange. The system bus 105 generally includes a data line for transmitting data, an address line for transmitting an address, and a control line for transmitting an interrupt and for operating the bus. An example of this system bus is the PCI (Peripheral Component Interconnect) bus. Some of today's advanced bus bars provide a function known as bus arbitration, which utilizes an extension card, controller, and CPU 110 to adjust access to the bus. Devices that are attached to these bus bars and arbitrated to manage the bus bars are called bus masters. The bus manager support also allows multi-processor configuration of the bus, which is generated by adding a bus manager switch that includes a processor and its supporting chips.

The memory device coupled to system bus 105 includes random access memory (RAM) 125 and read only memory (ROM) 130. This memory contains circuitry that allows information to be stored and retrieved. ROM 130 typically contains stored material that cannot be modified. The data stored in the RAM 125 can be read or changed using the CPU 110 or other hardware device. Access to RAM 125 and/or ROM 130 can be controlled using memory controller 120. The memory controller 120 can provide an address translation function that translates the virtual address into a physical address when the instruction is executed. The memory controller 120 also provides a memory protection function that isolates the processing within the system and isolates the system handler from the user handler. Thus, a program executing in user mode typically only has access to memory that is mapped using its unique handler virtual address space; it cannot access memory in the virtual address space of another handler, Unless the memory shared between the handlers has been set.

In addition, computing system 100 can include peripheral controller 135 that is backed up from CPU 110 to peripherals, such as printer 140, keyboard 145, mouse 150, and data storage driver 155.

Display 165, which is controlled by display controller 163, is used to display the visual output produced by computing system 100. This visual output can include text, graphics, animated graphics, and video. The display 165 can be fabricated using a CRT-based video display, an LCD-based flat panel display, a plasma-based flat panel display, a touch panel, or other form of display. Display controller 163 includes the electronic components needed to generate the video signals that are transmitted to display 165.

Further, computing system 100 can include a network adapter 170 that can be used to connect computing system 100 to an external communication network 160. The communication network 160 can electronically provide methods and information for computer users to communicate and transfer software. Additionally, communication network 160 can provide distributed processing that includes many computers and work-time sharing or collaborative efforts. It should be understood that the network connections shown are merely examples and other methods of establishing a communication link between computers can be used.

It should be appreciated that the example computer system 100 is merely a computing environment in which the systems and methods described above are operational, and embodiments of the systems and methods in the computing environment described above are not limited to having different components and configurations, as described above. The concept can be fabricated in a variety of computing environments with a variety of components and configurations.

Data communication structure:

Figure 2-4 depicts a block diagram of a data communication structure for use in an example of a computing environment. The data communication structure of the presentation can be fabricated as a computing environment component and can employ SERDES components. In particular, Figure 2 shows a block diagram of an illustrative data communication structure 200. As shown in FIG. 2, the data communication structure 200 includes data communication interface modules 205 and 210 that are coupled to the communication material 230 via the physical link 220. The data interface communication modules 205 and 210 include at least one transmit core and at least one receive core. The physical link 220 is attached to the data communication interface modules 205 and 210 via the physical connector 225.

In operation, the example computing environment (not shown) is coupled to the data communication interface modules 205 and 210 to communicate data between the data communication interface modules 205 and 210. In the illustrated embodiment, the data communication interface module can exist in different geographic locations within the example computing environment (not shown) or can exist as a component of a sample computing environment (not shown) printed circuit board (PCB). . As shown, the data can be communicated between the transmit core and the receive core of the data communication interfaces 205 and 210 in a selected direction or bidirectionally, such as the indications of arrows 232 and 234 on physical link 220 and data 230. It should also be appreciated that the physical links 220 being displayed have different line thicknesses to indicate different physical link 220 media.

Still further, as shown, dashed line block 215 shows the components of the data communication backplane paradigm. In the embodiment provided, the backplane 215 is shown with a pair of transmit-receive cores operating with communication material. In particular, the data is processed by the transmit core 235 of the data communication interface 205 to communicate to the receive core 245 of the data communication interface 210 via the physical connector 225 and the physical link 220. Similarly, data may be processed by the transmit core 250 of the data communication interface 210 for communication to the receive core 240 of the data communication interface 205. In addition, the transmit-receive core set pair 235, 240 and 245, 250 can cooperate to form a communication channel. As a communication channel, the transmit-receive core group pair can be calibrated and trained to process data in accordance with a selected encoding protocol (e.g., octet-decibel (8b10b) encoding).

Further, as shown in FIG. 2, the material 230 can include some packets. Specifically, the material 230 can include a header portion and a data packet portion. The data packet portion may further include a small data packet. It should be appreciated that in the illustrated embodiment provided, a small packet may be considered a data packet, which is a full size data packet that is smaller than a standard size. In operation, various data, control, training, and channel management information can be communicated over the example data communication structure 200 (e.g., material 230).

Figure 3 shows a block diagram of an example of a transmitting core environment 300 that reveals its components and their mating objects. As shown in FIG. 3, the transmit core environment 300 example includes a plurality of transmit cores from the transmit core 300-1 to the transmit core 300-n. Transmit core 300-1 is shown to include logic blocks, including a plurality of serializers from serial 1 to serializer n and a plurality of drivers from drive 1 to drive m, respectively. Additionally, the transmitting core 300-1 is coupled to an external data communication component (not shown) to obtain the clock signal CLK. Also, as shown, the transmitting core 300-1 also contains logic that holds the set of instructions to indicate that the component of the transmitting core 300-1 (e.g., the serializer 1) performs functions in accordance with the data communication operation. The logic of the transmit core 300-1 can also function to maintain one or more modules and mechanisms for use during data communication operations, the module and mechanism including (but not limited to) data buffers (not The display module 305, the training module 310, the error introduction module 315, and the error detection module 320 are shown.

In operation, the data is provided as input to a serializer of one of the transmitting cores 300-1. The data is encoded according to a selected encoding protocol (eg, 8-bit-10 bit encoding) and is prepared to communicate to a data communication component by a driver of a transmitting core on an output channel of a transmitting core. . The encoding protocol can employ a CLK signal to encode some bits during the period selected by the CLK signal. For example, the material A can be encoded using the serializer 1 of the transmitting core 300-1 according to the selected encoding protocol, and is prepared to communicate with the driver 1 according to the instructions provided by the logic of the transmitting core 300-1. The output of channel A produces the encoded data. Similarly, the material B can be encoded by the serializer 2 of the transmitting core 300-1 according to a selected encoding protocol and prepared to communicate with the driver 2 at channel B to generate encoded material. This encoding program and data communication is prepared in the transmitting core 300-1 of the transmitting core environment 300 and the remaining serials and drivers of the other transmitting cores.

Figure 4 shows a block diagram of an example of a receiving core environment 400 that reveals its components and their mating objects. As shown in FIG. 4, the receive core 400 example includes a plurality of receive cores from the receive core 400-1 to the receive core 400-n. The receiving core 400-1 is shown to include a logical block, which includes a plurality of de-serializers from the de-serial 1 to the deserializer n and a driver from the driver 1 to the driver m, respectively. In addition, the receiving core 400-1 is coupled to an external data communication component (not shown) to obtain the clock signal CLK. Also, as shown, receive core 400-1 also includes a logic that maintains a set of instructions to instruct receiving core 400-1 components (e.g., deserializer 1) to perform its functions in accordance with data communication operations. The receiving core 400-1 logic can also function to maintain one or more modules and mechanisms for use during data communication operations, including (but not limited to) data buffers (not shown), debug modules 405. The training module 410, the error introduction module 415, and the error detection module 420.

In operation, the encoded material is provided as an input to a deserializer of one of the receiving cores 400-1. The data is decoded in accordance with the selected decoding protocol (e.g., 10-bit-8 bits) and is prepared for communication by a receiving core driver to a mating data communication component of the de-serial output of a receiving core. The decoding protocol can employ a CLK signal to decode some bits during the selected CLK signal period. For example, the encoded material A can be decoded using the deserializer 1 of the receiving core 400-1 in accordance with the selected decoding protocol, and is prepared for communication by the driver 1 in accordance with the logic provided by the receiving core 400-1. Data A is generated by the instruction. Similarly, the encoded material B can be decoded using the deserializer 2 of the receiving core 400-1 in accordance with the selected decoding protocol, and is prepared for communication by the driver 2 to generate the material B. This decoding process and data communication are prepared in the receiving core 400-1 of the core environment 400 and the remaining deserializers and drivers of the other receiving cores.

Figures 3 and 4 together illustrate an example of a communication channel environment such that data is encoded for decoding and processing by one or more receiving cores in sequence by one or more transmitting core communications. Although separate components have been described, it should be understood that the transmitting core and the receiving core may be present on individual communication components (see data communication interface 205 of Figure 2). In addition, the transmit core and the receive core can operate in pairs to form one or more bidirectional data communication channels.

Communication information across the communication link:

Figure 5 shows the processing performed by the example data communication structure 200 when establishing a communication channel. As shown, the process begins at block 500 and proceeds to block 505 where the communication components are powered to operate. From there, the process proceeds to block 510 where the communication link is established between the data communication fabric components. The communication link is then trained at block 515 to form a communication channel. Next at block 520, training data is sent via the communication channel to test the communication channel. A check is then made at block 525 to determine if the communication channel test was successful. If it is successful, the process proceeds to block 540 where a check is made to determine if there is a data stream communicating over the successfully tested communication channel. If at block 540, it is determined that there is no data communication, then the process returns to the input of block 540. However, if there is a data stream communicating via the successfully tested and trained communication channel, then the process proceeds to block 545 where the data stream is encoded using the serializer. The encoded data stream is then communicated over the communication channel to match the deserializer of block 550. The data stream is then decoded at block 555 using a deserializer. A check is then made at block 560 to determine if the small data packets of the data stream were successfully communicated. If the small data packet was successfully sent, the handler reverts to block 540 and proceeds from there. However, if the small data packet was not successfully communicated, the process returns to block 530 where the communication channel is retrained and continues from there.

However, if it is determined at block 525 that the communication channel test was not successful, then the process proceeds to block 530 where the communication link is retrained. From there, the process continues to block 535 where control information is communicated between the communication link components. From there, the handler reverts to block 520 and proceeds from there.

In operation, the illustrated embodiment provides a training sequence that is managed by a communications link deserializer. In particular, the initiation of training immediately after the write indication of the selected software type register on the deserializer is recognized is considered complete. At this point, the data is driven to the link using the serializer of the communication channel. In the form of the deserializer operation, the deserializer maintains one or more sets of instructions that instruct the deserializer to detect activity on the link to signal to the companion to begin initialization. The deserializer and the serializer of the communication channel maintain at least one instruction set to indicate that the channel begins to start. After successful startup, each channel's own test is performed and the results are collected and compared. The set of instructions then instructs the serializer and the deserializer to communicate a selected data pattern that is expected by the deserializer, which allows the deserializer to determine the aggregation for use by the serializer and the deserializer. The bit unit used by the encoding and decoding protocol.

Additionally, the second identifiable data sample is communicated to the deserializer, where the deserializer treats it as a small packet data communication. By setting up the small packet data communication, the deserializer is operable to match the small packets in the cluster to the initial communication mode of the small packet. Once the second data sample is successfully communicated and processed, the control signal self-deserializer is transmitted to the serial link of the communication link indicating that the training has been completed. According to this argument, data packets can be communicated across the channel being trained.

Moreover, the illustrated embodiment provides that if an error occurs over a communication link, the link can be retrained. Link retraining is similar to the link training described above in the aforementioned launch communication channel components. Retraining may be triggered by the use of some events (including, but not limited to, misidentification across the communication link) or by receiving an error signal generated on the link using the communication link to receive the endpoint.

Debugging operation:

The example data communication structure 200 of Figure 2 is also capable of transmitting debug data for processing and analysis. In the SERDES data communication structure of this paper, the internal design of the data communication structure example is more clearly translatable into a more effective debugging and confirmation of the design and production of the SERDES data communication structure. In the SERDES data communication architecture, during debug operations, debug data is directed across various components of the structure for processing and analysis. When the debug data is successfully transmitted across the structure, proper firing and unloading of the debug information occurs.

In the embodiment provided, the debug data may be from an internal debug data hardware component that includes any portion of the transmit core (300 of Figure 3) or the receive core (400 of Figure 4). The debug data is processed in accordance with one or more sets of instructions to transfer the debug data between the mating components of the example communication structure. In an embodiment provided, the example structure can receive debug data having a first selected number of bits and group the debug data to generate modified debug data having a second selected number of bits (eg, Wrong data packet). The paired debug data can then be buffered to match the communication link frequency and then communicated across the communication link. At the receiving end, the paired debug data can be obtained and decomposed into data packets having the first selected number of bits.

The debug operation may include an ability to utilize the receiving endpoints of the example communication link of the example communication structure to collect general non-debug processing of the link and provide all, or part, of the non-debug processing to the sequential communication Internal debug logic (for example, different instances of the example communication structure are processed repeatedly on the outer link). Therefore, the debug logic provides more efficient processing and data communication across the sample data communication structure.

Additionally, the illustrated embodiment provides that the transmitting end of the communication link can be configured with an interleaving period for the internal debug data hardware component as a debug data packet, or it can use a valid indication that the debug data is transmitted with the debug data. Matching debug data transmitted from a cooperating data communication fabric (eg, link interface). Still further, the illustrated embodiment provides that the example data communication structure can be enabled for debug operation via link retraining. After the link training sequence is completed, the debug operation is performed immediately.

Figure 6 shows the processing performed by the example data communication structure 200 when processing the debug data. As shown, processing begins at block 600 and proceeds to block 610 where the debug data having the number of bits initially selected (eg, 76 bits) is paired to produce a second set of selected bits. A debug data packet of a number of elements (for example, 152 bits). From there, at block 615, the debug data packet is buffered to match it to the communication link frequency. Next at block 620, the debug data packet is communicated across the communication link. From there, the debug data packet is obtained at block 625 on the receiving end of the communication link and processed.

A check is then made at block 640 to determine if there is a link failure. If the check at block 640 indicates a link failure, then the process proceeds to block 645 where the fault is reported for further action. The process then proceeds to block 660 where the communication link is retrained. From there, the handler reverts to block 610 and continues from there.

However, if it is determined at block 640 that there is no link failure, then the process proceeds to block 635 where the debug data packet is decomposed into a form in which the debug data has its originally selected number of bits. From there, processing proceeds to block 650 to continue processing of the data. The handler then terminates at block 655.

Link identification information:

The sample data communication structure 200 is also capable of transmitting link identification information. The illustrated embodiment operates by using link identification information to allow validation, approval, and mapping of the example communication material structure 200 physical communication links.

In the SERDES data communication architecture herein, many links are used together for various point-to-point connections within the data communication structure paradigm. In the illustrated embodiment, the communication nodes of the SERDES data communication structure can be connected as a crossbar hardware component that facilitates communication of data across the SERDES data communication structure. These entity connections indicate and specify the operation of the sample data communication structure. To ensure that these connections are correct and/or to establish a connection map, knowledge of the connection is needed.

The illustrated embodiment provides that the communication link of the example data communication structure can be trained prior to use. During the training period, the sample data communication structure confirms the clock position of various matching components of the data communication structure. Using clock positioning information, the data packet can be calibrated from the transmitting end of the communication link to the receiving end to ensure data communication.

The illustrated embodiment further provides that, in operation, a location identifier is generated and that the transmitting endpoint of the example communication link is communicated to the receiving endpoint of the communication link to provide location information regarding the transmitting endpoint of the communication link ( For example, mapping and linking). In the illustrated embodiment, the location identifier can be embedded in the training sequence, or in the training step, depending on the selected interval, but should be before the link is released for normal operation. The embedded location identifier is obtained by the receiving endpoint during the training sequence according to the receiving endpoint logic (eg, the instruction set and the command), and the location identification signal is placed in the storage component for sequential Processing. In this context, an example of a data communication structure may employ one or more sets of instructions to process location identification information (eg, via use of internal or external software) to produce an architectural pattern of data communication structure connections and connection relationships.

In particular, the type of data (eg, location identifier) transmitted by the endpoint via the communication link may be hardwired using hardware logic and/or programmable via an instruction set (eg, software) The sample may be provided using an external source (eg, a mating hardware component). The illustrated embodiment provides that the location identifier data field can be a programmable type that is loaded into the receiving end by the load, which is driven by utilizing one or more field programmable gate arrays (FPGAs) (not shown). An external input communication port transfers the data type (for example, a location identifier). In this programmable format, the data sample may contain additional information about physical connections just beyond the location, including (but not limited to) hardware types (eg, wafer type), link frequency, and link status. In the context of this information, such information may include (but is not limited to) reset progress, interface status, configuration information, or error status.

Figure 7 shows the processing performed by the example data communication structure 200 when transmitting link identification information. As shown, processing begins at block 700 and proceeds to block 705 where the data communication structure initiates training of the communication link. From there, the process proceeds to block 710 where a location identifier is obtained which confirms the relative location of the transmitting endpoint to the receiving endpoint of the example communication link. At block 715, the location identifier is embedded as part of the communication link training sequence. Processing then proceeds to block 720 where the location identifier is obtained by the communication link receiving endpoint and processed. At block 725, the location identifier value is compared to an expected value using the communication link receiving endpoint.

A check is then made at block 830 to determine if there are any errors in the location identifier transmission. If it is determined at block 830 that there are no errors, then the process proceeds to block 735 where training is completed and data processing is performed.

However, if an error is determined at block 730, the process proceeds to block 750 where the error is reported. This error is then re-solved at block 755. From there, processing proceeds to block 705 and continues from there.

Error introduction:

The example data communication architecture 200 of Figure 2 can also introduce selected errors as part of the communication link test. In the SERDES data communication structure herein, the illustrated embodiment confirms the error condition function in the system under evaluation (eg, communication link test).

The SERDES data communication architecture provides a number of different correctness checks for the data received at the receiving end of the communication link. Different activities are expected depending on the nature of the error, and at the receiving end of the communication link, different information may be expected. The illustrated embodiment explicitly illustrates a variety of introduced error events that are triggered by a debug logic (e.g., 315 of FIG. 3) signal found on the communication link transmitting endpoint. For example, such an error event may include (but is not limited to) a simple unit error, skipping or adding a small data packet, and cutting off the communication link channel.

Additionally, the illustrated embodiment provides for introducing more than one error as part of the test sequence. In this context, a sequential error can be introduced, so it occurs simultaneously with the first set of errors, or when the second set of triggers occurs. With this ability, most error events can be tested. Additionally, the illustrated embodiment may allow for continuous specifications of various error patterns. This may be from one to many cycles, or permanently (for example, until the situation is removed from the communication link). For its part, the embodiment shown here is capable of handling sporadic and continuous failures. Moreover, when an error trigger occurs, the illustrated embodiment can obtain a small data packet that is corrupted in the buffer on the communication link transmission endpoint (e.g., 300 of FIG. 3). Thus, a reference can be generated to confirm the expected communication link action compared to the error record obtained at the link receiving endpoint.

Figure 8 shows the processing performed by the example data communication structure 200 of Figure 2 when an error is introduced as part of the communication link test. As shown, processing begins at block 800 and proceeds to block 805 where a communication link is established. From there, processing proceeds to block 810 where one or more errors (eg, runaway, time lapse, incorrect small data packets, etc.) are introduced from the communication link transmitting endpoint to be communicated to Receive data from the endpoint. Processing then proceeds to block 815 where the error that was generated is introduced into the material. The modified data is then communicated across block 820 across the communication link. Next at block 825, an error is obtained at the communication link receiving endpoint. The error obtained is then analyzed at block 830 to compare the error that was initially introduced. Based on the comparison, the communication link operation is checked at block 835. A check is then made at block 840 to determine if the link is operating as intended. If the check at block 840 indicates that the communication link is operating as expected, the process terminates at block 850.

However, if at block 840, it is determined that the link is not operating properly, then the process proceeds to block 845 where the failure of the communication link is analyzed. From there, processing terminates at block 850.

Error detection:

The example data communication structure 200 of Fig. 2 can also effectively detect errors in the data communication processing program without introducing an incubation period into the communication link. In the context of the SERDES data communication architecture, the illustrated embodiment is capable of retrieving data transfers that cannot be transmitted accurately across the SERDES communication link.

In the SERDES data communication structure, data packets can be tracked and monitored to determine successful delivery. In this document, the flag of the selected small data packet across the link is monitored to determine the successful transmission from the communication link transmitting endpoint to the communication link receiving endpoint. After successful transmission, the acknowledgement message can be immediately transmitted from the communication link receiving endpoint to the communication link transmitting endpoint to indicate a successful transmission. As previously explained, processing can be transmitted across the communication link as a sequence of small data packets: a small data packet with routing and processing headers, and a number of additional small files needed to process the type information followed by data transfer. Data packet. In the illustrated embodiment, the header can include the current small data packet tag.

In operation, the link receiving endpoint checks the tag contained in the header packet and indicates a link error if the expected tag is not found. For its part, when it is expected that a small data packet under the file header does not have the correct label, errors due to rounding off or repeating the small data packet will be discovered. However, when all the processing is completed, the error may not be detected, and inefficiency may occur.

The illustrated embodiment provides the ability to include bits of an implicit tag in a co-located column that is used to protect the bit error of a small data packet. In operation, the tag bit is included in a parity bit that is calculated to detect a different bit error. For its part, lost or duplicated small data packets will result in a parity calculation error on the communication link receiving endpoint. The illustrated embodiment, upon detecting a parity error, immediately requests retransmission of the small data packet and also prevents the corrupted data from being transmitted from the communication link receiving endpoint.

Figure 9 shows the processing performed by the example data communication structure 200 of Figure 2 when detecting errors in data communication processing. As shown, processing begins at block 900 and proceeds to block 905 where a communication link is established. From there, the process proceeds to block 910 where the tag bit of the implicit data tag is generated. The generated tag bit is then encoded at block 915 (e.g., the eight parity bits carrying the data across the channel are calculated, wherein each co-bit is the first of the octets of the transmitted data on the link. , 2, 3, ... 8-bit-based communication) becomes the calculation of the parity bit on the transmission link of the communication link. From there, processing proceeds to block 920 where the data having the encoded tag bit as part of the parity bit is communicated across the communication link. The data is received at the communication link receiving endpoint and the parity data is calculated at block 925 using the receiving endpoint. A check is then made at block 930 to determine if there are any errors in the transmitted parity calculation and the received parity calculation. If it is determined at block 930 that there are no errors, then the process proceeds to block 940 where the data communication process continues. The process then terminates at block 945.

However, if at block 930, an error is determined, then the process proceeds to block 940 where the data retransmission request is transmitted to the communication link transmitting endpoint using the communication link. The process then returns to block 910 and continues.

Briefly, the above apparatus and method provide a data communication structure for use in a computing environment communication structure that reduces data latency. However, it should be understood that the invention is capable of various modifications and various modifications. The invention is not limited to the specific configurations described herein. Rather, the invention is intended to cover all modifications, various modifications, and equivalents

It should also be noted that the present invention can be fabricated in a variety of computer environments (including both non-wireless and wireless computer environments), part of the computing environment, and real world environments. The various techniques described above can be fabricated in hardware or software, or a combination of both. Preferably, the technology is fabricated in a computing environment that maintains a programmable computer, the programmable computer including a processor, a storage medium readable by the processor (including electrical and non-electrical memory) And/or storage element), at least one input device, and at least one output device. Computational hardware logic coupled to various instruction sets is applied to the data to perform the functions described above and to generate output information. The output information is applied to one or more output devices. The programs used by the example computing hardware can be optimally programmed to communicate with a computer system in a variety of programming languages, including high level programming or object oriented programming languages. The apparatus and methods described herein can be fabricated in combination or machine language, if desired. In any case, the language can be a language that is compiled or interpreted. Preferably, the computer programs are each stored on a storage medium or device (for example, a ROM or a magnetic disk), which can be read by a programmable computer for general or special use, when the storage medium or device is read by a computer. In time, it can configure and operate the computer to perform the above steps. The device can also be considered as a computer readable storage medium, configured using a computer program, whereby the configured storage medium causes the computer to operate in a specific and predetermined manner.

While the invention has been described in detail hereinabove, it is understood that the invention may be Accordingly, these and all such modifications are intended to be included within the scope of the invention. The invention is preferably defined by the scope of the following claims.

100. . . Computing system

105. . . System bus

110. . . Computer central processing unit

112. . . interconnection

115. . . Auxiliary processor

120. . . Memory controller

125. . . Random access memory (RAM)

130. . . Read only memory (ROM)

135. . . Peripheral controller

140. . . Printer

145. . . keyboard

150. . . mouse

155. . . Data storage drive

160. . . Communication network

163. . . Display controller

165. . . monitor

170. . . Network adapter

180. . . Computing application

200. . . Data communication structure

205. . . Data communication interface module

210. . . Data communication interface module

215. . . Backplane

220. . . Physical link

225. . . Physical connector

230. . . Communication information

234. . . Sending direction

235, 240. . . Send and receive core group pair

245, 250. . . Send and receive core group pair

300. . . Send core environment

305. . . Debug module

310. . . Training module

315. . . Error introduction module

320. . . Error detection module

400. . . Receiving core

405. . . Debug module

410. . . Training module

415. . . Error introduction module

420. . . Error detection module

1 is a block diagram showing an example of a computing environment according to the above system and method embodiment; FIG. 2 is a block diagram showing an example of a component that is combined with an example of a data communication structure; and FIG. 3 is a transmitting core according to an example of a data communication structure implementation; Figure 4 is a block diagram of the receiving core according to the implementation example of the data communication structure; Figure 5 is a flow chart showing the processing performed by the data communication structure example when communicating data; Figure 6 is a diagram showing A flow chart processed by the data communication structure example when processing debug information; FIG. 7 is a flow chart showing the processing performed by the data communication structure example when processing the identification information; FIG. 8 is a display when introduced The error is a flow chart processed by the data communication structure example as part of the link test; and FIG. 9 is a flow chart showing the processing performed by the data communication structure example when the error detection is processed.

200. . . Data communication structure

205. . . Data communication interface module

210. . . Data communication interface module

215. . . Backplane

220. . . Physical link

225. . . Physical connector

230. . . Communication information

234. . . Sending direction

235, 240. . . Send and receive core group pair

245, 250. . . Send and receive core group pair

Claims (11)

A system for identifying components of a data communication architecture, the system comprising: a training module operative to assemble the components of the data communication architecture in accordance with a training sequence; a location identifier comprising the training a portion of the sequence to indicate the physical and virtual location of at least one first component of the data communication architecture relative to a second component of the data communication architecture; and a communication link having a transmitting endpoint and a receiving endpoint The operation of transmitting the location identifier across the components of the data communication architecture; wherein one of the transmitting endpoint and the receiving endpoint comprises the first component, and the transmitting endpoint and the receiving end The other point includes the second member. The system of claim 1, further comprising at least one set of instructions to provide an indication to the training module to embed the location identifier as part of the training sequence. The system of claim 2, wherein the communication link comprises any one of a serializer and a deserializer. The system of claim 3, wherein the training module includes a portion of the serializer. The system of claim 4, wherein the training module includes a portion of the deserializer. The system of claim 1, wherein the location identifier is One of the communication links is generated by the sending endpoint. A system as claimed in claim 1, wherein the location identifier transmitted across the communication link is obtained at a receiving end of the communication link. The system of claim 7, wherein the obtained location identifier is compared to a selected value at the receiving end of the communication link. The system of claim 8, wherein the receiving end of the communication link is included in a set of expected values provided by the training module to identify an error. A system of claim 9 further comprising a set of instructions for providing an indication to the receiving endpoint of the communication link to process an identified error. A system as claimed in claim 10, wherein the receiving end of the communication link generates a report when an error is identified.