Patent Publication Number: US-6993611-B2

Title: Enhanced general input/output architecture and related methods for establishing virtual channels therein

Description:
PRIORITY 
   This application is a continuation of patent application Ser. No. 09/968,620, filed Sep. 30, 2001 now U.S. Pat. No. 6,691,192 and entitled “AN ENHANCED GENERAL INPUT/OUTPUT ARCHITECTURE AND RELATED METHODS FOR ESTABLISHING VIRTUAL CHANNELS THEREIN” 
   The present application expressly claims priority to U.S. Provisional Application No. 60/314,708 entitled A High-speed, Point-to-Point Interconnection and Communication Architecture, Protocol and Related Methods filed on Aug. 24, 2001 by Ajanovic et al, and commonly assigned to the Assignee of this application. 

   TECHNICAL FIELD 
   This invention generally relates to general input/output bus architectures and, more particularly, to a high-speed, point-to-point interconnection and communication architecture, protocol and related methods. 
   BACKGROUND 
   Computing appliances, e.g., computer systems, servers, networking switches and routers, wireless communication devices, and the like are typically comprised of a number of disparate elements. Such elements often include a processor, microcontroller or other control logic, a memory system, input and output interface(s), and the like. To facilitate communication between such elements, computing appliances have long relied on a general purpose input/output (GIO) bus to enable these disparate elements of the computing system to communicate with one another in support of the myriad of applications offered by such appliances. 
   Perhaps one of the most pervasive of such conventional GIO bus architectures is the peripheral component interconnect, or PCI, bus architecture. The PCI bus standard (Peripheral Component Interconnect (PCI) Local Bus Specification, Rev. 2.2, released Dec. 18, 1998) defines a multi-drop, parallel bus architecture for interconnecting chips, expansion boards, and processor/memory subsystems in an arbitrated fashion within a computing appliance. The content of the PCI local bus standard is expressly incorporated herein by reference, for all purposes. While conventional PCI bus implementations have a 133 Mbps throughput (i.e., 32 bits at 33 MHz), the PCI 2.2 standard allows for 64 bits per pin of the parallel connection clocked at up to 133 MHz resulting in a theoretical throughput of just over 1 Gbps. 
   In this regard, the throughput provided by such conventional multi-drop PCI bus architectures has, until recently, provided adequate bandwidth to accommodate the internal communication needs of even the most advanced of computing appliances (e.g., multiprocessor server applications, network appliances, etc.). However, with recent advances in processing power taking processing speeds above the 1 Ghz threshold, coupled with the widespread deployment of broadband Internet access, conventional GIO architectures such as the PCI bus architecture have become a bottleneck within such computing appliances. 
   Another limitation associated with conventional GIO architectures is that they are typically not well-suited to handle/process isochronous (or, time dependent) data streams. An example of just such an isochronous data stream is multimedia data streams, which require an isochronous transport mechanism to ensure that the data is consumed as fast as it is received, and that the audio portion is synchronized with the video portion. Conventional GIO architectures process data asynchronously, or in random intervals as bandwidth permits. Such asynchronous processing of isochronous data can result in misaligned audio and video and, as a result, certain providers of isochronous multimedia have rules that prioritize certain data over other, e.g., prioritizing audio data over video data so that at least the end-user receives a relatively steady stream of audio (i.e., not broken-up) so that they may enjoy the song, understand the story, etc. that is being streamed. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention is illustrated by way of example, and not necessarily by way of limitation in the figures of the accompanying drawings in which like reference numerals refer to similar elements. 
       FIG. 1  is a block diagram of an electronic appliance incorporating one or more aspects of the present invention to facilitate communication between one or more elements comprising the appliance, in accordance with the teachings of the present invention; 
       FIG. 2  is a graphical illustration of an example communication stack employed by one or more elements of the electronic appliance to facilitate communication between such elements, in according to one example embodiment of the present invention; 
       FIG. 3  is a graphical illustration of an example transaction descriptor is presented, in accordance with the teachings of the present invention; 
       FIG. 4  is a graphical illustration of an example communication link comprising one or more virtual channels to facilitate communication between one or more elements of the electronic device, according to one aspect of the present invention; 
       FIG. 5  is a block diagram of an example communication agent to implement one or more aspects of the present invention, according to one example embodiment of the present invention; 
       FIG. 6  is a block diagram of various packet header formats used within the transaction layer of the present invention; 
       FIG. 7  is a block diagram of an example memory architecture employed to facilitate one or more aspects of the present invention, according to an example embodiment of the present invention; 
       FIG. 8  is a state diagram of an example links state machine diagram, according to one aspect of the present invention; 
       FIG. 9  is a block diagram of an accessible medium comprising content which, when accessed by an electronic device, implements one or more aspects of the present invention; and 
       FIG. 10  is a flow chart of an example method of establishing virtual channels within a general input/output bus architecture, according to one aspect of the present invention. 
   

   DETAILED DESCRIPTION 
   This invention is generally drawn to an innovative point-to-point interconnection architecture, communication protocol and related methods to provide a scalable/extensible general input/output (I/O) communication platform for deployment within an electronic appliance. In this regard, an innovative enhanced general input/output (EGIO) interconnection architecture and associated EGIO communications protocol is introduced. According to one example embodiment, the disparate elements of an EGIO architecture include one or more of a host bridge, a switch, or end-points, each incorporating at least a subset of EGIO features to support EGIO communication between such elements. 
   Communication between the EGIO facilities of such elements is performed using serial communication channel(s) by employing an innovative EGIO communication protocol which, as will be developed more fully below, supports one or more innovative features including, but not limited to, virtual communication channels, tailer-based error forwarding, support for legacy PCI-based devices, multiple request response type(s), flow control and/or data integrity management facilities. According to one aspect of the invention, the communication protocol is supported within each of the elements of the computing appliance with introduction of an EGIO communication protocol stack, the stack comprising a physical layer, a data link layer and a transaction layer. 
   In accordance with an alternate implementation, a communications agent is introduced incorporating an EGIO engine comprising at least a subset of the foregoing features. It will be apparent, from the discussion to follow, that the communications agent may well be used by legacy elements of an electronic appliance to introduce the communication protocol requirements of the present invention to an otherwise non-EGIO interconnection compliant architecture. In light of the foregoing, and the description to follow, those skilled in the art will appreciate that one or more elements of the present invention may well be embodied in hardware, software, a propagated signal, or a combination thereof. 
   Reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments. 
   Terminology 
   Before delving into the particulars of the innovative EGIO interconnection architecture and communication protocol, it may be useful to introduce the elements of the vocabulary that will be used throughout this detailed description:
         Advertise: Used the context of EGIO flow control to refer to the act of a receiver sending information regarding its flow control credit availability by using a flow control update message of the EGIO protocol;   Completer: A logical device addressed by a request;   Completer ID: A combination of one or more of a completer&#39;s bus identifier (e.g., number), device identifier, and a function identifier which uniquely identifies the completer of the request;   Completion: A packet used to terminate, or to partially terminate a sequence is referred to as a completion. According to one example implementation, a completion corresponds to a preceding request, and in some cases includes data;   Configuration space: One of the four address spaces within the EGIO architecture. Packets with a configuration space address are used to configure a device;   Component: A physical device (i.e., within a single package);   Data Link Layer: The intermediate layer of the EGIO architecture that lies between the transaction layer (above) and the physical layer (below);   DLLP: Data link layer packet is a packet generated in the data link layer to support link management functions;   Downstream: refers to either the relative position of an element, or the flow of information away from the host bridge;   End-point: an EGIO device with a type 00 h configuration space header;   Flow Control: A method for communicating receive buffer information from a receiver to a transmitter to prevent receive buffer overflow and to allow transmitter compliance with ordering rules;   Flow Control Packet (FCP): A transaction layer packet (TLP) used to send flow control information from the transaction layering one component to a transaction layer in another component;   Function: One independent section of a multi-function device identified in configuration space by a unique function identifier (e.g., a function number);   Hierarchy: Defines the I/O interconnect topology implemented in the EGIO architecture. A hierarchy is characterized by a single host bridge corresponding to the link closest to the enumerating device (e.g., the host CPU);   Hierarchy domain: An EGIO hierarchy is segmented into multiple fragments by a host bridge that source more than one EGIO interface, wherein such fragments are referred to as a hierarchy domain;   Host Bridge: Connects a host CPU complex to one or more EGIO links;   IO Space: One of the four address spaces of the EGIO architecture;   Lane: A set of differential signal pairs of the physical link, one pair for transmission and one pair for reception. A by-N interface is comprised of N lanes;   Link: A dual-simplex communication path between two components; the collection of two ports (one transmit and one receive) and their interconnecting lane(s);   Logical Bus: The logical connection among a collection of devices that have the same bus number in configuration space;   Logical Device: An element of an EGIO architecture that responds to a unique device identifier in configuration space;   Memory Space: One of the four address spaces of the EGIO architecture;   Message: A packet with a message space type;   Message Space: One of the four address spaces of the EGIO architecture. Special cycles as defined in PCI are included-as a subset of Message Space and, accordingly, provides an interface with legacy device(s);   Legacy Software Model(s): The software model(s) necessary to initialize, discover, configure and use a legacy device (e.g., inclusion of the PCI software model in, for example, an EGIO-to-Legacy Bridge facilitates interaction with legacy devices);   Physical Layer: The layer of the EGIO architecture that directly interfaces with the communication medium between the two components;   Port: An interface associated with a component, between that component and a EGIO link;   Receiver: The component receiving packet information across a link is the receiver (sometimes referred to as a target);   Request: A packet used to initiate a sequence is referred to as a request. A request includes some operation code and, in some cases, includes address and length, data or other information;   Requester: A logical device that first introduces a sequence into the EGIO domain;   Requester ID: A combination of one or more of a requester&#39;s bus identifier (e.g., bus number), device identifier and a function identifier that uniquely identifies the requester. In most cases, an EGIO bridge or switch forwards requests from one interface to another without modifying the requester ID. A bridge from a bus other than an EGIO bus should typically store the requester ID for use when creating a completion for that request;   Sequence: A single request and zero or more completions associated with carrying out a single logical transfer by a requester;   Sequence ID: A combination of one or more of a requester ID and a Tag, wherein the combination uniquely identifies requests and completions that are part of a common sequence;   Split transaction: A single logical transfer containing an initial transaction (the split request) that the target (the completer, or bridge) terminates with a split response, followed by one or more transactions (the split completions) initiated by the completer (or bridge) to send the read data (if a read) or a completion message back to the requester;   Symbol: A 10 bit quantity produced as the result of 8 b/10 b encoding;   Symbol Time: The period of time required to place a symbol on a lane;   Tag: A number assigned to a given sequence by the requester to distinguish it from other sequences—part of the sequence ID;   Transaction Layer Packet: TLP is a packet generated within the transaction layer to convey a request or completion;   Transaction Layer: The outermost (uppermost) layer of the EGIO architecture that operates at the level of transactions (e.g., read, write, etc.);   Transaction Descriptor: An element of a packet header that, in addition to address, length and type describes the properties of a transaction; and
 
