阅读说明：本技术 基于票证的请求流控制 (Ticket-based request flow control ) 是由 J·G·麦克唐纳 G·M·德拉帕拉 E·F·罗宾森 T·P·施派尔 K·N·马吉尔 R·G 于 2020-03-04 设计创作，主要内容包括：公开了在具有一个或多个主机和一个或多个从机的处理系统中的出票流控制机制。在一个方面中,目标从机从请求主机接收请求。如果所述目标从机不可用于服务于所述请求,则用于所述请求的票证被提供给所述请求主机。当所述目标从机中的资源变得可用时,消息针对所述请求主机被广播以更新所述票证值。当所述票证值已经被更新到最终值时,所述请求主机可以重传所述请求。(A ticket outflow control mechanism in a processing system having one or more masters and one or more slaves is disclosed. In one aspect, the target slave receives a request from a requesting master. If the target slave is not available to service the request, a ticket for the request is provided to the requesting master. When resources in the target slave become available, a message is broadcast for the requesting master to update the ticket value. When the ticket value has been updated to a final value, the requesting host may retransmit the request.)

1. A method of managing traffic in a processing system having one or more masters and one or more slaves, the method comprising:

receiving, at the target slave, a request from the requesting master;

providing, by the target slave, a ticket having a ticket value to the requesting host, the ticket value having an initial value;

broadcasting, by the target slave, one or more updates to the ticket value of the ticket to update the ticket value; and

servicing, by the target slave, a retransmission of the request from the requesting host, the retransmission of the request having a final ticket value for the ticket value of the ticket.

2. The method of claim 1, wherein the target slave provides the ticket based on the target slave being unavailable to service the request.

3. The method of claim 1, wherein the target slave provides the ticket based on the target slave being unavailable to service a new request of the same category as the request.

4. The method of claim 1, wherein the target slave broadcasts the one or more updates to the ticket value when resources in the target slave become available.

5. The method of claim 1, wherein the target slave receives the retransmission of the request when the ticket value of the ticket has been decremented to the final ticket value.

6. The method of claim 1, wherein the request includes a field indicating a ticket category of the ticket.

7. The method of claim 6, wherein the ticket value is independent of the ticket category.

8. The method of claim 1, wherein the target slave assigns the request to a high priority category based on the request having previously been ticketed.

9. The method of claim 1, wherein the request is a high priority request, and wherein the target slave maintains a separate pool of tickets for high priority requests.

10. The method of claim 1, wherein the target slave is a memory module, and wherein the requesting master is a processor.

11. The method of claim 10, wherein the memory module and the processor are components of: a cellular phone, a Personal Digital Assistant (PDA), a laptop computer, a tablet computer, a desktop computer, a server, a set-top box, a music player, a video player, an entertainment unit, a navigation device, a gaming device, or a fixed location data unit.

12. A method of managing traffic in a processing system having one or more masters and one or more slaves, the method comprising:

transmitting the request from the requesting master to the target slave;

receiving, at the request master, a ticket for the request from the target slave to indicate that the target slave is unavailable to service the request, the ticket having a ticket value;

receiving, at the requesting master, one or more broadcast messages from the target slave to indicate that the ticket value is to be updated;

updating, by the requesting host, the ticket value based on the one or more broadcast messages; and

retransmitting, by the request master, the request to the target slave when the ticket value has reached a final ticket value.

13. The method of claim 12, wherein the request master receives the ticket based on the target slave being unavailable to service a new request of the same category as the request.

14. The method of claim 12, wherein the requesting master receives the one or more broadcast messages when resources in the target slave become available.

15. The method of claim 12, wherein the requesting host retransmits the request when the ticket value of the ticket has been decremented to the final ticket value.

16. The method of claim 12, wherein the request is a high priority request, and wherein the target slave maintains a separate pool of tickets for high priority requests.

17. The method of claim 12, wherein the request includes a field indicating a ticket category of the ticket.

18. The method of claim 17, wherein the ticket value is independent of the ticket category.

19. The method of claim 12, wherein the request is placed in a high priority category based on the request having previously been ticketed.

20. The method of claim 12, wherein the target slave is a memory module, and wherein the requesting master is a processor.

21. The method of claim 20, wherein the memory module and the processor are components of: a cellular phone, a Personal Digital Assistant (PDA), a laptop computer, a tablet computer, a desktop computer, a server, a set-top box, a music player, a video player, an entertainment unit, a navigation device, a gaming device, or a fixed location data unit.

22. A target slave of a processing system having one or more masters and one or more slaves, comprising:

circuitry configured to receive a request from a requesting host;

circuitry configured to provide a ticket having a ticket value to the requesting host, the ticket value having an initial value;

circuitry configured to broadcast one or more updates to the ticket value of the ticket to update the ticket value; and

circuitry configured to service a retransmission of the request from the requesting host, the retransmission of the request having a final ticket value for the ticket value of the ticket.

23. The target slave of claim 22, wherein the target slave provides the ticket based on the target slave being unavailable to service the request.

24. The target slave of claim 22, wherein the target slave provides the ticket based on the target slave being unavailable to service a new request of the same category as the request.

25. The target slave of claim 22, wherein the target slave broadcasts the one or more updates to the ticket value when resources in the target slave become available.

