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
object
s which implementobject.__eq__()
andobject.__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 inrig.place_and_route
(though users are free to use their own):rig.place_and_route.Cores
: Resource identifier for (monitor and application) processor cores.rig.place_and_route.SDRAM
: Resource identifier for shared off-die SDRAM (in bytes).rig.place_and_route.SRAM
: Resource identifier for shared on-die SRAM (in bytes).
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 theSystemInfo
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 aMachine
and set ofrig.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 thesystem_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. Theseslice
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 withrig.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. Theseslice
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. Theseslice
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 therig.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. Therig.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 produceThe resource allocated to the resource specified by the ``core_resource`
argument (which defaults toCores
) is assumed to indicate the core number for each vertex.For example, if a vertex,
v
, is allocated the resources{Cores: slice(1, 3)
, ifv
is the sink in a net, that tree will terminate at cores 1 and 2 of the chipv
is placed on (assumingcore_resource
isCores
).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 thecore_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 theseRoutingTree
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
set
s to store children. This was changed tolist
s 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. IfRoutes
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 theRoutes
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.
-
__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).
-
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 aSystemInfo
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 ofconstraints
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 usingrig.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.
- system_info :
-
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
ReserveResourceConstraint
s 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.
- system_info :
-
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()
andrig.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`, …]
- routes : {net: