Shmuel doc #78
Shmuel doc #78
Conversation
…into shmuel_doc
…into shmuel_doc
MAS for all modules. block duagram for all modules wexcept the router module organize the mess in the files location
| 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. | ||
|
|
||
| **Purpose and Functionality:** | ||
| 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. |
There was a problem hiding this comment.
Please fix the "and facilitates UART communication."
And mention that each tile has an "endpoint" component, (CPU, accelerator or other IO component such as uart)
| | clk | Input | Clock signal. | | ||
| | rst | Input | Reset signal. | | ||
| | RstPc | Input | Reset for the program counter. | | ||
| | InUartValid | Input | Valid signal for UART read/write requests. | |
There was a problem hiding this comment.
This is not the correct IO - We should have uart tx,rx.
and eventually all the FPGA IO. (switch, LED, button, VGA)
There was a problem hiding this comment.
i took the IO from the fabric.sv file. what other IO do we have?
| **Data Flow Description:** | ||
| 1. The module receives clock (`clk`) and reset (`rst`) signals for control. | ||
| 2. It handles UART read/write requests through `InUartValid` and `InUart` and provides UART responses via `OutUartValid` and `OutUart`. | ||
| 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. |
There was a problem hiding this comment.
Please add the "struct" detail of the transactions
There was a problem hiding this comment.
WIP, not sure what you mean
|
|
||
| ## 5. Configuration and Control | ||
|
|
||
| **Configuration Registers:** |
There was a problem hiding this comment.
This is not a great title - we don't have configuration register..
But we should be able to scale up the fabric to any ROW x COL + the tiles are interchangeable and can facilitate many different logic units
There was a problem hiding this comment.
Generaly this documentation is missing the essence of the fabric.
A general architecture that can facilitate many types of tiles, which are all connected in a mesh fashion.
It can scale to as many tiles as you want
Each tile has its own to its Memory Map and all memory are accessible using "Direct Memory Access (DMA)" by the fabric different aganets..
Will be used for distributed computation, AI, image process, all any type of "pipe-line" computation across different cores that move data from one to another
There was a problem hiding this comment.
done, but this is not the purpose of the HAS?
| 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. | ||
|
|
||
| # 4. Configuration and Control |
|
|
||
| The module is primarily configured through the `NEXT_TILE_CARDINAL` parameter, which specifies the preferred cardinal direction for forwarding requests. | ||
|
|
||
| # 5. Testing and Verification |
There was a problem hiding this comment.
Exaplain what are the cases that we should hit and validate in this block.
(coverage points")
| | out_local_ready | Output | Ready signal indicating the availability for data exchange to the Local direction. | | ||
| | out_local_req_valid | Output | Signal indicating the validity of requests forwarded to the Local direction. | | ||
| | out_local_req | Output | Transaction details for requests forwarded to the Local direction. | | ||
|
|
There was a problem hiding this comment.
We should add a 'main component chapter"
explaining what builds this module
There is a lot more to describe in this block
There was a problem hiding this comment.
there are lot of next_tile_fifo_arb and fifo_arb, should i explain each one of them? not sure what this chapter will describe.
| 1. The module receives requests from various directions, each with its associated validity signal, transaction details, and ready signal. | ||
| 2. It performs arbitration to determine the priority of requests from different directions. | ||
| 3. The selected request is then forwarded to the appropriate output direction. | ||
| 4. Ready signals are asserted to indicate the availability for data exchange in the selected direction. |
There was a problem hiding this comment.
Please mention the backpresure
There was a problem hiding this comment.
PLease describe how are solving the HOL-blocking problem
| | in_local_next_tile_fifo_arb_card | Output | The selected cardinal direction for forwarding requests from the Local direction. | | ||
|
|
||
| # 3. Functional Description | ||
| Operational Modes: |
There was a problem hiding this comment.
PLease describe how are solving the HOL-blocking problem
organized all the fabric doc, MAS block diagrams etc.