RaveNoC - configurable Network-on-Chip

Quickstart regression
Introduction
Integration
RTL uArch
Other
License

<a name="quick"></a> Quickstart regression

To run the regression tests for the NoC, please follow the sequence below:

$ cd ravenoc_project_folder
$ docker run --rm --name ravenoc_run -v $(pwd):/ravenoc -w /ravenoc aignacio/ravenoc tox

To run a specific test, use the Makefile, replacing the SPEC_TEST variable by the name/flavor of the test you want then:

make all

Once it is running, it will create the run_dir folder with all the logs and waveforms (in .fst format) for each of the runs. To get more details of the tests please read Tb readme.

<a name="intro"></a> Introduction

RaveNoC is a configurable HDL for mesh NoCs topology that allows the user to change parameters and setup new configurations. In summary, the features of the RaveNoC are:

Mesh topology (2D-XY)
Valid/ready flow control
Switching: Pipelined wormhole
Virtual channel flow control
Slave I/F AMBA AXI4
Different IRQs that can be muxed/masked individually
Support multiple clock configurations (CDC)
Configurable parameters:
- Flit/AXI data width
- Number of buffers in the input module
- Number of virtual channels
- Order of priority in the VCs
- Dimensions of the NoC (Rows_X_Cols)
- Routing algorithm
- Maximum size of packets

<a name="usg"></a> Integration

The RTL top file exports arrays of inputs/outputs of an AXI4 slave interface that has length equal to the number of routers in the NoC i.e Rows X Cols. Also as an input parameter of ravenoc module, there is AXI_CDC_REQ array which is used to specify if each router need or not the CDC async gp fifo due to cross clock domain aspect.

There is a single clock/async. reset for the NoC and an array of clocks/async. resets for the AXIs due to the fact that every router can have a different clock domain. An additional input called bypass_cdc is used in the testbench but it is not recommended to be used during integration once if CDC is not required, the user should change the AXI_CDC_REQ parameter as mentioned in the specific array index.

See the SV structs to understand the possible values for the IRQ_RD_MUX.

<a name="pluscsrs"></a> Additional CSRs

Considering the example above, to get the size of the packet in the virtual channel 3, the user must read the address AXI_CSR_BASE_ADDR+'h24.

<a name="irqs"></a> IRQs

In the top level it is available an array of IRQs (Interrupt Request Signals) that is a struct which is connected to every router / AXI modules of the NoC. All the IRQs are related to the AXI read VC buffers of the router. Two CSRs mentioned previously are important to configure the IRQ behavior in each router. The IRQ_RD_MUX selects which is the input source for the IRQs, that can be either the empty or full flags of the read AXI buffers or a comparison with the number of flits available to be read at the read buffer. And the IRQ_RD_MASK is an input mask that does the AND logical operation with every bit of the output of IRQ_RD_MUX and in case this one is set to comparison, the mask will represent the reference value. When the MUX is selected to IRQ_PULSE_HEAD_FLIT, the IRQ needs to be acknowledged by writing any value into the IRQ_PULSE_ACK CSR. The image down below tries to explain in a more ilustrative way: IRQs RaveNoC

<a name="confparam"></a> Configurable parameters

Ravenoc

Install / Use

README