1. Technical Field
Methods and example embodiments described herein are generally directed to interconnect architecture, and more specifically, to network on chip system interconnect architecture.
2. Related Art
The number of components on a chip is rapidly growing due to increasing levels of integration, system complexity and shrinking transistor geometry. Complex System-on-Chips (SoCs) may involve a variety of components e.g., processor cores, DSPs, hardware accelerators, memory and I/O, while Chip Multi-Processors (CMPs) may involve a large number of homogenous processor cores, memory and I/O subsystems. In both systems the on-chip interconnect plays a role in providing high-performance communication between the various components. Due to scalability limitations of traditional buses and crossbar based interconnects, Network-on-Chip (NoC) has emerged as a paradigm to interconnect a large number of components on the chip. NoC is a global shared communication infrastructure made up of several routing nodes interconnected with each other using point-to-point physical links.
Messages are injected by the source and are routed from the source node to the destination over multiple intermediate nodes and physical links. The destination node then ejects the message and provides it to the destination. For the remainder of the document, terms ‘components’, ‘blocks’, ‘hosts’ or ‘cores’ will be used interchangeably to refer to the various system components which are interconnected using a NoC. Terms ‘routers’ and ‘nodes’ will also be used interchangeably. Without loss of generalization, the system with multiple interconnected components will itself be referred to as a ‘multi-core system’.
There are several possible topologies in which the routers can connect to one another to create the system network. Bi-directional rings (as shown in
Packets are message transport units for intercommunication between various components. Routing involves identifying a path composed of a set of routers and physical links of the network over which packets are sent from a source to a destination. Components are connected to one or multiple ports of one or multiple routers; with each such port having a unique ID. Packets carry the destination's router and port ID for use by the intermediate routers to route the packet to the destination component.
Examples of routing techniques include deterministic routing, which involves choosing the same path from A to B for every packet. This form of routing is independent from the state of the network and does not load balance across path diversities which might exist in the underlying network. However, such deterministic routing may be simple to implement in hardware, maintains packet ordering and may be easy to render free of network level deadlocks. Shortest path routing may minimize the latency as such routing reduces the number of hops from the source to the destination. For this reason, the shortest path may also be the lowest power path for communication between the two components. Dimension-order routing is a form of deterministic shortest path routing in 2D mesh networks.
Source routing and routing using tables are other routing options used in NoC. Adaptive routing can dynamically change the path taken between two points on the network based on the state of the network. This form of routing may be complex to analyze and implement.
A NoC interconnect may contain multiple physical networks. Over each physical network, there may exist multiple virtual networks, wherein different message types are transmitted over different virtual networks. In this case, at each physical link or channel, there are multiple virtual channels; each virtual channel may have dedicated buffers at both end points. In any given clock cycle, only one virtual channel can transmit data on the physical channel.
NoC interconnects often employ wormhole routing, wherein, a large message or packet is broken into small pieces known as flits (also referred to as flow control digits). The first flit is the header flit which holds information about this packet's route and key message level info along with payload data and sets up the routing behavior for all subsequent flits associated with the message. Optionally, one or more body flits follows the head flit, containing the remaining payload of data. The final flit is the tail flit which in addition to containing the last payload also performs some book keeping to close the connection for the message. In wormhole flow control, virtual channels are often implemented.
The physical channels are time sliced into a number of independent logical channels called virtual channels (VCs). VCs provide multiple independent paths to route packets, however they are time-multiplexed on the physical channels. A virtual channel holds the state needed to coordinate the handling of the flits of a packet over a channel. At a minimum, this state identifies the output channel of the current node for the next hop of the route and the state of the virtual channel (idle, waiting for resources, or active). The virtual channel may also include pointers to the flits of the packet that are buffered on the current node and the number of flit buffers available on the next node.
The term “wormhole” plays on the way messages are transmitted over the channels: the output port at the next router can be so short that received data can be translated in the head flit before the full message arrives. This allows the router to quickly set up the route upon arrival of the head flit and then opt out from the rest of the conversation. Since a message is transmitted flit by flit, the message may occupy several flit buffers along its path at different routers, creating a worm-like image.
A standard n×m mesh NoC can connect n×m cores and the maximum latency of n×m mesh NoC is n+m−1 hops, when the hosts at the two far end corners inter-communicate. To minimize the latency n and m must be chosen to be as close as possible, creating a more square like topology. In this case, as the network scales in size, the maximum latency is on the order of n1/2, where n is the total number of nodes in the NoC.
The present inventive concept provides for construction of a mesh based system interconnect that uses two key topology optimizations, namely virtual nodes, and hierarchical asymmetric mesh, to reduce the latency in number of hops compared to a standard mesh. An exemplary process to construct such mesh based system interconnects having lower latency in number of hops than a standard mesh is also provided.
Aspects of the present application may include a method, which involves, for a network on chip (NOC) configuration including a plurality of cores interconnected by a plurality of routers in a mesh arrangement, generating a plurality of virtual routers configured to connect ones of the plurality of routers having one or more unused ports; and configuring each of the plurality of virtual routers to connect to an unused port of a router from the ones of the plurality of routers having the one or more unused ports.
Aspects of the present application may include a computer readable storage medium storing instructions for executing a process. The instructions may involve, for a network on chip (NOC) configuration including a plurality of cores interconnected by a plurality of routers in a mesh arrangement, generating a plurality of virtual routers configured to connect ones of the plurality of routers having one or more unused ports; and configuring each of the plurality of virtual routers to connect to an unused port of a router from the ones of the plurality of routers having the one or more unused ports.
Aspects of the present application may include a method, which involves constructing a plurality of clusters, each of the clusters including a single router; for at least one of the plurality of clusters, connecting one or more cores to the single router of the at least one of the plurality of clusters; and connecting said single router of a first one of the plurality of clusters to said single router of a second one of the plurality of clusters.
Aspects of the present application may include a computer readable storage medium storing instructions for executing a process. The instructions may involve constructing a plurality of clusters, each of the clusters including a single router; for at least one of the plurality of clusters, connecting one or more cores to the single router of the at least one of the plurality of clusters; and connecting said single router of a first one of the plurality of clusters to said single router of a second one of the plurality of clusters.
a) and
a) illustrates a 4×4 standard mesh;
b) illustrates a hierarchical mesh according to a second example embodiment;
a) illustrates a hierarchical mesh according to another example of the second embodiment;
b) illustrates a hierarchical mesh according to an yet another example of the second embodiment;
The present inventive concept augments the standard mesh topology with virtual routers. Consider a case where we add additional routers at the mesh boundary and connect them to the unconnected boundary ports of the original routers at the mesh boundary, thereby expanding a n×m mesh to a (n+2)×(m+2) mesh as illustrated in
With virtual routers, the unused router ports of a standard mesh are utilized more effectively, thereby increasing the number of cores than can be connected to a n×m mesh from n×m to (n+2)×(m+2)−4. The maximum latency in number of hops remains the same as the original mesh, which is n+m−1. Thus, for a given number of cores that needs to be connected with mesh NoC, virtual routers can reduce the latency as well as the number of routers needed compared to a standard mesh. For example, to connect 21 nodes to a 5×5 standard mesh, at least 21 routers are needed, and maximum latency will be 5+5−1=9 hops. With virtual router support, we need a 3×3 original NoC mesh with 12 additional virtual routers, thus reducing the hardware cost to 9 routers, and latency to 3+3−1=5 hops.
Using virtual routers affects the routing. First, the number of bits needed to represent a node ID needs to be expanded. In a 3×3 standard mesh NoC, a node can be identified with 4-bit ID, 2 bits for an x-coordinate and 2 bits for a y-coordinate (assuming dimension based ID, which is useful in dimension ordered routing). With virtual routers, the dimension order will become 5×5, and with dimension based ID, we will need 3 bits for the x-coordinate and 3 bits for the y-coordinate to identify all nodes in the system. Routing needs to be done looking at the expanded node IDs. Second, when a virtual node receives and transmits a message, then a fixed dimension ordered route which is often used in a standard mesh cannot always be taken. In dimension ordered routing, routing is performed along the X or Y axis until the x- or y-coordinate of the destination node ID is reached, and then a single turn is made and the route is traversed along the other axis.
Consider a mesh designed such that all messages take an X-Y route, i.e. messages first traverse along X-axis, take a turn, and then traverse along Y-axis to reach to the destination. The default routing circuit at all routers upon receiving a message at any input port, looks up the destination ID, and forwards the message along the X-axis towards the destination if the x-coordinate of the destination router is not the same as the x-coordinate of the router, else along the Y-axis towards the destination. If we use virtual routers as illustrated in
The present inventive concept uses multi-turn based routing in a mesh NoC that may have virtual routers.
As an example, consider the case where up to three turns in the path are allowed. The turn can be encoded using 2 bits which indicate the direction of the next path. To encode the path length, the number of bits depends upon the longest straight path, e.g. for a mesh NoC of n×n original routers, we need ceiling(log2(n+1)) bits; n+1 is used instead of n because there can be one additional virtual router along the longest path. The turn and path length information will repeat three times to describe the entire path as shown below:
(first turn) (path length) (second turn) (path length) (third turn) (path length)
For a 3×3 original mesh with virtual routers (which can now connect up to 21 cores), this will need total of 12 bits to support up to three turns. When path contains less than three turns the unused paths lengths can be set to zero.
To summarize, using virtual routers reduces the latency in number of hops and may utilize the unused router ports of boundary routers more efficiently.
Another inventive concept referred to as a hierarchical mesh is provided to reduce the number of hop latency in a mesh NoC. Hierarchical mesh is orthogonal to virtual routers, and it will be presented in the context of a standard mesh (without virtual routers).
Consider a 4×4 standard mesh as illustrated in
In hierarchical mesh, since there may be multiple ejection ports at a router connected to the local cores, the multi-turn route information in messages also need to contain the output port ID at the last router along the path. If up to four cores are connected at a router then a 2-bit ejection port ID needed as part of the route information.
A hierarchical mesh is easy to place on a 2D chip, as illustrated by
The present inventive concept allows formation of partial mesh as well, wherein some clusters and routers of a full mesh may be omitted. In such cases, dimension ordered routing cannot be used, and multi-turn based routing may need to be used.
Each cluster may contain a different number of cores, based on which the radix of the router connecting cores within the cluster can be chosen. This leads to asymmetric clusters in a hierarchical mesh. A cluster is allowed to contain zero cores, in which case the router of the cluster will become a transit router, i.e., it will participate in message routing like normal routers, however will never inject or eject a new message in the network. Furthermore some inter-router links of the mesh may be omitted in which case alternative paths may need to be taken when standard path does not exist between a source and destination router. An example of hierarchical partial mesh with asymmetric cluster size, a transit router, and some omitted links is illustrated in
The server 1005 may also be connected to an external storage 1050, which can contain removable storage such as a portable hard drive, optical media (CD or DVD), disk media or any other medium from which a computer can read executable code. The server may also be connected an output device 1055, such as a display to output data and other information to a user, as well as request additional information from a user. The connections from the server 1005 to the user interface 1040, the operator interface 1045, the external storage 1050, and the output device 1055 may via wireless protocols, such as the 802.11 standards, Bluetooth® or cellular protocols, or via physical transmission media, such as cables or fiber optics. The output device 1055 may therefore further act as an input device for interacting with a user.
The processor 1010 may execute one or more modules. A router construction module 1011 may be configured to, for a network on chip (NOC) configuration involving a plurality of cores interconnected by a plurality of routers in a mesh arrangement, generate a plurality of virtual routers configured to connect ones of the plurality of routers having one or more unused ports; and configure each of the plurality of virtual routers to connect to an unused port of a router from the ones of the plurality of routers having the one or more unused ports. The router construction module 1011 may be further configured to configure each of the plurality of virtual routers with at least one of a register and a flow control logic between a host port and a router port of the virtual router, and a pass through logic facilitating a direct connection between the host port and the router port of the virtual router. The router construction module 1011 may also be further configured to connect a host to one of the plurality of virtual routers connected to a previously unused port of one of the plurality of routers.
The router construction module 1011 may also be further configured to construct a plurality of clusters, each of the clusters having a single router; for at least one of the plurality of clusters, connecting one or more cores to the single router of the at least one of the plurality of clusters; and connecting said single router of a first one of the plurality of clusters to said single router of a second one of the plurality of clusters.
The message management module 1012 may be configured to route a message through the NOC configuration by using multi-turn based routing in the mesh arrangement. The routing of the message may involve limiting a number of turns for the message and determining a path in the mesh arrangement based on the limiting.
To summarize, the inventive concept allows formation of hierarchical mesh, where clusters of one or more cores are directly connected to a local router, and the routers are connected in a mesh topology. Different clusters may contain different number of cores. There may exist transit routers, i.e., clusters with zero cores. Some clusters and routers of a standard full mesh may be omitted, and some standard inter-router links may also be omitted. Routing that takes a finite number of turns (between zero and a fixed constant) is used to provide the required connectivity.
Number | Name | Date | Kind |
---|---|---|---|
5432785 | Ahmed et al. | Jul 1995 | A |
5764740 | Holender | Jun 1998 | A |
5991308 | Fuhrmann et al. | Nov 1999 | A |
6003029 | Agrawal et al. | Dec 1999 | A |
6249902 | Igusa et al. | Jun 2001 | B1 |
6415282 | Mukherjea et al. | Jul 2002 | B1 |
6925627 | Longway et al. | Aug 2005 | B1 |
7065730 | Alpert et al. | Jun 2006 | B2 |
7318214 | Prasad et al. | Jan 2008 | B1 |
7590959 | Tanaka | Sep 2009 | B2 |
7725859 | Lenahan et al. | May 2010 | B1 |
7808968 | Kalmanek, Jr. et al. | Oct 2010 | B1 |
7917885 | Becker | Mar 2011 | B2 |
8050256 | Bao et al. | Nov 2011 | B1 |
8059551 | Milliken | Nov 2011 | B2 |
8099757 | Riedl et al. | Jan 2012 | B2 |
8136071 | Solomon | Mar 2012 | B2 |
8281297 | Dasu et al. | Oct 2012 | B2 |
8312402 | Okhmatovski et al. | Nov 2012 | B1 |
8448102 | Kornachuk et al. | May 2013 | B2 |
8492886 | Or-Bach et al. | Jul 2013 | B2 |
8541819 | Or-Bach et al. | Sep 2013 | B1 |
8543964 | Ge et al. | Sep 2013 | B2 |
8601423 | Philip et al. | Dec 2013 | B1 |
8635577 | Kazda et al. | Jan 2014 | B2 |
8667439 | Kumar et al. | Mar 2014 | B1 |
8717875 | Bejerano et al. | May 2014 | B2 |
20020071392 | Grover et al. | Jun 2002 | A1 |
20020073380 | Cooke et al. | Jun 2002 | A1 |
20020095430 | Egilsson et al. | Jul 2002 | A1 |
20040216072 | Alpert et al. | Oct 2004 | A1 |
20050147081 | Acharya et al. | Jul 2005 | A1 |
20060161875 | Rhee | Jul 2006 | A1 |
20070118320 | Luo et al. | May 2007 | A1 |
20070244676 | Shang et al. | Oct 2007 | A1 |
20070256044 | Coryer et al. | Nov 2007 | A1 |
20070267680 | Uchino et al. | Nov 2007 | A1 |
20080072182 | He et al. | Mar 2008 | A1 |
20080120129 | Seubert et al. | May 2008 | A1 |
20090070726 | Mehrotra et al. | Mar 2009 | A1 |
20090268677 | Chou et al. | Oct 2009 | A1 |
20090313592 | Murali et al. | Dec 2009 | A1 |
20100040162 | Suehiro | Feb 2010 | A1 |
20110035523 | Feero et al. | Feb 2011 | A1 |
20110060831 | Ishii et al. | Mar 2011 | A1 |
20110072407 | Keinert et al. | Mar 2011 | A1 |
20110154282 | Chang et al. | Jun 2011 | A1 |
20110235531 | Vangal et al. | Sep 2011 | A1 |
20110276937 | Waller | Nov 2011 | A1 |
20110307734 | Boesen et al. | Dec 2011 | A1 |
20120022841 | Appleyard | Jan 2012 | A1 |
20120023473 | Brown et al. | Jan 2012 | A1 |
20120026917 | Guo et al. | Feb 2012 | A1 |
20120110541 | Ge et al. | May 2012 | A1 |
20120155250 | Carney et al. | Jun 2012 | A1 |
20130051397 | Guo et al. | Feb 2013 | A1 |
20130080073 | de Corral | Mar 2013 | A1 |
20130103369 | Huynh et al. | Apr 2013 | A1 |
20130136129 | Locatelli et al. | May 2013 | A1 |
20130151215 | Mustapha | Jun 2013 | A1 |
20130159944 | Uno et al. | Jun 2013 | A1 |
20130174113 | Lecler et al. | Jul 2013 | A1 |
20130182606 | So et al. | Jul 2013 | A1 |
20130207801 | Barnes | Aug 2013 | A1 |
20130219148 | Chen et al. | Aug 2013 | A1 |
20130263068 | Cho et al. | Oct 2013 | A1 |
20130326458 | Kazda et al. | Dec 2013 | A1 |
20140068132 | Philip et al. | Mar 2014 | A1 |
20140092740 | Wang et al. | Apr 2014 | A1 |
20140098683 | Kumar et al. | Apr 2014 | A1 |
20140115218 | Philip et al. | Apr 2014 | A1 |
20140115298 | Philip et al. | Apr 2014 | A1 |
Number | Date | Country |
---|---|---|
103684961 | Mar 2014 | CN |
2014059024 | Apr 2014 | WO |
Entry |
---|
Abts, D., et al., Age-Based Packet Arbitration in Large-Radix k-ary n-cubes, Supercomputing 2007 (SC07), Nov. 10-16, 2007, 11 pgs. |
Das, R., et al., Aergia: Exploiting Packet Latency Slack in On-Chip Networks, 37th International Symposium on Computer Architecture (ISCA '10), Jun. 19-23, 2010, 11 pgs. |
Ebrahimi, F, et al., Fairness via Source Throttling: A Configurable and High-Performance Fairness Substrate for Multi-Core Memory Systems, ASPLOS '10, Mar. 13-17, 2010, 12 pgs. |
Grot, B., Preemptive Virtual Clock: A Flexible, Efficient, and Cost-Effective QOS Scheme for Networks-on-Chip, Micro '09, Dec. 16, 2009, 12 pgs. |
Grot, B., Kilo-NOC: A Heterogeneous Network-on-Chip Architecture for Scalability and Service Guarantees, ISCA '11, Jun. 4-8, 2011, 12 pgs. |
Grot, B., Topology-Aware Quality-of-Service Support in Highly Integrated Chip Multiprocessors, 6th Annual Workshop on the Interaction between Operating Systems and Computer Architecture, Jun. 2006, 11 pgs. |
Jiang, N., et al., Performance Implications of Age-Based Allocations in On-Chip Networks, CVA MEMO 129, May 24, 2011, 21 pgs. |
Lee, J. W., et al., Globally-Synchronized Frames for Guaranteed Quality-of-Service in On-Chip Networks, 35th IEEE/ACM International Symposium on Computer Architecture (ISCA), Jun. 2008, 12 pgs. |
Lee, M. M., et al., Approximating Age-Based Arbitration in On-Chip Networks, PACT '10, Sep. 11-15, 2010, 2 pgs. |
Li, B., et al., CoQoS: Coordinating QoS-Aware Shared Resources in NoC-based SoCs, J. Parallel Distrib. Comput., 71 (5), May 2011, 14 pgs. |
International Search Report and Written Opinion for PCT/US2013/064140, Jan. 22, 2014, 9 pgs. |
International Search Report and Written Opinion for PCT/US2014/012003, Mar. 26, 2014, 9 pgs. |
International Search Report and Written Opinion for PCT/US2014/012012, May 14, 2014, 9 pgs. |
Ababei, C., et al., Achieving Network on Chip Fault Tolerance by Adaptive Remapping, Parallel & Distributed Processing, 2009, IEEE International Symposium, 4 pgs. |
Beretta, I, et al., A Mapping Flow for Dynamically Reconfigurable Multi-Core System-on-Chip Design, IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, Aug. 2011, 30(8), pp. 1211-1224. |
Gindin, R., et al., NoC-Based FPGA: Architecture and Routing, Proceedings of the First International Symposium on Networks-on-Chip (NOCS'07), May 2007, pp. 253-262. |
Yang, J., et al., Homogeneous NoC-based FPGA: The Foundation for Virtual FPGA, 10th IEEE International Conference on Computer and Information Technology (CIT 2010), Jun. 2010, pp. 62-67. |
Number | Date | Country | |
---|---|---|---|
20140177473 A1 | Jun 2014 | US |