11-03-2019 05:21 PM
i'm using gt wizard for zcu102 board, and don't know how to get the transmission aligned. The data width and internal width are both 32 bits.
i have checked the Plus comma and Minus comma and Detect comined comma in GUI, but don't know how to realize it then. Do I need to send pattern data in code before sending real data? if so what data (in 32 bit wide parrel format) should i send? and Do i need to check it in receiver. thanks.
11-04-2019 01:21 AM
typically you need to enable the 8b10b encoder and decoder for comma alignment to work.
after generating the ip, right click on the .xci file and select Open IP Example Design.
you can look at the example and know how to send the txdata patterns and how is rxdata aligned.
11-11-2019 04:18 AM
hi Boris, I've selected the options as follows, and send count data from 0x00 to 0xff. But the received data looks not aligned on four-byte boundry as expected. What's your sugggestion for this? thanks.
11-12-2019 07:31 PM
did you send at lease one byte comma (TXDATA[7:0]=BC and TXCTRL2=1'b1) after GT intialization is done (RXRESETDONE asserted)?
11-12-2019 08:37 PM
you specify the 4 byte boundary in the GUI. so you need to place the BC on the byte0. Please don't put the BC in other bytes.
if you put 4 BCs in all bytes of the data beat, the aligner will try alignment four times. every time, it will try to put received BC to the byte 0 position on RXDATA. thus the rxdata may not be aligned to the TXDATA.
my suggestion is set TXDATA=0xABCDEFBC and TXCTRL2=4'b0001.
11-12-2019 10:41 PM
it seems work now. thank you very much.
by the way, if i don't enable 8b10b, for example, for high utilization of bandwidth, how could i realize byte alignment in gth?
11-13-2019 08:38 AM
You could also use the 64B/66B encoding which has a block alignment that would do the job. You might consider using the free aurora protocol if this is a possibility as it takes care of all these issues and allows you to treat the GT as a data bus. The attached highlights the 8B10B enable.
11-13-2019 06:32 PM
without 8b10b, the comma alignment still can work. But you have a chance to encounter mis-alignment issue.
for example, if you define comma to be AABBCCDD and our comma align circuit is already aligned to the correct boundary.
later, you send some user data like this, first cycle AAxxxxxx, second cycle xxDDCCBB, and then our comma aligner will identify the comma pattern and make re-alignment occur. so the boundary becomes wrong. This is mis-alignment issue.
To avoid this, you can first send comma during training stage, after alignment is successfully achieved, you can disable the comma alignment circuit in user data stage, by de-asserting PCOMMAALIGNEN and NCOMMAALIGNEN. so that mis-alignment will not happen.
like Roy mentioned, alternatively, 64b66b can provide you high bandwidth efficicency and you don't need to do alignment because we provided the block sync module in our example.
11-14-2019 01:13 AM
comma detector is enabled by RXCOMMADETEN.
comma aligner is enabled by RXPCOMMAALIGNEN and RXNCOMMAALIGNEN.
comma pattern is defined by ALIGN_MCOMMA_VALUE, ALIGN_NCOMMA_VALUE.
The comma circuit is looking for a pattern defied by above attributes and align to the boundary of the pattern.
If you send the pattern from TX side, our receiver can identify it and aligned to it. It doesn't care if it is a 8b10b pattern or a regular pattern.
The risk is the mis-alignment. If you can carefully take care of this issue, the circuit could work.
11-18-2019 07:46 AM - edited 11-18-2019 07:51 AM
The utility of using 8B10B is that the comma pattern is designed so that no other combinations of patterns taken out of position will generate a comma and trigger a realignment that you don't want. If you don't have an encoding then you have to exclude combinations of data patterns that would generate an out of position comma and this limits what you can send over the connection. For example, if your comma were xF0 and you send x1E0f the x1E0 would be seen as an out of position comma (4 ones followed by 4 0's) and trigger a realignment. It is very unusual to not use an encoding for this reason and also the fact that random bitstreams are not dc balanced.