Example Electronic Appliance
       

     FIG. 1  is a block diagram of a simplified electronic appliance  100  incorporating an enhanced general input/output (EGIO) bus architecture, protocol and related methods, in accordance with the teachings of the present invention. In accordance with the illustrated example of  FIG. 1 , electronic appliance  100  is depicted comprising one or more of processor(s)  102 , a host bridge  104 , switches  108  and end-points  110 , each coupled as shown. In accordance with the teachings of the present invention, at least host bridge  104 , switch(es)  108 , and end-points  110  are endowed with one or more instances of an EGIO communication interface  106  to facilitate one or more aspects of the present invention. 
   As shown, each of the elements  102 ,  104 ,  108  and  110  are communicatively coupled to at least one other element through a communication link  112  supporting one or more EGIO communication channel(s) via the EGIO interface  106 . As introduced above, electronic appliance  100  is intended to represent one or more of any of a wide variety of traditional and non-traditional computing systems, servers, network switches, network routers, wireless communication subscriber units, wireless communication telephony infrastructure elements, personal digital assistants, set-top boxes, or any electric appliance that would benefit from the communication resources introduced through integration of at least a subset of the EGIO interconnection architecture, communications protocol or related methods described herein. 
   In accordance with the illustrated example implementation of  FIG. 1 , electronic appliance  100  is endowed with one or more processor(s)  102 . As used herein, processor(s)  102  control one or more aspects of the functional capability of the electronic appliance  100 . In this regard, processor(s)  102  are representative of any of a wide variety of control logic including, but not limited to one or more of a microprocessor, a programmable logic device (PLD), programmable logic array (PLA), application specific integrated circuit (ASIC), a microcontroller, and the like. 
   Host bridge  104  provides a communication interface between processor  102  and/or a processor/memory complex and one or more other elements  108 ,  110  of the electronic appliance EGIO architecture and is, in this regard, the root of the EGIO architecture hierarchy. As used herein, a host bridge  104  refers to a logical entity of an EGIO hierarchy that is closest to a host controller, a memory controller hub, an IO controller hub, or any combination of the above, or some combination of chipset/CPU elements (i.e., in a computing system environment). In this regard, although depicted in  FIG. 1  as a single unit, host bridge  104  may well be thought of as a single logical entity that may well have multiple physical components. According to the illustrated example implementation of  FIG. 1 , host bridge  104  is populated with one or more EGIO interface(s)  106  to facilitate communication with other peripheral devices, e.g., switch(es)  108 , end-point(s)  110  and, although not particularly depicted, legacy bridge(s)  114 , or  116 . According to one implementation, each EGIO interface  106  represents a different EGIO hierarchy domain. In this regard, the illustrated implementation of  FIG. 1  denotes a host bridge  104  with three (3) hierarchy domains It should be noted that although depicted as comprising multiple separate EGIO interfaces  106 , alternate implementations are anticipated wherein a single interface  106  is endowed with multiple ports to accommodate communication with multiple devices. 
   In accordance with the teachings of the present invention, switches  108  have at least one upstream port (i.e., directed towards the host bridge  104 ), and at least one downstream port. According to one implementation, a switch  108  distinguishes one port (i.e., a port of an interface or the interface  106  itself) which is closest to the host bridge as the upstream port, while all other port(s) are downstream ports. According to one implementation, switches  108  appear to configuration software (e.g., legacy configuration software) as a PCI-to-PCI bridge, and use PCI bridge mechanisms for routing transactions. 
   In the context of switches  108 , peer-to-peer transactions are defined as transactions for which the receive port and the transmitting port are both downstream ports. According to one implementation, switches  108  support routing of all types of transaction layer packets (TLP) except those associated with a locked transaction sequence from any port to any other port. In this regard, all broadcast messages should typically be routed from the receiving port to all other ports on the switch  108 . A transaction layer packet which cannot be routed to a port should typically be terminated as an unsupported TLP by the switch  108 . Switches  108  typically do not modify transaction layer packet(s) (TLP) when transferring them from the receiving port to the transmitting port unless modification is required to conform to a different protocol requirement for the transmitting port (e.g., transmitting port coupled to a legacy bridge  114 ,  116 ). 
   It is to be appreciated that switches  108  act on behalf of other devices and, in this regard, do not have advance knowledge of traffic types and patterns. According to one implementation to be discussed more fully below, the flow control and data integrity aspects of the present invention are implemented on a per-link basis, and not on an end-to-end basis. Thus, in accordance with such an implementation, switches  108  participate in protocols used for flow control and data integrity. To participate in flow control, switch  108  maintains a separate flow control for each of the ports to improve performance characteristics of the switch  108 . Similarly, switch  108  supports data integrity processes on a per-link basis by checking each TLP entering the switch using the TLP error detection mechanisms, described more fully below. According to one implementation, downstream ports of a switch  108  are permitted to form new EGIO hierarchy domains. 
   With continued reference to  FIG. 1 , an end-point  110  is defined as any device with a Type 00hex (00h) configuration space header. End-point devices  110  can be either a requester or a completer of an EGIO semantic transaction, either on its own behalf or on behalf of a distinct non-EGIO device. Examples of such end-points  110  include, but are not limited to, EGIO compliant graphics device(s), EGIO-compliant memory controller, and/or devices that implement a connection between EGIO and some other interface such as a universal serial bus (USB), Ethernet, and the like. Unlike a legacy bridge  114 ,  116  discussed more fully below, an end-point  110  acting as an interface for non-EGIO compliant devices may well not provide full software support for such non-EGIO compliant devices. While devices that connect a host processor complex  102  to an EGIO architecture are considered a host bridge  104 , it may well be the same device type as other end-points  110  located within the EGIO architecture distinguished only by its location relative to the processor complex  102 . 
   In accordance with the teachings of the present invention, end-points  110  may be lumped into one or more of three categories, (1) legacy and EGIO compliant end-points, (2) legacy end-points, and (3) EGIO compliant end-points, each having different rules of operation within the EGIO architecture. 
   As introduced above, EGIO compliant end-points  110  are distinguished from legacy end-points (e.g.,  118 ,  120 ) in that an EGIO end-point  110  will have a type 00h configuration space header. Either of such end-points ( 110 ,  118  and  120 ) support configuration requests as a completer. Such end-points are permitted to generate configuration requests, and may be classified as either a legacy end-point or as an EGIO compliant end-point, but such classification may well require adherence to the following additional rules. 
   Legacy end-points (e.g.,  118 ,  120 ) are permitted to support IO requests as a completer and are permitted to generate IO requests. Legacy end-points ( 118 ,  120 ) are permitted to generate lock semantics as completers if that is required by their legacy software support requirements. Legacy end-points typically do not issue a locked request. 
   EGIO compliant end-points  110  typically do not support IO requests as a completer and do not generate IO requests. EGIO end-points  110  do not support locked requests as a completer, and do not generate locked requests as a requester. 
   EGIO to Legacy bridges  114 ,  116  are specialized end-points  110  that include substantial software support, e.g., full software support, for the legacy devices ( 118 ,  120 ) they interface to the EGIO architecture. In this regard, a legacy bridge  114 ,  116  typically has one upstream port (but may have more), with multiple downstream ports (but may just have one). Locked requests are supported in accordance with the legacy software model. An upstream port of a legacy bridge  114 ,  116  should support flow control on a per-link basis and adhere to the flow control and data integrity rules of the EGIO architecture, developed more fully below. 
   As used herein, link  112  is intended to represent any of a wide variety of communication media including, but not limited to, copper lines, optical lines, wireless communication channel(s), an infrared communication link, and the like. According to one example implementation, an EGIO link  112  is a differential pair of serial lines, one pair each to support transmit and receive communications, thereby providing support for full-duplex communication capability. According to one implementation, the link provides a scalable serial clocking frequency with an initial (base) operating frequency of 2.5 GHz. The interface width, per direction, is scalable from ×1, ×2, ×4, ×8, ×12, ×16, ×32 physical lanes. As introduced above and will be described more fully below, EGIO link  112  may well support multiple virtual channels between devices thereby providing support for uninterrupted communication of isochronous traffic between such devices using one or more virtual channels, e.g., one channel for audio and one channel for video. 
   Example EGIO Interface Architecture 
     FIG. 2  is a graphical illustration of an example EGIO interface  106  architecture employed by one or more elements of the electronic appliance to facilitate communication between such elements, according to one example embodiment of the present invention. In accordance with the illustrated example implementation of  FIG. 2 , the EGIO interface  106  may well be represented as a communication protocol stack comprising a transaction layer  202 , a data link layer  204  and a physical layer  208 . As shown, the physical link layer interface is depicted comprising a logical sub-block  210 , and a physical sub-block, as shown, each of which will be developed more fully below. 
   Transaction Layer 
   In accordance with the teachings of the present invention, the transaction layer  202  provides an interface between the EGIO architecture and a device core. In this regard, a primary responsibility of the transaction layer  202  is the assembly and disassembly of packets (i.e., transaction layer packets, or TLPs) for one or more logical devices within a host device (or, agent). 
   Address Spaces, Transaction Types and Usage 
   Transactions form the basis for information transfer between an initiator agent and a target agent. According to one example embodiment, four address spaces are defined within the innovative EGIO architecture including, for example, a configuration address space, a memory address space, an input/output address space, and a message address space, each with its own unique intended usage (see, e.g.,  FIG. 7 , developed more fully below). 
   Memory space ( 706 ) transactions include one or more of read requests and write requests to transfer data to/from a memory-mapped location. Memory space transactions may use two different address formats, e.g., a short address format (e.g., 32-bit address) or a long address format (e.g., 64-bits long). According to one example embodiment, the EGIO architecture provides for conventional read, modify, and write sequences using lock protocol semantics (i.e., where an agent may well lock access to modified memory space). More particularly, support for downstream locks are permitted, in accordance with particular device rules (bridge, switch, end-point, legacy bridge). As introduced above, such lock semantics are supported in the support of legacy devices. 
   IO space ( 704 ) transactions are used to access input/output mapped memory registers within a IO address space (e.g., an 16-bit IO address space). Certain processors  102  such as Intel Architecture processors, and others, include n IO space definition through the processor&#39;s instructions set. Accordingly, IO space transactions include read requests and write requests to transfer data from/to an IO mapped location. 
   Configuration space ( 702 ) transactions are used to access configuration space of the EGIO devices. Transactions to the configuration space include read requests and write requests. In as much as conventional processors do not typically include a native configuration space, this space is mapped through a mechanism that is software compatible with convention PCI configuration space access mechanisms (e.g., using CFC/CFC8-based PCI configuration mechanism #1). Alternatively, a memory alias mechanism may well be used to access configuration space. 
   Message space ( 708 ) transactions (or, simply messages) are defined to support in-band communication between EGIO agents through interface(s)  106 . Conventional processors do not include support for native message space, so this is enabled through EGIO agents within the EGIO interface  106 . According to one example implementation, traditional “side-band” signals such as interrupts and power management requests are implemented as messages to reduce the pin count required to support such legacy signals. Some processors, and the PCI bus, include the concept of“special cycles,” which are also mapped into messages within the EGIO interface  106 . According to one embodiment, messages are generally divided into two categories: standard messages and vendor-defined messages. 
   In accordance with the illustrated example embodiment, standard messages include a general-purpose message group and a system management message group. General-purpose messages may be a single destination message or a broadcast/multicast message. The system management message group may well consist of one or more of interrupt control messages, power management messages, ordering control primitives, and error signaling, examples of which are introduced below. 
   According to one example implementation, the general purpose messages include messages for support of locked transaction. In accordance with this example implementation, an UNLOCK message is introduced, wherein switches (e.g.,  108 ) should typically forward the UNLOCK message through any port which may be taking part in a locked transaction. End-point devices (e.g.,  110 ,  118 ,  120 ) which receive an UNLOCK message when they are not locked will ignore the message. Otherwise, locked devices will unlock upon receipt of an UNLOCK message. 
   According to one example implementation, the system management message group includes special messages for ordering and synchronization messages. One such message is a FENCE message, to impose strict ordering rules on transactions generated by receiving elements of the EGIO architecture. According to one implementation, such FENCE messages are only reacted to by a select subset of network elements, e.g., end-points. In addition to the foregoing, messages denoting a correctable error, uncorrectable error, and fatal errors are anticipated herein, e.g., through the use of tailer error forwarding. 
   According to one aspect of the present invention, introduced above, the system management message group provides for signaling of interrupts using in-band messages. According to one implementation, the ASSERT — INTx/DEASSERT — INTx message pair is introduced wherein issuing of the assert interrupt message is sent to the processor complex through host bridge  104 . In accordance with the illustrated example implementation, usage rules for the ASSERT — INTx/DEASSERT — INTx message pair mirrors that of the PCI INTx# signals found in the PCI specification, introduced above. From any one device, for every transmission of Assert — INTx, there should typically be a corresponding transmission of Deassert — INTx. For a particular ‘x’ (A, B, C or D), there should typically be only one transmission of Assert — INTx preceeding a transmission of Deassert — INTx. Switches should typically route Assert — INTx/Deassert — INTx messages to the Host Bridge  104 , wherein the Host Bridge should typically track Assert — INTx/Deassert — INTx messages to generate virtual interrupt signals and map these signals to system interrupt resources. 
   In addition to the general purpose and system management message groups, the EGIO architecture establishes a standard framework within which core-logic (e.g., chipset) vendors can define their own vendor-defined messages tailored to fit the specific operating requirements of their platforms. This framework is established through a common message header format where encodings for vendor-defined messages are defined as “reserved”. 
   Transaction Descriptor 
   A transaction descriptor is a mechanism for carrying transaction information from the origination point, to the point of service, and back. It provides an extensible means for providing a generic interconnection solution that can support new types of emerging applications. In this regard, the transaction descriptor supports identification of transactions in the system, modifications of default transaction ordering, and association of transaction with virtual channels using the virtual channel ID mechanism. A graphical illustration of a transaction descriptor is presented with reference to  FIG. 3 . 
   Turning to  FIG. 3 , a graphical illustration of a datagram comprising an example transaction descriptor is presented, in accordance with the teachings of the present invention. In accordance with the teachings of the present invention, the transaction descriptor  300  is presented comprising a global identifier field  302 , an attributes field  306  and a virtual channel identifier field  308 . In the illustrated example implementation, the global identifier field  302  is depicted comprising a local transaction identifier field  308  and a source identifier field  310 . 
   Global Transaction Identifier  302   
   As used herein, the global transaction identifier is unique for all outstanding requests. In accordance with the illustrated example implementation of  FIG. 3 , the global transaction identifier  302  consists of two sub-fields: the local transaction identifier field  308  and a source identifier field  310 . According to one implementation, the local transaction identifier field  308  is an eight-bit field generated by each requestor, and it is unique for all outstanding requests that require a completion for that requester. The source identifier uniquely identifies the EGIO agent within the EGIO hierarchy. Accordingly, together with source ID the local transaction identifier field provides global identification of a transaction within a hierarchy domain. 
   According to one implementation, the local transaction identifier  308  allows requests/completions from a single source of requests to be handled out of order (subject to the ordering rules developed more fully below). For example, a source of read requests can generate reads A 1  and A 2 . The destination agent that services these read requests may return a completion for request A 2  transaction ID first, and then a completion for A 1  second. Within the completion packet header, local transaction ID information will identify which transaction is being completed. Such a mechanism is particularly important to appliances that employ distributed memory systems since it allows for handling of read requests in a more efficient manner. Note that support for such out-of-order read completions assumes that devices that issue read requests will ensure pre-allocation of buffer space for the completion. As introduced above, insofar as EGIO switches  108  are not end-points (i.e., merely passing completion requests to appropriate end-points) they need not reserve buffer space. 
   A single read request can result in multiple completions. Completions belonging to single read request can be returned out-of-order with respect to each other. This is supported by providing the address offset of the original request that corresponds to partial completion within a header of a completion packet (i.e., completion header). 
   According to one example implementation, the source identifier field  310  contains a 16-bit value that is unique for every logical EGIO device. Note that a single EGIO device may well include multiple logical devices. The source ID value is assigned during system configuration in a manner transparent to the standard PCI bus enumeration mechanism. EGIO devices internally and autonomously establish a source ID value using, for example, bus number information available during initial configuration accesses to those devices, along with internally available information that indicates, for example, a device number and a stream number. According to one implementation, such bus number information is generated during EGIO configuration cycles using a mechanism similar to that used for PCI configuration. According to one implementation, the bus number is assigned by a PCI initialization mechanism and captured by each device. In the case of Hot Plug and Hot Swap devices, such devices will need to re-capture this bus number information on every configuration cycle access to enable transparency to SHPC software stacks. 
   In accordance with one implementation of the EGIO architecture, a physical component may well contain one or more logical devices (or, agents). Each logical device is designed to respond to configuration cycles targeted at its particular device number, i.e., the notion of device number is embedded within the logical device. According to one implementation, up to sixteen logical devices are allowed in a single physical component. Each of such logical devices may well contain one or more streaming engines, e.g., up to a maximum of sixteen. Accordingly, a single physical component may well comprise up to 256 streaming engines. 
   Transactions tagged by different source identifiers belong to different logical EGIO input/output (IO) sources and can, therefore, be handled completely independently from each other from an ordering point of view. In the case of a three-party, peer-to-peer transactions, a fence ordering control primitive can be used to force ordering if necessary. 
   As used herein, the global transaction identifier field  302  of the transaction descriptor  300  adheres to at least a subset of the following rules:
         (a) each Completion Required Request is tagged with a global transaction ID (GTID);   (b) all outstanding Completion Required Requests initiated by an agent should typically be assigned a unique GTID;   (c) non-Completion Required Requests do not use the local transaction ID field  308  of the GTID, and the local transaction ID field is treated as Reserved;   (d) the target does not modify the requests GTID in any way, but simply echoes it in the header of a completion packet for all completions associate with the request, where the initiator used the GTID to match the completion(s) to the original request.       

   Attributes Field  304   
   As used herein, the attributes field  304  specifies characteristics and relationships of the transaction. In this regard, the attributes field  304  is used to provide additional information that allows modification of the default handling of transactions. These modifications may apply to different aspects of handling of the transactions within the system such as, for example, ordering, hardware coherency management. (e.g., snoop attributes) and priority. An example format for the attributes field  304  is presented with sub-fields  312 – 318 . 
   As shown, the attribute field  304  includes a priority sub-field  312 . The priority sub-field may be modified by an initiator to assign a priority to the transaction. In one example implementation, for example, class or quality of service characteristics of a transaction or an agent may be embodied in the priority sub-field  312 , thereby affecting processing by other system elements. 
   The reserved attribute field  314  is left reserved for future, or vendor-defined usage. Possible usage models using priority or security attributes may be implemented using the reserved attribute field. 
   The ordering attribute field  316  is used to supply optional information conveying the type of ordering that may modify default ordering rules within the same ordering plane (where the ordering plane encompasses the traffic initiated by the host processor ( 102 ) and the IO device with its corresponding source ID). According to one example implementation, an ordering attribute of “0” denotes default ordering rules are to apply, wherein an ordering attribute of “1” denotes relaxed ordering, wherein writes can pass writes in the same direction, and read completions can pass writes in the same direction. Devices that use relaxed ordering semantics primarily for moving the data and transactions with default ordering for reading/writing status information. 
   The snoop attribute field  318  is used to supply optional information conveying the type of cache coherency management that may modify default cache coherency management rules within the same ordering plane, wherein an ordering plane encompasses traffic initiated by a host processor  102  and the IO device with its corresponding source ID). In accordance with one example implementation, a snoop attribute field  318  value of “0” corresponds to a default cache coherency management scheme wherein transactions are snooped to enforce hardware level cache coherency. A value of “1” in the snoop attribute field  318 , on the other hand, suspends the default cache coherency management schemes and transactions are not snooped. Rather, the data being accessed is either non-cacheable or its coherency is being managed by software. 
   Virtual Channel ID Field  306   
   As used herein, the virtual channel ID field  306  identifies an independent virtual channel to which the transaction is associated. According to one embodiment, the virtual channel identifier (VCID) is a four-bit field that allows identification of up to sixteen virtual channels (VCs) on a per-transaction basis. An example of VC ID definitions are provided in table 1, below: 
                   TABLE I                  Virtual Channel ID Encoding                         VCID   VC Name   Usage Model               0000   Default Channel   General Purpose Traffic       0001   Isochronous Channel   This channel is used to carry               IO traffic that has the               following requirements: (a) IO               traffic is not snooped to allow               for deterministic service               timing; and (b) quality of               service is controlled using an               X/T contract (where               X = amount of data and               T = time)       0010–1111   Reserved   Future Use                    
