99 lines
4.5 KiB
Markdown
99 lines
4.5 KiB
Markdown
|
# Corona Optical Network on Chip (NoC) Simulation
|
|||
|
|
|
|||
|
|
This project simulates the Corona all optical Network-on-Chip (NoC) architecture using SystemC TLM 2.0.
|
|||
|
|
|
|||
|
|
## Project Structure
|
|||
|
|
|
|||
|
|
Corona_NoC_Optical_230924/
|
|||
|
|
├── include/
|
|||
|
|
│ ├── configuration.h
|
|||
|
|
│ ├── core.h
|
|||
|
|
│ ├── router.h
|
|||
|
|
├── src/
|
|||
|
|
│ ├── core.cpp
|
|||
|
|
│ ├── router.cpp
|
|||
|
|
├── main.cpp
|
|||
|
|
├── Makefile
|
|||
|
|
└── README.md
|
|||
|
|
|
|||
|
|
## 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
|
|||
|
|
make
|
|||
|
|
|
|||
|
|
## Output
|
|||
|
|
./out/noc_simulation
|
|||
|
|
|
|||
|
|
|
|||
|
|
# 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
|