Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorCYCLON 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_ForumAre 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
