Topology-Driven Structured Trunk Routing

Abstract

SOLUTION: A command that accepts multiple user input through various command options encapsulates and implements multiple original software algorithms that convert trunking design intent, expressed via the command options, into trunks on multiple layers of a process technology node. Once executed, the command generates shapes of trunks of specified topology on specified layers. The command includes a set of options to generate a simple or complex trunking topology. The command accepts topology, set of zones, nets and many other options that the user provides to the command to yield trunks of a desired topology.EFFECT: A topology description is relative, thus, it can be easily adjusted as design changes. The command together with its options represents trunk creation intent.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] High-speed and analog / mixed-signal designs often require custom routing topologies to ensure power, performance, and area (PPA) targets and time to market are met. Aggressive scaling, complex Design Rule Checking (DRC) rules, and metal sharing scenarios have increased complexity. Existing solutions cannot achieve the required design efficiency. Significant flow innovation is needed to enable rapid prototyping and "what-if" analysis with changes to floorplans, reusability, and scalability throughout the design cycle. [Brief explanation of the drawings]

[0002] Embodiments of the present disclosure will be more fully understood from the detailed description given below and from the accompanying drawings, which illustrate various embodiments of the present disclosure, but which should not be construed as limiting the present disclosure to the embodiments given, but are merely for purposes of illustration and understanding. [Figure 1] FIG. 1 illustrates a flowchart of a method for generating an intent-driven trunk topology according to some embodiments. [Figure 2] FIG. 2 illustrates the topology of vertical and horizontal tracks displayed in relation to the current design, according to some embodiments. [Figure 3A] FIG. 3A illustrates a set of two topologies with two gutters having different track plans, according to some embodiments. [Figure 3B] FIG. 3B illustrates a set of two topologies with two gutters having different track plans, according to some embodiments. [Figure 4] FIG. 4 shows an example of two zones with a straight boundary, according to some embodiments. [Figure 5A] FIG. 5A illustrates various track porosities, according to some embodiments. [Figure 5B] FIG. 5B illustrates various track porosities, according to some embodiments. [Figure 5C] FIG. 5C illustrates various track porosities, according to some embodiments. [Figure 6] FIG. 6 shows zones with vertical and horizontal tracks numbered for the zones, according to some embodiments. [Figure 7A] FIG. 7A illustrates track enumeration when the zones are cells and the cells are flipped across the y-axis, according to some embodiments. [Figure 7B] FIG. 7B illustrates track enumeration when the zones are cells and the cells are flipped across the y-axis, according to some embodiments. [Figure 8] FIG. 8 illustrates a five-point and four-segment Manhattan path with minimum coordinates for defining a topology, according to some embodiments. [Figure 9] FIG. 9 illustrates a topology specification according to some embodiments. [Figure 10] FIG. 10 illustrates a topology specification according to some embodiments. [Figure 11] FIG. 11 illustrates a topology specification according to some embodiments. [Figure 12] FIG. 12 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 13] FIG. 13 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 14] FIG. 14 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 15] FIG. 15 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 16] FIG. 16 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 17] FIG. 17 illustrates applying a topology to a net with stepping, according to some embodiments. [Figure 18] FIG. 18 illustrates a topology of a single segment from "no-where" to "no-where" in a zone, according to some embodiments. [Figure 19] FIG. 19 illustrates a multi-segment topology in a zone, according to some embodiments. [Figure 20] FIG. 20 illustrates a multi-segment topology that starts at an edge and stops at a track intersection, according to some embodiments. [Figure 21] FIG. 21 illustrates a multi-segment topology starting from an edge and stopping at the edge of a zone, according to some embodiments. [Figure 22] FIG. 22 illustrates a multi-segment topology that starts and stops on an edge along the pin centerline, according to some embodiments. [Figure 23] FIG. 23 illustrates a multi-segment topology starting at an edge, stopping at a pin, and then continuing to the edge, according to some embodiments. [Figure 24] FIG. 24 illustrates a multi-segment topology starting on an edge and referencing another edge of a zone, according to some embodiments. [Figure 25] FIG. 25 illustrates a multi-segment topology referencing a track with a topology description according to some embodiments. [Figure 26] FIG. 26 illustrates a multi-segment topology referencing gutters with topology information, according to some embodiments. [Figure 27A] FIG. 27A illustrates stair step topologies with track sharing and shielding, respectively, according to some embodiments. [Figure 27B] FIG. 27B illustrates stair step topologies with track sharing and shielding, respectively, according to some embodiments. [Figure 28] FIG. 28 illustrates a swizzle topology in a pair of net topologies, according to some embodiments. [Figure 29A] FIG. 29A illustrates a flowchart of a method for generating intent-driven trunk topologies, according to some embodiments. [Figure 29B] FIG. 29B illustrates a flowchart of a method for generating intent-driven trunk topologies, according to some embodiments. [Figure 29C] FIG. 29C illustrates a flowchart of a method for generating intent-driven trunk topologies, according to some embodiments. [Figure 30] FIG. 30 illustrates a computer system with a machine-readable storage medium having machine-executable instructions for generating intent-driven trunk topologies, according to some embodiments. [Figure 31] FIG. 31 illustrates a smart device, or computer system, or SoC (System on Chip), designed using an intent-driven trunk topology, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0003] Today's custom routing solutions, such as the Custom Galaxy Router, Create Route Tool, and Unified Topology Constraint Tool in ICC2 by Synopsys, do not meet the need for an intent-driven, command-based, repeatable approach that enables what-if scenarios to analyze floorplan feasibility early to achieve rapid design convergence.

[0004] Some embodiments provide a trunk creation scheme that utilizes a unique topology model consisting of a start point, an end point, and any number of optional intermediate jog points connected by multiple layer segments and widths. Point coordinates are not specified directly in micron values; instead, multiple reference objects are used to derive the coordinates. In some embodiments, topology point coordinates are calculated relative to a reference geometry, referred to as a zone. Zone geometries can be rectangular or rectilinear. One or more zones can be used to calculate topology points. Zone coordinates can be defined in terms of micron values ​​or derived from multiple reference objects. The resulting trunk created from the topology and zone descriptions does not need to belong to any of the reference zones and is created in the coordinate system of the current block.

[0005] The scheme of some embodiments is developed using computer-executable instructions (e.g., encoded TCL language). The computer-executable instructions include commands that accept multiple user inputs through various command options. The commands encapsulate and execute multiple original software algorithms. The algorithms translate trunking design intent, expressed through the command options, into trunks at multiple layers of a process technology node. Once executed, the commands generate trunk shapes of a specified topology at a specified layer for a specified net.

[0006] There are many technical advantages of various embodiments. For example, simple or complex trunking topologies can be generated by invoking a command (e.g., a single command) with a set of options. The command accepts a topology, a set of zones, nets, and many other options that the user provides to the command to generate a trunk of the desired topology. The topology description is relative and therefore can be easily adjusted during design changes. The command, along with the options, expresses the trunk creation intent. The sequence of commands can be saved in a trunk recipe file. The file can be used later to create or recreate a trunk with a changed design context at any time. Because the commands are self-contained and independent of execution state, the trunk result is deterministic. The scheme of various embodiments not only simplifies the management of trunk creation intent, but also enables rapid what-if scenarios by simply modifying input options to the command to analyze floorplan feasibility, thus enabling much faster silicon design convergence. The commands are also process-independent, enabling easy design migration and reuse by leveraging design intent for derivatives. Other technical advantages will be apparent from the various figures and embodiments.

[0007] In the following description, numerous details are discussed to provide a more thorough explanation of embodiments of the present disclosure. However, it will be apparent to those skilled in the art that embodiments of the present disclosure may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments of the present disclosure.

[0008] Note that in the corresponding drawings of the embodiments, signals are represented by lines. Some lines may be thicker to indicate signal paths through more components and / or may have arrows at one or more ends to indicate the direction of primary information flow. Such designations are not intended to be limiting. Rather, the lines are used in connection with one or more exemplary embodiments to facilitate understanding of a circuit or logic unit. As dictated by design need or preference, any represented signal may actually include one or more signals that can travel in either direction and may be implemented with any suitable type of signaling.

[0009] Throughout the specification and in the claims, the term "connected" means a direct connection, such as an electrical, mechanical, or magnetic connection, between the things that are connected, without any intermediary devices.

[0010] The term "coupled" means a direct or indirect connection, such as a direct electrical, mechanical, or magnetic connection between the things that are connected, or an indirect connection through one or more passive or active intermediary devices.

[0011] The term "adjacent" as used herein generally refers to the location of an object that is next to (e.g., immediately adjacent or proximate to one or more objects therebetween) or adjacent to (e.g., abutting) another object.

[0012] The terms "circuit" or "module" may refer to one or more passive and / or active components configured to cooperate with each other to provide a desired functionality.

[0013] The term "signal" refers to at least one current signal, voltage signal, magnetic signal, or data / clock signal. The meanings of "a," "an," and "the" include plural references. The meaning of "in" includes "in" and "on."

[0014] The term "scaling" generally refers to converting a design (schematic and layout) from one process technology to another, followed by a reduction in the layout area. In some cases, scaling can also refer to expanding a design from one process technology to another, followed by an increase in the layout area. The term "scaling" also generally refers to shrinking or expanding layouts and devices within the same technology node. The term "scaling" also refers to adjusting (e.g., slowing down or speeding up, i.e., shrinking or expanding, respectively) signal frequency relative to another parameter, e.g., power supply level.

[0015] The terms "substantially," "close," "approximately," "near," and "about" generally refer to being within + / - 10% of a target value.

[0016] Unless otherwise specified, the use of ordinal adjectives such as "first," "second," and "third," etc., to describe common objects merely indicates that different instances of similar objects are being referenced, and does not imply that the objects so described must be in a given sequence, whether in time, space, ranking, or otherwise.

[0017] For purposes of this disclosure, the phrases "A and / or B" and "A or B" mean (A), (B), or (A and B). For purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A and B and C).

[0018] The terms "left," "right," "front," "back," "top," "bottom," "over," "under," and the like in the specification and claims, if any, are used for descriptive purposes and are not necessarily used to describe permanent relative positions.

[0019] It is noted that elements of a figure having the same reference number (or name) as elements of any other figure may operate or function in a manner similar to that described, but are not limited to such.

[0020] For purposes of the embodiments, the transistors in the various circuit and logic blocks described herein are metal-oxide-semiconductor (MOS) transistors or their derivatives, where a MOS transistor includes a drain, a source, a gate, and a bulk terminal. Transistors and / or derivatives of MOS transistors also include Tri-Gate and FinFET transistors, Gate All Around Cylindrical Transistors, Tunneling FETs (TFETs), Square Wire or Rectangular Ribbon Transistors, Ferroelectric FETs (FeFETs), or other devices that perform transistor functions, such as carbon nanotube or spintronic devices. The symmetrical source and drain terminals of a MOSFET are identical terminals and are used interchangeably herein. On the other hand, a TFET device has asymmetrical source and drain terminals. Those skilled in the art will appreciate that other transistors, such as bipolar junction transistors (BJT PNP / NPN), BiCMOS, CMOS, etc., can be used without departing from the scope of this disclosure.

[0021] 1 illustrates a flowchart 100 of a method for generating an intent-driven trunk topology according to some embodiments. While various blocks are shown in a predetermined order, the order can be changed. For example, some blocks may be performed before others, while some blocks may be performed in parallel. Flowchart 100 illustrates block 101 for intent-driven trunk topology generation, as well as post-topology generation activities including silicon layout 102 of the trunks and tapeout 103 of an integrated circuit (IC) having the intent-driven trunks.

[0022] The trunk generation scheme utilizes a unique topology model consisting of a start point, an end point, and any number of arbitrary intermediate points connected by segments of multiple layers and widths. Point coordinates are not specified directly in microns, but rather, multiple reference objects are used to derive the coordinates.

