You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To gain more bandwidth we can use another signaling protocol on the FX3 (and other 32 bit wide physical interfaces).
Problem
GLIP is inteded to provide a 16 bit interface. If we currently have a 32 bit interface (FX3) only the lower 16 bit are used. Instead there should be some (de-) serialization. The problem is how to distinct a valid item from an invalid item on the upper 16 bit (the lower 16 bit are always set apparently).
Possible solution
A solution we chose to generate a side channel in the UART backend is to use a special word to signal no-data and to duplicate actual occurences of this item.
This requires some more fiddling and discussion.
The text was updated successfully, but these errors were encountered:
small correction here (agree otherwise): we use a 16 bit firmware for 16 bit FIFO width, so no bandwidth is wasted (e.g. on the USB bus). We're just limited by the maximum frequency of fx3_pclk, which doesn't allow using the full USB 3 bandwidth but only ~ 100 MByte/s bidirectional.
To gain more bandwidth we can use another signaling protocol on the FX3 (and other 32 bit wide physical interfaces).
Problem
GLIP is inteded to provide a 16 bit interface. If we currently have a 32 bit interface (FX3) only the lower 16 bit are used. Instead there should be some (de-) serialization. The problem is how to distinct a valid item from an invalid item on the upper 16 bit (the lower 16 bit are always set apparently).
Possible solution
A solution we chose to generate a side channel in the UART backend is to use a special word to signal no-data and to duplicate actual occurences of this item.
This requires some more fiddling and discussion.
The text was updated successfully, but these errors were encountered: