Patent ID: 12235782

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements of one example may be beneficially incorporated in other examples.

DETAILED DESCRIPTION

Various features are described hereinafter with reference to the figures. It should be noted that the figures may or may not be drawn to scale and that the elements of similar structures or functions are represented by like reference numerals throughout the figures. It should be noted that the figures are only intended to facilitate the description of the features. They are not intended as an exhaustive description of the description or as a limitation on the scope of the claims. In addition, an illustrated example need not have all the aspects or advantages shown. An aspect or an advantage described in conjunction with a particular example is not necessarily limited to that example and can be practiced in any other examples even if not so illustrated, or if not so explicitly described.

Embodiments herein describe a multi-chip device that includes multiple SoCs with interconnected NoCs. Because the number of SoCs (or more generally, integrated circuits (ICs)) in the multi-chip device can vary (e.g., 2, 4, etc.) the NoCs on the individual SoCs may not have sufficient address space to connect to the various destinations on the other SoCs. That is, a NoC on a first SoC may not have sufficient apertures to directly route to destinations connected to NoCs on a second SoC. Embodiments herein mitigate this issue by providing address translation circuitry in the SoCs. The address translation circuitry establishes a hierarchy where traffic originating from a first SoC that is intended for a destination on a second SoC is first routed to the address translation circuitry on the second SoC which then performs an address translation and insert the traffic back on the NoC in the second SoC but with a destination ID corresponding to the local destination. In this manner, the traffic originating from a different SoC can first be routed to the address translation circuitry on the local SoC. That way, a SoC can have only additional address apertures to route traffic to the address translation circuitry of the other SoCs rather than having address apertures for every destination in the other SoCs in the multi-chip device.

Embodiments herein can also provide additional horizontal and vertical connections between NoCs in different SoCs by leveraging direct fabric connections. For example, a NoC in one SoC may have four horizontal channels, but due to beachfront limitations on the SoC, only one or two of those channels may be connected to horizontal channels in a NoC in a neighboring SoC. Instead of using only these direct NoC connections, a NoC compiler can instead route traffic to traffic redistribution circuitry in the same SoC. In one embodiment, the traffic redistribution circuitry can be implemented using programmable logic (PL) that includes direction fabric connections to PL in the neighboring SoC. These fabric connections can be used to route the traffic to the PL in the neighboring SoC (e.g., another iteration of the traffic redistribution circuitry) which then inserts the traffic on the NoC on the neighboring SoC so it can reach its ultimate destination.

Embodiments herein can also prevent deadlocks by establishing X-Y routing where traffic originating in one SoC that is destined for a different SoC has to first route through an intermediate SoC in the X (horizontal) direction before then routing in the Y (vertical) direction. This ensures loops are not created where neighboring SoCs are competing for the same resources.

FIG.1is a block diagram of the SoC100containing a NoC105, according to an example. In one embodiment, the SoC100is implemented using a single IC. In one embodiment, the SoC100includes a mix of hardened and programmable logic. For example, the NoC105may be formed using hardened circuitry rather than programmable circuitry so that its footprint in the SoC100is reduced.

As shown, the NoC105interconnects a programmable logic (PL) block125A, a PL block125B, a processor110, and a memory120. That is, the NoC105can be used in the SoC100to permit different hardened and programmable circuitry elements in the SoC100to communicate. For example, the PL block125A may use one ingress logic block115(also referred to as a NoC Master Unit (NMU)) to communicate with the PL block125B and another ingress logic block115to communicate with the processor110. However, in another embodiment, the PL block125A may use the same ingress logic block115to communicate with both the PL block125B and the processor110(assuming the endpoints use the same communication protocol). The PL block125A can transmit the data to the respective egress logic blocks140(also referred to as NoC Slave Units or NoC Servant Units (NSU)) for the PL block125B and the processor110which can determine whether the data is intended for them based on an address (if using a memory mapped protocol) or a destination ID (if using a streaming protocol).

The PL block125A may include egress logic blocks140for receiving data transmitted by the PL block125B and the processor110. In one embodiment, the hardware logic blocks (or hardware logic circuits) are able to communicate with all the other hardware logic blocks that are also connected to the NoC105, but in other embodiments, the hardware logic blocks may communicate with only a sub-portion of the other hardware logic blocks connected to the NoC105. For example, the memory120may be able to communicate with the PL block125A but not with the PL block125B.

As described above, the ingress and egress logic blocks115,140may all use the same communication protocol to communicate with the PL blocks125, the processor110, and the memory120, or can use different communication protocols. For example, the PL block125A may use a memory mapped protocol to communicate with the PL block125B while the processor110uses a streaming protocol to communicate with the memory120. In one embodiment, the NoC105can support multiple protocols.

