System and method for editing a network-on-chip (NOC)

Abstract

A system and method implemented by tool is disclosed. The tool receives input of a network-on-chip (NoC) and the NoC's desired connectivity and efficiently guides the designer through interactive NoC topology editing sessions to ensure the obtained network is both complete and correct during topology creation or modification.

Description

FIELD OF THE INVENTION

The present technology is in the field of computer system design and, more specifically, tool that allows editing of networks-on-chip.

BACKGROUND

Multiprocessor systems have been implemented in systems-on-chips (SoCs) that communicate through network-on-chips (NoCs). The SoCs include instances of sources (initiators) intellectual properties (IPs) and destination (targets) IPs. Transactions are sent from a source to one or more destinations using industry-standard protocols. Source, connected to the NoC, sends a request transaction to a destination, using an address to select the destination. The NoC decodes the address and transports the request from source to the destination. The destination handles the transaction and sends a response transaction, which is transported back by the NoC to source.

Typically, a NoC description is generated using a synthesis tool during the design process. The tool generates a NoC from a set of constraints. If changes are made, then the tool will have to be restarted and re-executed. One example of a traditional approach is selecting a new NoC element and adding it to the set of existing NoC elements. The user would then make and/or re-route connections between existing NoC elements. The user would then define specific routes through the new NoC element if there is ambiguity about the paths to take from a source to a destination.

Every time there is a change to the NoC topology or the input constraints change, the tool is restarted or the synthesis is re-executed. As such, there is a risk of giving a completely different solution from one run to the next, even if the changes are limited or minor. This is due to the nature of the network synthesis process, which typically uses a constraint solver approach to minimizing metrics, and the constraint solver may find very different solutions in response to minor changes or slightly different set of constraints. As such, the tool may find a different solution every time it runs for minor changes or slightly different constraints. Thus, the tool has a reduced usability when used by a SoC designer to automatically create the NoC. During the design time of SoC, the constraints change and evolve. If the tool generates substantially different results each time the tool runs and every time the user makes a small change, then this will lead to the designer being unable to reuse some of the implementation work already done. Therefore, what is needed is a solution that will take as input the NoC desired connectivity and efficiently guide the designer through interactive topology editing sessions at each step of topology creation or modification, to ensure the obtained network is both complete and correct.

SUMMARY

A solution is provided that will guide a designer through interactive topology editing sessions. The invention applies to tool that permits creating and modifying networks-on-chip (NoC or NoCs) topology. NoC topology includes a set of components that exist in the NoC, with the components' configuration, on one hand, and, on the other hand, a set of paths through these components describing the precise route between a source of traffic and a destination of traffic that needs to be logically connected.

For example, consider the situation when the NoC has already been generated from a set of constraints. The NoC components use an internal NoC transport protocol to communicate with each other, typically based on the transmission of packets. NIUs convert the protocol used by the attached system-on-chip (SoC) into the transport protocol used inside the NoC. Switches route flows of traffic between sources and destinations. Adapters deal with various conversions between data width, clock and power domains. Buffers are used to insert pipelining elements to span long distances, or to store packets to deal with rate adaptation between fast senders and slow receivers or vice-versa. NoCs are implemented in SoCs with digital logic, such as logic gates and sequential elements (flip-flops) The result has been processed through the ASIC design flow with logic synthesis and place and route steps done. The steps typically take a lot of time, e.g. multiple days. After this first generation, it is decided to remove a component from the SoC, which result in slight modification of the floorplan and the connectivity. The tool generating the NoC is run again with the updated constraints. The tool gives a completely different result compared to the first run. As such, all the previous work on logic synthesis and place and route needs to be done again from scratch, even if the constraint change was very small. This is very costly for the project.

When creating or modifying the topology of a NoC by hand, either through a Graphical User Interface (GUI), or programmatically through a set of commands given to a tool, the NoC designer tries to ensure that the design choices (actions) result in a NoC that implements the desired functionality within the constraints. One of the key functionalities of a NoC is connectivity: the specification that a particular source of traffic, which includes transactions, is able to send packets to a particular destination. For large networks with many components, it can be difficult for the designer to ensure that the network is correct and implements effectively all the required paths between all sources of traffic and all the destinations.

In addition to implementing the desired connectivity where no paths are missing when they are required, the NoC topology shall also follow some rules, including constraints, regarding connection of the NoC elements with each other. These rules depend on the NoC technology used. One example is that no more than a single transport interface shall be used in components such as network interface units (NIUs) or adapters. Another example or that switches shall never exceed some specific size of ingress or egress ports numbers, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more fully understand the invention, reference is made to the accompanying drawings or figures. The invention is described in accordance with the aspects and embodiments in the following description with reference to the drawings or figures (FIG.), in which like numbers represent the same or similar elements. Understanding that these drawings are not to be considered limitations in the scope of the invention, the presently described aspects and embodiments and the presently understood best mode of the invention are described with additional detail through use of the accompanying drawings.

FIG. 1 Illustrates a logical view of a NoC with various elements to create a netlist in accordance with the various aspects and embodiments of the invention.

FIG. 2 illustrates a process for guiding a designer through interactive topology editing sessions in accordance with the various aspects and embodiments of the invention.

FIG. 3 illustrates high level connectivity map or chart for a NoC topology in accordance with the various aspects and embodiments of the invention.

FIG. 4 illustrates the NoC of FIG. 3 highlighting routes from one source to four destinations in accordance with the various aspects and embodiments of the invention.

FIG. 5 illustrates modification of FIG. 4 in accordance with the various aspects and embodiments of the invention.

FIG. 6. illustrates modification of FIG. 5 in accordance with the various aspects and embodiments of the invention.

FIG. 7 illustrates modification of FIG. 6 in accordance with the various aspects and embodiments of the invention.

FIG. 8 illustrates modification of FIG. 7 in accordance with the various aspects and embodiments of the invention.

FIG. 9 illustrates modification of FIG. 8 by the user deleting an insertion point causing an illegal route that needs correcting in accordance with the various aspects and embodiments of the invention.

DETAILED DESCRIPTION

The following describes various examples of the present technology that illustrate various aspects and embodiments of the invention. Generally, examples can use the described aspects in any combination. All statements herein reciting principles, aspects, and embodiments as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents and equivalents developed in the future, i.e., any elements developed that perform the same function, regardless of structure.

It is noted that, as used herein, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. Reference throughout this specification to “one aspect,” “an aspect,” “certain aspects,” “various aspects,” or similar language means that a particular aspect, feature, structure, or characteristic described in connection with any embodiment is included in at least one embodiment of the invention.

Appearances of the phrases “in one embodiment,” “in at least one embodiment,” “in an embodiment,” “in certain embodiments,” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment or similar embodiments. Furthermore, aspects and embodiments of the invention described herein are merely exemplary, and should not be construed as limiting of the scope or spirit of the invention as appreciated by those of ordinary skill in the art. The disclosed invention is effectively made or used in any embodiment that includes any novel aspect described herein. All statements herein reciting aspects and embodiments of the invention are intended to encompass both structural and functional equivalents thereof. It is intended that such equivalents include both currently known equivalents and equivalents developed in the future.

The terms “path” and “route” are used interchangeable herein. Paths or routes includes and are made up of any combination of nodes (nodes are also referred to herein as switches) and edges (edges are also referred to herein as links), along which data travels form source to destination (sink or target). According to various aspects and embodiments of the invention, a path or a route is an ordered list of NoC components along a given direction from a source to a destination. As used herein, a “master,” “origin,” “initiator,” and “source node” refer to intellectual property (IP) blocks, units, or modules that initiate or send a transaction. The terms “master” and “initiator” and “source node” are used interchangeably within the scope and embodiments of the invention. As used herein, a “slave,” a “target,” “destination,” and “sink node” refer to IP blocks that receive and handle transaction and, in some instances, produce or generate a response. The terms “slave” and “target” and “destination” and “sink node” are used interchangeably within the scope and embodiments of the invention. As used herein, a transaction may be a request transaction or a response transaction. Examples of request transactions include write request and read request.