26. The target slave of claim 22, wherein the target slave receives the retransmission of the request when the ticket value of the ticket has been decremented to the final ticket value.

27. The target slave of claim 22, wherein the request includes a field indicating a ticket category of the ticket.

28. A target slave according to claim 27, wherein the ticket value is independent of the ticket category.

29. The target slave of claim 22, wherein the target slave assigns the request to a high priority category based on the request having previously been billed.

30. The target slave of claim 22, wherein the request is a high priority request, and wherein the target slave maintains a separate pool of tickets for high priority requests.

31. The target slave of claim 22, wherein the target slave is a memory module, and wherein the requesting master is a processor.

32. The target slave of claim 31, wherein the memory module and the processor are components of: a cellular phone, a Personal Digital Assistant (PDA), a laptop computer, a tablet computer, a desktop computer, a server, a set-top box, a music player, a video player, an entertainment unit, a navigation device, a gaming device, or a fixed location data unit.

33. A requesting master of a processing system having one or more masters and one or more slaves, comprising:

circuitry configured to transmit a request to a target slave;

circuitry configured to receive a ticket for the request from the target slave to indicate that the target slave is unavailable to service the request, the ticket having a ticket value;

circuitry configured to receive one or more broadcast messages from the target slave indicating that the ticket value is to be updated;

circuitry configured to update the ticket value based on the one or more broadcast messages; and

circuitry configured to retransmit the request to the target slave when the ticket value has reached a final ticket value.

34. The requesting master of claim 33, wherein the requesting master receives the ticket based on the target slave not being available to service a new request of the same category as the request.

35. The requesting master of claim 33, wherein the requesting master receives the one or more broadcast messages when resources in the target slave become available.

36. The requesting host of claim 33, wherein the requesting host retransmits the request when the ticket value of the ticket has been decremented to the final ticket value.

37. The request master of claim 33, wherein the request is a high priority request, and wherein the target slave maintains a separate ticket pool for high priority requests.

38. The requesting host of claim 33, wherein the request includes a field indicating a ticket category of the ticket.

39. The requesting host of claim 38, wherein the ticket value is independent of the ticket category.

40. The requesting host of claim 33, wherein the request is placed in a high priority category based on the request having previously been ticketed.

41. The requesting master of claim 33, wherein the target slave is a memory module, and wherein the requesting master is a processor.

42. The requesting host of claim 41, wherein the memory module and the processor are components of: a cellular phone, a Personal Digital Assistant (PDA), a laptop computer, a tablet computer, a desktop computer, a server, a set-top box, a music player, a video player, an entertainment unit, a navigation device, a gaming device, or a fixed location data unit.

43. A target slave of a processing system having one or more masters and one or more slaves, comprising:

means for receiving a request from a requesting host;

means for providing a ticket having a ticket value to the requesting host, the ticket value having an initial value;

means for broadcasting one or more updates to the ticket value of the ticket to update the ticket value; and

means for servicing a retransmission of the request from the requesting host, the retransmission of the request having a final ticket value for the ticket value of the ticket.

44. A requesting master of a processing system having one or more masters and one or more slaves, comprising:

means for transmitting a request to a target slave;

means for receiving the requested ticket from the target slave to indicate that the target slave is unavailable to service the request, the ticket having a ticket value;

means for receiving one or more broadcast messages from the target slave indicating that the ticket value is to be updated;

means for updating the ticket value based on the one or more broadcast messages; and

means for retransmitting the request to the target slave when the ticket value has reached a final ticket value.

Technical Field

The disclosed aspects relate to traffic management and data flow control in a multiprocessor system.

Background

A multiprocessor system is a computer system that uses two or more Central Processing Units (CPUs) within a single computer system. These multiple CPUs communicate closely with each other, sharing computer bus(s), memory system(s), and other peripherals. Multiprocessor systems are often used when very high speeds are required to process large amounts of data.

A CPU or more generally a host of a multiprocessor system may interface with a memory system or more generally a slave using one or more memory controllers. There may be interconnection systems for traffic flow between various masters and slaves, which have serialization points, such as a common bus. A flow control method is used to attempt to allow access requests from the master to reach the target slave in an efficient and balanced manner.

Disclosure of Invention

The following presents a simplified summary in connection with one or more aspects disclosed herein. Thus, the following summary should not be considered an extensive overview relating to all contemplated aspects, nor should the following summary be considered to identify key or critical elements relating to all contemplated aspects, or to delineate the scope associated with any particular aspect. Accordingly, the sole purpose of the following summary is to present some concepts related to one or more aspects related to the mechanisms disclosed herein in a simplified form prior to the detailed description presented below.

In one aspect, a method of managing traffic in a processing system having one or more masters and one or more slaves includes: receiving, at the target slave, a request from the requesting master; providing, by the target slave, a ticket having a ticket value to the requesting host, the ticket value having an initial value; broadcasting, by the target slave, one or more updates to the ticket value of the ticket to update the ticket value; and serving, by the target slave, a retransmission of the request from the requesting master, the retransmission of the request having a final ticket value for the ticket value of the ticket.

