Route Selection Logic

Once each ALFU is given identification as explained above, it is easy to form a route selection logic which is based upon the average delay factor between the data source and data destination. It works on the principle of Expected Relieve Time (ERT).

Working: The Resource Managers of Different Cores (Ref. Figure 2) will keep track of all the ALFUs and the ALFU Utilization Table will provide the necessary details on which ALISA is getting mapped on and which ALFU gets utilized. In addition to that, the ALFU Utilization Table will have the factor ERT. It will give the number of clock cycles for which the ALFU will be utilized (or after how many clock cycles will the ALFU gets relieved *of the work load*). For different ALFUs (of the required type) different ERT values are provided by the various Core Resource Managers.

Let us consider, a data has been executed in some ALFU, and it needs to go to a destination. So, the number of clock cycles taken for the execution of a particular data is required. Let this be X. But, to which destination will the data go?? To find this, along with X, a factor called Routing Delay (lets say Y) is to be added. For these ALFUs, the expected time for transition is available in the Route Table. This table is very simple and is formed as soon as the Core Formation is done. It will contain the distance between every ALFUs (taking Core, Segment and Population into consideration).

The sum of X and Y will give (Z) the time taken for the data (which got executed in sourceALFU) to get to the destination. By keeping “minimum difference” between ERT and Z ensures data transfer without much of a wastage in clock cycle/ ALFU left free (without usage).

The routing outside Local and Global Router is done, after implementing the above said concepts. Now, there is a challenge within the router, to tackle various problems of buffering, packetizing, switching, encryption and inter-router associating.