added more info to MAS

docs/fabric/MAS_fabric/mas_fabric.md

@@ -50,5 +50,15 @@ The `fabric` module operates in a single mode, facilitating data routing and com
 In future we will be able to cange the size of the fabric by changing the ROW and COL paramters, we will also be able to connect different tiles and not just the mini_core_tile.
 
 ## 6. Testing and Verification
+ We wanted to test some crutial points, the verification is in the [fabric verification tab](../verification/verification_fabric.md).
+
+The testing and verification of the fabric module were conducted to ensure its functionality, performance, and robustness. Several key tests were performed:
+
+1. **All Tiles Tests:** This test demonstrated that each tile within the fabric could successfully send data to any other tile. It included operations with opcodes for write (WR) and read (RD), as well as read responses (RD_RSP).
+
+2. **Stress Test:** This test put the fabric under high stress by injecting data at a rapid rate. The purpose was to evaluate the fabric's performance and stability under extreme load conditions.
+
+3. **Back Pressure (BP) Test:** In this test, all the FIFOs in the fabric were filled to capacity, simulating a scenario where the fabric is under maximum load. The test verified that the fabric could handle this situation without losing transactions and that once the fabric reached full capacity, it properly halted further transactions.
+
+These tests, along with others detailed in the fabric verification documentation, ensured that the fabric module met the required specifications and performance expectations.
 
-Specify details about testing and verification procedures in the verification sidebar.

docs/fabric/MAS_router/mas_arbiter.md

@@ -43,3 +43,7 @@ Typically one clock cycle for arbitration decision.
 The module does not explicitly include error handling mechanisms in this design.
 # 8. Testing and Verification
 In the verification sidebar.
+
+
+
+

docs/fabric/MAS_router/mas_fifo_arb.md

@@ -28,14 +28,13 @@ Signal Descriptions:
 | in_ready_local_arb_fifo       | Input     | Signal indicating the readiness of the arbiter fifo in the Local direction. |
 
 # 4. Functional Description
-Operational Modes:
+The fifo_arb module utilizes a complex Round Robin scheme to prioritize allocation requests from multiple clients. This scheme involves masking the Round Robin candidates with two conditions:
 
-The module arbitrates among NUM_CLIENTS clients connected to different fifos.
-It uses the arbiter module to determine a winner based on fifo and next tile readiness.
-Data Flow Description:
+1. Valid Request Waiting to Pop: The Round Robin candidates are masked to exclude any clients whose allocation requests are not valid or ready to be processed. This ensures that only requests that are eligible for processing are considered in the Round Robin selection.
 
-Allocation requests from different clients are prioritized based on fifo and next tile readiness.
-Upon determining a winner, the winning request is sent to the next tile.
+2. Target Readiness: Additionally, the Round Robin candidates are masked based on the readiness of the target FIFO arbiter to accept new requests. This means that even if a client has a valid request, it will only be considered if the target FIFO arbiter is ready to receive new requests. This condition optimizes the allocation process by ensuring that requests are processed efficiently and without unnecessary delays.
+
+The combination of these masking conditions in the Round Robin scheme enhances the overall efficiency and fairness of request allocation in the fifo_arb module, allowing it to effectively manage multiple client requests and select winners based on predefined criteria.
 
 # 5. Configuration and Control
 Configuration Registers:

docs/fabric/MAS_router/mas_next_tile_fifo_arb.md

@@ -30,17 +30,29 @@ Signal Descriptions:
 | in_west_next_tile_fifo_arb_card       | Output    | The selected cardinal direction for forwarding requests from the West direction.  |
 | in_local_next_tile_fifo_arb_card      | Output    | The selected cardinal direction for forwarding requests from the Local direction. |
 
-# 3. Functional Description
-Operational Modes:
 
-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.
+### 3. Functional Description
 
-Data Flow Description:
+#### Operational Modes:
+The `next_tile_fifo_arb` module operates using an "x,y" approach in its routing algorithm, determining the next cardinal direction for forwarding requests based on the current tile's ID and the target address. Here's how the "x,y" approach typically works:
 
-1. The module receives requests from various directions, each with its associated validity signal and address.
-2. It calculates the next_tile_id based on the current tile's ID and the predefined NEXT_TILE_CARDINAL parameter.
-3. It determines the priority of different cardinal directions based on the target address and the current tile's ID.
-4. The selected cardinal direction for each request is then provided as output.
+1. **Current Tile's ID (x, y):** Each tile in the system has a unique identifier represented as (x, y), where 'x' represents the column number and 'y' represents the row number.
+
+2. **Target Address (x_target, y_target):** When a request arrives at a tile, it contains the target address it needs to reach, represented as (x_target, y_target).
+
+3. **Calculating Next Cardinal Direction:**
+   - **Priority:** The "x,y" approach prioritizes reaching the 'x' coordinate (column) before the 'y' coordinate (row).
+   - **Horizontal Movement (x-axis):** If the current tile's 'x' coordinate is not equal to the target's 'x' coordinate, the routing algorithm selects the cardinal direction (EAST or WEST) that moves the request closer to the target's 'x' coordinate.
+   - **Vertical Movement (y-axis):** Once the request reaches the target's 'x' coordinate, the routing algorithm then selects the cardinal direction (NORTH or SOUTH) that moves the request closer to the target's 'y' coordinate.
+
+4. **Forwarding the Request:** Based on the calculations, the routing algorithm determines the next cardinal direction (NORTH, SOUTH, EAST, or WEST) and forwards the request to the neighboring tile in that direction.
+
+5. **Reaching the Target:** This process continues until the request reaches the tile with the target address (x_target, y_target).
+
+#### Future Improvements:
+While the current routing algorithm uses the "x,y" approach, there is potential for future enhancements to the routing scheme. One possibility is to explore a different routing approach, such as a "y,x" scheme, where requests would reach the 'y' direction before the 'x' direction. Implementing such changes would require modifying the algorithm to prioritize reaching the row before the column, potentially improving the efficiency and performance of request forwarding in specific scenarios.
+
+Another possible improvement to the routing scheme could be the use of adaptive routing. Adaptive routing algorithms dynamically select the path for each packet based on the network conditions and traffic load at the time of routing. This approach can potentially optimize the routing path to avoid congested or faulty areas in the network, leading to better overall performance and reliability. Implementing adaptive routing would involve monitoring network conditions and updating the routing decisions accordingly, which could be achieved through additional logic and decision-making mechanisms in the routing algorithm.
 
 # 4. Testing and Verification
 - In the tests we had to make sure that we get to a sevearl coverage points to ensure the reliability of this module.

docs/fabric/MAS_router/mas_router.md

@@ -100,7 +100,7 @@ In our design, HOL blocking can occur if we naively insert only one fifo_arb for
 The router module that addresses the HOL blocking problem by efficiently managing the allocation of communication resources among multiple incoming requests. Here's how the router module achieves this:
 
 1. **Input Buffering**:
-   - Incoming communication requests from neighboring tiles are first buffered in FIFO buffers within the `fifo_arb` module. Each FIFO buffer corresponds to a particular communication channel or direction.
+   - Incoming communication requests from neighboring tiles are first buffered in FIFO buffers within the `fifo_arb` module. Each FIFO buffer corresponds to a particular communication channel or direction, more info on the [mas_fifo_arb tab](mas_fifo_arb.md)
 
 2. **Arbitration**:
    - The `fifo_arb` module uses the `arbiter` module to arbitrate among the buffered requests. The `arbiter` ensures fair access to the communication resources by selecting one request at a time based on a round-robin scheduling policy.