As used herein, a node is defined as a distribution point or a communication endpoint that is capable of creating, receiving, and/or transmitting information over a communication path or channel. A node may refer to any one of the following: switches, splitters, mergers, buffers, and adapters. As used herein, splitters and mergers are switches; not all switches are splitters or mergers. As used herein and in accordance with the various aspects and embodiments of the invention, the term “splitter” describes a switch that has a single ingress port and multiple egress ports. As used herein and in accordance with the various aspects and embodiments of the invention, the term “merger” describes a switch that has a single egress port and multiple ingress ports.

Referring now to FIG. 1, a network-on-chip (NoC) 100 is shown according to various aspects and embodiments of the invention. The NoC 100 includes elementary network components (elements), such as source network interface units (SNIUs) 102, switches 104, adapter 106 (only one is shown for clarity), buffer 108 (only one is shown for clarity), and destination network interface units (DNIUs) 110. The NoC 100 components use an internal NoC transport protocol to communicate with each other for transmission of packets. SNIU 102 are converting the protocol that is used by the attached IP blocks of the system-on-chip (SoC) into the transport protocol used inside the NoC 100.

Switches 104 route flows of traffic between source and destinations. Adapters 106 manage various conversions between data width, clock and power domains. Buffers 108 insert pipelining elements to span long distances, or to store packets to deal with rate adaptation between fast senders and slow receivers or slow senders and fast receivers. DNIUs 110 convert transport protocol used in the NoC 100 back into protocol used by the SoC. NoC 100 is implemented with digital logic, such as logic gates and sequential elements (flip-flops).

Referring now to FIG. 2 and FIG. 1, a flow process is shown for how a user interacts with tool to create the NoC 100 topology according to various aspects and embodiments of the invention. Steps 202, 206, and 212 represent user inputs. Steps 204, 208, and 210 represent actions performed by the tool, which allows a user to interact with the tool to create, configure and modify NoC topology.

At step 202 the process 200 starts by the user's definition of the required connectivity of the NoC 100. The user describes all sources and all destinations of traffic that are in communication with the NoC 100. The user also describes what traffic source shall reach which traffic destination. This description is done using the NoC 100 configuration tool and exists in a non-transitory computer readable form, either in memory or on a computer file.

In step 204, the tool creates an initial topology based on the user's inputs in accordance with some aspects and embodiments of the invention. At step 204, the tool automatically creates an initial topology based on the user's inputs in accordance with some aspects and embodiments of the invention. The initial topology includes, and is not limited by, the number of the network interface units 102 that are required to support sources and destinations of traffic. Typically, this first network is complete with all source to destination paths existing, even though some of which may be illegal. For example, it is illegal for multiple connections go out of or into network interface units (NIU), 102 which can only support one connection in accordance with some aspects and embodiments of the invention.

At step 206, the user selects and edits a set of routes in the NoC 100, by specifying NIU 102 sources of traffic and the NIU 110 destinations for the traffic. The user then selects which route changes through the NoC 100 need to be done. The user can select one or more routes to be changed. If the set or routes has more than one route, all selected routes shall have one or more elements in common. The user then selects an element that all of the routes have in common and chooses the selected element to be the insertion point.

When the user performs an editing operation, the user can either: (1) insert a new NoC 100 element on each selected route after the insertion point; (2) insert a new NoC 100 element on each selected route before the insertion point; (3) delete the insertion point from every route; or (4) replace the insertion point by another existing element. This is not a complete list of the operations that the user can execute on the routes in the NoC 100; other operations are possible.

At step 208, the tool automatically updates the NoC 100 netlist based upon the user's edits in accordance with some aspects and embodiments of the invention.

