Serializer&Deserializer implementation and test. - #335
Conversation
|
add brief description and diagram in this PR's description section? |
yyan7223
changed the title
| NoCFlitType = mk_inter_cgra_pkt( | ||
| num_cgra_columns, | ||
| num_cgra_rows, | ||
| num_tiles, | ||
| num_rd_tiles, | ||
| FlitType | ||
| ) |
There was a problem hiding this comment.
Hmm, I think the packet->flit concept is different from my understand (based on NoC textbook).
I looked into https://github.com/tancheng/PyOCN/blob/d8ffacc64fb8dd24ce26e944d501016880302bbe/pymtl3_net/ocnlib/packets/MflitPacket.py, but found it is explicitly mentioned (non-translatable).
We either need to make it translatable, or hold on this PR. wdyt?
There was a problem hiding this comment.
Hmm, I think the packet->flit concept is different from my understand (based on NoC textbook).
I remember that you said flit head-body-tail before, do you mean this? Only head flit should contain the destination information. This may require the router to lock the routing direction after analysing the head flit, let the body flits flow along this direction, and unlock it after receiving the last flit, am I right?
We either need to make it translatable, or hold on this PR. wdyt?
Don't worry, I'm happy to follow the standard flit concept to re-design the Serialized&Deserializer. Can you share the NoC textbook with me?
There was a problem hiding this comment.
Actually I also think adding destination information for each flit is pretty redundant, but it requires no modification to other modules.
There was a problem hiding this comment.
https://dl.acm.org/doi/book/10.5555/3134175
The flit concept should be invisible to any IP (e.g., CGRA), it should be handled by the NoC itself. (maybe only serializer or deserializer needs a bit refactoring, but hopefully not)
There was a problem hiding this comment.
Hi @tancheng ,
Thank you for recommending this book. After reading it with some help from GPT, I have three questions that I’d like to discuss with you.
(1) According to the book, a flit can be represented with three main fields: Type, VCID, and Data. The PyOCN design https://github.com/tancheng/PyOCN/blob/d8ffacc64fb8dd24ce26e944d501016880302bbe/pymtl3_net/ocnlib/packets/MflitPacket.py you mentioned also supports phits and includes additional fields such as flit_idx and nflits.
However, the book states at the end of page 59:
“To date, in on-chip networks, flits are composed of a single phit and are the smallest subdivision of a message due to wide on-chip channels.”
In our case, would it therefore be reasonable to simplify NoCFlitType to contain only Type, VCID, and Data?
(2) My understanding from the book is that the VC used by a packet is allocated hop by hop. For example, before a flit is sent from Router 0 to Router 1, Router 0 selects an available input VC at Router 1, and the outgoing flit carries the corresponding VCID. The body and tail flits then inherit the VC selected for the head flit.
After looking through the PyOCN implementation with GPT, I could not find an explicit VC allocator that dynamically selects and updates the VCID in this way. Do we need to add this mechanism in our implementation? If so, we may also need an injection VC allocator/selector before Router 0 to assign the initial VCID to the flits generated by the Serializer (Or maybe put the VC allocator just in Serializer).
(3) Should the Deserializer also be VC-aware? Since flits from different packets may be interleaved on the same physical link when multiple VCs are used, a single Deserializer state may not be sufficient to reconstruct multiple packets correctly. Would it make sense for the Deserializer to maintain separate state for different VCs, or should the ejection side first select one VC and drain the whole packet before sending it to the Deserializer?
WDYT?
There was a problem hiding this comment.
When Bill Dally first developed these concepts in the 1980s and 1990s, he was designing interconnection networks for massive supercomputers (like the Cray T3D and T3E) where physical wires were tightly constrained, meaning flits > phits.
But things changed today.
All ur comments make sense. Feel free to propose your own design. You can fork PyOCN (the version we used in VectorCGRA).
2 participants
This PR is to support flit for NoC pkg (#59).
Serializer design
Serializer for converting a full NoCPktType packet into multiple NoCFlitType flits to be sent over the NoC. The packet payload is serialized from LSB to MSB. If the packet payload width is not an integer multiple of the flit payload width, the final flit is padded with zeros in its upper bits.
Deserializer design