- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi CHebl,
where can I download this "ug_jesd204b" from Intel web ? I wanto have a study of this as well. Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The document can be found here (JESD204B Intel FPGA IP User Guide):
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_jesd204b.pdf
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hie,
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.
Regards,
Nathan
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page