TUM-LIS
Create generic multi-channel protocol
Create a protocol which we can layer on top of the current FIFO protocols to support multiple channels through a shared connection.
- Design a protocol (or use an existing one) to multiplex multiple channels into one FIFO connection as its currently used in GLIP. Ideally we also have a checksum in it and the ability for retransmissions, as this would have saved us multiple times in the past when moving into corner cases of the implementation.
- Implement a HW wrapper which can be used in the BACKEND_glip_toplevel modules
- Implement SW functionality for this in libglip
Hi,
this is a great thing. We should consider accomodating more functionality into a common protocol layer. For example we have the credit based flow control or the packetization into wider interfaces. In the end we may up with the glip physical/data link and with the glib transport layer or so.
Cheers, Stefan
Hi, I am currently working on this issue. I want to implement channel multiplexing module into the communication between the host and the target (nexys4ddr) using uart backend.
Main idea is using special words to trigger the channel multiplexing.
- control word: 0xBABE
- channel number word: 0xCDxx. The lower 8 bit is the channel number. That means, the max channel num = 256.
- channel number must come after control word.
- If control word needs to be transmitted as data, it needs to be transferred twice. If the second word is not the same, that is a control message.
Here is short proposal about the channel multiplexing protocol ( taken target receiving data as example):
- Data is read from FIFO and send to the (small) FIFO of each channel.
- If control word 0xBABE occurs, the next is 0xCDxx, so change the channel and send the following data until the next control word . If the next word is 0xBABE, then skip this one and continue. If the next is neither of them, a error flag will be set.
What do you think? I hope this makes sense and really look forward to hearing your opinions. Thank you very much!
Best regards, Yao
The protocol sounds good. But please choose another control word than 0xBABE. How about 0xC001?