At step 210, the tool automatically finds and reports on rule violations in the netlist, which are based on the constraints and requirements. In accordance with some aspects and embodiments of the invention, a rule violation exists, and is considered illegal, when more than one connection goes into or out of network interface units that can only support one connection. If an illegal NoC 100 route is created, the tool alerts the user that a rule violation exists in one or more routes. In accordance with some aspects and embodiments of the invention, corrections are made based on the alerts. At step 212 the tool determines if the user is done with editing and determines if NoC route editing is complete or not complete. The user corrects the error(s) by completing actions listed in the third step 206. If at step 212 editing is not complete, for example because of errors or rule violations, then the process returns to step 210. At step 212, if no violations of a rule are found, the tool indicates to the user that editing of the NoC 100 routes is complete 212 and the process ends or is done.

Referring now to FIG. 3 and FIG. 2, according to various aspects and embodiments of the invention, a connectivity map or connectivity chart 300 is shown. The connectivity chart 300 represents the initial NoC topology based upon the users definition of connectivity from step 202 and the tool's creation of initial topology 204. The result creates four sources of traffic 302, 304, 306, and 308 of the chart 300 and four destinations for traffic 310, 312, 314, and 316 represented on the right margin of the chart 300. In accordance with some aspects and embodiments of the invention, a route exists between all four sources 302, 304, 306, 308 extending to all four destinations 310, 312, 314, 316. This is an initial creation of topology. This topology may have some portions that are illegal because multiple connections go out of each source of traffic 302, 304, 306, 308 and into each destination of traffic 310, 312, 314, 316. The connectivity that this NoC can be shown or illustrated as a matrix. The matrix would show all sources being able to send traffic to all destinations. In accordance with some aspects and embodiments of the invention, the chart 300 represents an illegal starting point for the NoC 100 topology; the tool edits and creates the desired NoC 100 traffic routing outcome as the user provides additional inputs and changes.

Referring now to FIG. 4, FIG. 3, and FIG. 2, according to various aspects and embodiments of the invention, a chart 400 is shown to indicate the result of an initial application of the tool to the illegal route configuration indicated in the chart 300. According to various aspects and embodiments of the invention, there are illegal routes in FIG. 3 because there is more than one output for the sources, such as source 302. In this example, the user has implemented user editing of illegal route configuration in the chart 300 with the tool editing from step 206. Next, the tool automatically updates (at step 208) the NoC netlist as indicated in chart 400. After an initial edit (at step 206) of the routes, four routes are created extending from 302, one to each of the four destinations 310, 312, 314, 316. In accordance with some aspects and embodiments of the invention, a matrix for the chart 400 can indicate the selection of all routes from route source 302. The tool evaluates this NoC configuration (at step 210) and determine if this route configuration is still illegal; for example and in accordance with some aspects and embodiments of the invention, it is illegal because multiple routes originate from a single source of traffic 302. The tool reports the rules violation to the user in accordance with some aspects and embodiments of the invention. The user can again edit the operation of the routes (at step 206).

In accordance with some aspects and embodiments of the invention, as the user modifies the routes in the NoC, and the tool infers the netlist of the NoC. Routes are ordered lists of NoC units that exist along a communication path between a source of traffic and a destination of traffic. The NoC netlist is the set of connections (wires) that exists between the NoC elements. The user selects a set of routes to modify first, then performs an editing operation.

After the user operation, the tool infers automatically the new elements required and the connections between the NoC elements (the netlist). If some NoC elements assembly rules are violated, the tool flags them to the user and the user can fix the errors. During step-by-step changes to the topology, there can be (and the topology may be) in an illegal state after a given step or change. The user is provided the error or illegal state information. The user is then able to fix the error during subsequent steps, for example by making additional changes. If the editing session is complete, the process exits, else the user proceeds with the next editing operation. In one embodiment, the user shall be able to save an editing session on a computer file, and resume it later.

