Skip to content

Commit 8ca1ad9

Browse files
actions-useractions-user
committed
organized fabric:
MAS for all modules. block duagram for all modules wexcept the router module organize the mess in the files location
1 parent d2e7335 commit 8ca1ad9

19 files changed

+1314
-1399
lines changed

‎docs/fabric/MAS_fabric/mas_fabric.md

Lines changed: 47 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,47 @@
1+
# Fabric MAS
2+
3+
## 1. Overview
4+
5+
**Brief Description:**
6+
This document outlines the micro-architecture of the `fabric` module, responsible for managing data routing, arbitration, and communication between different tiles in a tile-based system.
7+
8+
**Purpose and Functionality:**
9+
The `fabric` module serves as the interconnection fabric, enabling communication between tiles within the system. It handles data exchange in multiple directions (North, East, West, South) and facilitates UART communication. Local tile IDs are generated based on tile positions for routing.
10+
11+
## 2. Block Diagram
12+
![fabric](/drawio/fabric.jpg)
13+
14+
## 3. Interfaces
15+
16+
### Signal Descriptions:
17+
18+
| Signal Name | Direction | Description |
19+
|------------------------|-----------|---------------------------------------------------------|
20+
| clk | Input | Clock signal. |
21+
| rst | Input | Reset signal. |
22+
| RstPc | Input | Reset for the program counter. |
23+
| InUartValid | Input | Valid signal for UART read/write requests. |
24+
| InUart | Input | UART transaction details (read/write). |
25+
| OutUartValid | Output | Valid signal for UART responses. |
26+
| OutUart | Output | UART response details. |
27+
28+
29+
## 4. Functional Description
30+
31+
**Operational Modes:**
32+
The `fabric` module operates in a single mode, facilitating data routing and communication between tiles.
33+
34+
**Data Flow Description:**
35+
1. The module receives clock (`clk`) and reset (`rst`) signals for control.
36+
2. It handles UART read/write requests through `InUartValid` and `InUart` and provides UART responses via `OutUartValid` and `OutUart`.
37+
3. For tile-to-tile communication, it manages data exchange in all four cardinal directions (North, East, West, South) using arrays of signals (`in_` and `out_` signals) for request validity, transaction details, and ready signals.
38+
4. Local tile IDs are generated based on tile positions for routing.
39+
40+
## 5. Configuration and Control
41+
42+
**Configuration Registers:**
43+
The `fabric` module does not include explicit configuration registers. Configuration and control may be implemented at a higher system level.
44+
45+
## 6. Testing and Verification
46+
47+
Specify details about testing and verification procedures in the verification sidebar.

‎docs/fabric/MAS_fabric/mas_mini_core_tile.md