In one embodiment, the SoC100is an FPGA which configures the PL blocks125according to a user design. That is, in this example, the FPGA includes both programmable and hardened logic blocks. However, in other embodiments, the SoC100may be an ASIC that includes only hardened logic blocks. That is, the SoC100may not include the PL blocks125. Even though in that example the logic blocks are non-programmable, the NoC105may still be programmable so that the hardened logic blocks—e.g., the processor110and the memory120can switch between different communication protocols, change data widths at the interface, or adjust the frequency.

In addition,FIG.1illustrates the connections and various switches135(labeled as boxes with “X”) used by the NoC105to route packets between the ingress and egress logic blocks115and140.

The locations of the PL blocks125, the processor110, and the memory120in the physical layout of the SoC100are just one example of arranging these hardware elements. Further, the SoC100can include more hardware elements than shown. For instance, the SoC100may include additional PL blocks, processors, and memory that are disposed at different locations on the SoC100. Further, the SoC100can include other hardware elements such as I/O modules and a memory controller which may, or may not, be coupled to the NoC105using respective ingress and egress logic blocks115and140. For example, the I/O modules may be disposed around a periphery of the SoC100.

FIGS.2A-2Cillustrate multi-chip devices200A-C, according to an example. In one embodiment, the multi-chip devices200A-C include two or more of the SoCs100illustrated inFIG.1. However, the multi-chip devices200A-C are not limited to any particular SoC implementation. In generally, the multi-chip devices200A-C can be formed from any number of ICs205which include NoCs105.

FIG.2Aillustrates a multi-chip device200A that includes two ICs205that are connected vertically.FIG.2Aillustrates a top down view of the multi-chip device200A where the ICs205have been rotated 180 degrees from each other. That is, the ICs205are the same (e.g., generated from the same tapeout) but one IC205has been rotated 180 degrees from the other IC202. The arrows indicate connections between the NoCs105in the two ICs205.

In addition, the ICs205include address translation circuitry210. The NoCs105on the individual ICs205(or SoCs) may not have sufficient address space to route directly to the various destinations on the other IC205. Instead of routing traffic from a source on a NoC105in a first IC205to a destination connected to the NoC105in a second IC205, the traffic is first routed to the address translation circuitry210on the second IC205. This is discussed in more detail inFIGS.3-5.

FIG.2Ba multi-chip device200B that includes two ICs205that are connected horizontally.FIG.2Billustrates a top down view of the multi-chip device200B where the ICs205have the same orientation. Like inFIG.2A, the ICs205inFIG.2Bare the same (e.g., generated from the same tapeout) but unlike inFIG.2A, here the ICs205have the same orientation. The arrows indicate connections between the NoCs105in the two ICs205.

The ICs205also include address translation circuitry210which provide a routing hierarchy where inter-IC traffic can first be routed to the address translation circuitry210which then performs an address translation to identify and forward the traffic to a local destination.

FIG.2Ca multi-chip device200C that includes two pairs of ICs that are connected both vertically and horizontally. That is, the device200C includes a first pair of ICs that include the ICs205and a second pair of ICs that include the ICs220.FIG.2Cillustrates a top down view of the multi-chip device200C where the ICs205have been rotated 180 degrees from each other and the ICs220have been rotated 180 degrees from each other. In one embodiment, the ICs205inFIG.2Care the same (e.g., generated from the same tapeout) and the ICs220are the same, but the ICs205and the ICs220are not the same. In one embodiment, the ICs220are a mirror of the ICs205. That is, while the ICs205and the ICs220are formed using different tapeouts, once the ICs205are designed, the ICs220can be easily designed by instructing an Electronic Design Automation (EDA) tool to mirror the design of the IC205. The two pairs of mirrored ICs can then be interconnected horizontally as shown.

In one embodiment, each of the ICs205and220in the multi-chip device200C can transmit traffic to each other using the direct NoC connections. That is, the ICs205,220can transmit traffic to any of the three other ICs205,220using the NoCs105. However, since there are four ICs inFIG.2C, the address space needed to directly route data using the NoCs105for one IC to all three of the other ICs is even larger. To mitigate this, the ICs205and220include the address translation circuitry210which provide a routing hierarchy where inter-IC traffic can first be routed to the address translation circuit210which then performs an address translation to identify and forward the traffic to a local destination.