Referring now to FIG. 5, FIG. 4, and FIG. 2, according to various aspects and embodiments of the invention, a connectivity chart 500 representing a new NoC topology, which is created after the editing procedure performed on the NoC represented in chart 400, is shown. In accordance with some aspects and embodiments of the invention, the user performs an editing operation, which can be: inserting a new NoC element on each selected route after the insertion point; inserting a new NoC element on each selected route before the insertion point; deleting the insertion point from every route; and/or replacing the insertion point by another existing element. This list is not complete and other operations are possible. The various changes to the NoC topology, such as insertion, replacement, and deletion operations are within the scope of the invention. After the operation on routes is done, the tool automatically infers the update to the NoC topology and generates the netlist that is needed, which includes any one or more of:

• • (1) a new component is added to the topology;
  • (2) a deleted component is removed from the topology; and
  • (3) no longer used components are removed from the topology.

Connections between NoC components are updated to ensure the newly defined routes are implemented. In accordance with some aspects and embodiments of the invention loops in the resulting routes, such as when the same component is found multiple times in a route, are removed. In according to various aspects and embodiments of the invention, the tool is able to create more than just the network interface units, for instance create an initial legal topology through some simple heuristic or topology synthesis.

Referring now to FIG. 4, the user identifies a source or node for which the user modifies or issues commands to modify the NoC topology from this initial NoC topology. For example, the user selects all routes initiating from the same source. The user then determines or selects the routes to modify. The user selects the set of routes through the NoC, onto which the change needs to be done. In this non-limiting example, routes from source 302 are selected. The selected source 302 (and its set of routes) can have one or more routes according to various aspects and embodiments of the invention. If source has more than one route, all selected routes shall have one or more elements (in this example source) in common.

Referring now to FIG. 5, source 302 is identified and an element selected—in this example a switch—and an insertion point is identified according to various aspects and embodiments of the invention. In this example, there are four routes from source 302. Also, an insertion point for a new element, such as a switch, is identified. From the insertion point of switch 502, the user selects all routes going from source 302 to a destination that receives traffic from source 302, as shown by the routes. The tool guides the user to use an insertion point for inserting switch 502. All routes from source 302 are now routed from switch 502. As shown, the tool automatically modifies the four connections or routes going from source 302 to its four destinations 310, 312, 314, and 316 into a single connection between source 302 and switch 502. Then from switch 502 to the four destinations 310, 312, 314, and 316 of traffic. According to various aspects and embodiments of the invention, these routes have not been modified directly by the user. According to various aspects and embodiments of the invention, the tools inferred the routes considering the required connectivity and the changes to the routes performed by the user.

Referring now to FIG. 6, a replace operation is shown according to various aspects and embodiments of the invention. Insertion points are identified for each source 304, 306, and 308, similar to the process for switch 502 of FIG. 5. The tool is capable of identifying and generating an insertion point for each route emerging from each source 304, 306, and 308 in order to generate a single route emerging from each source 304, 306, and 308 and connecting to a new NoC element, such as a switch, similar to the process disclose in FIG. 5 with respect to locating the insertion point and inserting switch 502.

From the insertion point of switch 502, the user selects all routes going from source 302 and switch 502 to any destination 310, 312, 314, and 316. The tool guides the user to use an insertion point for inserting switches between switch 502 and destination sources 310, 312, 314, and 316. All routes from source 302 are now routed through switch 502 and switches 604, 606, 608, and 610. Thus, the routes emerging from switch 502 are considered and insertion points identified as needed. Thus, according to various aspects and embodiments of the invention, routes to (and from) switch 502 are selected along with an insertion point for those routes. The resulting example, shown for source 302, is the routes from source 302 to switch 502, to switch 604, and the destination 310. Additionally, the resulting example, shown for source 302, is the route from source 302 to switch 502, to switch 606, and the destination 312. Additionally, the resulting example, shown for source 302, is the route from source 302 to switch 502, to switch 606, and the destination 312. Additionally, the resulting example, shown for source 302, is the route from source 302 to switch 502, to switch 608, and the destination 314. Additionally, the resulting example, shown for source 302, is the route from source 302 to switch 502, to switch 608, and the destination 316.