Lines changed: 92 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,92 @@
1+
# Mini_core_tile MAS
2+
3+
## 1. Overview
4+
5+
**Brief Description:**
6+
This document outlines the micro-architecture of the `mini_core_tile` module, which serves as a tile within a tile-based system. It manages data communication with neighboring tiles in multiple directions (North, East, West, South) and includes a local interface.
7+
8+
**Purpose and Functionality:**
9+
The `mini_core_tile` module facilitates inter-tile communication and routing of data within a tile-based system. It supports UART communication, interfaces with neighboring tiles, and includes a local interface for communication with the mini core.
10+
11+
## 2. Block Diagram
12+
![mini_core_tile](/drawio/mini_core_tile.jpg)
13+
14+
## 3. Interfaces
15+
16+
## North Interface
17+
18+
| Signal Name | Description |
19+
|------------------------|------------------------------------------|
20+
| in_north_req_valid | Validity of incoming North requests. |
21+
| in_north_req | Incoming North requests. |
22+
| in_north_ready | Ready signal for incoming North requests.|
23+
| out_north_req_valid | Validity of outgoing North requests. |
24+
| out_north_req | Outgoing North requests. |
25+
| out_north_ready | Ready signal for outgoing North requests.|
26+
27+
## East Interface
28+
29+
| Signal Name | Description |
30+
|------------------------|------------------------------------------|
31+
| in_east_req_valid | Validity of incoming East requests. |
32+
| in_east_req | Incoming East requests. |
33+
| in_east_ready | Ready signal for incoming East requests. |
34+
| out_east_req_valid | Validity of outgoing East requests. |
35+
| out_east_req | Outgoing East requests. |
36+
| out_east_ready | Ready signal for outgoing East requests. |
37+
38+
## West Interface
39+
40+
| Signal Name | Description |
41+
|------------------------|------------------------------------------|
42+
| in_west_req_valid | Validity of incoming West requests. |
43+
| in_west_req | Incoming West requests. |
44+
| in_west_ready | Ready signal for incoming West requests. |
45+
| out_west_req_valid | Validity of outgoing West requests. |
46+
| out_west_req | Outgoing West requests. |
47+
| out_west_ready | Ready signal for outgoing West requests. |
48+
49+
## South Interface
50+
51+
| Signal Name | Description |
52+
|------------------------|------------------------------------------|
53+
| in_south_req_valid | Validity of incoming South requests. |
54+
| in_south_req | Incoming South requests. |
55+
| in_south_ready | Ready signal for incoming South requests.|
56+
| out_south_req_valid | Validity of outgoing South requests. |
57+
| out_south_req | Outgoing South requests. |
58+
| out_south_ready | Ready signal for outgoing South requests.|
59+
60+
## Local Interface
61+
62+
| Signal Name | Description |
63+
|------------------------|------------------------------------------|
64+
| in_local_req_valid | Validity of incoming local requests. |
65+
| in_local_req | Incoming local requests. |
66+
| in_local_ready | Ready signal for incoming local requests.|
67+
| OutFabricValidQ505H | Validity of outgoing local requests. |
68+
| OutFabricQ505H | Outgoing local requests. |
69+
| out_local_ready | Ready signal for outgoing local requests.|
70+
71+
72+
73+
74+
## 4. Functional Description
75+
76+
**Operational Modes:**
77+
The `mini_core_tile` module operates in a single mode, facilitating data routing and communication with neighboring tiles.
78+
79+
**Data Flow Description:**
80+
1. The module receives clock (`clk`) and reset (`rst`) signals for control.
81+
2. It manages data communication in all four cardinal directions (North, East, West, South) with neighboring tiles using the specified input and output signals.
82+
3. Local requests are received and processed via the `in_local_req_valid`, `in_local_req`, and `in_local_ready` signals.
83+
4. It interfaces with the `router` module for routing data between directions.
84+
85+
## 5. Configuration and Control
86+
87+
**Configuration Registers:**
88+
The `mini_core_tile` module does not include explicit configuration registers. Configuration and control may be implemented at a higher system level.
89+
90+
## 6. Testing and Verification
91+
92+
Specify details about testing and verification procedures in the verification sidebar.

‎docs/fabric/MAS_router/mas_arbiter.md

Lines changed: 4 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
Micro-Architecture Specification (MAS) for Arbiter Module
1+
# Arbiter MAS
22
# 1. Overview
33
Brief Description:
44
This document details the micro-architecture of an Arbiter module designed to manage multiple client requests and select a winner based on a predefined arbitration scheme.
@@ -7,8 +7,7 @@ Purpose and Functionality:
77
The Arbiter module is used to arbitrate among NUM_CLIENTS clients. It determines which client gains access based on the input signals.
88

99
# 2. Block Diagram
10-
[Placeholder for Block Diagram]
11-
Insert High-Level Block Diagram of the Arbiter here
10+
![arbiter](/drawio/arbiter.jpg)
1211

1312
# 3. Interfaces
1413
Signal Descriptions:
@@ -41,21 +40,6 @@ Latency:
4140
Typically one clock cycle for arbitration decision.
4241

