CYCLON IV GX - ALTGX Won't recieve any valid data

[Altera_Forum]

Hello 

 I'm new in the forum, seems like very nice one  me and my partner working on a final project for the university engineering degree. We have designed and manufactured two printed circuits implementing a serial connectivity based on optical fibers. Optical transceivers connected to the dedicated high speed transceivers pins. we're having difficulties getting the transceivers to work. We are trying to transmit 8bit data from one board to the other. The data is 55h repeatedly in the transmitter side but all we get in the receiver side is FFh all the time, never even a piece from the original data. The receiver is configured with low-latency PCS. We also never get rx_freqlocked asserted, even after a reset sequence as described in the handbook in the transceivers section. CDR lock mode is auto. The acceptable ppm between the pll reference clock and the CDR clock is 300 on both sides (receive and transmit), also the pll_inclk is differential 100MHz on both sides. System clock on both sides is 100MHz.   Maybe someone have an idea how to solve this problem?

[Altera_Forum]

Are you sure, that the problem is in the fpga and not on the board side? I would start checking the transmitting fpga with Signal Tap, then if Signal Tap result is ok I would take logic analyzer and check the board, then the same on receiving fpga and its board.

[Altera_Forum]

Hey 

Thanks for the fast reply We are working right now ONLY with signal tap on both sides. We did check with an oscilloscope the transmitter and the receiver and they seem to be fine. The data on the receiver board also fine. The receiver side seems to have the data (with the oscilloscope) so it looks like there's a problem with the code. I think I might get a nice picture from the oscilloscope of the data on the receiver board but only in Sunday. Would it be useful? By the way we have been told not to check the serial data out from the transmitter with signal tap because it won't work (it's too fast, but we did cache it with the oscilloscope). We have a logic analyzer but we asked and told it won't do any good and we have to use the oscilloscope. What the advantages of the logic analyzer compared to oscilloscope?

[Altera_Forum]

Hey everyone, I'm ggg456's partner for this project, let me clearify and add to what he said: 

 -Yes, we have checked the physical layer of our boards, all signals look great up to the receiver side of the FPGA.  -we are running the system at 600Mbps in order to view the signal on a scope (in order to check the signal is still properly going in.)  -the assumption I have risen today is that sending a constant data packet to the CDR will cause it to derive a clock rate that is half of the actual rate, I am planning on changing our test code to send a switching pattern between 55h and AAh, is my assumption correct?

[Altera_Forum]

--- Quote Start ---   the assumption I have risen today is that sending a constant data packet to the CDR will cause it to derive a clock rate that is half of the actual rate, I am planning on changing our test code to send a switching pattern between 55h and AAh, is my assumption correct?  --- Quote End ---    Sending 55h continuously should be fine. I'm testing 5Gbps Stratix IV GX links with a 32-bit 00FF00FFh pattern so that I can look at it on a 1GHz scope (312.5MHz).  The CDR PLLs are like high-Q filters. They lock fine to lower rate data streams where the stream has a repeating pattern that is a fraction of the data rate.  Have you tried simulating your link in Modelsim? The ALTGX blocks simulate fine - including responding correctly to the reset sequence.  I would recommend getting a simulation working first, and then when that works, review your hardware setup.  Cheers, Dave

[Altera_Forum]

Hey dave, we haven't tried simulating our link with modelsim, I'll try and run a simulation now. 

 the most important point is that freq_locked is not asserted, the question is what would cause that?

[Altera_Forum]

--- Quote Start ---   Hey dave, we haven't tried simulating our link with modelsim, I'll try and run a simulation now.   --- Quote End ---   Ok.    --- Quote Start ---   the most important point is that freq_locked is not asserted, the question is what would cause that?  --- Quote End ---    No signal on the receiver pins, incorrect reset sequence, etc.  Look at the attached document. It contains the reset sequence for a receiver-only design. I've done similar things on a Cyclone IV GX Starter Kit, and they are pretty much the same.  Use SignalTap to trace your reset controller and check that it looks the same (or at least similar).  Cheers, Dave

[Altera_Forum]

so yeah, I checked with modelsim and it works fine, we will review our code again and see maybe the physical layer is doing some troubles. 

  Thanks a lot dave!

[Altera_Forum]

--- Quote Start ---  so yeah, I checked with modelsim and it works fine, we will review our code again and see maybe the physical layer is doing some troubles.   --- Quote End ---    Set your transmitter pattern to something slow enough that you can see it with a scope, and probe the RX pins.  Check you're not missing something obvious, eg., the correct pin assignments, or a missing termination, or power supply voltage.  Also check to see whether you need to AC couple the links. If you're testing FPGA-to-FPGA, it should be ok, but if you're interfacing to something else, then check the common-mode voltage is compatible.  Cheers, Dave

[Altera_Forum]

yeah dave it's fpga to fpga, were using an LVDS rx input, could that be causing problems? we had to do the pin assignment workaround (setting it to 1.5PCML) (we're using quartus 11.1),external termination, all voltages are fine. 

  also the logic levels are beautiful, really stable.

