FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5920 Discussions


New Contributor I

I'm currently trying to implement a loop back test using the JESD204B IP Core on an Arria 10 module.

The core is configured to run with a reference clock of 100 MHz and a data rate of 6000 Mbps. I provide a 100 MHz device clock externally and route it through an internal PLL to generate the frame and link clock of same frequency. The device clock is free-running and permanently connected to the JESD-IP-Core, while all other clocks can be held in reset through the PLL.


After asserting all resets, I go through the "wake up"-sequence of the core, which is described in ug_jesd204b p. 71 and p. 73.

After making sure both link and frame clock are stable i deassert the XCVR-Reset and shortly after the PLL locked signal goes high. What baffles me is, that even though avs, link and frame reset are still active (low), the pcfifo_full of the RX channel and pcfifo_empty of TX channel get asserted. These flags aren't getting cleared after going through the complete reset sequence and thus the link is not valid after completing the sequence (according to the documentation of rx_err0 in the RX register map), even though the valid signals are being asserted.

The reset-sequence is completely controlled via a program running in Linux on the HPS, so reset durations shouldn't be a problem.

I've attached a CSV with hopefully all the relevant waveforms from the logic analyzer.

reset_out0 is the reset for the frame and link clock PLL and reset_out1 is the reset for the XCVR reset controller.

Many thanks for your help.

0 Kudos
4 Replies
New Contributor I

hi CHebl,


where can I download this "ug_jesd204b" from Intel web ? I wanto have a study of this as well. Thanks

New Contributor I

The document can be found here (JESD204B Intel FPGA IP User Guide):


New Contributor I

In the Intel Arria 10 Transceiver PHY User Guide on p. 79 and p. 80 it is written, that the mentioned flags can be ignored. This is conflicting to mentioned documentation of the register maps of the JESD-IP Core.

Can I still ignore these flags?

Also my problems might be due to SYNC~ being asserted before SYSREF has been registered and thus after LMFC alignment SYNC~ gets asserted.

Now I'm going to look into why the CGS completes in Subclass 1 Mode without SYSREF being registered.


The PHY Guide can be found here:





The csr_pcfifo_full_err are debug registers that

are when rx_err is observed. This are not direct status flags but registered; hence it might not be cleared until CSR registers are configured. Please check if the CSR registers are configured. Hence, I will not recommend to ignore this flags.

Anyway the Arria 10 Phy user guide mentioned when using enhanced PCS, you can ignore the Phase Comp FIFO flag signal when used in Phase Comp FIFO mode. JESD IP does not use the Enhanced PCS hence its not contradicting between JESD IP user guide and Arria 10 Transceiver Phy user guide.


Please use the csr_sysref_lmfc_err ro check whether SYSREF period matches the LMFC period.


Even in Subclass 1, CGS will completed as long as Rx able to see K28.5 character. As long as sync_n is deasserted, sysref is provided to converter and JESD204B IP, the Rx can start looking for K28.5 and completed CGS.