Virtual Channels
 
   In accordance with one aspect of the present invention, the transaction layer  202  of the EGIO interface  106  can establish one or more virtual channels within the bandwidth of the communication link  112 . The virtual channel (VC) aspect of the present invention, introduced above, is used to define separate, logical communication interfaces within a single physical EGIO link  112 . In this regard, separate VCs are used to map traffic that would benefit from different handling policies and servicing priorities. For example, traffic that requires deterministic quality of service, in terms of guaranteeing X amount of data transferred within T period of time, can be mapped to an isochronous (time dependent) virtual channel. Transactions mapped to different virtual channels may not have any ordering requirements with respect to each other. That is, virtual channels operate as separate logical interfaces, having different flow control rules and attributes. 
   With respect to traffic initiated by host processor  102 , virtual channels may require ordering control based on default order mechanism rules or the traffic may be handled completely out of order. According to one example implementation, VCs comprehend the following two types of traffic: general purpose IO traffic, and Isochronous traffic. That is, in accordance with this example implementation, two types of virtual channels are described: (1) general purpose IO virtual channels, and (2) isochronous virtual channels. 
   As used herein, transaction layer  202  maintains independent flow control for each of the one or more virtual channel(s) actively supported by the component. As used herein, all EGIO compliant components should typically support the general IO type virtual channel, e.g., virtual channel  0 , where there are no ordering relationships required between disparate virtual channels of this type. By default, VC  0  is used for general purpose IO traffic, while VC  1  is assigned to handle Isochronous traffic. In alternate implementations, any virtual channel may be assigned to handle any traffic type. A conceptual illustration of an EGIO link comprising multiple, independently managed virtual channels is presented with reference to  FIG. 4 . 
   Turning to  FIG. 4 , a graphical illustration of an example EGIO link  112  is presented comprising multiple virtual channels (VC), according to one aspect of the present invention. In accordance with the illustrated example implementation of  FIG. 4 , EGIO link  112  is presented comprising multiple virtual channels  402 ,  404  created between EGIO interface(s)  106 . According to one example implementation, with respect to virtual channel  402 , traffic from multiple sources  406 A . . . N are illustrated, differentiated by at least their source ID. As shown, virtual channel  402  was established with no ordering requirements between transactions from different sources (e.g., agents, interfaces, etc.). 
   Similarly, virtual channel  404  is presented comprising traffic from multiple sources multiple transactions  408 A . . . N wherein each of the transactions are denoted by at least a source ID. In accordance with the illustrated example, transactions from source ID  0   406 A are strongly ordered unless modified by the attributes field  304  of the transaction header, while the transactions from source  408 N depict no such ordering rules. An example method of establishing and managing virtual channel(s) is presented with reference to  FIG. 10 , below. 
   Transaction Ordering 
   Although it is simpler to force all responses to be processed in-order, transaction layer  202  attempts to improve performance by permitting transaction re-ordering. To facilitate such re-ordering, transaction layer  202  “tags” transactions. That is, according to one embodiment, transaction layer  202  adds a transaction descriptor to each packet such that its transmit time may be optimized (e.g., through re-ordering) by elements in the EGIO architecture, without losing track of the relative order in which the packet was originally processed. Such transaction descriptors are used to facilitate routing of request and completion packets through the EGIO interface hierarchy. 
   Thus, one of the innovative aspects of the EGIO interconnection architecture and communication protocol is that it provides for out of order communication, thereby improving data throughput through reduction of idle or wait states. In this regard, the transaction layer  202  employs a set of rules to define the ordering requirements for EGIO transactions. Transaction ordering requirements are defined to ensure correct operation with software designed to support the producer-consumer ordering model while, at the same time, allowing improved transaction handling flexibility for application based on different ordering models (e.g., relaxed ordering for graphics attach applications). Ordering requirements for two different types of models are presented below, a single ordering plane model and a multiple ordering plane model. 
   Basic Transaction Ordering—Single “Ordering Plane” Model 
   Assume that two components are connected via an EGIO architecture similar to that of  FIG. 1 : a memory control hub that provides an interface to a host processor and a memory subsystem, and an IO control hub that provides interface to an IO subsystem. Both hubs contain internal queues that handle inbound and outbound traffic and in this simple model all IO traffic is mapped to a single “ordering plane”. (Note that Transaction Descriptor Source ID information provides a unique identification for each Agent within an EGIO Hierarchy. Note also that IO traffic mapped to the Source ID can carry different Transaction ordering attributes). Ordering rules for this system configuration are defined between IO initiated traffic and host-initiated traffic. From that perspective IO traffic mapped to a Source ID together with host processor initiated traffic represent traffic that is conducted within a single “ordering plane”. 
   An example of such transaction ordering rules are provided below with reference to Table II. The rules defined in this table apply uniformly to all types of Transactions in the EGIO system including Memory, IO, Configuration and Messages. In Table II, below, the columns represent the first of two Transactions, and the rows represent the second. The table entry indicates the ordering relationship between the two Transactions. The table entries are defined as follows: 
   
     
       
         
             
           
             
               TABLE II 
             
           
          
             
                 
             
             
               Transaction Ordering and Deadlock Avoidance for Single Ordering Plane 
             
          
         
         
             
             
             
             
             
             
          
             
                 
               WR — Req 
                 
               WR — Req 
                 
                 
             
             
               Row pass 
               (No compl. Req) 
               RD — Req 
               (compl. Req) 
               RD — Comp. 
               WR — Comp 
             
             
               Column? 
               (col. 2) 
               (col. 3) 
               (col. 4) 
               (col. 5) 
               (col. 6) 
             
             
                 
             
             
               WR — Req 
               NO 
               YES 
               a. NO 
               Y/N 
               Y/N 
             
             
               No comp Req 
                 
                 
               b. YES 
             
             
               (Row A) 
             
             
               RD — Req 
               NO 
               a. NO 
               Y/N 
               Y/N 
               Y/N 
             
             
               (Row B) 
                 
               b. Y/N 
             
             
               WR — Req 
               NO 
               Y/N 
               a. NO 
               Y/N 
               Y/N 
             
             
               (comp. Req) 
                 
                 
               b. Y/N 
             
             
               (Row C) 
             
             
               RD — Comp. 
               NO 
               YES 
               YES 
               a. NO 
               Y/N 
             
             
               (Row D) 
                 
                 
                 
               b. Y/N 
             
             
               WR — Comp. 
               Y/N 
               YES 
               YES 
               Y/N 
               Y/N 
             
             
               (Row E) 
             
             
                 
             
             
               Yes—the second Transaction should typically be allowed to pass the first to avoid deadlock. (When blocking occurs, the second Transaction is required to pass the first Transaction. Fairness should typically be comprehended to prevent starvation). 
             
             
               Y/N—there are no requirements. The first Transaction may optionally pass the second Transaction or be blocked by it. 
             
             
               No—the second Transaction should typically not be allowed to pass the first Transaction. This is required to preserve strong ordering. 
             
          
         
       
     
   
   
     
       
         
             
           
             
               TABLE III 
             
           
          
             
                 
             
             
               Transaction Ordering Explanations 
             
          
         
         
             
             
          
             
               Row:Column ID 
               Explanation of Table II Entry 
             
             
                 
             
             
               A2 
               A posted memory write request (WR — REQ) should typically not pass any 
             
             
                 
               other posted memory write request 
             
             
               A3 
               A posted memory write request should typically be allowed to pass read 
             
             
                 
               requests to avoid deadlocks 
             
             
               A4 
               a. A posted memory WR — REQ should typically not be allowed to pass a 
             
             
                 
               memory WR — REQ with a completion required attribute. 
             
             
                 
               b. A posted memory WR — REQ should typically be allowed to pass IO and 
             
             
                 
               Configuration Requests to avoid deadlocks 
             
             
               A5, A6 
               A posted memory WR — REQ is not required to pass completions. To allow 
             
             
                 
               this implementation flexibility while still guaranteeing deadlock free 
             
             
                 
               operation, the EGIO communication protocol provides that agents guarantee 
             
             
                 
               acceptance of completions 
             
             
               B2, C2 
               These requests cannot pass a posted memory WR — REQ, thereby preserving 
             
             
                 
               strong write ordering required to support producer/consumer usage model. 
             
             
               B3 
               a. In a base implementation (i.e., no out of order processing) read requests are 
             
             
                 
               not permitted to pass each other. 
             
             
                 
               b. In alternate implementations, read request permitted to pass each other. 
             
             
                 
               Transaction identification is essential for providing such functionality. 
             
             
               B4, C3 
               Requests of different types are permitted to be blocked by or to be passed by 
             
             
                 
               each other. 
             
             
               B5, B6, C5, C6 
               These requests are permitted to be block by or to pass completions. 
             
             
               D2 
               Read completions cannot pass a posted memory WR — Req (to preserve strong 
             
             
                 
               write ordering). 
             
             
               D3, D4, E3, E4 
               Completions should typically be allowed to pass non-posted requests to avoid 
             
             
                 
               deadlocks 
             
             
               D5 
               a. In a base implementation, read completions are not permitted to pass each 
             
             
                 
               other; 
             
             
                 
               b. In alternate implementations, read completions are permitted to pass each 
             
             
                 
               other. Again, the need for strong transaction identification may well be 
             
             
                 
               required. 
             
             
               E6 
               These completions are permitted to pass each other. Important to maintain 
             
             
                 
               track of transactions using, e.g., transaction ID mechanism 
             
             
               D6, E5 
               Completions of different types can pass each other. 
             
             
               E2 
               Write completions are permitted to e blocked by or to pass posted memory 
             
             
                 
               WR — REQ. Such write transactions are actually moving in the opposite 
             
             
                 
               direction and, therefore, have no ordering relationship 
             
             
                 
             
          
         
       
     
   
   Advanced Transaction Ordering—“Multi-Plane” Transaction Ordering Model 
   The previous section defined ordering rules within a single “ordering plane”. As introduced above, the EGIO interconnection architecture and communication protocol employs a unique Transaction Descriptor mechanism to associate additional information with a Transaction to support more sophisticated ordering relationships. Fields in the Transaction Descriptor allow the creation of multiple “ordering planes” that are independent of each other from an IO traffic ordering point of view. Each “ordering plane” consists of queuing/buffering logic that corresponds to a particular IO device (designated by a unique Source ID) and of queuing/buffering logic that carries host processor initiated traffic. The ordering within the “plane” is typically defined only between these two. The rules defined in the previous Section to support the Producer/Consumer usage model and to prevent deadlocks are enforced for each “ordering plane” independent of other “ordering planes”. For example, read Completions for Requests initiated by “plane” N can go around Read Completions for Requests initiated by “plane” M. However, neither Read Completions for plane N nor the ones for plane M can go around Posted Memory Writes initiated from the host. 
   Although use of the plane mapping mechanism permits the existence of multiple ordering planes, some or all of the ordering planes can be “collapsed” together to simplify the implementation (i.e. combining multiple separately controlled buffers/FIFOs into a single one). When all planes are collapsed together, the Transaction Descriptor Source ID mechanism is used only to facilitate routing of Transactions and it is not used to relax ordering between independent streams of IO traffic. 
   In addition to the foregoing, the transaction descriptor mechanism provides for modifying default ordering within a single ordering plane using an ordering attribute. Modifications of ordering can, therefore, be controlled on per-transaction basis. 
   Transaction Layer Protocol Packet Format 
   As introduced above, the innovative EGIO architecture uses a packet based protocol to exchange information between transaction layers of two devices that communicate with one another. The EGIO architecture generally supports the Memory, IO, Configuration and Messages transaction types. Such transactions are typically carried using request or completion packets, wherein completion packets are only used when required, i.e., to return data or to acknowledge receipt of a transaction. 
   With reference to  FIG. 6  a graphical illustration of an example transaction layer protocol is presented, in accordance with the teachings of the present invention. In accordance with the illustrated example implementation of  FIG. 6 , TLP header  600  is presented comprising a format field, a type field, an extended type/extended length (ET/EL) field, and a length field. Note that some TLPs include data following the header as determined by the format field specified in the header. No TLP should include more data than the limit set by MAX — PAYLOAD — SIZE. In accordance with one example implementation, TLP data is four-byte naturally aligned and in increments of a four-byte double word (DW). 
   As used herein, the format (FMT) field specifies the format of the TLP, in accordance with the following definitions:
         000-2DW Header, No Data   001-3DW Header, No Data   010-4DW Header, No Data   101-3DW Header, With Data   110-4DW Header, With Data   All Other Encodings are Reserved       

   The TYPE field is used to denote the type encodings used in the TLP. According to one implementation, both Fmt[2:0] and Type[3:0] should typically be decoded to determine the TLP format. According to one implementation, the value in the type[3:0] field is used to determine whether the extended type/extended length field is used to extend the Type field or the Length field. The ET/EL field is typically only used to extend the length field with memory-type read requests. 
   The length field provides an indication of the length of the payload, again in DW increments of:
         0000 0000=1DW   0000 0001=2DW    . . .   1111 1111=256DW       

   A summary of at least a subset of example TLP transaction types, their corresponding header formats, and a description is provided below, in table IV: 
   
     
       
         
             
             
             
             
             
           
             
                 
             
             
                 
               FMT 
               Type 
               Et 
                 
             
             
               TLP Type 
               [2:0] 
               [3:0] 
               [1:0] 
               Description 
             
             
                 
             
           
          
             
               Initial FCP 
               000 
               0000 
               00 
               Initial flow control information 
             
             
               Update FCP 
               000 
               0001 
               00 
               Update flow control information 
             
             
               MRd 
               001 
               1001 
               E19 E18 
               Memory read request 
             
             
                 
               010 
                 
                 
               Et/El field used for length [9:8] 
             
             
               MRdLK 
               001 
               1011 
               00 
               Memory read request—locked 
             
             
                 
               010 
                 
             
             
               MWR 
               101 
               0001 
               00 
               Memory Write request—posted 
             
             
                 
               110 
                 
             
             
               IORd 
               001 
               1010 
               00 
               IO Read request 
             
             
               IOWr 
               101 
               1010 
               00 
               IO Write request 
             
             
               CfgRd0 
               001 
               1010 
               01 
               Configuration read type 0 
             
             
               CfgWr0 
               101 
               1010 
               01 
               Configuration write type 0 
             
             
               CfgRd1 
               001 
               1010 
               11 
               Configuration read type 1 
             
             
               CfgWr1 
               101 
               1010 
               11 
               Configuration write type 1 
             
             
               Msg 
               010 
               011s2 
               s1s0 
               Message request—the sub-field s[2:0] specify a 
             
             
                 
                 
                 
                 
               group of messages. According to one 
             
             
                 
                 
                 
                 
               implementation, the message field is decoded to 
             
             
                 
                 
                 
                 
               determine specific cycle including if a 
             
             
                 
                 
                 
                 
               completion is required 
             
             
               MsgD 
               110 
               001s2 
               s1s0 
               Message request with data—the sub-field s[2:0] 
             
             
                 
                 
                 
                 
               specify a group of messages. According to one 
             
             
                 
                 
                 
                 
               implementation, the message field is decoded to 
             
             
                 
                 
                 
                 
               determine specific cycle including if a 
             
             
                 
                 
                 
                 
               completion is required 
             
             
               MsgCR 
               010 
               111s2 
               s1s0 
               Message request completion required—The sub- 
             
             
                 
                 
                 
                 
               fields s[2:0] specify a group of messages. 
             
             
                 
                 
                 
                 
               According to one implementation, the message 
             
             
                 
                 
                 
                 
               field is decoded to determine specific cycle 
             
             
               MsgDCR 
               110 
               111s2 
               s1s0 
               Message request with data completion required— 
             
             
                 
                 
                 
                 
               The sub-fields s[2:0] specify a group of 
             
             
                 
                 
                 
                 
               messages. According to one implementation, the 
             
             
                 
                 
                 
                 
               Special Cycle field is decided to determine 
             
             
                 
                 
                 
                 
               specific cycle. 
             
             
               CPL 
               001 
               0100 
               00 
               Completion without data—used for IO and 
             
             
                 
                 
                 
                 
               configuration write completions, some message 
             
             
                 
                 
                 
                 
               completions, and memory read completions with 
             
             
                 
                 
                 
                 
               completion status other than successful 
             
             
                 
                 
                 
                 
               completion. 
             
             
               CplD 
               101 
               0100 
               00 
               Completion with data—used for memory, IO, 
             
             
                 
                 
                 
                 
               and configration read completions, and some 
             
             
                 
                 
                 
                 
               message completions. 
             
             
               CplDLk 
               101 
                001 
               01 
               Completion for locked memory read—otherwise 
             
             
                 
                 
                 
                 
               like CplD 
             
             
                 
             
          
         
       
     
   
   Additional detail regarding requests and completions is provided in Appendix A, the specification of which is hereby expressly incorporated herein by reference. 
   Flow Control 
   One of the limitations commonly associated with conventional flow control schemes is that they are reactive to problems that may occur, rather than proactively reducing the opportunity for such problems to occur in the first place. In the conventional PCI system, for example, a transmitter will send information to a receiver until it receives a message to halt/suspend transmission until further notice. Such requests may subsequently be followed by requests for retransmission of packets starting at a given point in the transmission. Those skilled in the art will appreciate that this reactive approach results in wasted cycles and can, in this regard, be inefficient. 
   To address this limitation, the transaction layer  202  of the EGIO interface  106  includes a flow control mechanism that proactively reduces the opportunity for overflow conditions to arise, while also providing for adherence to ordering rules on a per-link basis of the virtual channel established between the initiator and the completer(s). In accordance with one aspect of the present invention, the concept of a flow control “credit” is introduced, wherein a receiver shares information about (a) the size of the buffer (in credits), and (b) the currently available buffer space with a transmitter for each of the virtual channel(s) established between the transmitter and the receiver (i.e., on a per-virtual channel basis). This enables the transaction layer  202  of the transmitter to maintain an estimate of the available buffer space (e.g., a count of available credits) allocated to transmission through an identified virtual channel, and proactively throttle its transmission through any of the virtual channels if it determines that transmission would cause an overflow condition in the receive buffer. 
   In accordance with one aspect of the present invention, the transaction layer  202  introduces flow control to prevent overflow of receiver buffers and to enable compliance with the ordering rules, introduced above. In accordance with one implementation, the flow control mechanism of the transaction layer  202  is used by a requester to track the queue/buffer space available in an agent across the EGIO link  112 . As used herein, flow control does not imply that a request has reached its ultimate completer. 
   In accordance with the teachings of the present invention, flow control is orthogonal to the data integrity mechanisms used to implement reliable information exchange between a transmitter and a receiver. That is, flow control can treat the flow of transaction layer packet (TLP) information from transmitter to receiver as perfect, since the data integrity mechanisms ensure that corrupted and lost TLPs are corrected through retransmission. As used herein, the flow control comprehends the virtual channels of the EGIO link  112 . In this regard, each virtual channel supported by a receiver will be reflected in the flow control credits (FCC) advertised by the receiver. 
   In accordance with the teachings of the present invention, flow control is performed by the transaction layer  202  in cooperation with the data link layer  204 . For ease of illustration in describing the flow control mechanism, the following types of packet information is distinguished:
         (a) Posted Request Headers (PRH)   (b) Posted Request Data (PRD)   (c) Non-Posted Request Headers (NPRH)   (d) Non-Posted Request Data (NPRD)   (e) Read, Write and Message Completion Headers (CPLH —     (f) Read and Message Completion Data (CPLD)       

   As introduced above, the unit of measure in the EGIO implementation of proactive flow control is a flow control credit (FCC). In accordance with but one implementation, a flow control credit is 16 bytes for data. For headers, the unit of flow control credit is one header. As introduced above, each virtual channel has independent flow control. For each virtual channel, separate indicators of credits are maintained and tracked for each of the foregoing types of packet information ((a)–(f), as denoted above). In accordance with the illustrated example implementation, transmission of packets consume flow control credits in accordance with the following:
         Memory/IO/Configuration Read Request: 1 NPRH unit   Memory Write Request: 1PRH+nPRD units (where n is associated with the size of the data payload, e.g., the length of the data divided by the flow control unit size (e.g., 16 Bytes)   IO/Configuration Write Request: 1NPRH+1NPRD   Message Requests: Depending on the message at least 1PRH and/or 1NPRH unit(s)   Completions with Data: 1CPLH+nCPLD units (where n is related to size of data divided by the flow control data unit size, e.g., 16 Bytes)   Completions without Data: 1CPLH       

   For each type of information tracked, there are three conceptual registers, each eight bits wide to monitor the credits consumed (in transmitter), a credit limit (in transmitter) and a credits allocated (in the receiver). The credits consumed register includes a count of the total number of flow control units modula  256  consumed since initialization. Upon initialization, the credits consumed register is set to all zeros (0) and incremented as the transaction layer commits to sending information to the data link layer. The size of the increment is associated with the number of credits consumed by the information committed to be sent. According to one implementation, when the maximum count (e.g., all 1&#39;s) is reached or exceeded, the counter rolls over to zero. According to one implementation, unsigned 8 bit module arithmetic is used to maintain the counter. 
   The credit limit register contains the limit for the maximum number of flow control units which may be consumed. Upon interface initialization, the register is set to all zeros, and is set to the value indicated in an flow control update message (introduced above) upon message receipt. 
   The credits allocated register maintains a count of the total number of credits granted to the transmitter since initialization. The count is initially set according to the buffer size and allocation policies of the receiver. This value may well be included in flow control update messages. The value is incremented as the receiver transaction layer removes processed information from its receive buffer. The size of the increment is associated with the size of the space made available. According to one embodiment, receivers should typically initially set the credits allocated to values equal to or greater than the following values:
         PRH: 1 flow control unit (FCU);   PRD: FCU equal to the largest possible setting of the maximum payload size of the device;   NPRH: 1 FCU   NPRD: FCU equal to the largest possible setting of the maximum payload size of the device;   Switch devices—CPLH: 1FCU;   Switch devices—CPLD: FCU equal to the largest possible setting of the maximum payload size of the device, or the largest read request the device will ever generate, whichever is smaller;   Root &amp; End-point Devices—CPLH or CPLD: 255 FCUs (all 1&#39;s), a value considered to be infinite by the transmitter, which will therefore never throttle.
 
In accordance with this implementation, a receiver will typically not set credits allocated register values to greater than 127FCUs for any message type.
       

   In accordance with an alternate implementation, rather than maintaining the credits allocated register using the counter method, above, a transmitter can dynamically calculate the credits allocated in accordance with the following equation:
 
 C   —   A =(Credit unit number of the most recently received transmission)+(receive buffer space available)
 
   As introduced above, a transmitter implement the conceptual registers (credit consumed, credit limit) for each of the virtual channels which the transmitter will utilize. Similarly, receivers implement the conceptual registers (credits allocated) for each of the virtual channels supported by the receiver. To proactively inhibit the transmission of information if to do so would cause receive buffer overflow, a transmitter is permitted to transmit a type of information if the credits consumed count plus the number of credit units associate with the data to be transmit is less than or equal to the credit limit value. When a transmitter receives flow control information for completions (CPLs) indicating non-infinite credits (i.e., &lt;255 FCUs), the transmitter will throttle completions according to the credit available. When accounting for credit use and return, information from different transactions is not mixed within a credit. Similarly, when accounting for credit use and return, header and data information from one transaction is never mixed within one credit. Thus, when some packet is blocked from transmission by a lack of flow control credit(s), transmitters will follow the ordering rules (above) when determining what types of packets should be permitted to bypass the “stalled” packet. The return of flow control credits for a transaction is not interpreted to mean that the transaction has completed or achieved system visibility. Message signaled interrupts (MSI) using a memory write request semantic are treated like any other memory write. If a subsequent FC Update Message (from the receiver) indicates a lower credit — limit value than was initially indicated, the transmitter should respect the new lower limit and may well provide a messaging error. 
   In accordance with the flow control mechanism described herein, if a receiver receives more information than it has allocated credits for (exceeding the credits allocated) the receiver will indicate a receiver overflow error to the offending transmitter, and initiate a data link level retry request for the packet causing the overflow. 
   Flow Control Packets (FCPs) 
   According to one implementation, the flow control information necessary to maintain the registers, above, is communicated between devices using flow control packets (FCPs). According to one embodiment, flow control packets are comprised of two-DW Header format and convey information for a specific Virtual Channel about the status of the six Credit registers maintained by the Flow Control logic of the Receive Transaction Layer for each VC. In accordance with the teachings of the present invention there are two types of FCPs: Initial FCP and Update FCP, as illustrated in  FIG. 6 . 
   As introduced above, an initial FCP  602  is issued upon initialization of the Transaction Layer. Following initialization of the Transaction Layer, Update FCPs  604  are used to update information in the registers. Receipt of an Initial FCP during normal operation causes a reset of the local flow control mechanism and the transmission of an Initial FCP. The content of an Initial FCP includes at least a subset of the advertised credits for each of the PRH, PRD, NPRH, NPRD, CPH, CPD, and Channel ID (e.g., the Virtual channel associated to which FC information applies). The format of an Update FCP is similar to that of the Initial FCP. Note that although the FC Header does not include the Length field common other transaction layer packet header format, the size of the Packet is unambiguous because there is no additional DW data associated with this Packet. 
   Error Forwarding 
   Unlike conventional error forwarding mechanisms, the EGIO architecture relies on tailer information, appended to datagram(s) identified as defective for any of a number of reasons, as discussed below. According to one example implementation, the transaction layer  202  employs any of a number of well-known error detection techniques such as, for example, cyclical redundancy check (CRC) error control and the like. 
   According to one implementation, to facilitate error forwarding features, the EGIO architecture uses a “tailer”, which is appended to TLPs carrying known bad data. Examples of cases in which tailer Error Forwarding might be used include:
         Example #1: A read from main memory encounters uncorrectable ECC error   Example #2: Parity error on a PCI write to main memory   Example #3: Data integrity error on an internal data buffer or cache.       

   According to one example implementation, error forwarding is only used for read completion data, or the write data. That is, error forwarding is not typically employed for cases when the error occurs in the administrative overhead associated with the datagram, e.g., an error in the header (e.g., request phase, address/command, etc.). As used herein, requests/completions with header errors cannot be forwarded in general since a true destination cannot be positively identified and, therefore, such error forwarding may well cause a direct or side effects such as, fore example data corruption, system failures, etc. According to one embodiment, error forwarding is used for propagation of error through the system, system diagnostics. Error forwarding does not utilize data link layer retry and, thus TLPs ending with the tailer will be retried only if there are transmission errors on the EGIO link  112  as determined by the TLP error detection mechanisms (e.g., cyclical redundancy check (CRC), etc.). Thus, the tailer may ultimately cause the originator of the request to re-issue it (at the transaction layer of above) or to take some other action. 
   As used herein, all EGIO receivers (e.g., located within the EGIO interface  106 ) are able to process TLPs ending with a tailer. Support for adding a tailer in a transmitter is optional (and therefore compatible with legacy devices). Switches  108  route a tailer along with the rest of a TLP. Host Bridges  104  with peer routing support will typically route a tailer along with the rest of a TLP, but are not required to do so. Error Forwarding typically applies to the data within a Write Request (Posted or Non-Posted) or a Read Completion. TLPs which are known to the transmitter to include bad data should end with the tailer. 
   According to one example implementation, a tailer consists of two DW, wherein bytes [7:5] are all zeroes (e.g., 000), and bits [4:1] are all ones (e.g., 1111), while all other bits are reserved. An EGIO receiver will consider all the data within a TLP ending with the tailer corrupt. 
   If applying error forwarding, the receiver will cause all data from the indicated TLP to be tagged as bad (“poisoned”). Within the transaction layer, a parser will typically parse to the end of the entire TLP and check immediately the following data to understand if the data completed or not. 
   Data Link Layer  204   
   As introduced above, the data link layer  204  of  FIG. 2  acts as an intermediate stage between the Transaction Layer  202  and the Physical Layer  206 . The primary responsibility of the data link layer  204  is providing a reliable mechanism for exchanging Transaction Layer Packets (TLPs) between two components over an EGIO Link  112 . The transmission side of the Data Link Layer  204  accepts TLPs assembled by the Transaction Layer  202 , applies a Packet Sequence Identifier (e.g., an identification number), calculates and applies an error detection code (e.g., CRC code), and submits the modified TLPs to the Physical Layer  206  for transmission across a select one or more of the virtual channels established within the bandwidth of the EGIO Link  112 . 
   The receiving Data Link Layer  204  is responsible for checking the integrity of received TLPs (e.g., using CRC mechanisms, etc.) and for submitting those TLPs for which the integrity check was positive to the Transaction Layer  204  for disassembly before forwarding to the device core. 
   Services provided by the Data Link Layer  204  generally include data exchange, error detection and retry, initialization and power management services, and data link layer inter-communication services. Each of the services offered under each of the foregoing categories are enumerated below. 
   Data Exchange Services
         Accept TLPs for transmission from the Transmit Transaction Layer   Accept TLPs received over the Link from the Physical Layer and convey them to the Receive Transaction Layer       

   Error Detection &amp; Retry
         TLP Sequence Number and CRC generation   Transmitted TLP storage for Data Link Layer Retry   Data integrity checking   Acknowledgement and Retry DLLPs   Error indications for error reporting and logging mechanisms   Link Ack Timeout timer       

   Initialization and Power Management Services
         Track Link state and convey active/reset/disconnected state to Transaction Layer       

   Data Link Layer inter-communication Services
         Used for Link Management functions including error detection and retry   Transferred between Data Link Layers of the two directly connected components   Not exposed to the Transaction Layers       

   As used within the EGIO interface  106 , the Data Link Layer  204  appears as an information conduit with varying latency to the Transaction Layer  202 . All information fed into the Transmit Data Link Layer will appear at the output of the Receive Data Link Layer at a later time. The latency will depend on a number of factors, including pipeline latencies, width and operational frequency of the Link  112 , transmission of communication signals across the medium, and delays caused by Data Link Layer Retry. Because of these delays, the Transmit Data Link Layer can apply backpressure to the Transmit Transaction Layer  202 , and the Receive Data Link Layer communicates the presence or absence of valid information to the Receive Transaction Layer  202 . 
   According to one implementation, the data link layer  204  tracks the state of the EGIO link  112 . In this regard, the DLL  204  communicates Link status with the Transaction  202  and Physical Layers  206 , and performs Link Management through the Physical Layer  206 . According to one implementation, the Data Link Layer contains a Link Control and Management State Machine to perform such management tasks. The states for this machine are described below: 
   Example DLL Link States:
         LinkDown (LD)—Physical Layer reporting Link is non-operational or Port is not connected   LinkInit (LI)—Physical Layer reporting Link is operational and is being initialized   LinkActive (LA)—Normal operation mode   LinkActDefer (LAD)—Normal operation disrupted, Physical Layer attempting to resume       

   Corresponding Management Rules per State (see, e.g.,  FIG. 8 ):
         LinkDown (LD)
           Initial state following Component reset   Upon entry to LD:
               Reset all Data Link Layer state information to default values   
               While in LD:
               Do not exchange TLP information with the Transaction or Physical Layers   Do not exchange DLLP information with the Physical Layer   Do not generate or accept DLLPs   
               Exit to LI if:
               Indication from the Transaction Layer that the Link is not disabled by SW   
               
           LinkInit (LI)
           While in LI:
               Do not exchange TLP information with the Transaction or Physical Layers   Do not exchange DLLP information with the Physical Layer   Do not generate or accept DLLPs   
               Exit to LA if:
               Indication from the Physical Layer that the Link training succeeded   
               Exit to LD if:
               Indication from the Physical Layer that the Link training failed   
               
           LinkActive (LA)
           While in LinkActive:
               Exchange TLP information with the Transaction and Physical Layers   Exchange DLLP information with the Physical Layer   Generate and accept DLLPs.   
               Exit to LinkActDefer if:
               Indication from the Data Link Layer Retry management mechanism that Link retraining is required, OR if Physical Layer reports that a retrain is in progress.   
               
           LinkActDefer (LAD)
           While in LinkActDefer:
               Do not exchange TLP information with the Transaction or Physical Layers   Do not exchange DLLP information with the Physical Layer   Do not generate or accept DLLPs   
               Exit to LinkActive if:
               Indication from the Physical Layer that the retraining was successful   
               Exit to LinkDown if:
               Indication from the Physical Layer that the retraining failed
 
Data Integrity Management
   
               
               

   As used herein, data link layer packets (DLLPs) are used to support the EGIO link data integrity mechanisms. In this regard, according to one implementation, the EGIO architecture provides for the following DLLPs to support link data integrity management:
         Ack DLLP: TLP Sequence number acknowledgement—used to indicate successful receipt of some number of TLPs   Nak DLLP: TLP Sequence number negative acknowledgement—used to indicate a Data Link Layer Retry   Ack Timeout DLLP: Indicates recently transmitted Sequence Number—used to detect some forms of TLP loss       

   As introduced above, the transaction layer  202  provides TLP boundary information to Data Link Layer  204 , enabling the DLL  204  to apply a Sequence Number and cyclical redundancy check (CRC) error detection to the TLP. According to one example implementation, the Receive Data Link Layer validates received TLPs by checking the Sequence Number, CRC code and any error indications from the Receive Physical Layer. In case of error in a TLP, Data Link Layer Retry is used for recovery. 
   CRC, Sequence Number, and Retry Management (Transmitter) 
   The mechanisms used to determine the TLP CRC and the Sequence Number and to support Data Link Layer Retry are described in terms of conceptual “counters” and “flags”, as follows: 
   CRC and Sequence Number Rules (Transmitter)
         The following 8 bit counters are used:
           TRANS — SEQ—Stores the sequence number applied to TLPs being prepared for transmission
               Set to all ‘0’s in LinkDown state   Incremented by 1 after each TLP transmitted   When at all ‘1’s the increment causes a roll-over to all ‘0’s   Receipt of a Nak DLLP causes the value to be set back to the sequence number indicated in the Nak DLLP   
               ACKD — SEQ—Stores the sequence number acknowledged in the most recently received Link to Link Acknowledgement DLLP.
               Set to all ‘1’s in LinkDown state   
               
           Each TLP is assigned an 8bit sequence number
           The counter TRANS — SEQ stores this number   If TRANS — SEQ equals (ACKD — SEQ−1) modulo  256 , the Transmitter should typically   not transmit another TLP until an Ack DLLP updates ACKD — SEQ such that the condition (TRANS — SEQ=ACKD — SEQ−1) modulo  256  is no longer true.   
           TRANS — SEQ is applied to the TLP by:
           prepending the single Byte value to the TLP   prepending a single Reserved Byte to the TLP   
           A 32b CRC is calculated for the TLP using the following algorithm and appended to the end of the TLP
           The polynomial used is 0×04C11DB7
               the same CRC-32 used by Ethernet   
               The procedure for the calculation is:   1) The initial value of the CRC-32 calculation is the DW formed by prepending 24 ‘0’s to the Sequence Number   2) The CRC calculation is continued using each DW of the TLP from the Transaction Layer in order from the DW including Byte  0  of the Header to the last DW of the TLP   3) The bit sequence from the calculation is complemented and the result is the TLP CRC   4) The CRC DW is appended to the end of the TLP   
           Copies of Transmitted TLPs should typically be stored in the Data Link Layer Retry Buffer   When an Ack DLLP is received from the other Device:
           ACKD — SEQ is loaded with the value specified in the DLLP   The Retry Buffer is purged of TLPs with Sequence Numbers in the range:
               From the previous value of ACKD — SEQ+1   To the new value of ACKD — SEQ   
               
           When a Nak DLLP is received from the other Component on the Link:
           If a TLP is currently being transferred to the Physical Layer, the transfer continues until the transfer of this TLP is complete   Additional TLPs are not taken from the Transaction Layer until the following steps are complete   The Retry Buffer is purged of TLPs with Sequence Numbers in the range:
               The previous value of ACKD — SEQ+1   The value specified in the Nak Sequence Number field of the Nak DLLP   
               All remaining TLPs in the Retry Buffer are re-presented to the Physical Layer for re-transmission in the original order
               Note: This will include all TLPs with Sequence Numbers in the range:   
               The value specified in the Nak Sequence Number field of the Nak DLLP+1   The value of TRANS — SEQ−1
               If there are no remaining TLPs in the Retry Buffer, the Nak DLLP was in error   
               The erroneous Nak DLLP should typically be reported according to the Error Tracking and   Logging Section   No further action is required by the Transmitter   
               

   CRC and Sequence Number (Receiver) 
   Similarly, the mechanisms used to check the TLP CRC and the Sequence Number and to support Data Link Layer Retry are described in terms of conceptual “counters” and “flags” as follows:
         The following 8 bit counter is used:
           NEXT — RCV — SEQ—Stores the expected Sequence Number for the next TLP
               Set to all ‘0’s in LinkDown state   Incremented by 1 for each TLP accepted, or when the DLLR — IN — PROGRESS flag (described below) is cleared by accepting a TLP   Loaded with the value (Trans. Seq. Num+1) each time a Link Layer DLLP is received and the DLLR — IN — PROGRESS flag is clear.   
               A loss of Sequence Number synchronization between Transmitter and Receiver is indicated if the value of NEXT — RCV — SEQ differs from the value specified by a received TLP or an Ack Timeout DLLP; in this case:
               If the DLLR — IN — PROGRESS flag is set,
                   Reset DLLR — IN — PROGRESS flag   Signal a “Sent Bad DLLR DLLP” error to Error Logging/Tracking   Note: This indicates that a DLLR DLLP (Nak) was sent in error   
                   If the DLLR — IN — PROGRESS flag is not set,
                   Set DLLR — IN — PROGRESS flag and initiate Nak DLLP   Note: This indicates that a TLP was lost   
                   
               
           The following 3 bit counter is used:
           DLLRR — COUNT—Counts number of times DLLR DLLP issued in a specified time period
               Set to b&#39;000 in LinkDown state   Incremented by 1 for each Nak DLLP issued   When the count reaches b&#39;100:
                   The Link Control State Machine moves from LinkActive to LinkActDefer   DLLRR — COUNT is then reset to b&#39;000   
                   If DLLRR — COUNT not equal to b&#39;000, decrements by 1 every 256 Symbol Times
                   i.e.: Saturates at b&#39;000   
                   
               
           The following flag is used:
           DLLR — IN — PROGRESS
               Set/Clear conditions are described below   When DLLR — IN — PROGRESS is set, all received TLPs are rejected (until the TLP indicated by the DLLR DLLP is received)   When DLLR — IN — PROGRESS is clear, Received TLPs are checked as described below   
               
           For a TLP to be accepted, the following conditions should typically be true:
           The Received TLP Sequence Number is equal to NEXT — RCV — SEQ   The Physical Layer has not indicated any errors in Receipt of the TLP   The TLP CRC check does not indicate an error   
           When a TLP is accepted:
           The Transaction Layer part of the TLP is forwarded to the Receive Transaction Layer   If set, the DLLR — IN — PROGRESS flag is cleared   NEXT — RCV SEQ is incremented   
           When a TLP is not accepted.
           The DLLR — IN — PROGRESS flag is set   A Nak DLLP is sent
               The Ack/Nak Sequence Number field should typically contain the value (NEXT — RCV — SEQ−1)   The Nak Type (NT) field should typically indicate the cause of the Nak:
                   b&#39;00—Receive Error identified by Physical Layer   b&#39;01—TLP CRC check failed   b&#39;10—Sequence Number incorrect   b&#39;11—Framing Error identified by the Physical Layer   
                   
               
           The Receiver should typically not allow the time from the receipt of the CRC for a TLP to Transmission of Nak to exceed 1023 Symbol Times, as measured from the Port of the Component
           Note: NEXT — RCV — SEQ is not incremented   
           If the Receive Data Link Layer fails to receive the expected TLP following a Nak DLLP within 512 Symbol Times, the Nak DLLP is repeated.
           If after four attempts the expected TLP has still not been received, the receiver will:
               Enter the LinkActDefer state and initiate Link retraining by the Physical Layer   Indicate the occurrence of a major error to Error Tracking and Logging   
               
           Data Link Layer Acknowledgement DLLPs should typically be Transmitted when the following conditions are true:
           The Data Link Control and Management State Machine is in the LinkActive state   TLPs have been accepted, but not yet acknowledged by sending an Acknowledgement DLLP   More than 512 Symbol Times have passed since the last Acknowledgement DLLP   
           Data Link Layer Acknowledgement DLLPs may be Transmitted more frequently than required   Data Link Layer Acknowledgement DLLPs specify the value (NEXT — RCV — SEQ−1) in the Ack Sequence Num field       

   Ack Timeout Mechanism 
   Consider the case where a TLP is corrupted on the Link  112  such that the Receiver does not detect the existence of the TLP. The lost TLP will be detected when a following TLP is sent because the TLP Sequence Number will not match the expected Sequence Number at the Receiver. However, the Transmit Data Link Layer  204  cannot in general bound the time for the next TLP to be presented to it from the Transmit Transport Layer. The Ack Timeout mechanism allows the Transmitter to bound the time required for the Receiver to detect the lost TLP. 
   Ack Timeout Mechanism Rules 
   If the Transmit Retry Buffer contains TLPs for which no Ack DLLP have been received, and if no TLPs or Link DLLPs have been transmitted for a period exceeding 1024 Symbol Times, an Ack Timeout DLLP should typically be transmitted. 
   Following the Transmission of an Ack Timeout DLLP, the Data Link Layer should typically not pass any TLPs to the Physical Layer for Transmission until an Acknowledgement DLLP has been received from the Component on the other side of the Link.
         If no Acknowledgement DLLP is received for a period exceeding 1023 Symbol Times, the Ack Timeout DLLP is Transmitted again
           1024 Symbol Times after the fourth successive transmission of an Ack Timeout DLLP without receipt of an Acknowledgement DLLP.
               Enter the LinkActDefer state and initiate Link retraining by the Physical Layer   
               
               

   Indicate the occurrence of a major error to Error Tracking and Logging. 
   Physical Layer  206   
   With continued reference to  FIG. 2 , the physical layer  206  is presented. As used herein, the physical layer  206  isolates the transaction  202  and data link  204  layers from the signaling technology used for link data interchange. In accordance with the illustrated example implementation of  FIG. 2 , the Physical Layer is divided into the logical  208  and physical  210  functional sub-blocks. 
   As used herein, the logical sub-block  208  is responsible for the “digital” functions of the Physical Layer  206 . In this regard, the logical sub-block  204  has two main divisions: a Transmit section that prepares outgoing information for transmission by the physical sub-block  210 , and a Receiver section that identifies and prepares received information before passing it to the Link Layer  204 . The logical sub-block  208  and physical sub-block  210  coordinate the Port state through a status and control register interface. Control and management functions of the Physical Layer  206  are directed by the logical sub-block  208 . 
   According to one example implementation, the EGIO architecture employs an 8b/10b transmission code. Using this scheme, eight-bit characters are treated as three-bits and five-bits mapped onto a four-bit code group and a six-bit code group, respectivley. These code groups are concatenated to form a ten-bit Symbol. The 8b/10b encoding scheme used by EGIO architecture provides Special Symbols which are distinct from the Data Symbols used to represent Characters. These Special Symbols are used for various Link Management mechanisms below. Special Symbols are also used to frame DLLPs and TLPs, using distinct Special Symbols to allow these two types of Packets to be quickly and easily distinguished. 
   The physical sub-block  210  contains a Transmitter and a Receiver. The Transmitter is supplied by the Logical sub-block  208  with Symbols which it serializes and transmits onto the Link  112 . The Receiver is supplied with serialized Symbols from the Link  112 . It transforms the received signals into a bit-stream which is de-serialized and supplied to the Logical sub-block  208  along with a Symbol clock recovered from the incoming serial stream. It will be appreciated that, as used herein, the EGIO link  112  may well represent any of a wide variety of communication media including an electrical communication link, an optical communication link, an RF communication link, an infrared communication link, a wireless communication link, and the like. In this respect, each of the transmitter(s) and/or receiver(s) comprising the physical sub-block  210  of the physical layer  206  is appropriate for one or more of the foregoing communication links. 
   Example Communication Agent 
     FIG. 5  illustrates a block diagram of an example communication agent incorporating at least a subset of the features associated with the present invention, in accordance with one example implementation of the present invention. In accordance with the illustrated example implementation of  FIG. 5 , communications agent  500  is depicted comprising control logic  502 , an EGIO communication engine  504 , memory space for data structures  506  and, optionally one or more applications  508 . As used herein, control logic  502  provides processing resources to each of the one or more elements of EGIO communication engine  504  to selectively implement one or more aspects of the present invention. In this regard, control logic  502  is intended to represent one or more of a microprocessor, a microcontroller, a finite state machine, a programmable logic device, a field programmable gate array, or content which, when executed, implements control logic to function as one of the above. 
   EGIO communication engine  504  is depicted comprising one or more of a transaction layer interface  202 , a data link layer interface  204  and a physical layer interface  206  comprising a logical sub-block  208  and a physical sub-block  210  to interface the communication agent  500  with an EGIO link  112 . As used herein, the elements of EGIO communication engine  504  perform function similar, if not equivalent to, those described above. 
   In accordance with the illustrated example implementation of  FIG. 5 , communications agent  500  is depicted comprising data structures  506 . As will be developed more fully below with reference to  FIG. 7 , data structures  506  may well include memory space, IO space, configuration space and message space utilized by communication engine  504  to facilitate communication between electronic appliance devices. 
   As used herein, applications  508  are intended to represent any of a wide variety of applications selectively invoked by communication engine  500  to implement the EGIO communication protocol and associated management functions. 
   Example Data Structure(s) 
   Turning to  FIG. 7  a graphical illustration of one or more data structure(s) employed by EGIO interface(s)  106  are depicted, in accordance with one implementation of the present invention. More particularly, with reference to the illustrated example implementation of  FIG. 7 , four (4) address spaces are defined for use within the EGIO architecture: the configuration space  710 , the IO space  720 , the memory space  730  and the message space  740 . As shown, configuration space  710  includes a header field  712 , which defines the EGIO category to which a host device belongs (e.g., end-point, etc.). Each of such address spaces perform their respective functions as detailed above. 
   Having introduced the architectural and protocol elements associated with the present invention above, with reference to  FIGS. 1-8 , attention is now directed to  FIG. 10 , where a flow chart of an example method of managing the physical communication resources of the enhanced general input/output architecture is presented. 
   Turning to  FIG. 10 , a flow chart of an example method of establishing an managing one or more virtual channel(s) within the physical resources of the enhanced general input/output link is presented, in accordance with one example embodiment of the present invention. In accordance with the illustrated example implementation of  FIG. 10 , the method begins with block  1002  wherein an EGIO interface  106  receives information for transmission to another component. In accordance with one example implementation, the transaction layer  202  of an EGIO interface  106  receives the information from a processing agent within a host component. 
   In block  1004 , the EGIO interface  106  determines whether the received information is associated with an established virtual channel, or whether a new virtual channel is required. According to one implementation, transaction layer  202  makes such a determination by identifying the source and destination of the information. If, in block  1004  transaction layer  202  identifies the information as associated with an existing virtual channel, transaction layer  202  generates transaction layer packets (TLP) associated with the appropriate virtual channel to communicate the received information through the physical link layer  206  to the appropriate virtual channel for transmission over the physical general input/output resources, block  1006 . 
   If, in block  1 . 004  the information requires creation of a new virtual channel, transaction layer  202  makes a further determination as to the type of virtual channel required, block  1008 . According to one example implementation, transaction layer  202  makes this determination based, at least in part, on the content of the received information. According to one example implementation, introduced above, the EGIO architecture provides support for multiple types of virtual channels selected based on the quality-of-service requirements associated with the information to be communicated. In this regard, transaction layer  202  determines whether the received information is time-dependent (isochronous) and, if so, establishes one or more isochronous virtual channels to support transmission of such information. According to one embodiment, the type of content is determined through analysis of the content itself, or inferred from the type of agent delivering the content to the transaction layer (e.g., the type of application). 
   In block  1010 , EGIO interface  106  establishes a virtual channel with separate flow control and ordering rules with which to transmit information across the physical resources of the EGIO link  112  to another component. More particularly, as introduced above, transaction layer  202  generates transaction layer packet(s) denoting the virtual channel type for delivery through the data link layer  204  to the physical layer  206  for routing onto the physical medium of the EGIO link  112 . In accordance with the teachings of the present invention, introduced above, transaction layer  202  maintains separate flow control and ordering rules for each of the virtual channels established by the transaction layer  202 . In this regard, an architecture, protocol and related methods for establishing and managing multiple virtual channels within the physical resources of an EGIO link  112  have been described. 
   Alternate Embodiments 
     FIG. 9  is a block diagram of a storage medium having stored thereon a plurality of instructions including instructions to implement one or more aspects of the EGIO interconnection architecture and communication protocol, according to yet another embodiment of the present invention. In general,  FIG. 9  illustrates a machine accessible medium/device  900  having content stored thereon(in) including at least a subset of which that, when executed by an accessing machine, implement the innovative EGIO interface  106  of the present invention. 
   As used herein, machine accessible medium  900  is intended to represent any of a number of such media known to those skilled in the art such as, for example, volatile memory devices, non-volatile memory devices, magnetic storage media, optical storage media, propagated signals and the like. Similarly, the executable instructions are intended to reflect any of a number of software languages known in the art such as, for example, C++, Visual Basic, Hypertext Markup Language (HTML), Java, eXtensible Markup Language (XML), and the like. Moreover, it is to be appreciated that the medium  900  need not be co-located with any host system. That is, medium  900  may well reside within a remote server communicatively coupled to and accessible by an executing system. Accordingly, the software implementation of  FIG. 9  is to be regarded as illustrative, as alternate storage media and software embodiments are anticipated within the spirit and scope of the present invention. 
   Although the invention has been described in the detailed description as well as in the Abstract in language specific to structural features and/or methodological steps, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or steps described. Rather, the specific features and steps are merely disclosed as exemplary forms of implementing the claimed invention. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the present invention. The present specification and figures are accordingly to be regarded as illustrative rather than restrictive. The description and abstract are not intended to be exhaustive or to limit the present invention to the precise forms disclosed. 
   The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with the established doctrines of claim interpretation.