rig.place_and_route: Place applications, allocate on-chip resources, create routing tables

Rig provides a set of algorithms and utilities for mapping graph-like applications onto specific cores in a SpiNNaker machine and defining routes between them. Broadly, the task is split into three steps:

  • Placement: Assign graph vertices to a chips.
  • Allocation: Allocate specific chip resources to each vertex (e.g. cores, memory).
  • Routing: Generate routes to connect vertices according to a supplied set of nets.

Rig provides a selection of complementary algorithm implementations for each step which attempt to carry out these tasks. Users are, of course, free to use their own application-specific processes in place of any or all of these steps.

Terminology

The key pieces of terminology used are defined below:

Application Graph
The hyper-graph which describes how an application’s computational resources (the vertices) are connected to each other by nets.
Vertex

A vertex in an application graph. Each vertex is mapped onto exactly one SpiNNaker chip by during the placement process. (Note: an individual SpiNNaker chip may have several vertices mapped to it). A vertex may consume a certain set of resources. In most applications a vertex will represent an application to be run on a single SpiNNaker core.

Vertices are represented by application-defined objects which implement object.__eq__() and object.__hash__().

Net

A (directed) connection from one vertex to a number of other vertices in the application graph. During routing, nets are converted into specific routes through a SpiNNaker machine which can be used to generate routing tables.

Nets are represented by instances of the rig.netlist.Net class.

Resource

A resource is any finite resource available to a SpiNNaker chip (e.g. SDRAM) which may be consumed by a vertex. Resources are allocated to each vertex during allocation. Users are welcome to define their own application-specific resources.

The type of a resource is represented by some unique Python object. Some common resources are defined in rig.place_and_route (though users are free to use their own):

Quantities of a resource are represented by positive integer values.

Constraint

Constraints specify additional requirements on how an application graph is placed and routed. For example a constraint might be used to force a particular vertex to always be placed on a specific chip.

A number of types of constraint are defined in rig.place_and_route.constraints.

Note

It is worth emphasising that vertices are placed on SpiNNaker chips, not specific cores. In this library, cores are just one of many chip resources which vertices may consume.

For most applications, each vertex represents exactly one core worth of work and so each vertex will consume a single core of spinnaker chip resource.

Vertices which consume no cores are typically only useful when describing external devices connected to the SpiNNaker system.

Vertices which consume more than one core are unlikely to be used frequently:

  • Vertices will always be placed on a single SpiNNaker chip: they cannot be split across many chips. If an application requires this type of behaviour, users must perform this step in an application-defined process prior to placement.
  • If several cores’ applications must share some on-chip resource (e.g. SDRAM) and must be placed on the same chip, a SameChipConstraint can be used to enforce this requirement. Unlike a vertex with multiple cores, each individual vertex (core) can have independent routes directly to and from them.

place_and_route_wrapper(): common case wrapper

Most applications simply require their application graph be translated into a set of data structures describing where binaries need to be loaded and a set of routing tables. For most users the rig.place_and_route.place_and_route_wrapper() will do exactly this with a minimum of fuss. For more advanced users, this function can be used as an example of the complete place-and-route process.

rig.place_and_route.place_and_route_wrapper(vertices_resources, vertices_applications, nets, net_keys, system_info, constraints=[], place=<function place>, place_kwargs={}, allocate=<function allocate>, allocate_kwargs={}, route=<function route>, route_kwargs={}, minimise_tables_methods=(<function minimise>, <function minimise>), core_resource=Cores, sdram_resource=SDRAM, sram_resource=SRAM)[source]

Wrapper for core place-and-route tasks for the common case.

This function takes a set of vertices and nets and produces placements, allocations, minimised routing tables and application loading information.

Note

This function replaces the deprecated wrapper() function and makes use of the additional information provided by the SystemInfo object to infer the constraints required by most applications such as reserving non-idle cores such as the monitor processor.

Parameters:
vertices_resources : {vertex: {resource: quantity, …}, …}

