We must develop a notion of routing in order to organize the transmission of FMR packets from one target to the next.
The traditional approach to this would be to draw a graph of the network and traverse it using a pathfinding algorithm to find the shortest path possible to the node in the graph which is able to process the request. The problem with this is the overhead required to parse graph information, as well as the speed at which information will travel from one device to the next.
The way that the FMR currently works is as follows:
The host constructs a packet that contains within in an identifier of the target for which the packet is destined. When a device is processing a packet, it selects the target for which the packet is destined and exectues the appropriate invoke function. If the packet is not destined for the active target, it is forwarded along a bus. If it is, it is invoked in place and the result returned throughout the FMR heirarchy.
We can employ much the same system in the new FMR, with one caveat. The targets need to be modular. Right now, a target is a hardcoded entity that is static after compile-time. Once firmware has been built for an FMR device it is impossible to change its endpoints, or give it the abilty to interface with other FMR compatible hardware entities. A simple way to improve upon this design would be to change the notion of targets to endpoints. Endpoints will always be static at compile time because a chip has a fixed number of peripherals. If an FMR packet can wake a peripheral and perform a data transfer over it arbitrarily, then FMR becomes dynamic. The trick then becomes the process of describing to a caller the path to take (across endpoints) to the target of the packet, assuming that the zero endpoint is virtual and describes to the FMR that the packet has reached the end of its journey. A simple operation would be to encode two separate kinds of data: number of jumps, and a jump table. The jump table would be variable in length, consisting of independant 4-bit nibbles, each of which describes the endpoint to take. When a packet prepares to make a jump the first 4 bits are read and used to identify the endpoint, the jump table would be shifted right by 4-bits and forwarded along the endpoint. An entry would then be placed in a small stack indicating the endpoint from which the packet was received. A return from interrupt would then be execut d. Upon receiving a packet in the opposite direction, the stack would be popped and the packet forwarded along the given endpoint.
georgemorgan
commented
7 years ago
We must develop a notion of routing in order to organize the transmission of FMR packets from one target to the next.
The traditional approach to this would be to draw a graph of the network and traverse it using a pathfinding algorithm to find the shortest path possible to the node in the graph which is able to process the request. The problem with this is the overhead required to parse graph information, as well as the speed at which information will travel from one device to the next.
The way that the FMR currently works is as follows:
The host constructs a packet that contains within in an identifier of the target for which the packet is destined. When a device is processing a packet, it selects the target for which the packet is destined and exectues the appropriate invoke function. If the packet is not destined for the active target, it is forwarded along a bus. If it is, it is invoked in place and the result returned throughout the FMR heirarchy.
We can employ much the same system in the new FMR, with one caveat. The targets need to be modular. Right now, a target is a hardcoded entity that is static after compile-time. Once firmware has been built for an FMR device it is impossible to change its endpoints, or give it the abilty to interface with other FMR compatible hardware entities. A simple way to improve upon this design would be to change the notion of targets to endpoints. Endpoints will always be static at compile time because a chip has a fixed number of peripherals. If an FMR packet can wake a peripheral and perform a data transfer over it arbitrarily, then FMR becomes dynamic. The trick then becomes the process of describing to a caller the path to take (across endpoints) to the target of the packet, assuming that the zero endpoint is virtual and describes to the FMR that the packet has reached the end of its journey. A simple operation would be to encode two separate kinds of data: number of jumps, and a jump table. The jump table would be variable in length, consisting of independant 4-bit nibbles, each of which describes the endpoint to take. When a packet prepares to make a jump the first 4 bits are read and used to identify the endpoint, the jump table would be shifted right by 4-bits and forwarded along the endpoint. An entry would then be placed in a small stack indicating the endpoint from which the packet was received. A return from interrupt would then be execut d. Upon receiving a packet in the opposite direction, the stack would be popped and the packet forwarded along the given endpoint.