Further, when routing traffic from non-neighboring ICs, the data may first be routed to the address translation circuit210in the intermediate IC before then being routed to the address translation circuit210in the destination IC. For example, if the IC205in the lower left of the device200C wants to route data to a destination in the IC220in the upper right, the IC205may first use its NoC to route the traffic to the address translation circuit210in the IC220in the lower right which in turn routes the traffic to the address translation circuit210in the IC220in the upper right. This address translation circuit210can then forward the traffic to the local destination.

Alternatively, the IC205in the lower left may instead transmit the traffic through the NoC105in the IC220in the lower right and into the NoC105in the IC220in the upper right without the data being routed through the address translation circuit210in the IC220in the lower right. The address translation circuit210in the IC220in the upper right then forwards the traffic to the local destination. In this case, the NoC105has an address aperture for the address translation circuit210in the IC220in the upper right, and thus, can route the traffic directly there using the NoCs105without the aid of the address translation circuits210in the intermediary ICs.

FIG.3is a flowchart of a method300for routing traffic between two NoCs in a multi-chip device, according to an example. For ease of explanation, the method300is discussed in tandem withFIG.4which illustrates a multi-chip device400with address translation circuitry connected to the NoCs, according to an example.

At block305, an ingress logic block on a first IC routes traffic to an address translation circuit on a second IC in the multi-chip device. UsingFIG.4as an example, Client A on the IC405A wants to transmit traffic to a destination on the IC405B. The Client A can be PL, a processor, memory, etc. in the IC405A. Furthermore, the ICs405A-D can be related as shown inFIG.2Cwhere the ICs405A and405D are the same but rotated 180 degrees from each other and the ICs405B and405C are mirrored tapeouts of the ICs405A and405D but rotated 180 degrees from each other. However, this is not a requirement. In other embodiments, the ICs405may be all different ICs which nonetheless have their NoCs interconnected. However, coupling together ICs with the same (or mirrored) layouts simplifies the process of forming a multi-chip device, but it is not a requirement.

As shown, Client A has four ingress logic blocks for inserting traffic into the NoC of the IC405A. In this example, it is assumed that the NoC in the IC405A does not have sufficient address space to route data directly to the destination in the IC405B. That is, the ingress logic block115A may not know the destination ID for the destination in the IC405B. However, the NoC in the IC405A does include an address aperture for the address translation circuitry210in the IC405B. In one embodiment, the destination ID for the address translation circuitry210in the IC405B may be stored in a remap register for the NoC in the IC405A. Remap registers provide flexibility to NoC addressing and are typically used for debugging purpose or when there is an error. However, the remap registers can also be used when the ICs405are placed in a multi-chip device to provide destination IDs to destinations in the other ICs, such as the address translation circuitry210.

InFIG.4, the NoC in the IC405A routes the traffic to NoC connections410that permit the NoC in the IC405A to communicate with the NoC in the IC405B. In one embodiment, the NoC connections410are located at the periphery of the ICs405and provide direct connections so that the traffic does not first propagate through any input/output elements (e.g., transceivers) on the ICs405. In one embodiment, the NoC connections410may use connections in an interposer or substrate on which ICs405are disposed. That is, the NoC connections410may be attached to connections or traces in the interposer which communicatively the two NoC connections410. In one embodiment, the NoC connections410are referred to as inter-die connections for coupling two NoCs together.

In one embodiment, the traffic is routed from Client A in the IC405A to the circuitry210in IC405B using the destination ID of the circuitry210. For example, each packet or flit can be routed through the switches in the NoCs in the ICs405A and405B using the destination ID of the circuitry210. A NoC compiler programs the switches to know the next hop associated with the destination ID. In this manner, the traffic can proceed through the switches in the NoCs in both ICs405A and405B along a first path415until reaching the egress logic block140A for the address translation circuitry210.

Returning to method300, at block310, the address translation circuitry performs an address translation to identify a local destination of the traffic on the second IC. That is, in addition to including a destination IC used to route the traffic through the NoCs, the traffic can also include an address which the address translation circuitry can then use to identify the local destination of the traffic on the IC. This address can be a source address or a destination address.

Again referring toFIG.4, the address translation circuitry210can perform an address translation to determine the local destination for the traffic. That is, the result of the address translation is a destination ID for the local destination on the IC405B for the traffic. The address translation circuitry210can then reinsert the traffic into the NoC using an ingress logic block115B, but this time the traffic includes the destination ID for the local destination.

At block315, the NoC on the second IC routes the traffic from the NoC ingress logic block on the second IC to the egress logic block on the second IC corresponding to the local destination. This is illustrated inFIG.4where the NoC in the IC405B routes the traffic to the destination as shown by the second path420where it is received by an egress logic block140B for the destination.