In one aspect, a method of managing traffic in a processing system having one or more masters and one or more slaves includes: transmitting a request from the requesting master to the target slave; receiving, at the requesting master, a ticket for the request from the target slave to indicate that the target slave is unavailable for the service request, the ticket having a ticket value; receiving, at the requesting master, one or more broadcast messages from the target slaves to indicate that the ticket value is to be updated; updating the ticket value based on the one or more broadcast messages; and retransmitting the request to the target slave when the ticket value has reached the final ticket value.

In one aspect, a target slave of a processing system having one or more masters and one or more slaves includes: circuitry configured to receive a request from a requesting host; circuitry configured to provide a ticket having a ticket value to a requesting host, the ticket value having an initial value; circuitry configured to broadcast one or more updates to a ticket value of a ticket to update the ticket value; and circuitry configured to service a retransmission of a request from a requesting host, the retransmission of the request having a final ticket value of the ticket.

In one aspect, a requesting master of a processing system having one or more masters and one or more slaves includes: circuitry configured to transmit a request from a requesting master to a target slave; circuitry configured to receive a ticket for the request from the target slave to indicate that the target slave is unavailable to service the request, the ticket having a ticket value; circuitry configured to receive one or more broadcast messages from a target slave to indicate that a ticket value is to be updated; circuitry configured to update a ticket value based on one or more broadcast messages; and circuitry configured to retransmit the request to the target slave when the ticket value has reached the final ticket value.

In one aspect, a target slave of a processing system having one or more masters and one or more slaves includes: means for receiving a request from a requesting host; means for providing a ticket having a ticket value to a requesting host, the ticket value having an initial value; means for broadcasting one or more updates to a ticket value of a ticket to update the ticket value; and means for servicing a retransmission of the request from the requesting host, the retransmission of the request having a final ticket value of the ticket.

In one aspect, a requesting master of a processing system having one or more masters and one or more slaves includes: means for transmitting a request from a requesting master to a target slave; means for receiving a ticket for the request from the target slave to indicate that the target slave is unavailable for the service request, the ticket having a ticket value; means for receiving one or more broadcast messages from the target slave indicating that the ticket value is to be updated; means for updating the ticket value based on the one or more broadcast messages; and means for retransmitting the request to the target slave when the ticket value has reached the final ticket value.

Other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art based on the drawings and detailed description.

Drawings

The drawings are presented to aid in the description of examples of one or more aspects of the disclosed subject matter and are provided for illustration only and not limitation thereof.

Fig. 1 is a schematic diagram of an exemplary processing system configured in accordance with various aspects of the present disclosure.

Fig. 2A-2C illustrate example sequences of commands and results in a ticketing flow control implementation in accordance with various aspects of the present disclosure.

Fig. 3 and 4 illustrate an exemplary method of traffic management according to an exemplary aspect.

Fig. 5 illustrates a computing device that may be employed by various aspects of the present disclosure.

Detailed Description

Various aspects of the disclosure are provided in the following description and related drawings directed to specific aspects of the disclosure. Alternate aspects may be devised without departing from the scope of the disclosure. Additionally, well-known elements of the disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the disclosure.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "various aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation.

The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the various aspects of the disclosure. For example, as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises," "comprising," "includes" and/or "including," when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

Further, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device (such as a multi-processor system). It will be recognized that various actions described herein can be performed by specific circuits (e.g., Application Specific Integrated Circuits (ASICs)), by program instructions being executed by one or more processors, or by a combination of both. Additionally, these sequence of actions described herein can be considered to be embodied entirely within any form of computer readable storage medium having stored therein a corresponding set of computer instructions that upon execution would cause an associated processor to perform the functionality described herein. Thus, the various aspects of the disclosure may be embodied in a number of different forms, all of which are contemplated to be within the scope of the claimed subject matter. Additionally, for each of the various aspects described herein, the corresponding form of any such aspect may be described herein as, for example, "logic configured to" perform the described action.

As mentioned above, flow control methods are used to attempt to allow access requests from a master (e.g., processor/core) to reach a target slave (e.g., memory module) in an efficient and balanced manner. Conventional traffic flow management techniques, such as those relying on credit-based protocols, are impractical and inefficient for large systems. For example, a relatively small number of serialization points may be responsible for reserving credits to allow requests from a large number of hosts, meaning that some requests may be backed up, increasing the round-trip delay of requests to be processed, and also degrading performance or requiring increased resources and costs. This may limit the active host from using idle credits even on a lightly loaded system.

Alternative techniques may avoid flow control altogether and allow the host to initiate requests at any time. While this may be practical for a less loaded system, as traffic increases, the target slave may quickly become overloaded, causing requests to be denied service, resulting in retransmission and imbalance of traffic flows on the system. Also, a master that is forced to retransmit its request may operate blindly without knowing when its intended slave will be available to service the master's request, and thus may initiate a retransmission too early (resulting in more retransmissions) or too late (resulting in performance loss). Therefore, there is a need for an improved flow control mechanism.

In an exemplary aspect of the disclosure, a ticketing flow control mechanism is disclosed for improving traffic management, for example, in a multiprocessing environment. In an exemplary aspect, a master (e.g., processor/core) may initiate a request to access a slave (e.g., memory module) at any point in time. When a request reaches its target slave (or at some intermediate node, as will be further explained), the request is accepted for service if the target slave has availability. However, if the slave does not have the availability required to service the request, then the requesting master is provided with a retry response, called a "ticket," as a placeholder for the request. The ticket may be an individual ticket or a group ticket that groups together multiple requests from one or more hosts. The ticket may include information about when the request may be retransmitted and possibly other information identifying the target slave (or issuer of the ticket). Note that as used herein, a slave provides a "retry" response (i.e., ticket) and the master "retransmits" the request.

Fig. 1 illustrates a schematic diagram of an exemplary processing system 100. For example, processing system 100 may be any special purpose or general purpose system on a chip (SoC). As shown, processing system 100 may include one or more cores 102 a-102 n. Cores 102 a-102 n may be any agent, processor, or computing device, such as a CPU, Digital Signal Processor (DSP), General Purpose Processor (GPP), Field Programmable Gate Array (FPGA), input/output device, interface device, or the like. Some cores 102 a-102 n may have one or more caches and/or other local memory devices, representatively illustrated as caches 104 a-104 m. The cores 102 a-102 n and, where applicable, the caches 104 a-104 m may be coupled to each other and to one or more slaves, including memory 108, slaves (not shown) connected by chip-to-chip (C2C) links 110, etc., by a system bus or interconnect 106. In one aspect, processing system 100 may be implemented as a multi-socket system supporting one or more sockets for connecting one or more off-chip memories or slaves, which may be accessed through a link, such as C2C link 110. It is noted that the illustrated arrangement of components of the processing system 100 is merely exemplary, and that alternative arrangements and connections of the above-described components are within the scope of the present disclosure.

Any of the cores 102 a-102 n or caches 104 a-104 m may represent hosts that may issue requests to be serviced. For example, if one of the cores 102 a-102 n issues a request that misses in one of the caches 104 a-104 m, the request may be forwarded to be serviced from the memory 108. In some cases, misses may be retrieved from one or more off-chip memories or slaves (e.g., integrated onto a chip separate from the chip on which one or more cores 102 a-102 n are integrated), and these misses may be serviced over C2C link 110.

Interconnect 106 may use a flow control mechanism to forward requests to slaves, such as memory 108 and/or C2C link 110. Memory 108 may have one or more memory banks or other memory subsystems that may be individually targeted and operable to service requests. A memory controller (not separately shown for simplicity) may be configured to control access to memory 108, and in particular to various subsystems of memory 108. In some aspects, the memory controller may have separate queues, as is known in the art, for storing requests and data, each queue being associated with a different memory bank or other subsystem. For example, the availability of the memory 108 to service the request may be determined based on the space in the associated queue. Thus, memory 108 may represent one or more slaves that may receive requests from one or more masters (e.g., one or more cores 102 a-102 n). Also, as previously mentioned, one or more slaves may also be accessed over the C2C link 110. As described herein, one or more slaves may be configured to issue tickets to one or more masters when they are unavailable to service requests immediately.

In fig. 1, command 120, result 130, and snoop 132 have been identified in a conceptual direction to indicate a command (command 120) flowing from the master to the slave, a result (such as a ticket) broadcast from the slave to the master (result 130), and a ticket update (snoop 132) supplied in accordance with the present disclosure, respectively. Logically speaking, command 120, result 130, and snoop 132 may flow through the respective command channel, result channel, and snoop channel, even though the command, result, and snoop channels may not be physically separate. The command channel, result channel, and listening channel may be part of an interconnect system that connects various masters and slaves of processing system 100 in fig. 1.

In an exemplary aspect, as described below, the ticket-based flow control mechanism may be implemented in a suitable combination of a command channel, a result channel, and a listening channel.

For example, a new request from one of the masters (requesting master) to access one of the slaves (target slave) may be sent on the command channel. If the target slave has availability to accept and service the request, the request may be delivered to and serviced by the target slave. In this case, the results of such a service may be provided on a result channel. In this case, once the request is delivered/accepted to/from the target slave, the request operation is completed.

However, if the target slave does not have availability and the request needs to be retransmitted, the target slave may provide the ticket and retry indication to the requesting master on the result channel. In some cases, group tickets may be provided instead of individual tickets per host to improve efficiency and reduce cost/traffic. Individual tickets are for a single request-directed ticket, while group tickets are for a set of multiple request-directed tickets from one or more hosts. The requesting master holds the request with the ticket and may not retransmit the request until the target slave indicates that it is now accepting the request for the group of tickets held by the requesting master.

The target slave may be identified in the request sent on the command channel and optionally the category to which the request belongs may also be included in the request. The category may indicate whether the request is a read, a write, an associated priority, etc. When the resources of the target slave become available so that it can begin accepting more requests, the target slave may provide a correlation indication by broadcasting a ticket decrement to all masters, for example on a listening channel, or alternatively to a selected subset of masters that may find broadcast correlations. The ticket decrementing on the listening channel may be associated with the source identifier of the ticket that the requesting host has issued (i.e., the identifier of the slave). When the master receives a ticket decrement indication from a target slave, the master decrements the ticket counts of all tickets held by the master from that slave that match the criteria indicated in the ticket decrement indication. In some cases, if the ticket decrementing indication includes a group ticket Identifier (ID), decrementing is performed for all group tickets that match the criteria indicated in the ticket decrementing indication. Once the host ticket count for the target slave reaches 0, the host can redeem the ticket and retransmit the request. Thus, when the ticket count of the requesting master reaches 0 after the ticket count from the target slave is decremented one or more times in succession, the requesting master may retransmit the request to the target slave.

