09-18-2018 11:18 AM
FPGA - Kinect Ultrascale
Transceiver - GTH
Speed - 1.6Gb/s
Incoming 20 bits 8b/10b encoded
For this example 1 lane
I am attempting to align on two ksel characters, BC(K.28.5) and 3C(K.28.1) they arrive as BC in the lower byte and 3C in the upper byte. <3C,BC> I would like to Receiver to align only when seeing this configuration. At the moment I have used the following settings to correctly do this.
This works at least for my current test cases. Currently the alignment is set to the RD+ for BC and RD- for 3C and I use the double length comma to detect alignment. The two byte boundary correctly aligns me to the right byte order of <3C,BC>. All of that is good for now however what I would like to do is align to any BC followed by 3C
How or what do I need to change in order to align to any BC version RD+/- followed by any 3C version RD+/-? Do I even need to worry about this case or does the protocol dictate that the first byte received is supposed to be RD+ followed by RD- version? Thank you for your time.
Note: RD + or - reference from here: https://en.wikipedia.org/wiki/8b/10b_encoding
09-19-2018 09:59 AM
the comma detection can either look for bc+3c- or bc-3c+, but not both together.
bc+3c+ and bc-3c- will not happen as the parity changes after K28.5 or K28.1 as their number of 1s and 0s is not balanced.
Check with your protocol that it definitely sends both versions of the comma. If it does, you can stick to your current setup.
You would only need to change if your protocol is sending only one version of the comma and if it can be either one. Means it chooses one version of the comma randomly and sticks to it then.
You probably need a two stage alignment then. You could use K28.5 in both parities for detection and align to two byte boundary.
Then in fabric you would need to check for the adjacent K28.1 and if correct disable further alignment.
09-19-2018 06:53 PM
I was able to verify that I am receiving both bc+ 3c- and bc- 3c+ so I will need to change my alignment to bc(K28.5)+/- with the two byte boundary. My question would then be how could I turn off the alignment once I have verified it is coming in correctly by checking for the adjacent 3C(K28.1)? Would I then need to implement a timer to check and realign every so often to be sure the lane does not drift off?
09-20-2018 01:50 AM
As you receive both possible commas, would it not be okay to just search for one of them?
It should not matter that you miss the other one.
09-20-2018 11:02 AM
It is possible that linking to just BC would work but symbol is likely to be used in both the first and second byte and different times. Therefore if I am aligning to BC I may switch by byte ordering if this occurs. For this reason I want to stick to the BC then 3C to find alignment for the receiver. (If I could change the transmit side to never move BC I would but I am under the impression the BC location is not constant).
So my questions still stand: "My question would then be how could I turn off the alignment once I have verified it is coming in correctly by checking for the adjacent 3C(K28.1)? Would I then need to implement a timer to check and realign every so often to be sure the lane does not drift off?"
09-20-2018 11:52 AM
to stop the alignment the transceiver user guide saya the following: "After successful alignment, the block holds RXBYTEISALIGNED High. At this time, RXMCOMMAALIGNEN and RXPCOMMAALIGNEN can be driven Low to turn off alignment and keep the current alignment position."
As you have the logic then already to check for K28.1, you could let this run later and check if the comma is still coming, of course in the case that your protocol is inserting this continuously. If it is not happening after your protocol dependent time, you could reenable the alignment...