Hi,i have a design with jesd204b interfacing adc device, but after upgrading to quartus 19.2, the sync signals seems to assert and deassert all the time.i re-generated all of the ip's.what could have gone wrong? nothing else has changed in the design.Thanks.

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,Its "Analog Devices" AD9689.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.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...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_busy3. 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

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

11 Replies

CheepinC_altera
Regular Contributor
5 years ago
Hi,
Thanks for your update. From the latest signaltap, I can see that there is no anomaly with the CDR. It is still maintaining lock-to-data mode through the sync_n toggling. I have had discussion with Factory on this and this observation seems to be something new to them.
Just would like to check with you on the following:
1. Just wonder if you have IPS access? As per discussion with Factory, they think that it would be great if we can continue to work this out through IPS.
2. If you does not have IPS access, probably you can engage with your local FAE to assist you to open a case.
3. Can you share with me the actual signaltap file? I would like to zoom in further to see if there is any anomaly on the data received to see if can spot any anomaly.
4. Just would like to check with you if this observation (16.2 pass, 19.2 fail) occurs across all boards or only specific board?
5. Just would like to check with you if this observation can be consistently replicated in the failing board?
Please let me know if there is any concern. Thank you.
Best regards,
Chee Pin

Forum Discussion

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

11 Replies

Recent Discussions

Can't generate F-Tile Ethernet Hard IP Design Example

Agilex 7 slew rate reconfiguration

Constraints not being picked for DCFIFO

Cyclone 10 GX IBIS-AMI models

F-Tile Ethernet Hard IP (100G)