Jesd204b interface seems to misbehave after upgrading quartus from 16 to 19

Hi,

As I understand it, you observe some sync issue with the JESD204B in Q19.2. There seems to be no issue when you are using Q16.0. To ensure we are on the same page, just would like to check with you on the following:

1. What is the specific device that you are using with the IP?

2. Would you mind to further elaborate on the sync toggling issue? Probably some screenshots with explanation will be helpful to further understand the observation.

3. Just would like to check with you if you have had a chance to try with Modelsim simulation simulation to see if similar issue occur? This is helpful to isolate out functional issue in 19.2.

4. Mind share with me the .qsys or .ip file of your JESD IP so that I can have better understanding on your configuration.

5. I understand that you have regenerated the IP. Just wonder if you have had a chance to review the SDC to see if there is any update required as mentioned in the IP user guide -> "Timing Constraints For Input Clocks".

6. Would you mind to signaltap on the signals as mentioned in the IP user guide -> "PHY Status Signals for All Supported Devices Except Intel Stratix 10 E-tile Devices" to see if there is any anomaly.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

Hi,

1. Its "Analog Devices" AD9689.
2. I can't tell much at the moment, i can only say that the sync signal is deasserting in a very short periods of time. if you can tell me what signals to look for i can do a more-intensive tests. as for screen shots, im not sure i will be able to supply them, but if you can address me to which signals to look for i could have more data about this.
3. i don't currently have a simulation of the IP itself. im assuming it should work since it worked with previous quartus version. were there any changes to the ip that could actually account to a functional difference? i checked the release notes, its didn't seemed to have anyting about such a functional diffrence...
4. its not gonna be easy to get the qsys file out to send, maybe ill be able to get it, how ever, i can say that iuts set to be just a reciever, with subcalss 1, Enabled Soft PCS and that the PLL/CDR Clock is 220. if you have any question about a specific parameter, let me know.

about 5,6 - thanks you very much, i wasn't aware for these sections in the guide. ill check these right away and let you know.

Thanks.

Hi,

Thanks for your update. Please see my responses as following:

1. Mind let me know which FPGA device that you are using to interface with the ADC?

2. When you refer to sync signal toggling, mind let me know which specific sync signal that you are referring to ie from the JESD204B IP?

3. For the screenshot, signaltap and .qsys or QAR file, you may send through email to me if there is any concern posting it to the Forum. I will send you an email and your may reply to that. Please share with me further on the issue observation so that I can have a better understanding on your sync issue.

4. As for the Modelsim simulation, it is recommended for you to perform a loopback using duplex mode JESD204B IP to further narrow down the issue. If issue occur even with loopback, then we could isolate the external device.

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

Hi,

the device is Arraia 10.

once i was going through the signals in signal tap and on the timing constraints described in the jesd204b ip pdf file, i noticed that the signals "rx_is_lockedtoref" droppes every now and then for at least one of the lanes (could change after shutting off and back of the device). after making sure the constraints match the definitions in the pdf file (put them in a different clock group) and re-apply some attributres ("set_global_assignment GLOBAL_SIGNAL GLOBAL_CLOCK" on several clocks, including those from the jesd204 pll ip) rx_is_lockedtoref seems to be stable at "f" (all ones)

the issue im seeing now, is that still, dev_sync_n signals drops for about 50 clocks all the time, after that the signals alldev_lane_aligned, dev_lane_aligned and jesd204_rx_link_valid deasserts one after the other for some reason.

as much as i know this is not the right behaviour for my setup.

ill see if i can get the qsys or signaltap image out, but chances are slim. for qar there's no chance at all. anyway - this may take a while.

any thuoghts so far? is there any other thing i can test ?

Thanks.

Hi,

Thanks for your update. Based on your observation, it seems like the RX has lost or could not achieve synchronization.

Just would like to check with you on the following:

1. Can you please to perform a Modelsim simulation to isolate any functional issue. It is recommended for you to perform a loopback using duplex mode JESD204B IP to further narrow down the issue. If issue occur even with loopback, then we could isolate the external device.

2. Please share with me the status of the following signals in your signaltap:

rx_is_lockedtodata

rx_analogreset

rx_digitalreset

rx_cal_busy

3. Just wonder when you perform a reset, at which stage is your signaltap different from the expected timing diagram as in "JESD204B Link Initialization" in the IP user guide?

Please let me know if there is any concern. Thank you.

Best regards,

Chee Pin

Hi again,

sorry for the delay..

1. as for the modelsim simulation, its a work in progress. there's should be something ready here, im looking for it for further testing.
2. rx_is_lockedtodata is at 'F', all the rest at '0' (to be exact, there are two jesd rx items in this design, one of them somtimes fails to lock to ref clock. turning the board on and off a few time seems to solve this issue for now)
3. please send me a mail, i got the qsys and signal tap of the "link initialization" from figure 33 to transfer to you.

Thanks

Hi,

Thanks for your update. I have sent you an email.

Regarding the unable to lock to refclk issue, just would like to check with you which specific signals are you monitoring to tell unable to lock to refclk?

Regarding the issue seems to be resolved after ON/OFF the boards a few times, the following are a few possible causes:

1. Signal integrity issue - you might need to further look into the refclk signal input to the FPGA pin to ensure it is meeting the refclk input requirement as in the datasheet. You can probe the signal using oscilloscope.

2. refclk - It would be great if you could check the signal using oscilloscope when issue occurs to check on the frequency. This is to ensure the frequency is correct and stable.

3. power up calibration - refclk need to be stable and free-running. The refclk should be stable before device power up to ensure power up calibration is completed successfully.

Please keep me posted on the loopback test in the Modelsim for single duplex instance.

Thank you.

there's a signal inside the ip, called "...|inst_phy|inst_xcvr|rx_is_locktoref[3..0]", which should be "F" but not always.

i know there used to be issues here previously but they were solved and everything is working with quartus 16.2

i used to have parameters regarding iopins (OUTPUT_IO_TIMING_NEAR_END_VMEAS and OUTPUT_IO_TIMING_FAR_END_VMEAS, set to "HALF VCCIO" and "HALF SIGNAL SWING" for both rise and fall)

both parameters are not being supported in quartus 19.2, so removed.

could these signals have anything to do with the system not working?

im stating this since everything seemed to work just fine with this project when compiled using quartus 16, i know there can't be anything too bad with the circuitry itself, since i can still switch back to quartus 16.2 and everything is working

I don't know if ill be able to get those test with the oscilloscope done but ill try to, and again - i don't think there's anything too bad since its working with quartus 16 ...

Thanks.

Hi,

Thanks for your update. I have taken a look into the signaltap that you shared. I can see that the rx_dev_sync_n seems to be de-asserted which trigger a new round of link initialization. The lane alignment achieved but after sometime, the rx_dev_sync_n seems to be de-asserted again. From the signaltap, I could not spot any anomaly which could lead the rx_dev_sync_n de-assertion.

It could be either an unexpected reset to the IP or the XCVR lose lock. To facilitate further debugging, would you mind to add the following signals to the SignalTap to check on RX PHY:

rx_is_lockedtoref

rx_is_lockedtodata

rx_analogreset

rx_digitalreset

rx_analogreset_stat

rx_digitalreset_stat

rx_cal_busy

Please let me know if there is any concern. Thank you.

Hi,

Regarding the parameters ie OUTPUT_IO_TIMING_NEAR_END_VMEAS, these are for GPIO pins which generally should not affect the XCVR operation or the JESD IP. The parameters seems to be for output pin only.

Please let me know if there is any concern. Thank you.