A dictionary from vertex to the required resources for that vertex. This dictionary must include an entry for every vertex in the application.

Resource requirements are specified by a dictionary {resource: quantity, …} where resource is some resource identifier and quantity is a non-negative integer representing the quantity of that resource required.

vertices_applications : {vertex: application, …}

A dictionary from vertices to the application binary to load onto cores associated with that vertex. Applications are given as a string containing the file name of the binary to load.

nets : [Net, …]

A list (in no particular order) defining the nets connecting vertices.

net_keys : {Net: (key, mask), …}

A dictionary from nets to (key, mask) tuples to be used in SpiNNaker routing tables for routes implementing this net. The key and mask should be given as 32-bit integers.

system_info : SystemInfo

A data structure which defines the resources available in the target SpiNNaker machine, typically returned by rig.machine_control.MachineController.get_system_info(). This information will be used internally to build a Machine and set of rig.place_and_route.constraints which describe the SpiNNaker machine used and ensure placement, allocation and routing only use working and unused chips, cores, memory and links. If greater control over these datastructures is required this wrapper may not be appropriate.

constraints : [constraint, …]

Optional. A list of additional constraints on placement, allocation and routing. Available constraints are provided in the rig.place_and_route.constraints module. These constraints will be added to those derrived from the system_info argument which restrict placement and allocation to only idle cores.

place : function (Default: rig.place_and_route.place())

Optional. Placement algorithm to use.

place_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the placer.

allocate : function (Default: rig.place_and_route.allocate())

Optional. Allocation algorithm to use.

allocate_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the allocator.

route : function (Default: rig.place_and_route.route())

Optional. Routing algorithm to use.

route_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the router.

minimise_tables_methods : [rig.routing_table.minimise(), …]

Optional. An iterable of routing table minimisation algorithms to use when routing tables outgrow the space available. Each method is tried in the order presented and the first to meet the required target length for a given chip is used. Consequently less computationally costly algorithms should be nearer the start of the list. The default methods will try to remove default routes (rig.routing_table.remove_default_routes.minimise()) and then fall back on the ordered covering algorithm (rig.routing_table.ordered_covering.minimise()).

core_resource : resource (Default: Cores)

Optional. The resource identifier used for cores.

sdram_resource : resource (Default: SDRAM)

Optional. The resource identifier used for SDRAM.

sram_resource : resource (Default: SRAM)

Optional. The resource identifier used for SRAM (System RAM).

Returns:
placements : {vertex: (x, y), …}

A dictionary from vertices to the chip coordinate produced by placement.

allocations : {vertex: {resource: slice, …}, …}

A dictionary from vertices to the resources allocated to it. Resource allocations are dictionaries from resources to a slice defining the range of the given resource type allocated to the vertex. These slice objects have start <= end and step set to None.

application_map : {application: {(x, y): set([core_num, …]), …}, …}

A dictionary from application to the set of cores it should be loaded onto. The set of cores is given as a dictionary from chip to sets of core numbers.

routing_tables : {(x, y): [RoutingTableEntry, …], …}

The generated routing tables. Provided as a dictionary from chip to a list of routing table entries.

rig.place_and_route.wrapper(vertices_resources, vertices_applications, nets, net_keys, machine, constraints=[], reserve_monitor=True, align_sdram=True, place=<function place>, place_kwargs={}, allocate=<function allocate>, allocate_kwargs={}, route=<function route>, route_kwargs={}, core_resource=Cores, sdram_resource=SDRAM)[source]

Wrapper for core place-and-route tasks for the common case. At a high level this function essentially takes a set of vertices and nets and produces placements, memory allocations, routing tables and application loading information.

Warning

This function is deprecated. New users should use place_and_route_wrapper() along with rig.machine_control.MachineController.get_system_info() in place of this function. The new wrapper automatically reserves cores and SDRAM already in use in the target machine, improving on the behaviour of this wrapper which blindly reserves certain ranges of resources presuming only core 0 (the monitor processor) is not idle.