Referring now to FIG. 7, a chart 700 is shown wherein the user replaces switch 502 at the insertion point by a new NoC element, for example switch 702. In this non-limiting example, the insertion point is now the location to where source 302 and source 304 send traffic. According to various aspects and embodiments of the invention, the tool automatically removes the no longer required element, such as switch 502 because no routes go through it anymore. The tool also handles all the connections to switch 502 by removing and replacing with one connection or route between source 302 and switch 702. Additionally, all routes between switch 502 and switches 604, 606, 608, and 610 are dropped or removed. There is also a route from source 304 o switch 702. Thus, there are now routes from switch 702 to each of switches 604, 606, 608, and 610. According to various aspects and embodiments of the invention, the routes for all other switches are handled in a similar manner. According to various aspects and embodiments of the invention, the tool provides information to and queries the user before removing the no longer required element and inserting new element.

Referring now to FIG. 8, according to various aspects and embodiments of the invention, a chart 800 shown where the user selects a single traffic route for further modification, for example the route between source 302 and destination 312. The other traffic routes originating from source 302 are also shown and are not discussed in this specific example. The tool analyzes the traffic flow from source 302, to switch 702, to switch 606, to destination 312. The insertion points for this route include switch 702 and switch 606. The tool determines if there are a rule violations and provides the information, if any, to the user through a graphical user interface or similar device. According to various aspects and embodiments of the invention, the user may keep this representation and the tool can produce the netlist. According to various aspects and embodiments of the invention, the user may further reduce the insertion point by deleting the insertion point 702.

Referring now to FIG. 9, a chart 900 is shown wherein the user deletes the insertion point at switch 702 for the path from source 302 because the insertion point (for source 302) was combined with the insertion point that already exists this location (for source 304 that has an insertion point), for the selected route discussed in FIG. 8. The tool now generates or identifies a route 902 and adds route 902 (new insertion point for source 302), which is at switch 606. The route 902 connects source 302 to switch 606. Source 302 now has two routes: 302 and 902. Additionally, if the insertion point (for source 302) was removed from the selected route, switch 702 is not deleted because there are other routes going through it. The resulting NoC topology is illegal for this non-limiting example because it only supports one connection out of a source of traffic. The rule violation can be indicated to the user on a display with a color coding. Although there is a rule violation or the route is illegal, it is perfectly normal that in the process of editing its topology the user ends up in transient illegal states, which the user will be prompted to fix. According to various aspects and embodiments of the invention, the user may add a switch to all routes from source 302 and routes after. According to various aspects and embodiments of the invention, the user inserts (or allows the tool to insert) the route 902 using a new insertion point for the source 302 at the switch 606.

According to various aspects and embodiments of the invention, the tool is adapted for handling only sub-sections of the network on-chip. According to various aspects and embodiments of the invention, the tool is adapted to modify more than one NoC, wherein the NoC are interconnected and within a single chip or across multiple connected chips.

Certain methods according to the various aspects of the invention may be performed by instructions that are stored upon a non-transitory computer readable medium or memory and executed by a processor. The non-transitory computer readable medium stores code including instructions that, if executed by one or more processors, would cause a system or computer to perform steps of the method described herein. The non-transitory computer readable medium includes: a rotating magnetic disk, a rotating optical disk, a flash random access memory (RAM) chip, and other mechanically moving or solid-state storage media. Any type of computer-readable medium is appropriate for storing code comprising instructions according to various example.

Certain examples have been described herein and it will be noted that different combinations of different components from different examples may be possible. Salient features are presented to better explain examples; however, it is clear that certain features may be added, modified, and/or omitted without modifying the functional aspects of these examples as described.

