89 lines
4.3 KiB
Markdown
89 lines
4.3 KiB
Markdown
|
||
# 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:
|
||
|
||
```bash
|
||
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
|