In this manner, the NoC on the IC405A (or more specifically, the address apertures in the NoC) does not have to be programmed to recognize the destination ID for the local destination on the IC405B. Instead, the NoC in the IC405A can be programmed to have an address aperture for the address translation circuitry210which then identifies the destination IDs for the various destinations in the IC405B. This can greatly reduce the number of address apertures needed in each of the NoCs in the ICs405when forming a multi-chip device.

In one embodiment, the address translation circuitry210is implemented in PL in the ICs405. However, in another embodiment, the address translation circuitry210may be hardened logic in the ICs405. While using PL to implement the address translation circuitry210offers more flexibility (e.g., can scale as the number of ICs in the multi-chip device scales), implementing the circuitry210in hardened logic may require less space in the ICs.

At block320, the NoCs in the first and second ICs route a response from the egress logic block on the second IC corresponding to the local destination to the ingress logic block on the first IC. Again referring toFIG.4, the egress logic block140B for the local destination on the IC405B can route the response directly to the ingress logic block115A for Client A on the IC405A. Notably, this response does not have to route through the address translation circuitry210on the IC405B (or any address translation circuitry on the IC405A). The response can be routed using the already known destination ID for the Client A, and as such, another address translation is not needed.

The method300can also be used to route traffic between ICs that are not direct neighbors in the IC. That is, the method300can be used to route traffic from the IC405A to the IC405C inFIG.4which do not have direct connections to each other. If the IC405A has sufficient available address apertures, the IC405A can insert traffic that flows from its NoC to the NoC in the IC405B, from the NoC in the IC405B to the NoC in the IC405C, and from the NoC in the IC405C to address translation circuitry in the IC405C. As discussed above, the address translation circuitry in the IC405C can perform the address translation and reinsert the traffic into the NoC in the IC405C so it can reach the local destination.

However, the NoC in the IC405A may not have sufficient address apertures to route traffic to the address translation circuitry in the IC405C. In that case, the traffic may be routed to the address translation circuitry210in the IC405B as shown inFIG.4. The address translation circuitry210can then identify the destination ID for the address translation circuitry in the IC405C and then reinsert the traffic into the NoC in the IC405B which then routes the traffic to the NoC in the IC405C and then to its address translation circuitry which performs an additional address translation which routes the traffic to the local destination on the IC405C. Thus, in this example, traffic flowing between non-neighboring ICs in the multi-chip device can be routed through the address translation circuitry in an intermediate IC (e.g., the IC405B in this example), or can bypass the address translation circuitry in the intermediate IC and instead rely solely on the address translation circuitry in the destination IC (e.g., the IC405C).

FIG.5illustrates an address translation table505, according to an example. As shown, the address translation table505is contained within the address translation circuitry210. For example, the address translation table505can be stored in memory in the address translation circuitry210.

The address translation circuitry210receives traffic (labeled as REQ ADDR A) at an egress logic block140. The address translation circuitry210uses ADDR A in the request to index into the table505to identify an entry corresponding to that address. In this example, the ADDR A is a source address.

The table505then returns the destination address (ADDR B) and the destination ID (5) for the local destination. With this information, the address translation circuitry210uses an ingress logic block115to re-insert the traffic into the NoC which has the destination ID (5) for the destination circuit510. The NoC then routes the traffic to an egress logic block140for the destination circuitry510.

Once received, the egress logic block140for the destination circuitry510can send a response to the ingress logic block that initiated the traffic (i.e., that transmitted the REQ ADDR A to the address translation circuitry210). Note that this response can bypass the address translation circuitry210. Stated differently, the response can be routed without having to pass through the address translation circuitry.

FIG.6is a flowchart of a method600for routing traffic between two NoCs in a multi-chip device, according to examples. For ease of explanation, the method600is discussed in tandem withFIG.7which illustrates a multi-chip device700with redistribution circuitry connected to the NoCs, according to examples. InFIGS.6and7it is assumed that the multi-chip device does not have sufficient NoC connections (e.g., inter-die NoC-to-NoC) connections to facilitate the amount of traffic that one IC wants to send to another IC.

At block605, a NoC ingress logic block on a first IC routes traffic to an egress logic block on the first IC corresponding to redistribution circuitry. In one embodiment, the redistribution circuitry is on the same IC as the egress logic block inserting the traffic into the NoC. For example,FIG.7illustrates three ingress logic blocks115B,115C, and115D inserting traffic into the NoC of the IC705A which is received at egress logic blocks140A,140B, and140C corresponding to the redistribution circuitry710A. In this case, the “X's” indicate horizontal channels (e.g., virtual channels) in the NoC that are not connected to corresponding horizontal channels in the NoC in the IC705B. For example, there may be insufficient beachfront in the ICs705A-D to have a NoC connection for each of the horizontal channels. In this embodiment, only one of the horizontal channels is directly connected to a horizontal channel in the NoC in the IC705B using respective NoC connections.