4342
# 7. Error Handling and Exceptions
44-
The module does not explicitly include error handling mechanisms in the provided RTL. Design-specific error handling should be considered.
43+
The module does not explicitly include error handling mechanisms in this design.
4544
# 8. Testing and Verification
46-
Test Plan Overview:
47-
48-
Verify correct arbitration among multiple clients.
49-
Test for edge cases where multiple clients request access simultaneously.
50-
Verification Strategies:
51-
52-
Simulate with varying numbers of clients.
53-
Stress test with simultaneous requests.
54-
55-
# 9. Change Log
56-
Revision History:
57-
58-
Initial version: [Date]
59-
Author Information:
60-
61-
[Author Name]
45+
In the verification sidebar.

‎docs/fabric/MAS_router/mas_fifo.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,4 @@
1+
# FIFO MAS
12
# Overview
23
Brief Description:
34
This document describes the micro-architecture specification of a FIFO (First-In-First-Out) module, designed to temporarily store and manage data in a sequential manner.

‎docs/fabric/MAS_router/mas_fifo_arb.md

Lines changed: 57 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,27 +1,57 @@
1-
# Fifo_Arb - MAS
2-
The fifo_arb Micro-Architecture-Specification
3-
A FIFO (First-In-First-Out) arbiter is a component that arbitrates between multiple FIFOs.
4-
5-
6-
## General-Description
7-
- Round Robin arbiter between 4 FIFOs
8-
- Using the Ready signals from the target TILE to determine which FIFO to pop from
9-
10-
11-
## Block Diagram
12-
13-
14-
## Top level interface
15-
16-
17-
## Main components:
18-
19-
### fifo
20-
- parametrize FIFO (first in-first out)
21-
#### Motivation:
22-
- storage requests without losing anyone.
23-
24-
### arbiter
25-
- Round Robin arbiter
26-
#### Motivation:
27-
- controll the output So that all the information is out.
1+
# FIFO_arb MAS
2+
# 1. Overview
3+
Brief Description:
4+
This document outlines the micro-architecture of a fifo_arb module designed to manage multiple client requests and select a winner based on a predefined arbitration scheme. It interfaces with multiple fifos, arbitrates among them, and selects a winner to transmit data to the next tile.
5+
6+
Purpose and Functionality:
7+
The fifo_arb module arbitrates among NUM_CLIENTS clients connected to different fifos. It uses an arbiter module to determine a winner based on the availability of data in the fifos and the readiness of the next tile to accept data.
8+
9+
# 2. Block Diagram
10+
![fifo_arb](/drawio/fifo_arb.jpg)
11+
12+
# 3. Interfaces
13+
Signal Descriptions:
14+
15+
| Signal Name | Direction | Description |
16+
|-------------------------------|-----------|--------------------------------------------------------------------|
17+
| clk | Input | Clock signal. |
18+
| rst | Input | Reset signal. |
19+
| valid_alloc_req0, 1, 2, 3 | Input | Signals indicating valid allocation requests from different clients (0 to NUM_CLIENTS-1). |
20+
| alloc_req0, 1, 2, 3 | Input | Transaction details of allocation requests from different clients (0 to NUM_CLIENTS-1). |
21+
| out_ready_fifo0, 1, 2, 3 | Output | Signals indicating whether the corresponding fifo (0 to NUM_CLIENTS-1) is ready to accept data. |
22+
| winner_req | Output | Transaction details of the winning request to be sent to the next tile. |
23+
| winner_req_valid | Output | Signal indicating the validity of the winning request. |
24+
| in_ready_north_arb_fifo | Input | Signal indicating the readiness of the arbiter fifo in the North direction. |
25+
| in_ready_east_arb_fifo | Input | Signal indicating the readiness of the arbiter fifo in the East direction. |
26+
| in_ready_south_arb_fifo | Input | Signal indicating the readiness of the arbiter fifo in the South direction. |
27+
| in_ready_west_arb_fifo | Input | Signal indicating the readiness of the arbiter fifo in the West direction. |
28+
| in_ready_local_arb_fifo | Input | Signal indicating the readiness of the arbiter fifo in the Local direction. |
29+
30+
# 4. Functional Description
31+
Operational Modes:
32+
33+
The module arbitrates among NUM_CLIENTS clients connected to different fifos.
34+
It uses the arbiter module to determine a winner based on fifo and next tile readiness.
35+
Data Flow Description:
36+
37+
Allocation requests from different clients are prioritized based on fifo and next tile readiness.
38+
Upon determining a winner, the winning request is sent to the next tile.
39+
40+
# 5. Configuration and Control
41+
Configuration Registers:
42+
43+
NUM_CLIENTS: Defines the number of clients participating in arbitration.
44+
FIFO_ARB_FIFO_DEPTH: Defines the depth of each fifo in the fifo_arb module.
45+
46+
# 6. Performance and Characteristics
47+
Throughput:
48+
Dependent on the clock frequency.
49+
50+
Latency:
51+
Dependent on the arbitration scheme and fifo availability.
52+
53+
# 7. Error Handling and Exceptions
54+
The module does not explicitly include error handling mechanisms in this design.
55+
56+
# 8. Testing and Verification
57+
In the verification sidebar.

