03-18-2011 11:32 AM
We are designing a front end that needs to simply deserialize the stream. I have simulated, disabling all the rx_buffers, decoding, and channel bonding, etc. It all works great (after fixing a tiny bug in the generated code).
Now, I need to dumb it down even more and want to understand everything I have generated. I took out the frame checker and the aligner with no issues. In the GTX user guide, it says I need to include the rx_sync module for each tranceiver that I bypass the buffer. I am willing to do that, but I am not sure what is happening in there.
The only inputs to the rx_sync module are a reset and clock. This clock is the usr_clk2, which is tied to pllrec_clk. The reset signal, after removing the aligner module, is just high until the GTX reset done signal is asserted. Then, the rx_sync module asserts the various phase align signals going to the GTX. My questions are:
1. Why do the phase alignment signals need to be asserted in this order and with 32 cycles in betwen?
2. Why not assert these signals once the reset is done.
3. If the pll loses lock, it seems that you would want to realign the phase, but the GTX0_RXPLLLKDET_OUT signal does not seem to trigger any of this in the example design.
I am new at high speed serial, so thank you for helping my ignorance. Attached is my dumbed down top level example file.
03-21-2011 02:46 PM - edited 03-21-2011 02:47 PM
Another follow up question. In the V6 GTX User Guide, it says to assert the RXDLYALIGNRESET for 20 clocks (page 235-236, Fig 4-32). However, in the generated example design, this reset is asserted as long as the SYNC_DONE output of the RX_SYNC module is not asserted. This would make the reset last through the entire phase align sequence, not just at the beginning. Which is correct?
11-09-2011 02:00 AM
I have the same problem when bypassing the RX elastic buffer. The rxsync generated by the CoreGen does not perform the phase alignment process as shown in the UG196 (page 181). Instead of "detecting CDR lock by measuring the quality
of incoming data" (as sugested in the document), it just performs the align procedure 32 times, hoping that it is enough.
In my case I need trully deterministic behaviour and I guess that the elastic buffer must be bypassed, yet I dont know if this is nessesary in your case.