[0023] Topology point coordinates are calculated relative to a reference geometry, referred to as a zone. The geometry of a zone can be rectangular or rectilinear. One or more zones can be used to calculate a topology point. Zone coordinates can be defined in terms of micron values ​​or derived from multiple reference objects. The trunk resulting from the topology and zone description does not have to belong to any of the reference zones and is generated in the coordinate system of the current block.

[0024] To implement the method, some embodiments use coded TCL (tool command language) commands that accept multiple user inputs through various command options. The commands encapsulate and implement multiple original software algorithms developed to translate the trunk design intent expressed through the command options into trunks at multiple layers. Once executed, the commands generate trunk shapes of the specified topology at the specified layers for the specified nets.

[0025] Here, the term "trunk" generally refers to a "pre-routed wire" (the term "wire" refers to an electrical connection that has a predetermined physical path in an IC layout), which is created by the user "by hand," i.e., without using a routing engine to determine the route. Typically, pin locations for a set of nets are determined during placement, and then the routing engine creates routes to electrically connect the pins. However, the user can pre-specify predetermined routes or portions of routes. Such routes or portions of routes are referred to as "trunks." The term "trunk routing" refers to the process for routing trunks.

[0026] The term "net" is described in the context of a netlist, which is a list (or collection) of "nets." Each "net" refers to a set of gates (or cells) whose inputs / outputs are electrically connected. For example, assume a driver cell drives the inputs of a set of driven cells. In this example, the term "net" can refer to the portion of the netlist that includes the driver cell, the set of driven cells, and the electrical connections (e.g., a network of metal wires) connecting the output of the driver cell to the input of the set of driven cells.

[0027] To meet the requirements of high-speed and mixed-signal interconnects, routing is structured and pre-planned. Trunking is the optimal method to ensure that stringent requirements on critical nets are met. A user intent-driven approach to trunk routing in various embodiments is adopted to ensure repeatability, respinability, and fast design convergence.

[0028] child Routing intent, then, differs from routing constraints. Routing intent is a high-level description of what to do with routing. One example of routing intent might be stated as follows: “I would like these net busses to be routed in a “Z”-shape topology connecting these two macros in these two layers.” In contrast, routing constraints correspond to options for the routing engine and are a set of configuration parameters that control the behavior of the routing engine at the lowest level of granularity in the routing process. Examples of routing constraints include defining areas to be routing corridors, setting minimum and maximum routing tiers, setting various costs per tier, creating non-default routing rules, and many other routing options that specify where the routing engine can and cannot place shapes. The set of constraints represents the state of the routing engine, and special care must be taken to preserve and roll back previous values. However, routing constraints cannot be used to capture the high-level intent that a user has for routing trunks.

[0029] A user specifies a routing intent by using a set of input parameters 101a and commands 101b. The set of commands may be provided in a file or may be generated based on the user interacting with the tool. For example, the set of commands 101b may be entered in a file, which may then be read, parsed, and executed by the program. In another example, the commands 101b and their input parameters may be entered through a graphical user interface (GUI). The GUI may be opened and used to launch and / or execute the intent-driven topology generator.

[0030] Regardless of how the user's trunk routing intent is encoded and provided to the IC design tool, the combination of the command name and its options conveys the routing intent and hides the implementation details from the user. Command 101b does not use actual / hard-coded coordinate values, thereby ensuring that the routing can be reproduced with an electrical design change order or new process.

[0031] Commands 101b of various embodiments reference existing objects, e.g., pins / ports, cells, and shapes. Up-leveling commands 101b to use objects instead of coordinates makes the routing results adjustable to the current layout, i.e., makes the intent "relative" to objects in the layout, which also makes the trunk routing intent specification ECO friendly.

[0032] Command 101b is packed with functionality to ensure all possible trunking tasks are performed. These include, but are not limited to, shielding (full, half, cap_shield), interleaving, swizzling, pin generation, user shapes, and blockage. Some embodiments support the creation of partial trunks by excluding predefined trunk segments and custom pullbacks from edges. This command can be used not only to generate trunks for signal nets, but also to generate power grids due to its flexible nature. Commands include "trim_area" (all trunk OUTSIDE areas are trimmed to that area, "everything outside removed") and "cutout_area" (all trunk INSIDE areas are removed to that area, "everything inside removed").

[0033] The options for the various input parameters 101a and the syntax for the structure of the command 101b are now explained.

[0034] cr_create_trunk_from_here_to_there # Create a trunk based on a topology description.

[0035] [-nets] (List of nets to create trunks for.)

[0036] [-ref_nets] (List of reference nets to get port / pin locations relative to the reference track. Must be the same length as -nets.)

[0037] [-nets_order] (interleave / reverse / expanded,bit|etc. interleaved nets, e.g., -nets "a[0:7]b[0:7]" results in "a[0]b[0]…a[7]b[7]".)

[0038] [-zone] (list of named trunking zones, e.g., "ch1:my_cell_1 ch2:slice / right_cell", where channel is an absolute bbox (or cell_name) or net(s) bbox.)

[0039] [-bloat_zone] (Inflate the net member bbox of a zone. "ch,10.06,-2.6" bloats the ch1 bbox by 10.06 microns in the X direction and -2.6 microns in the Y direction.)

[0040] [-topology] (Topology description as a list of trunking channels and legs referencing layers / widths / tracks / microns / p-values.)

[0041] [-skip_tracks] (Track skip rule. For example, "m8,9,5, m9,10,3-7-9" means skip the 3rd, 7th, and 9th of every 10 tracks for m9.)

[0042] [-avoid_area] (List of cells / absolute bboxes / relative bboxes (relative to a cell) to avoid. "mdf*18694.8000:0.0000:19595.5200:1184.8320 sprtile33,0:0:200:200 sprtile 43, 0:0:200:200" Any track inside these bboxes will be skipped.)

[0043] [-avoid_layers] (A separate list of layers for each element of the -avoid_area list. Any tracks for these layers within the -avoid_area bbox will be skipped.)

[0044] [-trim_area] (List of cells / absolute bbox-es / relative (to cells) bboxes used to trim trunks, "mdf*18694.8000:0.0000:19595.5200:1184.8320 sprtile33,0:0:200:200 sprtile43,0:0:200:200" Any trunk outside this area will be trimmed with 1 / 2 DR deflate.)

[0045] [-cutout_area] (list of cells / absolute bbox-es / relative bbox (to the cell) used to cut out the trunk, "mdf*18694.8000:0.0000:19595.5200:1184.8320 sprtile33,0:0:200:200 sprtile43,0:0:200:200" Any trunk inside this area will be cut out.)

[0046] [-cutout_bloat] (Inflate the cutout area in DR units. + is inflate, - is deflate.)

[0047] [-do_not_cutout_nets] (List of nets to ignore during cutout.)

[0048] [-swizzle] (Takes a pair of nets and performs a 1 track jog / swizzle / twisted pair route. If a list of nets is passed, they are run two after another. Requires "swizzle_layer,location" to be passed.)

[0049] [-stepping] (list of steps per layer / width pair, must correspond for shields, e.g., full-3,half-2).

[0050] [-create_port] (Create a port from the trunk.)

[0051] [-create_user_shape] (Create a user shape from the trunk.)

[0052] [-create_blockage] (Create a blockage from the trunk.)

[0053] [-use_pin] (Use the edge pin of the specified channel to override the layer / width / position (track / micron) for the edge topology definition.)

[0054] [-num_wires] (Number of trunks to create per net).

[0055] [-track_overrides_pin] (Use the passed track number even if a pin exists.)

