We have developed a High Speed on FPGA using the MGT/RocketIO to generate high speed signals. Also we receive the high speed signals using the MGT. Due to the nature of the application, we require a pure signal without encoding (We have switched off the 8B/10B encoding in the MGT). The problem is that it effects the clock recovery accuracy in the received signal as there might not be good DC balance in the signal. Which in turn effects the data received. And MGT is a black box to us.
Two options-
Another encoding mechanism such that we have pure signal and good clock recovery.
Or is there a parameter in MGT to improve the clock recovery.
We are looking for some solution around this problem.
Our setup: FPGA - Xilinx Virtex II Pro Board - Xilinx XUP Virtex(tm)-II Pro Development System Software - ISE 9.1i
The clock recovery circuitry requires that there be a minimum number of received edges per unit time. Otherwise, the recovered clock edges will drift with respect to the data stream.
If you don't use some type of encoding (e.g. 8B/10B), or you don't insure that your raw data ALWAYS provides this minimum edge density requirement, then the clock/data recovery circuitry will not work.
Perhaps a scrambler/descrambler using LFSR's would help alleviate any edge density or DC bias problems by randomizing the data a bit? I'm not sure if it would guarantee correct reception, but it may help.
You don't say why you need a "pure" signal (no coding). I could assume that you are trying to eliminate the overhead of coding (with 8b10b you only get an effective data bandwidth of 80%).
You didn't say whether or not you MUST have a DC-balanced signal. Are your transmitters AC-coupled to the receivers? If yes, the you must have a DC-balanced signal and coding IS required.
You also don't mention your clocking requirements. Do you have a common (distributed) reference clock, or are the reference clocks independant?
Typical clock recovery circuits assume plesio-synchronous operation. This means the the reference clocks can be independent but must be within +/- XYZ PPM (parts-per-million) of each other. For a receiver to track the transmitter the receiver must recover the clock (and data) from the transmitted bit stream. At high speeds this is done using PLLs. For the PLLs to perform well they require frequent edges in the transmitted bit stream.
Without a coded bit-stream you can't have DC-balance and you can't gaurantee frequent edges for the PLL. So if you really can't have a coded bit-stream then you must have a distributed (common) reference clock and you cannot use AC-coupling.
If you are trying to minimize the overhead of coding look at other coding methods like 64b/66b codes. These are more efficient but still have the benefits of DC-balanced tranmission and frequent clock edges.
Note that another benefit of 8b10b is the ability to align your symbols. How are you going to know the boundaries of a byte, a packet, etc., without a coded stream and use of non-data symbols (control symbols)? If you have independent reference clocks how are you going to avoid underrun and overrun of the reciever withouth control symbols (i.e. insertion and removal of idle characters)? Do you need any form of closed-loop flow control, error signalling, etc.? If yes, how are you going to do this without control symbols?
Thanks...we also noticed a new problem When we run our implementation on FPGA, there is loss of data on the non-active part of the signal. Its set to be 20180bits, but the number of bits received is less than that. The loss of data is not consistent either. But this doesn't appear in simulation in Modelsim. One reason could be the fact that the DC Balance is not there. But does it affect the data recovery from serial to parallel? Another option is use an external modulator chip on the receiver signal to achieve DC balance and the use the new modulated signal on MGT and decode it inside the FPGA.
Our setup: MGT Speed - 2 Gpbs FPGA - Xilinx Virtex II Pro Board - Xilinx XUP Virtex(tm)-II Pro Development System Software - ISE 9.1i
You are running into a fundamental limitation. What you receive is NRZ data, High for 1, Low for 0 (or something similar). You know that a High level of a certain duration means three ones in a row, but the receiver needs a clock to separate the bits. It gets this clock from its own PLL oscillator that is being kept alive and accurate by re- synchronizing itself from any transitions in the data stream. That's why you must have a transition quite often. Maybe you can run for 70 bits without a transition, but after tht, the PLL oscillator will drift and will not partition the incoming data stream properly. Sorry for this basic explanation, maybe everybody understands all this already. Peter Alfke
ahhhhh Thanks.. Now I get it.. So in long streams, its unable to partition the data to recover the exact bits.. hmm, I guess one solution is use an external scrambler/encoder on the signal to achieve data balance. then do descrambling/decoding inside the fpga to get the correct data..
Thats the way when you cannot use the simplest method, called 8B10B, where 10 bits are used to transmit the content of 8 data bits. Transceivers often include the necessary encoder/decoder, and DC balancing is automatically included. The penalty is a 25% loss in throughput ( e.g. only 2.5 Gbps from a 3,125 Gbps channel. Scrambling is populat with the telephone people. Peter Alfke, Xilinx
8b/10b and similar coding can always guarantee that the run length constraint is met. Scrambling is probabilistic. If your data is effectively random, once in a great while you'll get a violation of the run length constraint. If the data is packetized, retransmission will work as long as the start of the retransmission doesn't happen to occur at the same phase of the scrambler as the original transmission.
For a new design, I would use 8b/10b or similar coding rather than a scrambler, unless I had to interoperate with an existing system that uses a scrambler.
Manchester code used by many ethernet systems, also known as phase modulation or phase encoding (1600BPI 9 track tapes) is simpler, self clocking, and less efficient in bandwidth.
800BPI 9 track tape is NRZI coded and relies on odd parity for a transition in at least one track. That requires very careful azimuth adjustment on the drive. With phase encoding for 1600BPI each track clocks separately. 6250BPI are GCR coded, I don't know the specific code.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.