[Altera_Forum]

--- Quote Start ---  yeah dave it's fpga to fpga, were using an LVDS rx input, could that be causing problems? we had to do the pin assignment workaround (setting it to 1.5PCML) (we're using quartus 11.1),external termination, all voltages are fine.   --- Quote End ---    Could you please clarify.   Are you using an LVDS receiver channel or a transceiver channel?  I don't recall if the common-mode settings on a Cyclone support LVDS levels on the CML inputs. Can you can run a quick test where you AC-couple the signals?  For example, in my tests the signals are on SMA cables, so its easy to put a DC-block on the cables. Perhaps you can do the same.   Cheers, Dave

[Altera_Forum]

Okay let me clarify. 

 we chose to use the LVDS standard for the input of our reciever, the signal path is going from fpga# 1 to a pcml -> lvpecl converter to an AC coupled fiber transceiver (the ac coupling is internal.) after the fiber it goes to another converter from lvpecl to lvds and from that converter with a termination resistor into the rx of fpga# 2 I've added the schematic for you to look.

[Altera_Forum]

Ok, thanks, that is clearer. 

 So you have LVDS DC-coupled into a transceiver receiver channel on a EP4CGX50F484.  The common-mode voltage of LVDS is 1.25V, whereas the common-mode voltage of the receivers is 0.82V. In general I would have recommended AC-coupling these signals. However, "Table 1–2. Electrical Features Supported by the Receiver Input Buffer" in the Cyclone handbook indicates that DC coupling should be ok.  If you probe the signals at those receiver pins, how do they look, and what is the common-mode voltage?  Since you have an external termination, did you disable the on-chip termination (OCT)?  Cheers, Dave

[Altera_Forum]

Hey Dave, the waveforms that come out of the max9376 are really clean and comply with its datasheet, the vcm is indeed 1.25 volts. 

we have disabled OCT a long time ago but we will review all of these setting again.  the thing is we checked that the receiver FPGA can differentiate between '1' and '0' on the GXB lines and it does so it seems that using LVDS is fine.  it's a Friday so we're out of the office now, we will check everything Sunday hopefully.   Dave, thank you for all your help so far, we've been stuck on this problem for quite some time and we can use all the help we can get.

[Altera_Forum]

--- Quote Start ---  the waveforms that come out of the max9376 are really clean and comply with its datasheet, the vcm is indeed 1.25 volts. we have disabled OCT a long time ago but we will review all of these setting again.   --- Quote End ---    The fact that you measure 1.25V means that you have OCT disabled. If you did not, then the termination would be an external 100-Ohms in parallel with two 50-ohms terminated to 0.82V. I would expect that network would have a smaller voltage swing and a different offset voltage.    --- Quote Start ---   the thing is we checked that the receiver FPGA can differentiate between '1' and '0' on the GXB lines and it does so it seems that using LVDS is fine.   --- Quote End ---   Hang on, you said you could not receive any valid data. If you can differentiate between a 0 and a 1, that is valid data!!! :)    --- Quote Start ---   it's a Friday so we're out of the office now, we will check everything Sunday hopefully.  Dave, thank you for all your help so far, we've been stuck on this problem for quite some time and we can use all the help we can get.  --- Quote End ---    Talk to you soon then :)  Cheers, Dave

[Altera_Forum]