Some examples are one or more non-transitory computer readable media arranged to store such instructions for methods described herein. Whatever machine holds non-transitory computer readable media comprising any of the necessary code may implement an example. Some examples may be implemented as: physical devices such as semiconductor chips; hardware description language representations of the logical or functional behavior of such devices; and one or more non-transitory computer readable media arranged to store such hardware description language representations. Descriptions herein reciting principles, aspects, and embodiments encompass both structural and functional equivalents thereof. Elements described herein as coupled have an effectual relationship realizable by a direct connection or indirectly with one or more other intervening elements.

Practitioners skilled in the art will recognize many modifications and variations. The modifications and variations include any relevant combination of the disclosed features. Descriptions herein reciting principles, aspects, and embodiments encompass both structural and functional equivalents thereof. Elements described herein as “coupled” or “communicatively coupled” have an effectual relationship realizable by a direct connection or indirect connection, which uses one or more other intervening elements. Embodiments described herein as “communicating” or “in communication with” another device, module, or elements include any form of communication or link and include an effectual relationship. For example, a communication link may be established using a wired connection, wireless protocols, near-filed protocols, or RFID.

To the extent that the terms “including”, “includes”, “having”, “has”, “with”, or variants thereof are used in either the detailed description and the claims, such terms are intended to be inclusive in a similar manner to the term “comprising.”

The scope of the invention, therefore, is not intended to be limited to the exemplary embodiments and aspects that are shown and described herein. Rather, the scope and spirit of the invention is embodied by the appended claims.

Claims

1. A method comprising: receiving a description of a network-on-chip (NoC) connectivity, including: receiving a list of sources of traffic; andreceiving a list of destinations of traffic;creating an initial NoC topology chart showing routes for traffic between each source and each of the source's respective destinations;receiving user input for changes to at least one route;determining an insertion point for a NoC element;inserting the NoC element at the insertion point;updating the initial NoC topology to generate a new NoC topology that includes the NoC element at the insertion point;analyzing the new NoC topology for rule violations; andreporting the rule violation to a user.

2. The method of claim 1, wherein the description used to create an initial NoC topology includes a plurality of network interface units needed by each source and destination of traffic.

3. The method of claim 2, wherein the NoC topology includes required direct connections as part of the routes.

4. The method of claim 1, further comprising generating a netlist for the new NoC topology.

5. The method of claim 1, wherein the user input includes electing one or more routes to modify.

6. The method of claim 1, wherein the user input includes selecting a plurality of routes for editing such that all of the selected plurality of routes for editing have at least one element in common.

7. The method of claim 1 further comprising: receiving, as input from the user, a route to modify;identifying at least one common element in a route to modify;selecting the insertion point along the route.

8. The method of claim 1, further comprising performing an editing operation on a set of selected routes and the insertion point, wherein the editing operation includes at least one of: inserting a new element after the insertion point;inserting a new element before the insertion point;replacing the insertion point by another NoC element; anddeleting the insertion point.

9. The method of claim 1 further comprising automatically inferring, from a set of routes selected for editing, the changes required to the initial NoC topology including at least one of: removing elements no longer on any routes;adding new elements; andrewiring interconnections between elements to implement the required physical connectivity between NoC elements.

10. The method of claim 9 further comprising generating a netlist.

11. A system comprising: memory for storing code;a display; anda processor in communication with the memory and the display, wherein the processor executes the code to cause the system to: receive connectivity information for a network-on-chip (NoC) including sources and destinations;create an initial NoC topology chart for traffic between each source and each of the source's respective destinations;receive at least one user input identifying at least one change to the initial NoC topology;determine an insertion point for a NoC element based on the at least one change;inserts the NoC element at the insertion point;generate a new NoC topology by updating the initial NoC topology having the NoC element at the insertion point;analyzing the new NoC topology for rule violations; andreporting the rule violation to a user.

12. The system of claim 11, wherein the processor executes the code to further cause the system to generate a netlist for the new NoC topology.