[0056] [-reuse_zone_tracks] (Don't fetch tracks for the channel, reuse them from a previous call.)

[0057] [-clean_zone_tracks] (Clears the track cache, so all subsequent calls must fetch tracks for the channel.)

[0058] [-clean_named_zone_tracks] (Clears the track cache for the given zone, so that all subsequent calls must fetch tracks for the zone.)

[0059] [-Shield] (Shield.)

[0060] [-shield_name] (Shield name.)

[0061] [-shield_type] (Type of shield to perform.)

[0062] [-edge_overhang] (Overhangs an edge. Used to create a pin at an edge after pushing the trunk down the hierarchy. Cannot be used with -edge_pullback and / or edge_pullback_custom.)

[0063] [-edge_pullback] (Pullback from edge half DR (per layer). Cannot be used with -edge_pullback_custom and / or -edge_overhang.)

[0064] [-edge_pullback_custom] (List of "start|end,layer,pullback", e.g. "start,m10,100 end,m10,10 start,m9,80 end, m9,8". Pullback from the specified edge. Cannot be used together with -edge_pullback and / or -edge_overhang.)

[0065] [-cutout_pullback] (list of "start|end,layer,pullback", e.g. "end,m10,100 start,m9,80 end,m8,-18"). Pullback from the specified cutout area.

[0066] [-shield_pullback] (Pullback shield trunk from edge half DR (per layer)).

[0067] [-worng_way_metal] (Allows wrong way metal. Value is a list of names of layers where wrong way shapes are generated.)

[0068] [-snap_to_track] (Snap coordinate to track for a given layer / width when topology is specified using micron values.)

[0069] [-do_not_check_shorts] (Do not check for blockages in tracks.)

[0070] [-find_free_tracks] (Find free (non-blocking) tracks to trunk.)

[0071] [-include_power_for_free_tracks] (Allows you to include powerstraps when free tracks are detected. By default, they are ignored for speed.)

[0072] [-v_track_freedom] (Extend the search distance in microns in the X direction outside the net bbox to find free tracks.)

[0073] [-h_track_freedom] (Extend the search distance in microns in the Y direction outside the net bbox to find free tracks.)

[0074] [-ignore_boundary_guides] (Allows you to ignore boundary guides used for 1 / 2 dr spacing when detecting free tracks.)

[0075] [-just_clear_zone] (Remove all zone annotations.)

[0076] [-custom_attr] (List of shape attributes "attr_name attr_val", where "attr_name" assumes bool==1 and will be added to the trunk shape.)

[0077] [-custom_callback] (Procedure to be called on the generated object, passed as srgument.)

[0078] [-display_zone] (Annotate channel / edge and track volumes based on a comma-separated list of layers / widths.)

[0079] [-jut_clear_zone] (Remove all zone annotations.)

[0080] [-custom_attr] (List of shape attributes "attr_name attr_val", where "attr_name" assumes bool==1 and will be added to the trunk shape.)

[0081] [-custom_callback] (Procedure to be called on the generated object, passed as an assertion.)

[0082] [-custom_tag] (Internal tag added to trunk. Do not use in user scripts.)

[0083] [-log_track_number] (Reports the track number on which the net was created.)

[0084] [-verbose] (Turns on printing of display_channel capacities.)

[0085] [-preview] (Does not create geometry, just draws annotations of geometry.)

[0086] Command 101b is executed to generate one or more trunks and what-if scenarios. In its simplest form, command 101b specifies a net, one or more zones, and a topology description that expresses trunking design intent. In various embodiments, the command is process technology node independent. For example, a command used in a 10 nm process technology node can be used with the same options and parameters in a 7 nm process technology node. In some embodiments, command 101b includes a start point and an end point, where the start point includes fields separated by a separator. In some embodiments, the separator includes a comma. In some embodiments, the fields include a zone, a layer, a width of a track on the layer, and a coordinate reference. The coordinate reference is used to calculate a micron value for the coordinate based on the current design state and is executed at the time command 101b is executed. In some embodiments, the end point includes one or more fields.

[0087] The execution process includes parsing the command, validating the command options and parameters, etc. In some embodiments, command parser 101c parses various options and input parameters from command 101b and / or set of commands 101b. Command parser 101c can separate the input parameters associated with various options so that validity checker 101d can check whether the input command is valid. In some embodiments, validity checker 101d includes logic to process zone definitions and ensure zones exist and the geometry is valid. In some embodiments, validity checker 101d includes process topology definition checking logic to ensure syntax is correct and to ensure tracks exist for layers and / or widths and to lay out trunks. In some embodiments, validity checker 101d includes logic to process step definitions to ensure a stepping map for topology legs. In some embodiments, the user is notified of errors in the received command. In one such example, the software program prompts the user to re-enter the command, as indicated by the dotted line between block 101f and block 101b.

[0088] The process then moves to generating one or more trunks within one or more zones on the parsed and verified track (block 101e). The one or more trunks are generated in response to execution of the command and according to the topology description. In some embodiments, generating one or more trunks (block 101e) includes fetching the track from the current design and numbering the track relative to the edges of the one or more zones, taking into account faults, porosity, and / or avoidance areas within the one or more zones, where the one or more zones include multiple edges and the edges are numbered clockwise from the orientation of the zone.

[0089] In some embodiments, the one or more zones are one or more of the following: a current block, where the geometry of the current block defines the zone; a bounding box described by coordinates relative to the current block, where the bounding box defines the zone; a cell in any design hierarchy, where the geometry of the cell defines the boundary of the zone; a net or bus at any level of the hierarchy, where the bounding box of the net defines the zone; a blockage, placement, or routing, where the geometry of the blockage, placement, or routing defines the zone; and / or a gutter or gutter range, where the bounding box of the gutter from the start gutter to the end gutter defines the zone. In some embodiments, the zone is the coordinate system of a virtual object for computing topology point coordinates.

[0090] In some embodiments, one or more trunks do not belong to any zone. Zones are virtual and temporary geometric entities (e.g., not actual objects defined in the database). In some embodiments, zones are used to reference, measure, or define the coordinates of trunks in the topology. In some embodiments, the geometry of a zone is calculated at command execution time (e.g., zones are not persistent). These temporary geometric objects can be derived from actual objects in the database, such as cells, nets, etc., as well as from virtual objects, such as bbox definitions and gutters. Guttators, as described herein, are not actual database objects, but are used to organize and manipulate tracks in a structured way.

[0091] Topology coordinates are defined using zones and the coordinates of points measured relative to the zones. Multiple zones can be used in the same topology definition. Which zones are used depends on how the user defines the trunking intent. The same geometry of a trunk topology can be created using different zones as the coordinate reference. The resulting coordinates are in the coordinate system of the current block. The command knows the zone geometry in the coordinate system of the current block and performs all recalculations from the zone coordinate system to the current block.

[0092] In some embodiments, generating one or more trunks (block 101e) includes applying a topology model that includes a start point, an end point, and any number of intermediate jog points connected by segments of one or more layers and widths, where the one or more layers correspond to one or more layers of a process technology node.

[0093] In some embodiments, command implementation provides a preview mode 101f, where the command does not generate actual layout objects in the database, but rather generates annotations (cartoon drawings) that are displayed on the canvas. The preview (annotation) is a virtual layout object, is not persistent, and exists only for the duration of the interactive session. Once the session ends, the preview is discarded. The preview gives the user an accurate depiction of how the layout will be created without having to modify the database. If command 101b includes a preview mode, according to some embodiments, one or more trunks are not saved in the database. In some embodiments, if command 101b does not include a preview mode, one or more trunks are saved in the database.

[0094] In the preview approach, the user is free to make multiple attempts without expending time and effort to roll back to the original state, as indicated by the dotted line between blocks 101f and 101a. This mode is very fast, giving the user the ability to perform multiple what-if analyses, thus enabling efficient iteration to arrive at a result more quickly. Once the user achieves the desired result, the trunks and their coordinates are saved in the database, as indicated by block 101g. The desired result can be committed to the layout 102 by executing the same command without the preview mode. Additionally, the user can save the command, along with optional values, in a file (e.g., as indicated by block 101g) so that the layout can be recreated at any time later by issuing the command.

[0095] FIG. 2 illustrates a topology 200 of vertical and horizontal tracks displayed in relation to a current design, according to some embodiments. Trunks and other routing shapes are created around predefined route tracks. Route tracks, simply referred to as tracks, are objects in the design described by layers with center point coordinates and widths. Tracks span the entire width and height of the design. Tracks are counted starting from the left and working to the right for vertical layers and bottom to top for horizontal floors. In this example, the current design includes 47 M9 tracks and 21 M10 tracks that are orthogonal to the M9 tracks.

[0096] 3A-3B show two sets of topologies 300 and 320, each with two gutters having different track plans, according to some embodiments. The tracks are repetitive in nature. The stepping of the repetition is defined by the distance between the power rail and the ground rail. The set of signal tracks between the power rail and the ground rail is called a gutter.

[0097] There can be multiple track plans per gutter. For example, track plan 300 for metal m10 gutter 301 has six signal tracks 302 with a width of 1x between power rails 303, and another track plan 320 for metal m10 gutter 321 has three signal tracks 322 with a width of 2x between power rails. Guttators of different track plans may be adjacent to each other and even overlap. Gutters can be thought of as a way to organize, manipulate, and utilize track in a structured way.

[0098] For a given process technology, gutter design is done for each metal layer at the very early design stage to ensure that power delivery and reliability requirements are met. Careful gutter design is especially used for high-speed and analog mixed-signal designs with multiple power domains.

[0099] Gutters are a useful tool for early design feasibility (especially floorplan design) driving key design decisions to ensure convergence to power, performance, and area (PPA) requirements. Trunking is primarily performed for timing-critical and analog nets in different floorplan gutters for critical partitions throughout the design. Examples of critical partitions with trunks on multiple gutters include: clock mesh partitions, double data rate (DDR) to memory controller (MC) routing partitions, and structured data-path style blocks such as low-level caches (LLCs).

[0100] FIG. 4 shows an example 400 of two zones with straight boundaries, according to some embodiments. The first zone includes edge 401, and the second zone includes edge 402. The edges are listed clockwise from the orientation of the zone. Track capacity is reported using special options to the command. A zone is defined by the name of the zone, the layer, the layer width, and the number of tracks in the zone.

[0101] 5A-5C illustrate various topologies 500, 520, and 530 for track porosity, respectively, according to some embodiments. Certain tracks can be reserved for future use by excluding them from routing resources. Typically, tracks are reserved or excluded on a gutter-by-gutter basis. The reserving of tracks for future use is described using the concept of "porosity." Porosity is described as the number of tracks excluded from a gutter. Porosity is the exclusion of certain tracks from a gutter. Another method of excluding tracks exists when an entire region or set of regions is defined that excludes tracks that cross those regions. These regions are collectively referred to as "avoid areas." To provide more precise control, only tracks in certain layers can be excluded from the area defined by the avoidance region.

[0102] Topology 500 illustrates a case with six tracks per gutter and no porosity. Here, all tracks are counted (which is the default counting method). Topology 520 illustrates a case with porosity of 2 of 6, as indicated by reference numeral 521. In this case, every second track of each of the six signal tracks is excluded from track counting. Topology 530 illustrates a case with porosity for tracks 3 and 6 in a group of six tracks per gutter. In this case, track numbers 3 and 6 in each gutter are reserved for future use and therefore excluded from counting. Here, the porosity is 3,6 of 6, meaning that the third and sixth tracks of every six tracks are not available for track routing for intent-driven trunk generation.

[0103] FIG. 6 shows a zone 600 with numbered vertical and horizontal tracks for the zone 601, according to some embodiments. The geometry of the zone 601 is described by the x, y values ​​of the boundary vertices. In some embodiments, the coordinates of the vertices may be derived from a zone of a given type. The zone may be one or a list of types shown in Table 1. [Table 1]

[0104] Tracks are counted or numbered from 1 or reference edge 1 of the zone. In this example, M10 tracks are counted from 1 to 9 in zone 601, where track 1 of zone 601 is the same as track 2 in the current design. The same applies to M9 tracks, where track 1 of zone 601 is the same as track 11 of M9 in the current design. When zone my_zone is referenced in a topology description, according to various embodiments, the enumeration of tracks begins at the origin of the zone.

[0105] In some embodiments, zones can be aliased for ease of reference by using ":" in the topology definition. Some examples are shown in Table 2. [Table 2]

[0106] Some examples of gutter type zones are as follows:

[0107] z:m9:5:20 - gutters are counted relative to the origin of the current block (_top_). The border is the combined border of the gutters, from gutter #5 to gutter #20 inclusive. For horizontal layers, the border spans the full width of the current block, for verticals it is the full height.

[0108] z:m9:1:7,offset - gutters are counted with respect to the origin and offset of the current block (_top_). The border is the combined gutter border, from gutter #1 (offset from) to gutter #7 (offset from), inclusive. The offset value can be either a micron value, or a cell, if the cell offset value is the cell origin. For a micron offset, the border spans the full width or height of the current block. For a cell offset, the border spans the full width or height of the cell.

[0109] z:m9:my_cell,1:20 - The gutter is relative to the origin of cell my_cell. The gutter is inside my_cell. The border is the combined border of the gutter, starting from gutter #1 in cell my_cell up to and including gutter #20. The trunk counting depends on the orientation of the cell, such as zone of type cell. The border spans the full width or height of the cell.

[0110] 7A-7B show track enumeration when the zones are cells and the cells are flipped across the y-axis, according to some embodiments. Topology 700 is the same as topology 600, while topology 720 has been flipped across the y-axis. When zone 601 is a cell and the cells are flipped across the y-axis, the numbering changes.

[0111] A topology description can use one or many different zones to reference its coordinates. The resulting trunks created from a topology and zone description do not have to belong to any of the referenced zones. Zones can be combined, separated, and used as references to generate multiple flexible routing topologies.

[0112] 8 illustrates a five-point, four-segment Manhattan path 800 with minimum coordinates for defining a topology, according to some embodiments. In some implementations, the topology representation is modeled after the natural way a Manhattan path can be drawn on a piece of paper. For example, a first track is drawn horizontally from a starting point 1 in the lower left corner of the piece of paper to the next point 2, stopping at point 2. A second track starts from point 2 vertically from bottom to top to the next point 3, stopping at point 3, and continues until it stops at a final point N. Each segment represents a trunk leg, and each segment also carries information about the trunk leg's tier in the topology.

[0113] In this model topology, the ordered list of points is defined by the geometry of the given zone and its coordinates, measured relative to the given layer and layer width, of the trunk segment connecting each two consecutive points, either horizontally or vertically. The topology has a start point and an end point, and, optionally, any number of intermediate jog points. The connected segments of the topology change direction from horizontal to vertical or from vertical to horizontal. Therefore, it will be sufficient to specify two coordinates, x and y, for the start point, and one coordinate, x for vertical and y for horizontal, for all other points, since they inherit the other coordinate from the end point of the previous segment.

[0114] In addition to using micron values ​​to define coordinates, some embodiments use multiple reference objects to derive coordinates. The objects are zone tracks, zone edges, zone track capacitances, track gutters, trunk extensions with lengths in microns, ports, pins, and trunks. Both pins and ports with multiple terminals are supported by commands. Reference objects are often associated with layers and layer widths, and sometimes with nets. In some embodiments, the lowest level coordinate specified is either a micron value or a number of tracks per layer and width for a zone.

[0115] The next section provides an example of the syntax for specifying a topology as a list of consecutive points.

[0116] In some embodiments, topology coordinates have four comma-separated fields, including zone, layer, width, and coordinate reference. In some embodiments, the beginning of a topology description has four fields specified. In some embodiments, the end of a topology includes at least one field in the description. For example, in the topology "a.1,m8,1x,20 a.3", the end point is the shortcut "a.3". By specifying a zone edge (zone.edge) for the end point, the previous descriptions for metal layer, width, and track are used to define the end coordinate.

[0117] In some embodiments, a starting topology at the edge of a zone specifies two coordinates in one description, for example, topology "a.1,m8,1x,20 a.3". A topology can have a description that includes a starting point, which includes four comma-separated descriptors, and a single-ended topology descriptor, which is a zone, such as "a". For example, topology "a.1,b,b,d a.3".

[0118] In some embodiments, a topology can have a description that includes a start point that includes four comma-separated descriptors and an end point that includes all four comma-separated descriptors that are not on an edge, for example, "a.1,b,c,da,b,c,d".

[0119] In some embodiments, the first value "a" in the topology "a,b,c,d" description is the zone element name. In some embodiments, the zone is defined with the -zone option. In some embodiments, the zone element can be the zone itself (e.g., cell, bbox, net, toplevel). In some embodiments, the zone element can be the zone and the zone's edge number. In some embodiments, the zone element can be the zone and a minimum (e.g., reference minimum rmin and instance minimum imin). The minimum is automatically determined by the smallest x or y edge, depending on the layer in the topology description. In some embodiments, the zone can be the zone and a maximum (e.g., reference maximum max and instance maximum imax). The maximum is automatically determined by the largest x or y edge, depending on the layer in the topology description. Here, .rmin / .imin and .rmax / .imax are subsets of edge numbers to make specifying edges easier when dealing with straight boundaries. You don't need to specify the edge numbers as with .edge_number, by simply putting .rmin / .imin or .rmax / .imax at the end of the zone. "rmin" is translated to the bottom-left edge with respect to the cell origin (original). "rmax" is translated to the top-right edge with respect to the cell origin. "imin" is translated to the bottom-left edge and ignores the cell's translation. "imax" is translated to the top-right edge and ignores the cell's translation.

[0120] In some embodiments, the second value "b" in the description of the topology "a,b,c,d" is a layer name (e.g., m8 for metal layer 8). In some embodiments, the third value "c" in the description of the topology "a,b,c,d" is a width name (e.g., 2x). Specifying the values ​​"b" and "c" defines the track to use. The fourth value "d" in the description of the topology "a,b,c,d" defines a coordinate or point. Table 3 shows some examples of the fourth value "d". [Table 3]

[0121] 9-11 illustrate various topology specifications 900, 1000, and 1100, respectively, according to some embodiments. The topology specification "t.1,m8,1.5x,160" describes a start at an edge of zone 1, as shown in FIG. 9. The topology specification describes a track starting at the intersection of edge 1 of zone "t" in 1.5x-wide metal layer m8 and track 160 of zone "6." The topology specification also provides an end point "t,m9,1x,300 t12," which describes the track traveling in 1.5x-wide m8 until it hits track 300 of zone "t" in 1x-wide m9 to reach the end.

[0122] The topology specification "t.1,m8,1.5x,160 t,m9,1x,300 t.12" describes starting from the intersection of a 1.5x wide m8 track 160 and a 1x wide m9 track 300 in Zone 1, as shown in Figure 10. Here, to reach the end, the track moves 1x wide m9 until the following condition is met:

[0123] The topology specification "t.1,m8,1.5x,160 t,m9,1x,300 t.12" describes a start at the intersection of 1.5x wide m9 track 160 and 1x wide m9 track 300 of zone 1, as shown in FIG. 11. Here, to reach the end, the track moves at 1x wide m9 until the following condition is met: The topology specification "t.1,m8,1.5x,160 t,m9,1x,300" describes a start at the intersection of edge 1 of zone "t" and track 160 of zone "t" at m8. Then, the track moves at 1.5x wide m8 until it hits zone "t" 300 at 1x wide m9.

[0124] 12-17 illustrate applying a topology to a net with stepping 1200, 1300, 1400, 1500, 1600, and 1700, respectively, according to some embodiments. Here, topology defines a reference topology. Here, topology is applied to the first net in "-nets." If one or more nets -nets "foo[0:15]" are passed, the topologies for all subsequent nets are derived from the reference topology using the stepping option. The "-stepping" option is per segment of "-topology." Every coordinate reference in the topology is incremented by the corresponding stepping value. If a "-stepping" value is not provided, the default is a stepping of "1" for each segment.

[0125] Figures 12-15 provide stepping examples of "3 1", "3 3", and "3 -3", respectively. One example command with the "-stepping" option is: "-topology t.1,m8,1.5x,160 t,m9,1x,300 t.12" -stepping "1 1" -preview -clear." Stepping can be both positive and negative, and can even be "0". Negative stepping decrements the track by the step value, reversing the increment for the next track.

[0126] Stepping is a method of applying a reference topology to successive nets provided by the user through the -nets command option. Stepping values ​​are increments to the reference topology coordinates. The lowest level coordinates specified for the reference topology are either micron values ​​or tracks per layer and width for zones. Stepping is applied to each coordinate of a point in the reference topology by incrementing (for positive stepping values) or decrementing (for negative stepping values) each coordinate in the reference topology by the corresponding stepping value for each i+1 net in -net.

[0127] Here is an example of how stepping is applied to a three-point topology for three nets "abc." Assume the stepping value is 2 -1 1 and the coordinates are track numbers. Assume the reference topology uses track numbers N1, N2, and N3. The reference topology is applied to the first net "a." Then, after applying the stepping of 2 -1 1, the topology for net "abc" uses track numbers as shown in Table 4. [Table 4] The same applies to coordinates in microns, where the stepping values ​​are increments of microns and not increments of track numbers.

[0128] Figures 16-17 provide a stepping example with zero stepping. Zero stepping stops all segments on a single track and does not step to the next segment. An example command with a zero "-stepping" option is "t.1,m8,1.5x,160 t,m9,1x,300" -stepping "3 0" -preview -clear." The command creates a track starting at edge 1 of m8 in track 160 of zone "t." The track then moves until it hits track 300 of m9, and then stops. At that point, because stepping is zero, the track of m9 is not incremented for each bit in the bus. Zero stepping is often used to square off a wire at its termination so the wire stops on the same vertical track. Stepping is often used to extend a trunk from a port or pin to where another h2t command for the previous trunk follows. Stepping is also used for length and parallel wire matching.

[0129] Various embodiments support swizzle topology, also known as twisted pair. This topology is used in dense channel routing for self-heating purposes. The swizzle works off pairs of nets in a single-segment topology description. This command has a special option for swizzle, -swizzle, which takes the distance in microns of the start of the topology layer / swizzle layer relative to the width of layer-1.

[0130] Figure 18 illustrates a single segment topology 1800 from "nowhere" to "nowhere" within a zone, according to some embodiments. The command may read: my_zone,m9,1x,1 my_zone,m10,1.5x,2 my_zone,m9,1x,13. Trunk 1801 starts at the intersection of my_zone track 1 at m9,1x and track 2 at m10,1.5x, and travels at m10 until it hits track 13 at m9,1x.

[0131] Figure 19 shows a multi-segment topology 1900 for a zone, according to some embodiments. The command may read: my_zone,m9,1x,1 my_zone,m10,1.5x,2 my_zone,m9,1x,13 my_zone.m8,2x,9. The trunk 1901 starts at the intersection of my_zone track 1 at m9,1x and track 2 at m10,1.5x, and travels at m10 until it hits track 13 at m9,1x. It then turns and travels at m9 until it hits track 9 at m8,2x.

[0132] Figure 20 shows a multi-segment topology 2000 starting from an edge and stopping at a track intersection, according to some embodiments. The command may read: my_zone,m10,1.5x,2 my_zone,m9,1x,13 my_zone,m8,2x,9. The trunk 2001 starts at the intersection of my_zone edge 1 and track 2 at m10,1.5x, and moves at m10 until it hits track 13 at m9,1x. It then turns and moves at m9 until it hits track 9 at m8,2x.

[0133] Figure 21 illustrates a multi-segment topology 2100 starting from an edge and stopping at the edges of zones: my_zone,m10,1.5x,2 my_zone,m9,1x,13 my_zone,m8,2x,9 my_zone,3, according to some embodiments. Trunk 2101 starts at the intersection of edge 1 of my_zone and track 2 of m10,1.5x, travels on m10 until it hits track 13 of m9,1x, then turns and travels on m9 to hit track 9 of m8,2x, and then travels track 9 to edge 3 of my_zone.

[0134] Figure 22 shows a multi-segment topology 2200 that starts and stops on an edge along the pin centerline, according to some embodiments. The command may read: my_zone,m10,1.5x,2 my_zone,m9,1x,13 my_zone,m8,2x,p my_zone.3. The trunk 2201 starts at the intersection of edge 1 of my_zone and track 2 of m10,1.5x, moves m10 until it hits track 13 of m9,1x, then rotates and moves m9 until it hits the track of the pin centerline, and then moves to edge 3 of my_zone.

[0135] Figure 23 shows a multi-segment topology 2300 starting at an edge, stopping at a pin, and then continuing on the edge, according to some embodiments. The command may read: my_zone,m10,1.5x,2 my_zone,m9,1x,13 my_zone.p my_zone.3. The trunk 2301 starts at the intersection of edge 1 of my_zone and track 2 of m10,1.5x, moves with m10 until it hits track 13 of m9,1x, then rotates with m9 and moves until it hits the track of the pin centerline, inheriting the layer / width of the pin, and hits edge 3 of my_zone.

[0136] Figure 24 shows a multi-segment topology 2400 starting on an edge and referencing another edge of a zone, according to some embodiments. The command may read: my_zone,m10,1.5x,2 my_zone,my9,1x,13 my_zone.p my_zone.5. The trunk 2401 starts at the intersection of edge 1 of my_zone and track 2 of m10,1.5x, moves with m10 until it hits track 13 of m9,1x, then rotates and moves with m9 until it hits edge 2 snapped to track m8,2x, and then moves with m8 to edge 5.

[0137] Figure 25 shows a multi-segment topology 2500 referencing tracks with topology descriptions, according to some embodiments. The command may read as follows: G_zone,m10,1.5x,2:2g my_zone,m9,1x,13 my_zone,m8,2x,18 my_zone.3. Trunk 2501 starts at the intersection of my_zone edge 1 and track 2 of m10,1.5x, moves on m10 until it hits track 13 of m9,1x, then turns on m9 and moves to the existing trunk of m8 / 2x.

[0138] Figure 26 shows a multi-segment topology 2600 referencing a gutter with topology information, according to some embodiments. The command may read as follows: G_zone.1,m10,1.5x,3:2g my_zone,m9,1x,13 my_zone,m8,2x,9 my_zone.3. Trunk 2601 starts at the intersection of G_zone edge 1 with track 2 of the second gutter at m10 / 1.5x, travels at m10 until it hits track 13 at m9 / 1x, then travels at m9 until it hits track 9 at 8 / 2x.

[0139] 27A-27B show stair step topologies 2700 and 2720, respectively, with track sharing and shielding, according to some embodiments. In some embodiments, data nets or signals of interest (e.g., analog signals) can be shielded by Vcc (supply) and / or Vss (ground). One example command for track sharing and shielding is as follows: -topology t.1.m8,1.5x,160 t,m9,1x, 250 t,m8,1.5x,80 t,m9,1x,297 t.12 -stepping 20 6 20 -shield -shield_name Vss, Vcc -shield_type custom_shielded -preview clear. Here, the m8 track is shared by Vcc, data (or shielded route), and Vss, as shown in the zoomed portion 2701. Similarly for m9. This command allows stepping and sharing of paths to achieve shielding, according to some embodiments.

[0140] Shielding trunks are associated with the signal trunks they shield. Full and half shields are designated by the -shield_name option. For a full shield, either a single name (to place shield trunks on adjacent tracks on both sides of the signal trunk) or two shield names separated by a comma can be provided. The shield name on the left of the comma goes to the left or below the signal trunk depending on the layer direction, and the shield name on the right of the comma goes to the right or above the signal trunk. If there is a single shield name specified with a comma, the signal trunk is shielded on one side. If a shield name is on the left of the comma, a half shield is placed to the left or below the signal trunk depending on the layer direction. If a shield name is on the right of the comma, a half shield is placed to the right or above the signal trunk.

[0141] Figure 27B shows another example of shielding on shared nets. The commands used in this example are: -topology t.1.m8,1.5x,170 t,m9,1x,307 t,m8,1.5x,80 t,m9,1x,350 t.12 -stepping 20 6 20 -shield -shield_name Vss, Vcc -shield_type custom_shield -preview clear. In this case, m8 is shared by Vss, Data, and Vcc, as shown in zoomed version 2721. Here, Data is shielded by Vss and Vcc at m8.

[0142] Figure 28 illustrates a swizzle topology 2800 for a pair of nets, according to some embodiments. The command infrastructure allows for the implementation of a swizzle topology, also known as a twisted pair, according to some embodiments. Swizzle topologies are used in high-density channel routing for self-heating purposes. This swizzle works off a pair of nets in a single-segment topology description. This command has a special option for swizzle, -swizzle, which takes the distance in microns of the start of the topology layer / swizzle layer relative to the width of layer-1.

[0143] Swizzle is an automatic topology directive option to the command that crisscrosses signal pairs at a specified location when a straight, single-leg topology is passed. For example, if net A starts on track 1 and net B starts on track 2, and swizzle is passed, the topology layer and / or width are read along with user input for the swizzle location relative to the topology start point. Net A uses track from the existing trunk topology layer. Vias are dropped, and non-preferred direction metal is drawn in the same direction on the specified swizzle layer (either trunk layer plus 1 or trunk layer minus 1, as passed with the -swizzle option). The track direction is then rotated using the swizzle layer on the swizzle layer legal track. The tool then draws the non-preferred direction trunk on the swizzle layer. The via is then dropped, and the track continues in the topology trunk layer to the desired endpoint in the topology description. Net B draws a trunk from its starting point in the topology layer in track 2, and when it reaches the swizzle location, a non-preferred direction trunk is drawn in the same trunk layer (using the legal track of the swizzle layer) and jogs down to track 1. Once on track 1, the topology continues using the same trunk layer and completes the trunk to the topology end point using track 1 of the trunk layer.

[0144] 29A-C show a flowchart 2900 of a method for generating an intent-driven trunk topology, according to some embodiments. Although the blocks are shown in a predetermined order, the order may be changed. For example, some blocks may be performed in parallel, while other blocks may be performed out of order.

[0145] At block 2901, the user passes input parameters through the command and its options, as described herein. At block 2902, the user command is verified for validity. For example, zone definitions are processed to ensure the zones actually exist and the geometry is valid, the process topology definition is processed to ensure correct syntax for deriving tracks in terms of layers and widths, processed to ensure tracks exist, stepping is processed to ensure stepping maps to topology legs, and remaining command options are processed. If the command is valid, the process proceeds to block 2903. Otherwise, the process proceeds to block 2901. At block 2903, tracks are fetched for each zone in the topology, taking into account obstacles, porosity, and avoidance (no-go) areas. At block 2904, a determination is made as to whether the report zone capacity option is passed. If the report zone capacity option is passed in the command, the process proceeds to block 2905, where the number of tracks per layer / width for each zone is reported along with an optional display of the zones on the canvas (or graphical user interface). If the report zone capacity option is not passed in the command, processing proceeds to block 2906, referenced by indicator A.

[0146] At block 2906, the nets are reordered based on the passed options. Such options include interleave, reverse, bus expansion, mapped net references, number of trunks per net, etc. At block 2907, a master topology is calculated by processing the topology definition applying the remaining options (e.g., shield, swizzle, etc.). At block 2908, for each net, a net shape topology is calculated based on the master topology and stepping value. At block 2909, a determination is made as to whether preview mode has been enabled. If preview mode is enabled, the process proceeds to block 2910, as referenced by indicator C; otherwise, the process proceeds to block 2914, as indicated by indicator D.

[0147] At block 2910, annotations are generated on the given net using shape coordinates at layer / width, taking into account the options. At block 2911, a determination is made regarding satisfaction of the design requirements. If the design requirements are satisfied, the preview option is removed, and the command with the option values ​​(and parameters) is saved for a re-spin or re-run of the same analysis, as indicated by block 2912. The process then proceeds to block 2901, as indicated by indicator B. If the results do not satisfy the design requirements, the user can change the input parameters and / or options in the command at block 2913 and restart the intent-driven process, as indicated by indicator B.

[0148] In block 2914, annotations are generated on the given net using shape coordinates at the layer / width, taking into account the options. In block 2915, if the option to log last track was passed, the tool returns the last track number per net layer / width. For complex trunking (often involving track sharing and shielding), several trunking commands are called one after the other to achieve the desired result. Each successive command often uses the result and status of the previous command as a starting or reference point. The status of a command is characterized by the set of last track numbers used by the command. In this case, the return_last_track_number option is used to enable an interdependent chain of commands that represents a trunking recipe.

[0149] If a custom callback process option is passed, the tool calls the passed process, as indicated by block 2916. The custom callback is used to post-process the results of the trunk command, most likely for markup, maintenance, quality assessment, or bulk processing of the resulting trunk. The custom callback is a procedure, for example a TCL procedure, and is passed the collection of trunk objects generated by the command.

[0150] 30 illustrates a computer system with a machine-readable storage medium having machine-executable instructions for generating an intent-driven trunk topology, according to some embodiments. Elements of various embodiments are also provided as a machine-readable medium (e.g., memory) for storing computer-executable instructions (e.g., instructions for performing any other process discussed herein). In some embodiments, a computing platform 3000 includes a memory 3001, a processor 3002, a machine-readable storage medium 3003 (also referred to as a tangible machine-readable medium), a communication interface 3004 (e.g., a wireless or wired interface), a graphical user interface 3005, and a network bus 3006 coupled together as shown.

[0151] In some embodiments, the processor 3002 is a digital signal processor (DSP), an application specific integrated circuit (ASIC), a general purpose central processing unit (CPU), or low power logic implementing a simple finite state machine for performing various embodiments, or the like.

[0152] In some embodiments, GUI 3005 receives commands to generate an intent-driven trunk topology. Various input parameters and options can be selected via GUI 3005, and the results can be displayed on a display showing the trunk topology.

[0153] In some embodiments, the various logical blocks of system 3000 are coupled together via a network bus 3006. Any suitable protocol can be used to implement network bus 3006. In some embodiments, machine-readable storage medium 3003 includes instructions (also referred to as program software code / instructions) for generating intent-driven trunk topologies as described with reference to the various embodiments and flowcharts.

[0154] The program software code / instructions associated with the flowcharts (and / or various embodiments executed to implement embodiments of the disclosed subject matter) may be implemented as part of an operating system or a given application, component, program, object, module, routine, or other sequence of instructions referred to as "program software code / instructions," "operating system program software code / instructions," "application program software code / instructions," or simply "software," or firmware embedded in a processor. In some embodiments, the program software code / instructions associated with the flowcharts and / or various embodiments are executed by system 3000.

[0155] In some embodiments, program software code / instructions associated with the flowcharts (and / or various embodiments) are stored on a computer-executable storage medium 3003 and executed by a processor 3002, where the computer-executable storage medium 3003 is a tangible, machine-readable medium that can be used to store program software code / instructions and data that, when executed by a computing device, cause one or more processors (e.g., processor 3002) to perform a method as recited in one or more of the accompanying claims directed to the disclosed subject matter.

[0156] The tangible machine-readable medium 3003 may include storage of executable software program code / instructions and data in various tangible locations, including, for example, ROM, volatile RAM, non-volatile memory, and / or cache and / or other tangible memory as referenced herein. Portions of this program software code / instructions and / or data may be stored in any one of these storage and memory devices. Additionally, the program software code / instructions may be obtained from other storage, including the Internet, via, for example, a centralized server or a peer-to-peer network. Different portions of the software program code / instructions and data may be obtained at different times and in different communication sessions, or in the same communication session.

[0157] The software program code / instructions (as related to flowcharts and other embodiments) and data may be obtained in their entirety prior to execution of the respective software program or application by a computing device. Alternatively, portions of the software program code / instructions and data may be obtained dynamically in time, e.g., just-in-time, as needed for execution. Alternatively, some combination of these methods of obtaining the software program code / instructions and data may occur, for example, for different applications, components, programs, objects, modules, routines, other sequences of instructions, or organization of instruction sequences, as examples. Thus, it is not required that the data and instructions, as a whole, reside on a tangible machine-readable medium at a given instance of time.

[0158] Examples of tangible computer readable media 3003 include, but are not limited to, recordable and non-recordable types of media such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic storage media, optical storage media (e.g., compact disc read-only memory (CD-ROM), digital versatile disk (DVD), etc.), etc. The software program code / instructions may be stored temporarily on digital tangible communications links, while electrical, optical, acoustic, or other forms of propagated signals may be embodied as propagated waves, infrared signals, digital signals, etc. over such tangible communications links.

[0159] Generally, the tangible machine-readable medium 3003 includes any tangible mechanism that provides information in a form accessible by a computer (i.e., computing device) (i.e., stores and / or transmits information in a digital format, e.g., in data packets), whether or not applications and subsidized applications can be downloaded and executed from a communications network, such as may be included in a communications device, computing device, network device, personal digital assistant, manufacturing tool, mobile communications device, e.g., iPhone®, Galaxy®, Blackberry®, Droid®, etc. In one example, the processor-based system is in the form of or is embedded in a PDA (personal digital assistant), mobile phone, notebook computer, tablet, game console, set-top box, embedded system, TV (television), personal desktop computer, etc. Alternatively, traditional communications applications and subsidized applications may be used in some embodiments of the disclosed subject matter.

[0160] 31 illustrates a smart device, or computer system, or SoC (system-on-chip) designed using an intent-driven trunk topology, according to some embodiments. In some embodiments, device 3100 represents a suitable computing device, such as a computing tablet, a mobile phone or smartphone, a laptop, a desktop, an Internet of Things (IoT) device, a server, a wearable device, a set-top box, a wireless-enabled electronic reader, etc. It will be understood that certain components are shown generically and that not all components of such a device are shown in device 3100.

[0161] In one embodiment, device 3100 includes a system on a chip (SoC) 3101. An exemplary boundary of SoC 3101 is shown using dotted lines in Figure 31, and several exemplary components are shown as being included within SoC 3101. However, SoC 3101 may include any suitable components of device 3100.

[0162] In some embodiments, the device 3100 includes a processor 3104. The processor 3104 may include one or more physical devices, such as a microprocessor, application processor, microcontroller, programmable logic device, processing core, or other processing means. The processing operations performed by the processor 3104 include running an operating platform or operating system on which applications and / or device functions execute. The processing operations include operations related to I / O (input / output) with a human user or other devices, operations related to power management, operations related to connecting the computing device 3100 to other devices, and / or similar operations. The processing operations may also include operations related to audio I / O and / or display I / O.

[0163] In some embodiments, the processor 3104 includes multiple processing cores (also referred to as cores) 3108a, 3108b, 3108c. While only three cores 3108a, 3108b, 3108c are shown in FIG. 31, the processor 3104 may include any other suitable number of processing cores, e.g., tens or hundreds of processing cores. The processor cores 3108a, 3108b, 3108c may be implemented on a single integrated circuit (IC) chip. Additionally, the chip may include one or more shared and / or private caches, buses or interconnects, graphics and / or memory controllers, or other components.

[0164] In some embodiments, processor 3104 includes cache 3106. In one example, sections of cache 3106 may be dedicated to individual cores 3108 (e.g., a first section of cache 3106 dedicated to core 3108a, a second section of cache 3106 dedicated to core 3108b, etc.). In one example, one or more sections of cache 3106 may be shared between two or more of cores 3108. Cache 3106 may be divided into different levels, e.g., a level 1 (L1) cache, a level 2 (L2) cache, a level 3 (L3) cache, etc.

[0165] In some embodiments, processor core 3104 may include a fetch unit for retrieving instructions (including instructions with conditional branches) for execution by core 3104. Instructions may be fetched from any storage device, such as memory 3130. Processor core 3104 may also include a decode unit for decoding fetched instructions. For example, the decode unit may decode a fetched instruction into multiple micro-operations. Processor core 3104 may include a schedule unit for performing various operations related to storing decoded instructions. For example, the schedule unit may hold data from the decode unit until the instruction is ready for dispatch, e.g., until all source values ​​of the decoded instruction are available. In one example, the schedule unit may schedule and / or issue (or dispatch) decoded instructions to execution units.

[0166] The execution units may execute dispatched instructions after they are decoded (e.g., by a decode unit) and dispatched (e.g., by a schedule unit). In one embodiment, the execution units may include two or more execution units (such as an imaging computation unit, a graphics computation unit, a general-purpose computation unit, etc.). The execution units may also perform various arithmetic operations such as addition, subtraction, multiplication, and / or division and may include one or more arithmetic logic units (ALUs). In one embodiment, a coprocessor (not shown) may perform various arithmetic operations in conjunction with the execution units.

[0167] Additionally, the execution units may execute instructions out of order. Thus, in one embodiment, the processor core 3104 may be an out-of-order processor core. The processor core 3104 may also include a retirement unit. The retirement unit may retire executed instructions after they have been committed. In one embodiment, retirement of an executed instruction may result in the processor state being committed from the execution of the instruction, physical registers used by the instruction being reallocated, etc. The processor core 3104 may also include a bus unit that enables communication between components of the processor core 3104 and other components via one or more buses. The processor core 3104 may also include one or more registers that store data accessed by various components of the core 3104, such as values ​​related to assigned application priorities and / or subsystem state (mode) associations.

[0168] In some embodiments, device 3100 includes connection circuitry 3131. For example, connection circuitry 3131 includes hardware devices (e.g., wireless and / or wired connectors and communication hardware) and / or software components (e.g., drivers, protocol stacks) that, for example, enable device 3100 to communicate with external devices. Device 3100 may be isolated from external devices, such as other computing devices, wireless access points, or base stations.

[0169] In one embodiment, the connectivity circuitry 3131 may include multiple different types of connectivity. To generalize, the connectivity circuitry 3131 may include cellular connectivity circuitry, wireless connectivity circuitry, etc. The cellular connectivity circuitry of the connectivity circuitry 3131 generally refers to cellular network connectivity provided by wireless carriers, such as that provided via a global system for mobile communications (GSM) or a variation or derivative thereof, a code division multiple access (CDMA) or a variation or derivative thereof, a time division multiplexing (TDM) or a variation or derivative thereof, a 3rd Generation Partnership Project (3GPP) Universal Mobile Telecommunications System (UMTS) or a variation or derivative thereof, a 3GPP Long Term Evolution (LTE) system or a variation or derivative thereof, a 3GPP LTE-Advanced (LTE-A) system or a variation or derivative thereof, a fifth generation (5G) wireless system or a variation or derivative thereof, a 5G mobile network system or a variation or derivative thereof, a 5G New Radio (NR) system or a variation or derivative thereof, or other cellular service standard. The wireless connection circuitry (or wireless interface) of the connection circuitry 3131 refers to non-cellular wireless connections and may include personal area networks (such as Bluetooth, near field, etc.), local area networks (such as Wi-Fi), and / or wide area networks (such as WiMax), and / or other wireless communications. In one embodiment, the connection circuitry 3131 may include a network interface, such as a wired or wireless interface, such that an embodiment of the system may be incorporated into a wireless device, e.g., a mobile phone or personal digital assistant.

[0170] In some embodiments, device 3100 includes a control hub 3132 that represents hardware and / or software components related to interaction with one or more input / output devices. For example, processor 3104 can communicate with one or more of a display 3122, one or more peripheral devices 3124, storage 3128, one or more other external devices 3129, etc. via control hub 3132. Control hub 3132 may be a chipset, a platform control hub (PCH), and / or the like.

[0171] For example, control hub 3132 represents one or more connection points for additional devices to connect to device 3100, by way of example, through which a user can interact with the system. For example, devices that may be attached to device 3100 (e.g., device 3129) include a microphone device, a speaker or stereo system, an audio device, a video system or other display device, a keyboard or keypad device, or other I / O device for use in a given application, such as a card reader or other device.

[0172] As described above, the control hub 3132 can interact with audio devices, the display 3122, etc. For example, input via a microphone or other audio device can provide input or commands for one or more applications or functions of the device 3100. Furthermore, audio output can be provided instead of or in addition to display output. In another embodiment, if the display 3122 includes a touchscreen, the display 3122 also functions as an input device that can be at least partially managed by the control hub 3132. Additional buttons or switches may also be present on the computing device 3100 to provide I / O functionality managed by the control hub 3132. In one embodiment, the control hub 3132 manages devices such as an accelerometer, a camera, a light sensor or other environmental sensors, or other hardware that can be included in the device 3100. The input can be part of direct user interaction, provide environmental input to the system, and affect the operation of the system (e.g., filtering noise, adjusting the display for brightness detection, applying a flash for a camera, or other functions).

[0173] In some embodiments, the control hub 3132 can couple to various devices using any suitable communication protocol, such as Peripheral Component Interconnect Express (PCIe), Universal Serial Bus (USB), Thunderbolt, High Definition Multimedia Interface (HDMI), Firewire, etc.

[0174] In some embodiments, display 3122 represents hardware (e.g., display devices) and software (e.g., drivers) components that provide a visual and / or tactile display for a user to interact with device 3100. Display 3122 may include a display interface, a display screen, and / or a hardware device used to provide a display to a user. In some embodiments, display 3122 includes a touchscreen (or touchpad) device that provides both output and input to a user. In one example, display 3122 may communicate directly with processor 3104. Display 3122 may be one or more internal display devices, such as in a mobile electronic device or laptop device, or an external display device attached via a display interface (e.g., DisplayPort, etc.). In one example, display 3122 may be a head-mounted display (HMD), such as a stereoscopic display device for use in virtual reality (VR) or augmented reality (AR) applications.

[0175] In some embodiments, and although not shown, in addition to (or instead of) the processor 3104, the device 3100 may include a graphics processing unit (GPU) including one or more graphics processing cores that can control one or more aspects of displaying content on the display 3122.

[0176] The control hub 3132 (or platform control hub) may include, for example, hardware interfaces and connectors for peripheral device connections to the peripheral devices 3124, as well as software components (e.g., drivers, protocol stacks).

[0177] It will be appreciated that the device 3100 may be a peripheral to other computing devices and may have peripherals connected to it. The device 3100 may have a "docking" connector for connecting to other computing devices for purposes such as managing (e.g., downloading and / or uploading, modifying, synchronizing) content on the device 3100. Additionally, the docking connector may allow the computing device 3100 to connect to certain peripherals that allow the device 3100 to control content output to, for example, an audiovisual or other system.

[0178] In addition to dedicated docking connectors or other dedicated connection hardware, device 3100 can make peripheral connections through common or standards-based connectors. Common types can include Universal Serial Bus (USB) connectors (which can include any number of different hardware interfaces), Mini Display Port (MDP), High Definition Multimedia Interface (HDMI), Firewire, or DisplayPort, including other types.

[0179] In some embodiments, the connection circuitry 3131 may be coupled to the control hub 3132, for example, in addition to or instead of being directly coupled to the processor 3104. In some embodiments, the display 3122 may be coupled to the control hub 3132, for example, in addition to or instead of being directly coupled to the processor 3104.

[0180] In some embodiments, device 3100 includes memory 3130 coupled to processor 3104 via memory interface 3134. Memory 3130 includes a memory device for storing information within device 3100.

[0181] In some embodiments, memory 3130 includes a device for maintaining a stable clock, as described in connection with various embodiments. Memory may include non-volatile (state does not change when power to the memory device is interrupted) and / or volatile (state is indeterminate when power to the memory device is interrupted) memory devices. Memory device 3130 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, a phase-change memory device, or other memory device with performance suitable for serving as process memory. In one example, memory 3130 may operate as system memory for device 3100 to store data and instructions used by one or more processors 3104 when executing applications or processes. Memory 3130 may store application data, user data, music, photos, documents, or other data, as well as system data (long-term or temporary) related to the execution of applications and functions of device 3100.

[0182] Elements of various embodiments and examples may also be provided as a machine-readable medium (e.g., memory 3130) for storing computer-executable instructions (e.g., instructions for performing any other process described herein). The machine-readable medium (e.g., memory 3130) may include, but is not limited to, flash memory, optical disks, CD-ROMs, DVD-ROMs, RAM, EPROMs, EEPROMs, magnetic or optical cards, phase-change memory (PCM), or other types of machine-readable media suitable for storing electronic or computer-executable instructions. For example, embodiments of the present disclosure may be downloaded as a computer program (e.g., BIOS) that can be transferred by data signal from a remote computer (e.g., server) to a requesting computer (e.g., client) over a communications link (e.g., modem or network connection).

[0183] In some embodiments, device 3100 includes temperature measurement circuitry 3140, for example, to measure the temperatures of various components of device 3100. In one example, temperature measurement circuitry 3140 may be embedded in or coupled to various components whose temperatures are measured and monitored. For example, temperature measurement circuitry 3140 may measure the temperatures of one or more of cores 3108a, 3108b, 3108c, voltage regulator 3114, memory 3130, SoC 3101's motherboard, and / or any suitable component of device 3100.

[0184] In some embodiments, the device 3100 includes a power measurement circuit 3142, for example, to measure power consumed by one or more components of the device 3100. In one example, in addition to or instead of measuring power, the power measurement circuit 3142 can measure voltage and / or current. In one example, the power measurement circuit 3142 can be embedded in, coupled to, or attached to various components whose power, voltage, and / or current consumption are measured and monitored. For example, the power measurement circuit 3142 can measure power, current, and / or voltage supplied by one or more voltage regulators 3114, power supplied to the SoC 3101, power supplied to the device 3100, power consumed by the processor 3104 (or any other component) of the device 3100, etc.

[0185] In some embodiments, device 3100 includes one or more voltage regulator circuits, commonly referred to as voltage regulators (VRs) 3114. The VRs 3114 generate signals at appropriate voltage levels, which may be provided to operate any appropriate component of device 3100. By way of example only, the VRs 3114 are shown providing signals to the processor 3104 of device 3100. In some embodiments, the VRs 3114 receive one or more voltage identification (VID) signals and generate voltage signals at appropriate levels based on the VID signals. Various types of VRs may be utilized for the VRs 3114. For example, the VRs 3114 may include a "buck" VR, a "boost" VR, a combination of buck and boost VRs, a low dropout (LDO) regulator, a switching DC-DC regulator, a time-controller-based DC-DC regulator, etc. Buck VRs are commonly used in power delivery applications that require an input voltage to be converted to an output voltage at a ratio less than one. Boost VRs are commonly used in power delivery applications that require an input voltage to be converted to an output voltage by a ratio greater than one. In some embodiments, each processor core has its own VR controlled by the PCU3110a / b and / or PMIC3112. In some embodiments, each core has a network of distributed LDOs to provide efficient control for power management. The LDOs can be digital LDOs, analog LDOs, or a combination of digital and analog LDOs. In some embodiments, the VR3114 includes a current tracking device to measure the current through the power supply rails.

[0186] In some embodiments, device 3100 includes one or more clock generator circuits, generally referred to as clock generators 3116. Clock generators 3116 generate clock signals at appropriate frequency levels that may be provided to any appropriate components of device 3100. By way of example only, clock generator 3116 is shown providing clock signals to processor 3104 of device 3100. In some embodiments, clock generator 3116 receives one or more frequency identification (FID) signals and generates clock signals at appropriate frequencies based on the FID signals.

[0187] In some embodiments, device 3100 includes a battery 3118 that provides power to various components of device 3100. By way of example only, battery 3118 is shown powering processor 3104. Although not shown, device 3100 may include charging circuitry for, for example, recharging the battery based on alternating current (AC) power received from an AC adapter.

[0188] In some embodiments, device 3100 includes a power control unit (PCU) 3110 (also referred to as a power management unit (PMU), power controller, etc.). In one example, some sections of PCU 3110 may be implemented by one or more processing cores 3108; these sections of PCU 3110 are symbolically depicted using dotted boxes and labeled as PCU 3110a. In one example, some other sections of PCU 3110 may be implemented outside of processing cores 3108; these sections of PCU 3110 are symbolically depicted using dotted boxes and labeled as PCU 3110b. PCU 3110 can perform various power management operations for device 3100. PCU 3110 can include hardware interfaces, hardware circuits, connectors, registers, etc., as well as software components (e.g., drivers, protocol stacks) to perform various power management operations for device 3100.

[0189] In some embodiments, device 3100 includes a power management integrated circuit (PMIC) 3112, for example, to implement various power management operations for device 3100. In some embodiments, PMIC 3112 is a Reconfigurable Power Management IC (RPMIC) and / or an Intel® Mobile Voltage Positioning (IMVP). In one example, the PMIC resides in an IC chip separate from processor 3104. Various power management operations for device 3100 can be implemented. PMIC 3112 can include hardware interfaces, hardware circuits, connectors, registers, etc., as well as software components (e.g., drivers, protocol stacks) to implement various power management operations for device 3100.

[0190] In one embodiment, device 3100 includes one or both of PCU 3110 or PMIC 3112. In one embodiment, either PCU 3110 or PMIC 3112 may not be present in device 3100, and therefore, these components are illustrated using dotted lines.

[0191] Various power management operations of device 3100 may be performed by PCU 3110, by PMIC 3112, or by a combination of PCU 3110 and PMIC 3112. For example, PCU 3110 and / or PMIC 3112 may select a power state (e.g., a P-state) for various components of device 3100. For example, PCU 3110 and / or PMIC 3112 may select a power state (e.g., in accordance with the Advanced Configuration and Power Interface (ACPI) specification) for various components of device 3100. By way of example only, PCU 3110 and / or PMIC 3112 may transition various components of device 3100 into a sleep state, an active state, an appropriate C-state (e.g., a C0 state in accordance with the ACPI specification, or another appropriate C-state). In one embodiment, the PCU 3110 and / or the PMIC 3112 can control the voltage output by the VR 3114 and / or the frequency of the clock signal output by the clock generator, for example, by outputting a VID signal and / or an FID signal, respectively. In one embodiment, the PCU 3110 and / or the PMIC 3112 can control functions related to battery power usage, charging of the battery 3118, and power saving operations.

[0192] The clock generator 3116 may include a phase locked loop (PLL), a frequency locked loop (FLL), or any suitable clock source. In some embodiments, each core of the processor 3104 has its own clock source. Thus, each core can operate at a frequency independent of the operating frequency of the other cores. In some embodiments, the PCU 3110 and / or PMIC 3112 perform adaptive or dynamic frequency scaling or adjustment. For example, the clock frequency of a processor core may be increased if the core is not operating at its maximum power consumption threshold or limit. In some embodiments, if the PCU 3110 and / or PMIC 3112 determines that a core is operating below its target performance level, the PCU 3110 and / or PMIC 3112 adjusts the core's frequency and / or power supply voltage accordingly without causing the core's clock source (e.g., the core's PLL) to lose lock. For example, if a core draws less current from the power supply rails than the total current allocated for that core or processor 3104, the PCU 3110 and / or PMIC 3112 may temporarily increase power consumption for that core or processor 3104 (e.g., by increasing the clock frequency and / or power supply voltage level) so that the core or processor 3104 can operate at a higher performance level. Thus, the voltage and / or frequency can be temporarily increased for the processor 3104 without compromising product reliability.

[0193] In one embodiment, the PCU 3110 and / or the PMIC 3112 may perform power management operations based at least in part on receiving measurements from, for example, the power measurement circuit 3142, the temperature measurement circuit 3140, the charge level of the battery 3118, and / or any other suitable information that may be used for power management. To that end, the PMIC 3112 is communicatively coupled to one or more sensors to sense / detect various values / fluctuations in one or more factors that affect the power / thermal behavior of the system / platform. Examples of the one or more factors include current, voltage sag, temperature, operating frequency, operating voltage, power consumption, inter-core communication activity, etc. One or more of these sensors may be located in physical proximity to one or more components or logic / IP blocks of the computer system. Additionally, in at least one embodiment, sensors may be connected directly to the PCU3110 and / or PMIC3112 to enable the PCU3110 and / or PMIC3112 to manage processor core energy based, at least in part, on values ​​detected by one or more sensors.

[0194] An example software stack for device 3100 is also shown (although not all elements of the software stack are illustrated). By way of example only, processor 3104 may execute an application program 3150, an operating system 3152, one or more power management (PM) application programs (e.g., commonly referred to as PM applications 3158), and / or similar programs. PM application 3158 may also be executed by PCU 3110 and / or PMIC 3112. OS 3152 may also include one or more PM applications 3156a, 3156b, 3156c. OS 3152 may also include various drivers 3154a, 3154b, 3154c, etc., some of which may be specific for power management purposes. In some embodiments, device 3100 may further include a basic input / output system (BIOS) 3120. The BIOS 3120 may communicate with the OS 3152 (eg, via one or more drivers 3154 ) and with the processor 3104 .

[0195] For example, one or more of PM applications 3158, 3156, drivers 3154, BIOS 3120, etc. may be used to perform power management specific tasks, such as controlling the voltage and / or frequency of various components of device 3100, controlling the awake, sleep, and / or any other suitable power state of various components of device 3100, controlling battery power usage, charging battery 3118, functions related to power saving operations, etc.

[0196] In some embodiments, the battery 3118 is a lithium (Li) metal battery with a chamber for applying uniform pressure to the battery. The chamber is supported by a metal plate (e.g., a pressure equalization plate) that is used to apply uniform pressure to the battery. The chamber may contain pressurized gas, elastic material, a spring plate, etc. The outer plate of the chamber is free to flex and is restrained at its edges by a (metal) skin, yet still applies uniform pressure to the plate, compressing the battery cells. The chamber applies uniform pressure to the battery, which is used to enable high energy density batteries, e.g., with 20% or more battery life.

[0197] In some embodiments, the p-code (pCode) executing on the PCUs 3110a / b has functionality that allows extra computation and telemetry resources for p-code runtime support. Here, p-code refers to firmware executing on the PCUs 3110a / b to manage the performance of the SoC 3101. For example, the p-code can set the frequency and appropriate voltage for the processor. Portions of the p-code are accessible through the OS 3152. In various embodiments, mechanisms and methods are provided to dynamically change the Energy Performance Preference (EPP) value based on workload, user behavior, and / or system conditions. A well-defined interface may exist between the OS 3152 and the p-code. The interface may enable or facilitate software configuration of some parameters and / or may hint to the p-code. As one example, the EPP parameter may inform the p-code algorithm as to whether performance or battery life is more important.

[0198] This support can also be provided by OS3152 by including machine learning support as part of OS3152 and adjusting EPP values ​​that the OS hints to the hardware (e.g., various components of SoC3101) according to machine learning predictions, or by sending machine learning predictions to p-code in a manner similar to that done by Dynamic Tuning Technology (DTT) drivers. In this model, OS3152 can have visibility into the same set of telemetry available to DTT. As a result of DTT machine learning hint settings, p-code can adjust its internal algorithms to achieve optimal power and performance results according to machine learning predictions of activation types. The p-code can, for example, increase its responsibility for changes in processor utilization to enable quicker response to user activity, or it can increase its bias toward energy savings by decreasing its responsibility for processor utilization or by saving more power and increasing the performance lost by adjusting energy-saving optimizations. This approach can facilitate saving more battery life when the type of activity available results in lost performance levels above the system's usable performance level. The p-code may receive two inputs, one from OS3152 and one from software such as the DTT, and may include algorithms for dynamic EPP that can be selected to provide higher performance and / or responsiveness. As part of this method, the p-code may enable options in the DTT to tailor its response to different types of activity.

[0199] In some embodiments, an energy-efficient core-landing scheme for processor cores is used. This is similar to a preferred core in a multi-core processor system. However, here the preferred core (e.g., one of the 3108) is an energy-efficient core, allowing the SoC to use the core with the lowest Vmin (e.g., low power consumption) in terms of energy efficiency. Such Vmin values ​​are fused in appropriate registers during the HVM process. In some embodiments, an operating system (OS) scheduler can use the core ranking information to schedule a given application on the core with the lowest Vmin to achieve optimal energy performance.

[0200] In some embodiments, the bootstrap flow identifies the bootstrap processor core as the SoC's most energy-efficient core and assigns it the lowest Advanced Processor Interrupt Controller (APIC) identification (ID) value. The APIC ID value specifies the target processor for receiving interrupts delivered in logical destination mode on the local x2 APIC. It is a 32-bit value initialized by hardware. While APIC ID is an Intel architecture term, similar features in other processor architectures can also be used to identify the bootstrap processor. Initially, the BSP is core 0 3108a or any core in a multicore system. In a heterogeneous set of cores consisting of large cores (or complex and / or high-power applications) and small cores (less complex and / or low-power applications), the BSP can be one of the small cores. This initial BSP is used to identify the EE BSP.

[0201] In that context, microcode (e.g., p-code) or BIOS 3120 (embedded input / output system) reads fuses that store per-core Vmin values. These fuses are programmed during HVM. Upon reading the fuses, microcode or BIOS 3120 calculates and ranks the cores. Thus, microcode (e.g., p-code) or BIOS 3120 calculates and ranks the core APIC IDs based on their efficiency around the LFM (low frequency mode) frequency. Based on the calculated and ranked cores, microcode or BIOS 3120 transfers BSP ownership to the most efficient core (e.g., the core with the highest ranking) by setting a register (e.g., IA32_APIC_BASE.BSP=1).

[0202] In some embodiments, the microcode or BIOS 3120 then shares the APIC IDs of the cores ranked based on efficiency with the operating system (or kernel). For example, the microcode or BIOS shares the APIC IDs of the cores ranked based on efficiency with the OS via an ACPI (Advanced configuration and power interface) table such as the MADT (multiple interface controller table).

[0203] With the reordered APIC IDs, the OS efficiently services underutilized tasks, interrupts, and DPCs on the core with the lowest Vmin. Note that reordering APIC IDs also enables more efficient HW interrupt routing. In some embodiments, the OS scheduler uses the efficient cores as the preferred or desired cores for thread scheduling. If the SoC supports dynamic hardware (HW) feedback, the p-code (or any appropriate microcode or firmware) shares the updated efficient core rankings via shared memory or a model-specific register (MSR) interface.

[0204] For the present case, a reference in the specification to “an embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” means that a given feature, structure, or characteristic described in connection with an embodiment is included in at least some embodiments, but not necessarily all embodiments. Various appearances of “an embodiment,” “one embodiment,” or “some embodiments” do not necessarily refer to the same embodiments. When the specification describes a component, feature, structure, or characteristic as “may,” “might,” or “could” be included, the given component, feature, structure, or characteristic does not have to be included. When the specification or claims refer to “a” or “an” element, this does not mean that only one of the element is present. When the specification or claims refer to “an additional” element, this does not preclude one or more of the additional element from being present.

[0205] Furthermore, certain features, structures, functions, or characteristics may be combined in any suitable manner in one or more embodiments. For example, a first embodiment may be combined with a second embodiment if certain features, structures, functions, or characteristics associated with the two embodiments are not mutually exclusive.

[0206] While the present disclosure has been described in connection with certain embodiments thereof, many alternatives, modifications, and variations of such embodiments will be apparent to those skilled in the art in light of the foregoing description. The embodiments of the present disclosure are intended to embrace all such alternatives, modifications, and variations so as to fall within the broad scope of the appended claims.

[0207] Additionally, for ease of explanation and discussion and to avoid obscuring the present disclosure, well-known power / ground connections to integrated circuit (IC) chips and other components may or may not be shown in the presented figures. Furthermore, configurations may be shown in block diagram form to avoid obscuring the present disclosure and also in consideration of the fact that details regarding the implementation of such block diagram configurations will vary greatly depending on the platform on which the present disclosure is implemented (i.e., such details should be well within the purview of one skilled in the art). Where certain details (e.g., circuits) are described to explain exemplary embodiments of the present disclosure, it will be apparent to one skilled in the art that the present disclosure can be practiced without these certain details or with variations thereof. The description is therefore to be regarded as illustrative and not limiting.

[0208] The following examples relate to further embodiments. Specific details in the examples can be used anywhere in one or more embodiments. All optional features of the apparatus described herein may also be implemented in the context of a method or process. These examples may be combined in any combination. For example, Example 4 can be combined with Example 2.

[0209] Example 1: A machine-readable storage medium having machine-readable instructions that, when executed, cause one or more processors to: receive commands having input parameters and options, the commands specifying a topology description expressing nets, one or more zones, and trunk design intent; and execute the commands. and in response to execution of the command, creating one or more trunks on the net according to the topology description.

[0210] Example 2: The machine-readable storage medium of Example 1, wherein the method includes the steps of verifying the validity of a received command before executing the command, and notifying a user of an error in the received command and prompting the user to re-enter the command.

[0211] Example 3: The machine-readable storage medium of Example 1, wherein generating one or more trunks comprises: fetching tracks from a current design; and numbering the tracks with respect to an origin of the one or more zones, taking into account faults, porosity, and / or avoidance areas within the one or more zones, wherein the zones include multiple edges, and the edges are numbered clockwise from an orientation of the one or more zones; Includes.

[0212] Example 4: The machine-readable storage medium of example 1, wherein the commands are process technology node independent.

[0213] Example 5: The machine-readable storage medium of Example 1, wherein the one or more zones include one of: a current block, where the geometry of the current block defines the zone; a bounding box described by coordinates relative to the current block, where the bounding box defines the zone; a cell in any design hierarchy, where the geometry of the cell defines the boundary of the zone; a net or bus at any level of hierarchy, where the bounding box of the net defines the zone; an occlusion, placement, or routing, where the geometry of the occlusion, placement, or routing defines the zone; a gutter or gutter range, where the bounding box of the gutter from a start gutter to an end gutter defines the zone.

[0214] Example 6: The machine-readable storage medium of example 1, wherein the command includes a start point and an end point, the start point including fields separated by a separator.

[0215] Example 7: The machine-readable storage medium of example 6, wherein the separator comprises a comma.

[0216] Example 8: The machine-readable storage medium of example 6, wherein the fields include a zone, a layer, a width of a track of the layer, and a coordinate reference.

[0217] Example 9: The machine-readable storage medium of example 6, wherein the end point comprises one or more fields.

[0218] Example 10: The machine-readable storage medium of example 8, wherein the coordinate reference is applied to calculate a micron value of the coordinate based on a current design state.

[0219] Example 11: A machine-readable storage medium as described in Example 1, wherein the step of generating the one or more trunks includes applying a topology model including a start point, an end point, and any number of intermediate jog points connected by segments of one or more layers and widths, the one or more layers corresponding to one or more layers of a process technology node.

[0220] Example 12: The machine-readable storage medium of example 1, wherein the one or more zones are a reference system of coordinates of virtual objects for calculating topology point coordinates.

[0221] Example 13: The machine-readable storage medium of example 1, wherein if the command includes a preview mode, the one or more trunks are not saved in the database, and if the command does not include a preview mode, the one or more trunks are saved in the database.

[0222] Example 14: A machine-readable storage medium as described in Example 1, wherein the commands include stepping options for creating stair cases for tracks used to form the one or more trunks, options for creating pairs of swizzle or twisted tracks used to form the one or more trunks, and / or options for shielding signal nets with power and / or ground routes on the same metal layer.

[0223] Example 15: An apparatus including: a memory that stores computer-executable instructions; a processor coupled to the memory that executes the computer-executable instructions to perform operations including receiving commands having input parameters and options, the commands specifying a net, one or more zones, and a topology description that expresses trunk design intent; executing the commands; and, in response to executing the commands, creating one or more trunks on the net according to the topology description; and a display for displaying the one or more trunks.

[0224] Example 16: The apparatus of Example 15, wherein the command includes a start point and an end point, the start point includes a first set of fields separated by a separator, the separator comprising a comma, the fields including a zone, a layer, a track width of the layer, and a coordinate reference, and the end point includes one or more fields.

[0225] Example 17: The apparatus of Example 15, wherein the processor applies a topology model to generate the one or more trunks, the trunks including a start point, an end point, and any number of intermediate jog points connected by segments of one or more layers and widths, the one or more layers corresponding to one or more layers of a process technology node.

[0226] Example 18: The apparatus of example 15, wherein the zone is a reference system of coordinates of a virtual object for calculating topology point coordinates.

[0227] Example 19: The device of Example 18, wherein the virtual object is one of an exact track number, a position in microns, a position in microns snapped to the nearest track number, the last track number in the zone, the third to last track number in the zone, a percentage of track capacity, a reference from a port, a reference from a pin, a track number associated with an edge, a track number in a gutter, or a track on a specified layer.

[0228] Example 20: The device described in Example 15, wherein if the command includes a preview mode, the one or more trunks are not saved in the database, and if the command does not include a preview mode, the one or more trunks are saved in the database.

[0229] Example 21: A machine-readable storage medium containing machine-readable instructions that, when executed, cause one or more processors to perform a method including the steps of opening a graphical user interface; setting commands using input parameters and options in the graphical user interface, the commands specifying nets, one or more zones, and a topology description expressing trunk design intent; executing the commands via push buttons on the graphical user interface; and generating one or more trunks in accordance with the topology description in response to execution of the commands.

[0230] Example 22: A machine-readable storage medium as described in Example 21, wherein the method includes a step of verifying the validity of a received command before executing the command, and a step of notifying a user of an error in the received command and prompting the user to re-enter the command.

[0231] Example 23: A machine-readable storage medium as described in Example 21, wherein the step of generating one or more trunks includes the steps of fetching tracks from a current design and numbering the tracks with respect to the origin of the one or more zones, taking into account faults, porosity, and / or avoidance areas within the one or more zones, wherein the zones include multiple edges, and the edges are numbered clockwise from the orientation of the one or more zones.

[0232] An Abstract is provided to allow the reader to ascertain the nature and gist of the present technical disclosure. The Abstract is submitted with the understanding that it will not be used to limit the scope or meaning of the claims. The following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

Claims

1. A machine-readable storage medium having machine-readable instructions, comprising: The instructions, when executed, cause one or more processors to: receiving a command having input parameters and options, the command specifying a topology description expressing nets, one or more zones, and trunk design intent; executing the command; In response to execution of the command, creating one or more trunks on the net according to the topology description; causing a method to be performed, A machine-readable storage medium.

2. The method comprises: verifying the validity of the received command before executing the command; notifying a user of an error in the received command and prompting the user to re-enter the command; 10. The machine-readable storage medium of claim 1, comprising:

3. The step of creating one or more trunks comprises: fetching tracks from the current design; numbering the tracks with respect to an origin of the one or more zones, taking into account faults, porosity, and / or avoidance areas within the one or more zones, the zones including multiple edges, and the edges being numbered clockwise from the orientation of the one or more zones; 3. The machine-readable storage medium of claim 1, comprising:

4. The command is process technology node independent.

4. A machine-readable storage medium according to any one of claims 1 to 3.

5. The one or more zones include: a current block, the geometry of which defines a zone; a bounding box described by coordinates for the current block, the bounding box defining the zone; a cell in any design hierarchy, the geometry of said cell defining the boundary of said zone; a net or bus at any level of hierarchy, the bounding box of said net defining said zone; a blockage, placement, or routing, the geometry of which defines the zone; a gutter or range of gutters, the bounding box of the gutters from the start gutter to the end gutter defining the zone; including one of the following:

5. A machine-readable storage medium according to any one of claims 1 to 4.

6. the command includes a start point and an end point, the start point including fields separated by separators; 6. A machine-readable storage medium according to any one of claims 1 to 5.

7. The separator comprises a comma.

7. The machine-readable storage medium of claim 6.

8. The fields include a zone, a layer, a track width of the layer, and a coordinate reference.

8. The machine-readable storage medium according to claim 6 or 7.

9. the endpoint comprises one or more fields; 9. A machine-readable storage medium according to any one of claims 6 to 8.

10. The coordinate reference is applied to calculate a micron value for the coordinate based on the current design state.

9. The machine-readable storage medium of claim 8.

11. The step of creating the one or more trunks comprises: applying a topology model including a start point, an end point, and any number of intermediate jog points connected by segments of one or more layers and widths; the one or more layers correspond to one or more layers of a process technology node; 11. A machine-readable storage medium according to any one of claims 1 to 10.

12. the one or more zones are a reference system of coordinates of virtual objects for calculating topology point coordinates; 12. A machine-readable storage medium according to any one of claims 1 to 11.

13. If the command includes a preview mode, the one or more trunks are not saved in a database; and If the command does not include a preview mode, the one or more trunks are saved in the database.

13. A machine-readable storage medium according to any one of claims 1 to 12.

14. The command a stepping option for creating a stair case for the track used to form said one or more trunks; the option to create a pair of swizzle or twist tracks used to form the one or more trunks; and / or Option to shield signal nets with power and / or ground routes on the same metal layer; 14. A machine-readable storage medium according to any one of claims 1 to 13, comprising:

15. memory for storing computer-executable instructions; a processor coupled to the memory, for executing the computer-executable instructions, receiving a command having input parameters and options, the command specifying a topology description expressing nets, one or more zones, and trunk design intent; Execute the command, and In response to execution of the command, creating one or more trunks on the net in accordance with the topology description. a processor that performs operations including: a display for displaying one or more trunks; 1. An apparatus comprising:

16. the command includes a start point and an end point, the start point including a first set of fields separated by a separator; the separator comprises a comma; The fields include a zone, a layer, a track width of the layer, and a coordinate reference; and the endpoint comprises one or more fields; 16. The apparatus of claim 15.

17. The processor: applying a topology model to generate the one or more trunks, the trunks including start and end points and any number of intermediate jog points connected by segments of one or more layers and widths; the one or more layers correspond to one or more layers of a process technology node; 17. Apparatus according to claim 15 or 16.

18. The zone is a reference system of coordinates of a virtual object for calculating topology point coordinates.

18. Apparatus according to any one of claims 15 to 17.

19. The virtual object is Exact track number, Position in microns, Position in microns snapped to nearest track number, the last track number in said zone, the third from the last track number in said zone, Percent of truck capacity, Reference from port, Reference from pin, the track number associated with the edge, the track number in the gutter, or Tracks on a specified layer, One of the 20. The apparatus of claim 18.

20. If the command includes a preview mode, the one or more trunks are not saved in a database; and If the command does not include a preview mode, the one or more trunks are saved in the database.

20. Apparatus according to any one of claims 15 to 19.

21. A machine-readable storage medium containing machine-readable instructions, The instructions, when executed, cause one or more processors to: opening a graphical user interface; configuring commands using input parameters and options in the graphical user interface, the commands specifying nets, one or more zones, and a topology description expressing trunk design intent; executing the command via a push button on the graphical user interface; In response to execution of the command, creating one or more trunks according to the topology description; causing the device to perform a method comprising: A machine-readable storage medium.

22. The method comprises: verifying the validity of a received command before executing said command; notifying a user of an error in the received command and prompting the user to re-enter the command; 22. The machine-readable storage medium of claim 21, comprising:

23. The step of creating one or more trunks comprises: fetching tracks from the current design; numbering the tracks with respect to an origin of the one or more zones, taking into account faults, porosity, and / or avoidance areas within the one or more zones, the zones including multiple edges, and the edges being numbered clockwise from the orientation of the one or more zones; 23. The machine-readable storage medium of claim 21 or 22, comprising:

Images