Parameters:
vertices_resources : {vertex: {resource: quantity, …}, …}

A dictionary from vertex to the required resources for that vertex. This dictionary must include an entry for every vertex in the application. Resource requirements are specified by a dictionary {resource: quantity, …} where resource is some resource identifier and quantity is a non-negative integer representing the quantity of that resource required.

vertices_applications : {vertex: application, …}

A dictionary from vertices to the application binary to load onto cores associated with that vertex. Applications are given as a string containing the file name of the binary to load.

nets : [Net, …]

A list (in no particular order) defining the nets connecting vertices.

net_keys : {Net: (key, mask), …}

A dictionary from nets to (key, mask) tuples to be used in SpiNNaker routing tables for routes implementing this net. The key and mask should be given as 32-bit integers.

machine : rig.place_and_route.Machine

A data structure which defines the resources available in the target SpiNNaker machine.

constraints : [constraint, …]

A list of constraints on placement, allocation and routing. Available constraints are provided in the rig.place_and_route.constraints module.

reserve_monitor : bool (Default: True)

Optional. If True, reserve core zero since it will be used as the monitor processor using a rig.place_and_route.constraints.ReserveResourceConstraint.

align_sdram : bool (Default: True)

Optional. If True, SDRAM allocations will be aligned to 4-byte addresses. Specifically, the supplied constraints will be augmented with an AlignResourceConstraint(sdram_resource, 4).

place : function (Default: rig.place_and_route.place())

Optional. Placement algorithm to use.

place_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the placer.

allocate : function (Default: rig.place_and_route.allocate())

Optional. Allocation algorithm to use.

allocate_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the allocator.

route : function (Default: rig.place_and_route.route())

Optional. Routing algorithm to use.

route_kwargs : dict (Default: {})

Optional. Algorithm-specific arguments for the router.

core_resource : resource (Default: Cores)

Optional. The resource identifier used for cores.

sdram_resource : resource (Default: SDRAM)

Optional. The resource identifier used for SDRAM.

Returns:
placements : {vertex: (x, y), …}

A dictionary from vertices to the chip coordinate produced by placement.

allocations : {vertex: {resource: slice, …}, …}

A dictionary from vertices to the resources allocated to it. Resource allocations are dictionaries from resources to a slice defining the range of the given resource type allocated to the vertex. These slice objects have start <= end and step set to None.

application_map : {application: {(x, y): set([core_num, …]), …}, …}

A dictionary from application to the set of cores it should be loaded onto. The set of cores is given as a dictionary from chip to sets of core numbers.

routing_tables : {(x, y): [RoutingTableEntry, …], …}

The generated routing tables. Provided as a dictionary from chip to a list of routing table entries.

Placement, allocation and routing algorithms

The three key steps of the place-and-route process (placement, allocation and routing) are broken into three functions with a common API exposed by all algorithm implementations.

Since these tasks are largely NP-complete, rig attempts to include a selection of complimentary algorithms whose function prototypes are shared (and defined below) to allow users to easily swap between them as required.

Sensible default implementations for each function are aliased as:

place() prototype

rig.place_and_route.place(vertices_resources, nets, machine, constraints, **kwargs)[source]

Place vertices on specific chips.

The placement must be such that dead chips are not used and chip resources are not over-allocated.

vertices_resources : {vertex: {resource: quantity, …}, …}

A dictionary from vertex to the required resources for that vertex. This dictionary must include an entry for every vertex in the application.

Resource requirements are specified by a dictionary {resource: quantity, …} where resource is some resource identifier and quantity is a non-negative integer representing the quantity of that resource required.