‎docs/fabric/MAS_router/mas_next_tile_fifo_arb.md

Lines changed: 51 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,51 @@
1-
# next_tile_fifo_arb - MAS
2-
Micro Architecture specification for the next_tile_fifo_arb component
1+
# Next_tile_fifo_arb MAS
2+
# 1. Overview
3+
Brief Description:
4+
This document outlines the micro-architecture of the next_tile_fifo_arb module, which is designed to determine the cardinal direction for forwarding requests from the current tile to the next tile in a tile-based system. It takes into account the current tile's ID and the target address to make this decision.
5+
6+
Purpose and Functionality:
7+
The next_tile_fifo_arb module is responsible for selecting the cardinal direction (NORTH, EAST, SOUTH, WEST, or LOCAL) for forwarding requests based on the current tile's ID, the target address, and the availability of requests from different directions.
8+
9+
10+
# 2. Interfaces
11+
Signal Descriptions:
12+
13+
| Signal Name | Direction | Description |
14+
|---------------------------------------|-----------|----------------------------------------------------------|
15+
| clk | Input | Clock signal. |
16+
| local_tile_id | Input | The ID of the current tile. |
17+
| in_north_req_valid | Input | Signal indicating the validity of requests from the North direction. |
18+
| in_east_req_valid | Input | Signal indicating the validity of requests from the East direction. |
19+
| in_south_req_valid | Input | Signal indicating the validity of requests from the South direction. |
20+
| in_west_req_valid | Input | Signal indicating the validity of requests from the West direction. |
21+
| in_local_req_valid | Input | Signal indicating the validity of requests from the Local direction. |
22+
| in_north_req_address [31:24] | Input | Address information associated with requests from the North direction. |
23+
| in_east_req_address [31:24] | Input | Address information associated with requests from the East direction. |
24+
| in_south_req_address [31:24] | Input | Address information associated with requests from the South direction. |
25+
| in_west_req_address [31:24] | Input | Address information associated with requests from the West direction. |
26+
| in_local_req_address [31:24] | Input | Address information associated with requests from the Local direction. |
27+
| in_north_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the North direction. |
28+
| in_south_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the South direction. |
29+
| in_east_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the East direction. |
30+
| in_west_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the West direction. |
31+
| in_local_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the Local direction. |
32+
33+
# 3. Functional Description
34+
Operational Modes:
35+
36+
The module calculates the appropriate cardinal direction for forwarding requests based on the current tile's ID, the target address, and the availability of requests from different directions.
37+
38+
Data Flow Description:
39+
40+
1. The module receives requests from various directions, each with its associated validity signal and address.
41+
2. It calculates the next_tile_id based on the current tile's ID and the predefined NEXT_TILE_CARDINAL parameter.
42+
3. It determines the priority of different cardinal directions based on the target address and the current tile's ID.
43+
4. The selected cardinal direction for each request is then provided as output.
44+
45+
# 4. Configuration and Control
46+
Configuration Registers:
47+
48+
The module is primarily configured through the `NEXT_TILE_CARDINAL` parameter, which specifies the preferred cardinal direction for forwarding requests.
49+
50+
# 5. Testing and Verification
51+
In the verification sidebar.

0 commit comments

Comments
 (0)