Necessity of an On-Node NETwork

ONNET is arrived out of the requirements posed by high-performance node architecture with heterogeneous multi-core functional units, which are essentially

- Large number of functional units

- Higher (algorithmic) level functional units

- Hierarchical organization of functional units

- High bandwidth across functional units

- Longer (128-bit) data

- Instruction and Data association in the form of packets

- Faster Memory access


Satisfying one of these parameters alone wouldn’t suffice the entire design of a node that is efficient in processing instructions of large word length (of multiple VLIW) and manage resource allocation simultaneously.
Compiler and ONNET Interaction

The hardware-based compilers (or the Compilers-On-Silicon) are designed in such a way that it must issue instructions in a streamlined fashion, regardless of the execution time (of a single ALISA). In order to generate and issue such instructions, dedicated tables are used to identify the current status of different functional units (whether they are assigned or free or used) and also that of the instructions (whether they are issued and executed or in pipeline to be scheduled) along with the allocated ALFU’s ID.

So, the COS must have synchronous control over, apart from the ALFU controller, the ONNET controllers that are dedicated for every router (let that be Local or Global). This ensures at what instant the next instruction (which is generated in the COS after resolving their dependencies) is to be mapped on and to which particular ALFU. For this, two important factors are required.

- ALFU Resource Utilization Profile – from NODE Module

- ONNET Delay factor – from ONNET Module

Once these details are estimated from the simulator, the instructions can be issued continuously and there will not be any loss of clock cycles between every instruction issue (due to pipeline stalling), or wastage of resources (due to under-clocking or unnecessary delay between instruction issue.