nets : [Net, …]
A list (in no particular order) defining the nets connecting vertices.
machine : rig.place_and_route.Machine
A data structure which defines the resources available in the target SpiNNaker machine.
constraints : [constraint, …]
A list of constraints on placement, allocation and routing. Available constraints are provided in the rig.place_and_route.constraints module.
**kwargs
Additional implementation-specific options.
{vertex: (x, y), …}
A dictionary from vertices to chip coordinate.
rig.place_and_route.exceptions.InvalidConstraintError
If a constraint is impossible to meet.
rig.place_and_route.exceptions.InsufficientResourceError
The placer could not find a placement where sufficient resources are available on each core.

allocate() prototype

rig.place_and_route.allocate(vertices_resources, nets, machine, constraints, placements, **kwargs)[source]

Allocate chip resources to vertices.

vertices_resources : {vertex: {resource: quantity, …}, …}

A dictionary from vertex to the required resources for that vertex. This dictionary must include an entry for every vertex in the application.

Resource requirements are specified by a dictionary {resource: quantity, …} where resource is some resource identifier and quantity is a non-negative integer representing the quantity of that resource required.

nets : [Net, …]
A list (in no particular order) defining the nets connecting vertices.
machine : rig.place_and_route.Machine
A data structure which defines the resources available in the target SpiNNaker machine.
constraints : [constraint, …]
A list of constraints on placement, allocation and routing. Available constraints are provided in the rig.place_and_route.constraints module.
placements : {vertex: (x, y), …}

A dictionary of the format returned by place() describing a set of placements of vertices.

Warning

The placement must not have vertices on dead/non-existent chips. failure to comply with this requirement will result in undefined behaviour.

**kwargs
Additional implementation-specific options.
{vertex: {resource: slice, …}, …}
A dictionary from vertices to the resources allocated to it. Resource allocations are dictionaries from resources to a slice defining the range of the given resource type allocated to the vertex. These slice objects have start <= end and step set to None (i.e. resources are allocated to vertices in continuous blocks).
rig.place_and_route.exceptions.InvalidConstraintError
If a constraint is impossible to meet.
rig.place_and_route.exceptions.InsufficientResourceError
The allocator could not allocate all desired resources to those available.

route() prototype

rig.place_and_route.route(vertices_resources, nets, machine, constraints, placements, allocations={}, core_resource=Cores, **kwargs)[source]

Generate routes which connect the vertices of all nets together.

This function produces a RoutingTree for each net which defines a multicast tree route through chips rooted at the chip containing the source vertex and visiting every chip on which a sink vertex is placed on. This data structure can then be converted into routing tables ready for loading onto a SpiNNaker machine using the rig.routing_table.routing_tree_to_tables() function. A number of routing table minimisation algorithms are also provided to cope with situations where the generated tables do not fit. The rig.routing_table.minimise_tables() function should prove sufficient for the majority of applications.

