Corona Optical Network on Chip (NoC) Simulation with Ratatoskr

This project simulates the Corona all optical Network-on-Chip (NoC) architecture using SystemC TLM 2.0.

Prerequisites

• SystemC (version 2.3.3 or later)
• C++ compiler supporting C++17 or later (e.g., GCC 7+ or Clang 5+)
• Make

Setup

1. Install SystemC on your system.

2. Set the SYSTEMC_HOME environment variable to point to your SystemC installation directory:

   export SYSTEMC_HOME=/path/to/your/systemc/installation
   
   

Compilation

./build.sh

Output simple test - 1 Task

./sim --configFolder simple_test

Output - 2 Task

./sim --configFolder simple_2_point_test

Log file

The log file is in out/report.log

The current setup

• There are ROUTER_NO of routers. • Multiple cores (CORE_NO) are connected to each router • The cores transmit the data to each routers using non-blocking TLM • The routers receive data from core in the input fifo • The data from the input fifo is processed to find destination router • The sender router waits for the destination router's token (Semaphore) • When the semaphore is available, the sender writes the data using non-blocking write to destination router's output fifo - this confirms whether space available in the fifo too • At the destination router, the data from output fifo is processed to find the destination core • The data is transmitted to the destination core using non-blocking TLM

Introduction to Corona

The Corona architecture is as follows;

1. Architectural Design:

Corona is a 3D many-core architecture with 256 low-power multithreaded cores, organized into 64 clusters with each cluster having 4 cores and hub to facilitate communication. It uses nanophotonic communication for both inter-core and off-stack communication to memory or I/O devices. Each cluster has a channel associated with it. The channel starts at a cluster and passes through all other clusters and ends at the home cluster in a serpentine manner. Only the home cluster can read from the channel, but all other clusters can write into the channel. Each cluster has a token associated with it. The clusters can write into the channels of any other cluster by acquiring destination cluster’s token.

The key components include: • A photonic crossbar that fully interconnects the cores • Dense wavelength division multiplexed (DWDM) optically connected memory modules • An optical broadcast bus • Memory controllers and network interfaces

2. Communication Control:

Communication in Corona is controlled through a distributed, all-optical, token-based arbitration scheme. This means: • Each node participates in the token management process • Optical tokens circulate continuously through the network • Nodes must acquire a token to gain access to a communication channel

3. Communication Decisions:

The decision-making process for communication is as follows: • When to communicate: A node initiates communication when it has data to send and has acquired the appropriate token. • Who to communicate with: The destination is determined by the application needs. The photonic crossbar allows any node to communicate with any other node. • When to stop: After completing its transmission, the node releases the token back into the network.

4. Broadcast bus • In addition, there is a broadcast bus waveguide, to which all clusters can read and write • The clusters can write a common message into the broadcast bus by acquiring the broadcast token.

The corona architecture has a global optical clock and the local optical clock is in phase synchronization with the global clock.

In general, if we consider any particular cluster ‘n’, there will be a number of activities going on; • Detecting token to transmit data • Divert and acquire the token when it is detected • Transmit data by modulating light on the desired channel • Release the token once the data transmission is finished • Detect broadcast token when it has a broadcast message to send • Divert and acquire the broadcast token when it is detected • Send broadcast message by modulating light on the broadcast channel • Release broadcast token when broadcast message transmission is finished • Detects for messages on home channel ‘n’ (Reading data) • Detecting the broadcast channel for broadcast messages • Acquire and renew the home token