Forum Discussion
Altera_Forum
Honored Contributor
13 years agoCYCLON IV GX - ALTGX Won't recieve any valid data
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?
27 Replies
- Altera_Forum
Honored Contributor
-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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
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
Honored Contributor
--- 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
Honored Contributor
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
Honored Contributor
--- 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