Most applications will probably wish to supply the allocations optional argument which enables the router to produce The resource allocated to the resource specified by the ``core_resource` argument (which defaults to Cores) is assumed to indicate the core number for each vertex.

For example, if a vertex, v, is allocated the resources {Cores: slice(1, 3), if v is the sink in a net, that tree will terminate at cores 1 and 2 of the chip v is placed on (assuming core_resource is Cores).

Note that if a vertex is allocated an empty set of cores, e.g. {Cores: slice(0, 0)}, the tree will terminate at the chip allocated to the vertex but not be routed to any cores.

If the allocations argument is ommitted or for any vertices not allocated the core_resource resource, the trees produced by this function do not terminate on individual cores but instead terminate on individual chips (with the exception of any constraint-enforced endpoints). The sink vertices are included in the set of children of these RoutingTree nodes but the route to these children is set to None. It is left up to the application author to decide how to route these vertices in an application-specific post-processing step.

vertices_resources : {vertex: {resource: quantity, …}, …}

A dictionary from vertex to the required resources for that vertex. This dictionary must include an entry for every vertex in the application.

Resource requirements are specified by a dictionary {resource: quantity, …} where resource is some resource identifier and quantity is a non-negative integer representing the quantity of that resource required.

nets : [Net, …]
A list (in no particular order) defining the nets connecting vertices.
machine : rig.place_and_route.Machine
A data structure which defines the resources available in the target SpiNNaker machine.
constraints : [constraint, …]
A list of constraints on placement, allocation and routing. Available constraints are provided in the rig.place_and_route.constraints module.
placements : {vertex: (x, y), …}

A dictionary of the format returned by place() describing a set of placements of vertices.

Warning

The placement must not have vertices on dead/non-existent chips. failure to comply with this requirement will result in undefined behaviour.

allocations : {vertex: {resource: slice, …}, …}
An optional dictionary of the format returned by allocate() describing the allocation of resources to vertices. If not supplied, this dictionary defaults to being empty.
core_resource : resource (Default: Cores)

Optional. Identifier of the resource in allocations which indicates the cores to route to when routing to a vertex.

Note

Vertices which do not consume this resource will result in routes which terminate at the chip they’re placed on but do not route to any cores.

Note

If no cores are allocated to a vertex, the router will still route the net to the chip where the vertex is placed, but not to any cores.

**kwargs
Additional implementation-specific options.
{Net: RoutingTree, …}
A dictionary from nets to routing trees which specify an appropriate route through a SpiNNaker machine.
rig.place_and_route.exceptions.InvalidConstraintError
If a routing constraint is impossible.
rig.place_and_route.exceptions.MachineHasDisconnectedSubregion
If any pair of vertices in a net have no path between them (i.e. the system is impossible to route).

Available algorithms

For more details on the available algorithms, see:

constraints: place and route constraints

Specifications of constraints for placement, allocation and routing.

All constraints defined in this module should be respected by any placement and routing algorithm. Individual algorithms are permitted to define their own implementation-specific constraints seperately.

class rig.place_and_route.constraints.LocationConstraint(vertex, location)[source]

Unconditionally place a vertex on a specific chip.

Attributes:
vertex : object

The user-supplied object representing the vertex.

location : (x, y)

The x- and y-coordinates of the chip the vertex must be placed on.

class rig.place_and_route.constraints.SameChipConstraint(vertices)[source]

Ensure that a group of vertices is always placed on the same chip.

Attributes:
vertices : [object, …]

The list of user-supplied objects representing the vertices to be placed together.

class rig.place_and_route.constraints.ReserveResourceConstraint(resource, reservation, location=None)[source]

Reserve a range of a resource on all or a specific chip.

For example, this can be used to reserve areas of SDRAM used by the system software to prevent allocations occurring there.

Note: Reserved ranges must not be be partly or fully outside the available resources for a chip nor may they overlap with one another. Violation of these rules will result in undefined behaviour.

Note: placers are obliged by this constraint to subtract the reserved resource from the total available resource but not to determine whether the remaining resources include sufficient continuous ranges of resource for their placement. Users should thus be extremely careful reserving resources which are not immediately at the beginning or end of a resource range.

Attributes:
resource : object

A resource identifier for the resource being reserved.

reservation : slice

The range over that resource which must not be used.

location : (x, y) or None

The chip to which this reservation applies. If None then the reservation applies globally.

class rig.place_and_route.constraints.AlignResourceConstraint(resource, alignment)[source]

Force alignment of start-indices of resource ranges.

For example, this can be used to ensure assignments into SDRAM are word aligned.

Note: placers are not obliged to be aware of or compensate for wastage of a resource due to this constraint and so may produce impossible placements in the event of large numbers of individual items using a non-aligned width block of resource.

Attributes:
resource : object

A resource identifier for the resource to align.

alignment : int

The number of which all assigned start-indices must be a multiple.

class rig.place_and_route.constraints.RouteEndpointConstraint(vertex, route)[source]

Force the endpoint of a path through the network to be a particular route.

This constraint forces routes to/from the constrained vertex to terminate on the route specified in the constraint. For example, this could be used with a vertex representing an external device to force packets sent to the vertex to be absorbed.

Note: This constraint does not check for dead links. This is useful since links attached to external devices will not typically respond to nearest-neighbour PEEK/POKE requests used by the SpiNNaker software to detect link liveness.

Example Usage

If a silicon retina is attached to the north link of chip (1,1) in a 2x2 SpiNNaker machine, the following pair of constraints will ensure traffic destined for the device vertex is routed to the appropriate link:

my_device_vertex = ...
constraints = [LocationConstraint(my_device_vertex, (1, 1)),
               RouteEndpointConstraint(my_device_vertex, Routes.north)]
Attributes:
vertex : object

The user-supplied object representing the vertex.

route : Routes

The route to which paths will be directed.

RoutingTree data structure

class rig.place_and_route.routing_tree.RoutingTree(chip, children=None)[source]

Explicitly defines a multicast route through a SpiNNaker machine.

Each instance represents a single hop in a route and recursively refers to following steps.

See also

rig.routing_table.routing_tree_to_tables
May be used to convert RoutingTree objects into routing tables suitable for loading onto a SpiNNaker machine.
Attributes:
chip : (x, y)

The chip the route is currently passing through.

children : list

A list of the next steps in the route represented by a (route, object) tuple.

Note

Up until Rig 1.5.1 this structure used sets to store children. This was changed to lists since sets incur a large memory overhead and in practice the set-like behaviour of the list of children is not useful.

The route must be either Routes or None. If Routes then this indicates the next step in the route uses a particular route.

The object indicates the intended destination of this step in the route. It may be one of:

  • RoutingTree representing the continuation of the routing tree after following a given link. (Only used if the Routes object is a link and not a core).
  • A vertex (i.e. some other Python object) when the route terminates at the supplied vertex. Note that the direction may be None and so additional logic may be required to determine what core to target to reach the vertex.
__init__(chip, children=None)[source]

x.__init__(…) initializes x; see help(type(x)) for signature

__iter__()[source]

Iterate over this node and then all its children, recursively and in no specific order. This iterator iterates over the child objects (i.e. not the route part of the child tuple).

__repr__() <==> repr(x)[source]
traverse()[source]

Traverse the tree yielding the direction taken to a node, the co-ordinates of that node and the directions leading from the Node.

Yields:
(direction, (x, y), {:py:class:`~rig.routing_table.Routes`, …})

Direction taken to reach a Node in the tree, the (x, y) co-ordinate of that Node and routes leading to children of the Node.

utils: Utility functions

Utilities functions which assist in the generation of commonly required data structures from the products of placement, allocation and routing.

rig.place_and_route.utils.build_machine(system_info, core_resource=Cores, sdram_resource=SDRAM, sram_resource=SRAM)[source]

Build a Machine object from a SystemInfo object.

Note

Links are tested by sending a ‘PEEK’ command down the link which checks to see if the remote device responds correctly. If the link is dead, no response will be received and the link will be assumed dead. Since peripherals do not generally respond to ‘PEEK’ commands, working links attached to peripherals will also be marked as dead.

Note

The returned object does not report how much memory is free, nor how many cores are idle but rather the total number of working cores and the size of the heap. See build_resource_constraints() for a function which can generate a set of constraints which prevent the use of already in-use cores and memory.

Note

This method replaces the deprecated rig.machine_control.MachineController.get_machine() method. Its functionality may be recreated using rig.machine_control.MachineController.get_system_info() along with this function like so:

>> sys_info = mc.get_system_info()
>> machine = build_machine(sys_info)
Parameters:
system_info : rig.machine_control.machine_controller.SystemInfo

The resource availability information for a SpiNNaker machine, typically produced by rig.machine_control.MachineController.get_system_info().

core_resource : resource (default: rig.place_and_route.Cores)

The resource type to use to represent the number of working cores on a chip, including the monitor, those already in use and all idle cores.

sdram_resource : resource (default: rig.place_and_route.SDRAM)

The resource type to use to represent SDRAM on a chip. This resource will be set to the number of bytes in the largest free block in the SDRAM heap. This gives a conservative estimate of the amount of free SDRAM on the chip which will be an underestimate in the presence of memory fragmentation.

sram_resource : resource (default: rig.place_and_route.SRAM)

The resource type to use to represent SRAM (a.k.a. system RAM) on a chip. This resource will be set to the number of bytes in the largest free block in the SRAM heap. This gives a conservative estimate of the amount of free SRAM on the chip which will be an underestimate in the presence of memory fragmentation.

Returns:
:py:class:`rig.place_and_route.Machine`

A Machine object representing the resources available within a SpiNNaker machine in the form used by the place-and-route infrastructure.

rig.place_and_route.utils.build_core_constraints(system_info, core_resource=Cores)[source]

Return a set of place-and-route ReserveResourceConstraint which reserve any cores that that are already in use.

The returned list of ReserveResourceConstraints reserves all cores not in an Idle state (i.e. not a monitor and not already running an application).

Note

Historically, every application was required to add a :py:class:~rig.place_and_route.constraints.ReserveResourceConstraint to reserve the monitor processor on each chip. This method improves upon this approach by automatically generating constraints which reserve not just the monitor core but also any other cores which are already in use.

Parameters:
system_info : rig.machine_control.machine_controller.SystemInfo

The resource availability information for a SpiNNaker machine, typically produced by rig.machine_control.MachineController.get_system_info().

core_resource : resource (Default: Cores)

The resource identifier used for cores.

Returns:
[:py:class:`rig.place_and_route.constraints.ReserveResourceConstraint`, …]

A set of place-and-route constraints which reserves all non-idle cores. The resource type given in the core_resource argument will be reserved accordingly.

rig.place_and_route.utils.build_application_map(vertices_applications, placements, allocations, core_resource=Cores)[source]

Build a mapping from application to a list of cores where the application is used.

This utility function assumes that each vertex is associated with a specific application.

Parameters:
vertices_applications : {vertex: application, …}

Applications are represented by the path of their APLX file.

placements : {vertex: (x, y), …}
allocations : {vertex: {resource: slice, …}, …}

One of these resources should match the core_resource argument.

core_resource : object

The resource identifier which represents cores.

Returns:
{application: {(x, y) : set([c, …]), …}, …}

For each application, for each used chip a set of core numbers onto which the application should be loaded.

rig.place_and_route.utils.build_routing_tables(routes, net_keys, omit_default_routes=True)[source]

DEPRECATED Convert a set of RoutingTrees into a per-chip set of routing tables.

Warning

This method has been deprecated in favour of rig.routing_table.routing_tree_to_tables() and rig.routing_table.minimise().

E.g. most applications should use something like:

from rig.routing_table import routing_tree_to_tables, minimise
tables = minimise(routing_tree_to_tables(routes, net_keys),
                  target_lengths)

Where target_length gives the number of available routing entries on the chips in your SpiNNaker system (see :py:func:~rig.routing_table.utils.build_routing_table_target_lengths)

This command produces routing tables with entries optionally omitted when the route does not change direction (i.e. when default routing can be used).

Warning

A rig.routing_table.MultisourceRouteError will be raised if entries with identical keys and masks but with differing routes are generated. This is not a perfect test, entries which would otherwise collide are not spotted.

Warning

The routing trees provided are assumed to be correct and continuous (not missing any hops). If this is not the case, the output is undefined.

Note

If a routing tree has a terminating vertex whose route is set to None, that vertex is ignored.

Parameters:
routes : {net: RoutingTree, …}

The complete set of RoutingTrees representing all routes in the system. (Note: this is the same datastructure produced by routers in the place_and_route module.)

net_keys : {net: (key, mask), …}

The key and mask associated with each net.

omit_default_routes : bool

Do not create routing entries for routes which do not change direction (i.e. use default routing).

Returns:
{(x, y): [:py:class:`~rig.routing_table.RoutingTableEntry`, …]