However, the ICs705A-D have other connections to each other besides the NoC connections. In this example, the PL in the ICs have PL-to-PL connections (also referred to as fabric-to-fabric connections) between the ICs705A-D. These connections are illustrated as the indirect paths720that provide indirect communication between the NoCs in two different ICs in contrast to the direct NoC path715. In any case, traffic can flow between the NoCs in the ICs705A and705B via the indirect paths720and the direct NoC path715in parallel or simultaneously.

Returning toFIG.6, at block610the redistribution circuitry forwards the traffic received from the NoC to redistribution circuitry on a second IC using, e.g., the PL-to-PL connections. While the embodiments herein describe using PL-to-PL connections, other multi-chip devices may have different types of inter-die connections such as memory-to-memory connections. Thus, the embodiments herein are not limited to using PL-to-PL connections to facilitate the indirect paths720illustrated inFIG.7.

At block615, the redistribution circuitry in the second IC routes the traffic from a NoC ingress logic block on the second IC to an egress logic block on the second IC corresponding to the destination of the traffic. Put differently, traffic exits the NoC in the first IC, is forwarded to the redistribution circuitry in the second IC which then inserts the traffic into a NoC in the second IC where it is routed to the local destination. As an example,FIG.7illustrates three NoC traffic flows that are redirected through the indirect paths720between the redistribution circuitry710A and710B. The redistribution circuitry710B then uses three ingress logic blocks115E,115F, and115G to insert these three traffic flows into the NoC on the IC705B which in turns routes this traffic to the egress logic blocks140D,140E, and140F corresponding to their destinations in the IC705B.

In contrast, the traffic inserted by the ingress logic block115A in the IC705A can use the direct NoC path715(which uses the NoC connections) to transmit the traffic directly from the NoC in the IC705A to the NoC in the IC705B where it is routed to the egress logic block140G at the local destination. Thus, this traffic flow bypasses the redistribution circuitry710A and710B.

Although not shown, the redistribution circuitry710and the indirect paths720may be used in combination with the address translation circuitry discussed inFIGS.3-5. For example, the PL in the IC705B may include address translation circuitry. In that case, the traffic flows inserted into the NoC by the ingress logic blocks115B,115C, and115D still go to the redistribution circuitry710A where they then use the indirect paths720to reach the IC705B. However, instead of being immediately inserted into the NoC in the IC705B, the address translation circuitry in the IC705B may perform the address translation discussed above to identify the local destinations for the three traffic flows. Once the translation is performed, the three traffic flows are inserted into the NoC in the IC705B.

Similarly, the traffic flow inserted into the NoC in the IC705A by the ingress logic block115A can still use the direct NoC path715to reach the IC705B, but instead of the traffic going directly to the local destination, it is first routed to the address translation circuitry and then to its local destination as illustrated inFIG.4. Thus, the address translation discussed inFIGS.3-5can be used in combination with the indirect paths illustrated inFIGS.6and7, or the concepts can be used independently of one another.

In one embodiment, the redistribution circuitry710is implemented in PL in the ICs705A-D. However, in another embodiment, the redistribution circuitry710may be hardened logic in the ICs705A-D so long as this hardened logic has access to inter-die connections. While using PL to implement the redistribution circuitry710offers more flexibility (e.g., can scale as the number of ICs in the multi-chip device scales), implementing the redistribution circuitry710in hardened logic may require less space in the ICs.

In yet another embodiment, X-Y routing can be used to avoid deadlocks between the ICs in a multi-die device. UsingFIG.7as an example, the ICs may attempt to transmit data using a X pattern where, e.g., IC705A is attempting to transmit traffic to IC705C while IC705B is attempting to transmit traffic to IC705D. IC705A may be waiting on resources to free up in IC705B in order to reach IC705C at the same time the IC705B is waiting for resources to free up in IC705C to reach IC705D, and so forth. In some scenarios, the four ICs705A-D may be waiting for resources which can result in a deadlock. In one embodiment, the deadlock is avoided by using an X-Y routing policy where the ICs first route in the X (horizontal) direction (e.g., a first dimensions in the array) before then routing in the Y (vertical) direction (e.g., a dimension in the array that is perpendicular to the first dimension). This breaks any deadlock.

In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

As will be appreciated by one skilled in the art, the embodiments disclosed herein may be embodied as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium is any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus or device.

A computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects of the present disclosure are described below with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to embodiments presented in this disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various examples of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

While the foregoing is directed to specific examples, other and further examples may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.