In one aspect, high priority requests, such as write-back operations, may be accelerated by configuring target slaves for these requests to maintain separate ticket pools classified by their ticket categories. As mentioned above, the host may also capture ticket categories, including source IDs and category identifications, with the number of ticket groups for each category.

When a ticket is distributed, an indication of the ticket category of the target slave may be used by the host to determine its ticket category for future communications. Thus, the ticket class is provided when the ticket decrement notification is broadcast, and when the requesting host retransmits the request, the requesting host indicates its ticket class (so that the ticket is redeemed once the host's group ticket number has decremented to 0). It is to be appreciated that decrementing the ticket count to zero is only one way to update tickets to determine when they become redeemable, and that alternative methods of determining when tickets become redeemable may exist within the scope of the present disclosure.

As previously mentioned, the ticket may also be issued by one or more nodes or serialization points, such as the C2C link 110. For requests on the command channel, the C2C link 110 may form a serialization point when multiple requests are to be sent simultaneously to a memory or slave connected to the interconnect 106 through the C2C link 110. In this case, an intermediate ticketing mechanism may be employed even before the request reaches the target slave via the C2C link 110. This may form a multi-level ticketing mechanism, one ticketing level for the C2C link 110 and another ticketing level for the target slaves that are connected over the C2C link 110. Additional such ticketing levels may also be nested or accumulated without departing from the scope of this disclosure.

The following exemplary signaling may be used to implement the above ticketing process on the command channel, result channel, and listening channel. The C2C ticket in the following description refers to a ticket used to access the C2C link 110, and a non-C2C ticket refers to a ticket generated by a target slave that is not available to easily service a request.

For the command channel, the following fields may be used for a command or request (e.g., command 120) from a requesting host:

-RtyTktRequesed: this field indicates whether the ticket needs to be retried.

-TktReceived: this field indicates whether the association request has previously received a non-C2C ticket.

-TktClass [ n-1:0 ]: this field indicates the category of the ticket received from the target slave with the ticket. This field may only be valid if TktReceived or C2 ctktreeved is asserted.

-C2 ctktrrenceved: this field indicates whether the association request has previously received a ticket from the C2C link.

With the slave, the ticket is broadcast on the result channel and the ticket is decremented on the listening channel. For tickets and ticket decrements on these channels, the following fields may be available:

-TktValid: this field indicates whether a ticket has been assigned. This field is set to 0 if generated for a request sent on the command channel, where either RtyTktRequested is deasserted to indicate that the ticket does not need to be retried, or both RryTktRequested and C2CTkTValid are asserted (e.g., set to 1).

-tkttgrpcount: this field indicates the ticket group count, which is the decremented number of times performed by the requesting host before the request can be retransmitted.

-TktClass [ n-1:0 ]: this field indicates the category of the ticket, which can be used to differentiate command types (e.g., read, write back) or priority categories.

-TktSrcID: this field identifies the ticket source or drawer, i.e., the ticket generating slave or other ticket distribution entity, which is used in the ticket decrementing broadcast on the listening channel to identify which ticket group counts for the request are to be decremented.

-C2 CTktValid: this field indicates whether a C2C ticket has been assigned (where the ticket for the target slave and the C2C ticket used to access the C2C link 110 are separate). This field is set to 0 if generated in response to a request that RtyTktRequested deasserted or that both RryTktRequested and TktValid assert (e.g., set to 1). That is, TkTktRequired is mutually exclusive when RtyTktRequired is asserted.

The relationships between TktValid, C2CTktValid and RtyTktRequesed are shown in Table 1 below:

TABLE 1

Through the above signaling, it should be noted that the C2C link 110 does not require a unique copy of tktgropcount or TktSrcId in the case where tickets for both levels (C2C link 110 and the target slave (or remote endpoint)) are asserted/launched simultaneously.

Furthermore, in some cases, the C2C link 110 does not require a unique ticket category signal because requests that have received a ticket from a target slave may be placed in a high priority category, while requests that have not previously issued a ticket may be placed in a low priority category. Whether this applies and the relevant information can be inferred from the TktValid field. The host may still track the two ticket levels used to determine the decrementing (TktDecrement).

The following describes handling of requests by a ticket drawer, such as a slave or more generally an endpoint (e.g., memory 108 or a slave connected by a C2C link 110, etc.). The following scenario will be described when a request reaches an endpoint that cannot service or queue the request.

If the request has already been assigned a ticket, the ticket drawer does not issue a new ticket; the host retains the same ticket that the host previously had. The ticket group count in the result is filled with 0 (for example). Note that a new ticket may not be distributed for ticket group 0; thus, when the host sees a result of 0 in the ticket group field, the host knows to keep the existing ticket group count that the host previously received for the request.

If the request has no ticket yet and the ticket dispenser still has a ticket left for distribution, the ticket dispenser indicates in a retry result that the ticket dispenser is distributing the ticket to the requesting host; the ticker also indicates the number of ticket groups, which can then be used by the host to know how many ticket group decrementing notifications the host needs to see before retransmitting the same request. Note, however, that the host need not track the number of decremental notifications received. Conversely, when the ticket count has decremented to zero, the host may retransmit the request.

If the request has no ticket and the ticket dispenser has no remaining tickets to be distributed, the ticket dispenser indicates in the retry result that there are no remaining tickets (TktValid ═ 0). When tktvallid is 0, the remaining ticket information (e.g., results 130 including fields tktgropcount, TktSrcID, TktClass, etc.) may be supplied by the ticket drawer. The host waits for the indicated decrement number before retransmitting the request. The tktgcrpcount given when TktValid is 0 is smaller than the number of TktDecrement commands to be finally transmitted.

When a C2C ticket ejector issues a ticket (e.g., C2C link 110), the C2C ticket ejector is responsible for reflecting TktReceived back to TktValid in the result. The C2C ticketor can also replace the TktGrpCount, TktSrcID, TktClass fields with the C2C ticketor value.

Tickets may be distributed in sequence, for example starting from group '1'. Once all tickets of group 1 are distributed, the ticker can begin distributing tickets of group '2'. Once all of these tickets have been dispensed, the ticket dispenser may move to group '3', and so on. The ticket may not be able to be recovered until all existing tickets have been distributed. In other words, if the drawer still has n tickets in group j to distribute and has redeemed multiple tickets for group k (where k < j), the drawer may not redistribute those redeemed tickets. Conversely, once all tickets of group k have been redeemed, group k becomes the highest group (e.g., j +1 or j +2, etc.), and then the tickets of group k can be distributed accordingly.

A ticket group decrement command (TktDecrement) may be sent or broadcast on the listening channel as a field of listening 132. No response is returned to the ticketing machine in response to the notification.

The target slave or other endpoint may send a ticket group decrement command marking group "X" as the group currently being serviced, while the tickets for group X-1 remain pending. The target slave or other endpoint may perform a check to ensure that the group X ticket does not repeat the request to prevent retransmission of group X-1 to ensure that processing is proceeding. For example, if a ticketed request needs to be retransmitted, the ticketor can stop sending early TktDecrement until all pending requests for the current group have been returned.

The ticketing machine may also implement a mechanism for reusing tickets that are not filled or are filled with a slow group count. For example, the number of groups may be reused once the number of pending tickets for the group is equal to or less than the available space in the ticket dispenser for servicing the request. In this case, if the ticketing machine has sufficient resources to accept pending requests in the group, the ticketing machine may not wait for all tickets in the group to be distributed before reusing them.

While the target slave or other endpoint may have a pending ticket (i.e., a ticket that has been distributed but not yet redeemed), the target slave may accept a certain number of requests without tickets, but retain a certain number of requests to handle correctly ticketed tickets. If the target slave has any pending tickets, the target slave may implement a mechanism to prevent the resources of the target slave from being occupied for non-ticketed requests.

The ticketing engine may employ mechanisms with various granularities to track which hosts or groups of hosts need to see its/their ticket group decremental broadcast. For example, the ticketing agent may track the particular source ID/group to which the requesting host may belong using a vector, where the vector may be unique for each group of tickets, so that the ticketing agent knows when to stop forwarding the ticket group decrement notification to the group that includes the requesting host. Each vector of each group may be logically added (e.g., OR operated together) and if any vector bit is ON (ON), a ticket group decrement notification may be sent to the respective group.

In one aspect, the C2C link 110 may be viewed as a special class of ticketor that can generate tickets for its own resources, as well as deliver tickets from other endpoint ticketors. To support the behavior of hosts that do not need to re-queue at the C2C link 110, separate or dedicated fields for the C2C link 110 and other (non-C2C links) endpoints may be used. For example, all C2C ticketers may assert C2CTktValid, while all non-C2C ticketers may de-assert C2 CTktValid.

Requests issued by the requesting host are described in more detail below. In one aspect, if the request needs to be retransmitted, the host may indicate whether it needs a ticket when issuing the request. When the host issues a request, the host may indicate whether it is attempting to redeem the ticket with the request (i.e., retransmitting the request with a fully decremented ticket value). When the host retransmits the request with the ticket, the host expects not to change the request attributes that would cause the request to be routed to a different endpoint (e.g., a slave).

When the host receives a retry indication (e.g., a ticket), the host may store a ticket group count, a ticket category, a ticket source ID, and a suitable combination of TktValid and C2CTktValid indications, which are collectively referred to herein as a TktValid signal. The host may store the C2CTktClass separately from the endpoint TktClass. In one aspect, TktClass is the C2C class if C2CTktValid ═ 1, otherwise it is the endpoint TktClass.

If the host receives a retry indication without a valid ticket value (@ TktValid ═ 0), this may indicate that the ticket ejector is not a ticket. The remaining ticket information (tktgcrpcount, TktSrcID, TktClass, etc.) will be valid when TktValid is 0. Thus, the host may be configured to wait the indicated decrement number (TktReceived 0) before re-requesting.

When the host has a group ticket number for a pending request, the host may begin monitoring the listening channel for a ticket decrement command from the ticket dispenser. For each ticket decrement command broadcast that matches the request, the host may decrement the number of ticket groups by the received decrement value until the number of ticket groups reaches and remains (saturates) 0, since the group count may not be decremented below 0.

The host may be configured to wait for a retransmission request until the ticket group count reaches 0. When a request with a ticket reaches a target slave or drawer and the target slave is able to service or queue it, the ticket is said to be redeemed.

To ensure that the processing system 100 does not go wrong or "hang up" due to an apparent lack of resources, the ticket is designed to be lossless. That is, once a ticket has been distributed by a ticket dispenser for a request, the ticket is eventually returned to the ticket dispenser so that the ticket can be subsequently reused for another request to the ticket dispenser. A host wishing to abort a request may wait for the ticket group count to reach 0 and then send a TktCancel command with the same address/attribute as the original request.

That is, the ticket cancellation request (TktCancel) may be used by a host that previously issued the request and is given the group ticket. The disclosed ticketing scheme relies on the conservation of tickets, so if a host receives a ticket that later wants to be relinquished, the ticket should be returned to the endpoint. Before sending the request, the host should wait until its ticket count reaches zero. However, operations routed by command type (e.g., Distributed Virtual Memory (DVM) and barriers, point-to-point (P2P), data cache clean-up, and domain key ID level 2(DCCIRKIDL2) cache operation invalidation, etc.) may not issue TktCancel because there may not be enough information to route the cancellation request to the appropriate endpoint.

A ticket ejector receiving a request that has been retransmitted can reload the ticket field even though the previously granted ticket is being redeemed by the host. In this case, the ticker is responsible for setting the group count appropriately. This action allows the C2C ticketer to override the new group count value if necessary.

If the request previously received an endpoint ticket, the host that retransmitted the request to redeem the C2C ticket may use the endpoint TktClass. The C2C ticket drawer knows the ticket class to redeem based on the value of TktReceived.

Fig. 2A-2C illustrate an example sequence of commands 120 (i.e., requests) with associated outcomes 130 for a C2C ticket and an endpoint ticket, in accordance with various aspects of the present disclosure.

In particular, fig. 2A illustrates an exemplary sequence 200 that includes a command 120 (e.g., a request sent by a master) and a result 130 for combining an endpoint (e.g., a slave) and a C2C ticket, in the case where the C2C link 110 (drawer) sends a first ticket. In command 120, the tktReceived and C2 ctktrrenceved fields are set to "0," indicating that command 120 is an initial request. In the result 130, the tktValid, C2 ctkttvalid, and tktClass fields are set to "0", "1", and "000", respectively, indicating that the ticket is a low priority C2C ticket. In this case, the C2C link 110 is shown issuing enough snoops 132 to decrement to cause the command/request to be reissued.

FIG. 2B illustrates an exemplary sequence 210, which includes a command 120 (e.g., a request sent by a master) and a result 130 for combining an endpoint (e.g., a slave) and a C2C ticket, in the case where the C2C link 110 (drawer) sends the first ticket. In order 120, the tktReceived and C2 ctktrrenceved fields are set to "0" and "1," respectively, indicating that order 120 is a retransmitted request to redeem a C2C ticket. In the result 130, the tktValid, C2CtktValid, and tktClass fields are set to "1", "0", and "EPClass" (endpoint category), respectively, indicating that the ticket is for an endpoint. In this case, the endpoint is shown issuing enough snoops 132 to decrement to cause the command/request to be retried/redeemed, with the tktReceived, C2 ctktreeceived, and tktClass fields in the command 120 set to "1", "0", and "EPClass", respectively.

Fig. 2C illustrates an exemplary sequence 220 that includes a command 120 (e.g., a request sent by a host) and a result 130 for combining an endpoint and a C2C ticket, in the case where the endpoint (ticker) sends a first ticket. In command 120, the tktReceived, C2 ctktreeceived, and tktClass fields are set to "0" indicating an initial request. In result 130, the tktValid, C2CtktValid, and tktClass fields are set to "1", "0", and "EPClass", respectively, indicating that command 120 issued the ticket through C2C link 110 and C2C link 110 did not issue the ticket, and the opposite endpoint issued the ticket. The endpoint then issues a sufficient decrement for the command/request to be retransmitted, and the host retransmits the request by issuing another command 120 with the tktReceived, C2 ctktreeceived, and tktClass fields of the command 120 set to "1", "0", and "EPClass", respectively, to indicate that the command 120 is a re-request to redeem the endpoint ticket. In the example of FIG. 2C, in the result 130, the tktValid, C2CtktValid, and tktClass fields are set to "1", and "001", respectively, indicating that a high priority C2C ticket has been issued. Then, the C2C issues a decrement sufficient to cause the combined C2C and endpoint command/request to be retried. The host may then issue another command 210 in which the tktReceived, C2 ctktrreceived, and tktClass fields are set to "1", and "EPClass", respectively, indicating that the host is redeeming the C2C and endpoint ticket.

It is to be appreciated that the exemplary aspects include various methods for performing the processes, functions and/or algorithms disclosed herein. For example, FIG. 3 illustrates a method 300 of managing traffic in a processing system (e.g., processing system 100) having one or more masters and one or more slaves. The method 300 may be performed by a target slave (e.g., memory 108, C2C link 110).

At 302, the target slave receives a request (e.g., command 120 on a command channel) from a requesting master (e.g., cores 102 a-102 n).

In 304, if the target slave is not available to service the request, the target slave provides the request host with a ticket having a ticket value with an initial value (e.g., a value greater than "0"). The target slave may provide the ticket as a result 130 on a result channel.

In 306, the target slave broadcasts one or more updates to the ticket value of the ticket to update (e.g., decrement) the ticket value when resources in the target slave become available. The target slave may broadcast one or more updates to the requesting master as one or more listens 132 on the listen channel.

In 308, the target slave services a retransmission of the request from the requesting master with a final ticket value (e.g., a value of "0") of the ticket value of the ticket. The target slave may receive a repeat request as command 120 on the command channel.

Fig. 4 illustrates another method 400 of managing traffic in a processing system (e.g., processing system 100) having one or more masters and one or more slaves. Method 400 may be performed by a requesting host (e.g., cores 102 a-102 n).

At 402, the requesting master transmits a request (e.g., command 120 on a command channel) from the requesting master (e.g., cores 102 a-102 n) to the target slave (e.g., memory 108, C2C link 110).

In 404, the requesting master receives a ticket (e.g., result 130 on a result channel) for the request from the target slave to indicate that the target slave is unavailable to service the request, the ticket having a ticket value.

In 406, the requesting master receives one or more broadcast messages (e.g., one or more listens 132 on a listen channel) from the target slave to indicate that the ticket value is to be updated.

At 408, the requesting host updates (e.g., decrements) the ticket value based on one or more broadcast messages.

At 410, when the ticket value has reached the final ticket value (e.g., has been decremented to zero), the requesting master retransmits the voted request to the target slave (e.g., as a command 120 on a command channel).

An example apparatus with which exemplary aspects of the present disclosure may be utilized is shown in fig. 5. Fig. 5 shows a block diagram of an exemplary computing device 500, the exemplary computing device 500 including a processor 502, which may be a host, configured as one of the cores 102 a-102 n, and in particular, in the example of fig. 5, configured as core 102a in fig. 1. Correspondingly, the cache 104a, interconnect 106, memory 108, and C2C link 110 discussed with respect to fig. 1 are also shown (the C2C link 110 is shown external to the computing device 500 to conceptually illustrate that the C2C link 110 may provide connectivity to off-chip devices). Many other details of the processing system 100 shown in fig. 1 may be applicable to fig. 5, but for clarity these details have been omitted from the description of fig. 5, and it is to be understood that they may be configured similarly as described with reference to fig. 1. In one aspect, computing device 500 may be configured to perform methods 300 and 400 of fig. 3 and 4, respectively.

In fig. 5, the processor 502 is shown communicatively coupled to the memory 108 (e.g., via the cache 104a and the interconnect 106 in the example of fig. 5). Fig. 5 also shows a display controller 526 that is coupled to the processor 502 and to a display 528.

In some aspects, computing device 500 may include some optional blocks shown with dashed lines. For example, the computing device 500 may optionally include a coder/decoder (CODEC)534 (e.g., an audio and/or voice CODEC) coupled to the processor 502; a speaker 536 and a microphone 538 coupled to the CODEC 534; and a wireless controller 540 (which may include a modem) coupled to the wireless antenna 542 and the processor 502.

In a particular aspect, the processor 502, the display controller 526, the memory 108, the CODEC 534, and the wireless controller 540 may be included in a system-in-package or system-on-chip device 522, with one or more of the above optional blocks present. The input device 530, the power supply 544, the display 528, the speaker 536, the microphone 538, the wireless antenna 542, the power supply 544, and the C2C link 110 may be external to the system-on-chip device 522 and may be coupled to one or more components of the system-on-chip device 522, such as an interface or a controller.

It should be noted that although fig. 5 generally depicts a computing device 500, the processor 502 and memory 108 may also be integrated into a set-top box, music player, server, video player, entertainment unit, gaming device, navigation device, Personal Digital Assistant (PDA), fixed location data unit, computer, laptop computer, tablet computer, communications device, mobile phone, or other similar device.

Those of skill in the art would understand that information and signals may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

Further, those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the aspects disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The methods, sequences and/or algorithms described in connection with the aspects disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in Random Access Memory (RAM), flash memory, Read Only Memory (ROM), erasable programmable ROM (eprom), electrically erasable programmable ROM (eeprom), registers, a hard disk, a removable disk, a Compact Disk (CD), a Digital Video Disk (DVD), or any other form of storage medium known in the art. An exemplary storage medium may be coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor.

Accordingly, one aspect of the present disclosure may include a computer-readable medium embodying a method for managing traffic in a processing system. Accordingly, the present disclosure is not limited to the illustrated examples, and any means for performing the functionality described herein are included in the various aspects of the present disclosure.

While the foregoing disclosure shows illustrative aspects of the disclosure, it should be noted that various changes and modifications could be made herein without departing from the scope of the disclosure as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the various aspects of the disclosure described herein need not be performed in any particular order. Furthermore, although elements of the disclosure may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.