Hey dave, so we tested the new code, now sending f0 to get a slow repeating signal and yet we still can't get a freq_locked signal. 

 it seems that it is a physical problem after all..., we have no way to be certain since the signal seems fine. the bigger problem is we can't ac couple the signal since the board is already built, unless there is some way to do it.  the other thing is that we disabled Rref so we can't use internal termination since it has no refference resistors.  is there anything we can do?

[Altera_Forum]

--- Quote Start ---  Hey dave, so we tested the new code, now sending f0 to get a slow repeating signal and yet we still can't get a freq_locked signal.   --- Quote End ---    Ignore the freq_locked signal for a bit. In your first post you said you were always getting 0xFF. Is that the case now? Can you sometimes gets 0s or 1s? Did you look at the pages from the document I posted? You should reproduce those SignalTap II traces for your own design and confirm that you are reproducing the data sheet recommendations.  Did you check the Altera Knowledge Base for issues with your particular version of software? In Quartus 12.1sp1, freqlocked does not work properly on the Stratix IV series devices. The signal stays high. However, that does not affect the operation of the link, it just means that freqlocked is no use for detecting a broken link.    --- Quote Start ---   it seems that it is a physical problem after all..., we have no way to be certain since the signal seems fine. the bigger problem is we can't ac couple the signal since the board is already built, unless there is some way to do it.   --- Quote End ---   I don't see any problem with your LVDS circuit. It should work ok. Do you have another board or another receiver on the same board you can check?    --- Quote Start ---   is there anything we can do?  --- Quote End ---   Do you have another Cyclone IV GX board you can test? Either one of your custom boards or an Altera kit?  Did you check the power supplies on your receiver channel? Double check to make sure all the voltages are correct.  Cheers, Dave

[Altera_Forum]

-when we ignore freq_locked, we still get a constant ffh,  

-we are using quartus 11.1 -we are constantly interchanging the boards to assure this is an issue with the code/ hardware rather than a specific board.  -I checked the datasheet and it seems that while the altgx supports Lvds, it's with an 0.82 vcm so it is probably holding a constant '1', the optical transciever is AC coupled so sending a constant bit will simply disconnect it which is why we thought t he fpga gets valid data.  Is there anything we can do?

[Altera_Forum]

--- Quote Start ---   -when we ignore freq_locked, we still get a constant ffh,  -I checked the datasheet and it seems that while the altgx supports Lvds, it's with an 0.82 vcm so it is probably holding a constant '1', the optical transciever is AC coupled so sending a constant bit will simply disconnect it which is why we thought t he fpga gets valid data.  Is there anything we can do?  --- Quote End ---    This is the root cause of your problem.  You can DC-couple LVDS signals into the OCT, i.e., the *internal* on-chip termination. You cannot use an external termination and DC-couple the signals, because the LVDS signal swing is then 1.25V +/- 200mV (or so), so the minimum LVDS logic level is higher than the receiver common-mode voltage.    --- Quote Start ---   the other thing is that we disabled Rref so we can't use internal termination since it has no refference resistors   --- Quote End ---    Ok, so OCT needs the RREF resistor. Is there any way you can add an external OCT reference resistor?  If not, then you will have to create your own external termination network such that it looks like a 100-ohm differential termination with a common-mode of 0.82V  These types of networks are commonly used when you need to interface say LVPECL to LVDS. I don't want to spoil your learning experience by pointing you to the answer. See if you can figure it out what I am describing, and let me know if you cannot. Hint: there is a TI app note :)  Cheers, Dave

[Altera_Forum]

--- Quote Start ---   (we also bodged a 2kohm resistor on two vias under the fpga)  now we just need to get the sync right and we can start moving data!  dave, thank you so much, we have been stuck on this issue for two weeks!  --- Quote End ---    Nice work!  Don't ever get frustrated by these types of problems. These are actually the *best* type of problems to have.  For example, would you have ever read the data sheet properly if you didn't have this issue?  Now when you interface between two standards, you will know to look at the common-mode voltage (and the peak-to-peak voltage).  Good luck with your testing!  Cheers, Dave

[Altera_Forum]

Hey dave, might there be a chance that you help us again? 

 it seems that now we keep getting random noise on one of the parallel output bits, it keeps chaging where this "noise" appears bit-wise but it is always there, it comes to the point where I send A5 and the receivier gets "A4" constant and then randomly the LSB jumps to '1' for a bit and then falls again.  do you have any idea about this?  thanks again,  Maor.