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

--- Quote Start ---

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?

--- Quote End ---

Perhaps you have the receiver CDR in lock-to-reference mode?

The CDR PLLs are supposed to be started in lock-to-reference (LTR), and then transitioned to lock-to-data (LTD). If you've left your receiver in LTR mode, then it might work sometimes, but not others.

Cheers,

Dave

hey dave, let me tell you what my partner and I did so far:

-we had the CDR set to LTD constant(is this bad?)

-we tried a loopback, my partner told me the data came in correct just shifted(the PMA and PCS layers of the transceiver are okay, which was what I was worried about).

-we changed the capacitor to a lower value ( was 0.1uf, changed to 2nf)

-we tried numerous code methods (8b\10b, different word alignments, constant data, counters)

none of these worked, the strange loss of data is still there, but since the loopback proved the altgx fabric is fine (unless I'm wrong and it's not a reference to prove that.), we can assume this is still a physical issue.

something I'm worried about is the distance of the AC coupling capacitors from the FPGA, it's quite a long distance(see image) and I think this might be an issue for AC-coupled high data rates.

--- Quote Start ---

we had the CDR set to LTD constant(is this bad?)

--- Quote End ---

Technically speaking, it would be impossible to set the CDR in this manner. The CDR can operate in AUTO or MANUAL mode. In AUTO mode, it starts out in LTR and then automatically transitions to LTD. In manual mode you have to implement the transition. The fact that you are not saying things like this makes me wonder if its not implemented quite correctly. (Note: that I'm saying this based on my recent tests with the S4GXDK, but I also did similar tests on the Cyclone IV GX Starter kit, so I'm pretty sure the same comments apply).

--- Quote Start ---

-we tried a loopback, my partner told me the data came in correct just shifted(the PMA and PCS layers of the transceiver are okay, which was what I was worried about).

--- Quote End ---

Ok, I assume this was the internal loopback option.

--- Quote Start ---

-we changed the capacitor to a lower value ( was 0.1uf, changed to 2nf)

-we tried numerous code methods (8b\10b, different word alignments, constant data, counters)

none of these worked, the strange loss of data is still there, but since the loopback proved the altgx fabric is fine (unless I'm wrong and it's not a reference to prove that.), we can assume this is still a physical issue.

something I'm worried about is the distance of the AC coupling capacitors from the FPGA, it's quite a long distance(see image) and I think this might be an issue for AC-coupled high data rates.

--- Quote End ---

Its probably not the location of the capacitors that is the issue, but perhaps the is the transition into those capacitors created by soldering them to the board per the photo you sent previously. Keep in mind that you've taken nice 100-Ohms differential traces and broken them out into wires "hanging in the breeze". While this works fine for frequencies up to a few 100MHz, its a bit sketchy at high frequency :)

Try a test where you reduce the data rate. If you have an oscilloscope that operates up to 1GHz or maybe 2GHz, try to drop the data rate so that you can look at the signals with an oscilloscope.

If you're at a university, then ask around and see who has nicer test equipment. I am sure you can ask someone to probe your board and show you what the signals look like at the pins of the FPGA.

That might yield a little insight as to your issue.

Cheers,

Dave

Well dave,

we ran it for a long time at 600Mbps running an AAh signal and it is quite clear with no noise, we will try to run the a5h and read what the scope says.

any way, what is our options here?

I was thinking we short the the pads and cut the traces near the the old termination resistor and place the caps there, might that help?

--- Quote Start ---

I was thinking we short the the pads and cut the traces near the the old termination resistor and place the caps there, might that help?

--- Quote End ---

Yes, if you can create a nice transmission-line like environment for the coupling capacitors, then it should work at higher frequency.

Cutting the differential traces, scraping off the solder-mask, and soldering 0102 or 0204 or 0402 capacitors in-line with the old traces would result in the least impact. Try not to short the differential signals together though :)

Cheers,

Dave

hey dave!, it's the last week of our project, we have 5 days to finish the project let me bring you up to speed:

so we managed to get someone good enough to bodge 0402's on the end of the transmission lines and we managed to get a good stable link.

the problem now is that we still get odd jitters once in a while, data is kept stable for a while and then out of nowhere goes insane for one or two cycles and goes back.

we went back to basic and sent a simple counter through the optical line and we got this:

https://www.alteraforum.com/forum/attachment.php?attachmentid=7097

as you can see dave, the lsb seems to latch on for 3 cycles every 8 cycles. now I think this issue becomes greater when the data is a bit less "stable" and now we have no idea how to fix this.

my assumption is that it might be an issue that the 8b/10b can repair, can you confirm my assumption? and if so, do you happen to have any material I can browse to find how the hell you work with it? :oops:

I can't seem to find anything useful or thourgh online, and just placing the 8b/10b encoder gives me a constant 9Ch output(I think that means 'sequence' from what I manged to find) and when we reset the board we get a bit of 'error' packets and then it goes back to a constant 9Ch.

thank you so much for you help so far dave, we couldn't have progressed without your assistance!

--- Quote Start ---

it's the last week of our project, we have 5 days to finish the project let me bring you up to speed:

--- Quote End ---

Yikes! That doesn't give you much time!

--- Quote Start ---

I think this issue becomes greater when the data is a bit less "stable" and now we have no idea how to fix this.

my assumption is that it might be an issue that the 8b/10b can repair, can you confirm my assumption?

--- Quote End ---

You cannot use an AC-coupled link without ensuring there are enough "toggles" on the data going over the link.

--- Quote Start ---

I can't seem to find anything useful or thourgh online, and just placing the 8b/10b encoder gives me a constant 9Ch output(I think that means 'sequence' from what I manged to find) and when we reset the board we get a bit of 'error' packets and then it goes back to a constant 9Ch.

--- Quote End ---

I haven't used the 8/10B encoders on the transceivers, sorry. My tests use PRBS modulation to send data over the link. I'd recommend creating an ALTGX/ALTGX_RECONFIG combo with 8/10B encoding enabled and simulating it in Modelsim. It shouldn't take too long to figure out how to get data transferred over the link. If I recall correctly, the fabric interface is 8-bits plus a control flag.

--- Quote Start ---

thank you so much for you help so far dave, we couldn't have progressed without your assistance!

--- Quote End ---

You're welcome. Good luck with your project presentation.

Cheers,

Dave