- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have been trying to set up the GTS PMA/FEC Direct on the Agilex 5 and would like to know how to stream parallel data to/from the GTS when the GTS does not expose a AV-Sink/Source on the parallel data interfaces?
A pic of the IP for reference:
Thanks!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for filing this case and sharing the details. I appreciate your patience. Please allow me some time to review the information, and I’ll get back to you as soon as possible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thank you for your question regarding streaming parallel data to/from the GTS PMA/FEC Direct PHY in Agilex 5.
As I understand it, you're working with the GTS PHY, which provides a native parallel data interface. To stream data, you’ll need to directly interface with the i_tx_parallel_data and o_rx_parallel_data buses. These are accompanied by their respective parallel clocks: i_tx_coreclkin for transmit and o_rx_clkout for receive. I believe you are using Platform Designer to instantiate this PHY IP. Please note that parallel data are conduit ports, and you’ll need to export them and connect at the top-level RTL of your design manually.
For more detailed information on how the parallel data is mapped for both TX and RX paths, I recommend referring to the GTS Transceiver PHY User Guide under the section titled “Parallel Data Mapping Information for TX and RX.”
Please let me know if you have any further questions. Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks @CheePin_C_Intel
This is super useful - much appreciated. Actually yes, I do have a question on both the input and output parallel data lines for the GTS:
CLOCKING:
If I wanted to feed/read the input parallel data line (i_tx_parallel_data/o_rx_parallel_data) with, for instance, some basic oscillating component (feed) or some basic sampling component (read) - what clock should I power the oscillating/sampling unit with? Should it be with the same refclock that clocks the GTS (cdr_refclk, pll_refclk, refclk_xvcr)? Or should it be with the system clock that clocks the HPS? Or something else?
BIT MAPPING:
In this configuration map, I assume that the Lower and Upper Data bits are up to the user to set - so I am wondering how to use the 79 and 38 bits?
Many thanks!
Kai
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Regarding your inquiry about the appropriate clock signals for sampling parallel data into and out of the GTS PHY, please refer to the following recommendations:
1. o_tx_clkout
Connect this clock to the component that provides data to i_tx_parallel_data. Additionally, connect o_tx_clkout to i_tx_coreclkin to ensure that both the input data and the internal parallel logic of the GTS PHY operate within the same clock domain.
2. o_rx_clkout
Connect this clock to the component responsible for sampling data from o_rx_parallel_data. Also, connect o_rx_clkout to i_rx_coreclkin to maintain clock domain consistency on the receive path.
Please let me know if you have any further questions or concerns. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah ok I understand now - thanks!
On the o_rx_clkout side:
It seems that the mSGDMA is required to be on the same clock domain as the component which is sampling from o_rx_parallel_data (named here as raw_to_stream) and so I have set it up as shown - will this cause issues when issuing the DMA commands from the HPS?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Just to add on, you may refer to the GTS Transceiver PHY User Guide: Agilex 5 FPGAs and SoCs -> "Table 55. Recommended Connection and Source" for further details on the coreclkin & clkout connection.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ah - thank you again! Does there also include a place to explain how to connect resets for the o_tx_clkout / o_rx_clkout components?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
By the way, just wonder if you have had a chance to take a look at the example designs supported by the GTS XCVR PHY? You may refer to the GTS Transceiver PHY User Guide: Agilex 5 FPGAs and SoCs -> "Table 87. Example Design Options", for the list of available example designs. Then generate one which is closest to your target configuration to check on the PHY configuration and interconnection.
Please let me know if you have any further questions or concerns. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi yes I did see this - after compilation, you can see here that after performing these commands in section 6.6:
% run_test_silb
-----------------------------------------------------------
-----------------------------------------------------------
Link is not UP
-----------------------------------------------------------
Apply RX reset: 0x00000022
Number of lanes : 1
1. 0x6A040
2. 0x0006a040
Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000
1. 0x62040
2. 0x00062040
Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000
Release reset: 0x00000000
Number of lanes : 1
Serial loopback on Lane# 0 is enabled
PHY IP Setting : 0x0002c067
Scratch Register : 0x00000000
Soft Rst Crtl : 0x00000000
TX/RX/AVMM Ready : 0x00000010
TX PLL Locked : 0x00000001
CDR LTR & LTD : 0x00000001
RX ignore LTD : 0x00000000
Alarm status : 0x00000000
-----------------------------------
Value from issp reset probe is 0x45/0b1000101
--------------------------
Test Fail : Check the Link Status
--------------------------
--------------- SILB TEST DONE ----------------
Apply RX reset: 0x00000022
Number of lanes : 1
1. 0x0A040
2. 0x0000a040
Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000
1. 0x02040
2. 0x00002040
Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000
Release reset: 0x00000000
Number of lanes : 1
Serial loopback on Lane# 0 is disabled
Maybe you have seen such an error before?
Many thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Regarding your specific question about whether this might cause issues when issuing DMA commands from the HPS:
"will this cause issues when issuing the DMA commands from the HPS?"
I’m afraid this falls outside my area of expertise, so I’m unable to provide a reliable answer.
Would you mind opening a new thread on the Forum specifically for this inquiry? That way, our relevant experts can take a closer look and assist you more effectively.
Please let me know if you have any concerns. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have opened a thread on this topic here
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Regarding your following question about the reset, would you mind to further elaborate on what is referred by o_tx_clkout or o_rx_clkout components?
"Does there also include a place to explain how to connect resets for the o_tx_clkout / o_rx_clkout components?"
Please let me know if you have any concerns. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So for instance, as you expained earlier in the thread, the component that is sampled by the GTS would be clocked by o_tx_clkout, and the component that samples from the GTS would be clocked by o_rx_clkout.
In a diagram:
Now, there are also resets which I assume are controlled via these components, or am I incorrect?
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Regarding your run with the example design, could you please let me know which specific design from Table 87: Example Design Options you are using? I’d like to ensure we’re on the same page before providing further comments.
Please feel free to reach out if you have any concerns. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for your update. Regarding the example design, just wonder if you could test with a simpler example design ie "1 x 1G PMA Direct Mode (System PLL Clocking) with Custom Cadence" to facilitate debugging. This design is running at lower data rate. You can first try running the simulation and then only on hardware.
Please let me know if you have any concern. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Thanks for your update. As I compared your Terminal printout when running the example design, I notice some discrepancies between yours vs the one shown in the user guide.
Yours:
% run_test_silb
-----------------------------------------------------------
-----------------------------------------------------------
Link is not UP
-----------------------------------------------------------
Apply RX reset: 0x00000022
Number of lanes : 1
1. 0x6A040
2. 0x0006a040
Polling Successfull Bit 15: 0x000001 , Bit 14: 0x000000
1. 0x62040
2. 0x00062040
Polling Successfull Bit 15: 0x000000 , Bit 14: 0x000000
Release reset: 0x00000000
Number of lanes : 1
Serial loopback on Lane# 0 is enabled
PHY IP Setting : 0x0002c067
Scratch Register : 0x00000000
Soft Rst Crtl : 0x00000000
TX/RX/AVMM Ready : 0x00000010
TX PLL Locked : 0x00000001
CDR LTR & LTD : 0x00000001
RX ignore LTD : 0x00000000
Alarm status : 0x00000000
The one from user guide:
I observed:
Few discrepancies that I observed:
1. Your test starts with "Apply RX reset: 0x00000022" seems only resetting the RX while the example in UG starts with "Apply TX-RX reset: 0x00000033 "
2. In your case, the TX/RX/AVMM Ready : 0x00000010 but the one in the UG = 0x00000030. As I understand it from the main.tcl, we will need the value of 0x00000030 to declare the link up.
puts "-----------------------------------------------------------"
if {$phy_reset_status_reg==0x30} {puts "Link is UP"} {puts "Link is not UP"}
puts "----
3. In your case, the "CDR LTR & LTD : 0x00000001 " but the one in the UG = 0x00010001. In your case, the CDR has not yet achieved LTD state, this is indicated by the bit[16] = 0.
Can you help to look into these discrepancies and cross check with your test case to see if can give further clue.
Another thing to double check with you is it that you are running the example design on Agilex 5 FPGA ESeries 065B Premium Development Kit (ES1) board? If not, then you may also need to double check on the pin assignment.
Please let me know if there is any concern. Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @CheePin_C_Intel,
I am running the example design on this board.
I have changed the pin assignments in parameter.tcl.
I have not changed any other pins - should I have?
Many thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Just to add that in case you are not using the devkit as mentioned in the user guide, then you should also take note of the following steps from user guide before starting your own pin assignment:

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page