Honored Contributor
Honored ContributorHi Maik,
--- Quote Start --- I know I should use simulation. If you take a look at the other thread I mentioned above, you see that I test everything using signal tap. Maybe you have something to add to the questions, I asked over there. --- Quote End --- I'll take a look now (I didn't have time last night). --- Quote Start --- Since I don't use 8/10b encoding just like the transceiver toolkit examples, I wonder how I perform alignment myself. I haven't found that particular part in the TTkit until now, where the alignment takes place.... --- Quote End --- The TTK examples do not use alignment *at all*. The TTK examples use a pattern generator based on a linear feedback shift-register (LFSR), which is also referred to as a pseudo-random binary sequence (PRBS) (Technically the PRBS is the bit-stream and the LFSR is the bit-stream generator). Read all about LFSRs/PRBSs here: https://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial.pdf https://www.ovro.caltech.edu/~dwh/correlator/pdf/lfsr_tutorial_src.zip An LFSR can be loaded from the bits in a PRBS sequence, and then the contents of the LFSR used to predict what the next bits in the sequence should be. That is the feature the TTK uses. What does that mean? The TTK receive side simply gathers 32-bits or 40-bits from the parallel output of the receiver, loads those into the matching LFSR (an LFSR in the receiver that matches the transmitter polynomial), and then the output of the LFSR should match the next 32-bits or 40-bits from the parallel output. The receiver parallel bits are XORed with the expected PRBS bits, and any differences are counted as bit errors. The TTK receiver is dumb ... that is the beauty of the TTK ... if it doesn't work, you know you're in trouble :) If you want to transfer actual data over a link, then you need to take care of the alignment. The simplest method is to use 8/10B encoding. Cheers, Dave
